Bug 59070 - Launcher App : java.lang.UnsatisfiedLinkError: Couldn't load monodroid from loader dalvik.system.PathClassLoader
Summary: Launcher App : java.lang.UnsatisfiedLinkError: Couldn't load monodroid from l...
Status: NEEDINFO
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 7.4 (15.3)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2017-08-27 10:15 UTC by Hakan Çelik
Modified: 2017-08-29 17:56 UTC (History)
2 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
T110 Startup Log (749.71 KB, text/plain)
2017-08-27 10:15 UTC, Hakan Çelik
Details

Description Hakan Çelik 2017-08-27 10:15:12 UTC
Created attachment 24439 [details]
T110 Startup Log

I'm developing a kiosk application, which works as a launcher. I'm also using Samsung Knox Standard SDK.

The application is running on about 70 Samsung Galaxy Tab 3 Lite 7.0 (SM-T100) (http://www.gsmarena.com/samsung_galaxy_tab_3_lite_7_0-5969.php) tablets and also on some SM-T113 (http://www.gsmarena.com/samsung_galaxy_tab_3_lite_7_0_ve-7110.php) tablets which are a slightly upgraded version of the same. The real difference is T110 has Android 4.2.2 (API 17) and T113 has Android 4.4.4 (API 19).

I'm having this problem sporadically on T110s on system restart. In my experience T113s has never shown this error.

Environment:

Windows 10 Enterprise x64 : Version 10.0.15063 Build 15063
Microsoft Visual Studio Enterprise 2015 : Version 14.0.25431.01 Update 3
Microsoft .NET Framework : Version 4.7.02046
Xamarin : 4.6.0.297 (4a8abec)
Xamarin.Android : 7.4.0.19 (0cd0214)
Java : jdk1.8.0_112
Andorid SDK up to date

The problem :

Everything works normally, but time to time during a tablet restart, system tries to run my launcher (com.kripto.kpay) and an exception is thrown. User interface shows the standard "the xxx application stopped" error. 
Only way out I could find is to use the boot menu to factory reset the tablet.

The culprit :

I have managed to get all the logs during this occurence and the culprit seems to be the following excerpt. I'm attaching the whole log too.

08-26 13:34:58.773: E/AndroidRuntime(792): FATAL EXCEPTION: main
08-26 13:34:58.773: E/AndroidRuntime(792): java.lang.UnsatisfiedLinkError: Couldn't load monodroid from loader dalvik.system.PathClassLoader[dexPath=/data/app/com.kripto.kpay-2.apk,libraryPath=/data/app-lib/com.kripto.kpay-2]: findLibrary returned null
08-26 13:34:58.773: E/AndroidRuntime(792): 	at java.lang.Runtime.loadLibrary(Runtime.java:365)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at java.lang.System.loadLibrary(System.java:535)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at mono.MonoPackageManager.LoadApplication(MonoPackageManager.java:34)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at mono.MonoRuntimeProvider.attachInfo(MonoRuntimeProvider.java:22)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at android.app.ActivityThread.installProvider(ActivityThread.java:5067)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at android.app.ActivityThread.installContentProviders(ActivityThread.java:4679)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4592)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at android.app.ActivityThread.access$1400(ActivityThread.java:158)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1356)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at android.os.Handler.dispatchMessage(Handler.java:99)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at android.os.Looper.loop(Looper.java:176)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at android.app.ActivityThread.main(ActivityThread.java:5365)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at java.lang.reflect.Method.invokeNative(Native Method)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at java.lang.reflect.Method.invoke(Method.java:511)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)
08-26 13:34:58.773: E/AndroidRuntime(792): 	at dalvik.system.NativeStart.main(Native Method)


I have no idea what's going on here :( 
Any help would be highly appreciated.
Comment 1 Hakan Çelik 2017-08-27 11:32:37 UTC
I'm sorry, I have a typo in the second paragraph stating that the device is SM-T100. It should have been SM-T110.
Comment 2 Jon Douglas [MSFT] 2017-08-28 19:12:18 UTC
Thank you for your report!

The following logs:

08-26 13:34:58.773: E/AndroidRuntime(792): FATAL EXCEPTION: main
08-26 13:34:58.773: E/AndroidRuntime(792): java.lang.UnsatisfiedLinkError: Couldn't load monodroid from loader dalvik.system.PathClassLoader[dexPath=/data/app/com.kripto.kpay-2.apk,libraryPath=/data/app-lib/com.kripto.kpay-2]: findLibrary returned null

Tend to indicate that the libmonodroid.so is not being found. Why? I don't quite know yet.

When you create an APK, there are two main .so files created for your respective architecture:

1. libmonodroid.so (The glue/bridge)
2. libmonosgen-2.0.so (The runtime)

What should you check for? Double check that you are creating an APK with all of the proper architectures for these devices. I believe they are ARM / ARMv7 from a quick look at the chipsets. To ensure this, you can get the first supported ABI via:

String ABI = Build.SupportedAbis.FirstOrDefault();

Which might yield a result like: "armeabi-v7a"

However double check both of these devices are the same. You can also inspect the "Build.SupportedAbis" item to see the list based on preference (0 being preferred, last item being least preferred)

Secondly, you should get a copy of your APK that you are uploading to devices/play store/etc, and unzip it and look at your lib/ folder to ensure these libs exist for each architecture for your respective devices. You should see:

lib/armeabi-v7a

As most devices fallback on armeabi. Feel free to let us know what you find out!
Comment 3 Hakan Çelik 2017-08-29 17:56:24 UTC
Hello Jon, thank you for your time.

I thought, I should provide additional details, which might be useful for your analysis.

First of all this is an internal application which is side loaded to the devices. Then, when I update the app, the new apk is side loaded over the old one as well.

Since these devices support armeabi-v7a, I compile the apk only for that ABI.

This problem seems to happen after the app is updated, but not immediately. Non-updated devices didn't show this problem yet.

It seems that somehow app update process might be responsible for this.

On the other hand, I've checked the orgiginal version and the updated version by themselves on clean devices with no problem. I then updated the app, and restarted the device a few times. But I couldn't reproduce the problem.

Also, I've checked internal structures of the apks I produced. They all include ONLY the following in lib folder.

lib/armeabi-v7a/libmono-btls-shared.so
lib/armeabi-v7a/libmonodroid.so
lib/armeabi-v7a/libmonodroid_bundle_app.so
lib/armeabi-v7a/libmonosgen-2.0.so

If you think of something I can check or try please feel free to request it.

Thanks

Note You need to log in before you can comment on or make changes to this bug.