Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
The App crashes as soon as its uploaded, or started:
I/monodroid-gc( 973): environment supports jni NewWeakGlobalRef
W/monodroid-gc( 973): GREF GC Threshold: 46800
E/mono ( 973):
E/mono ( 973): Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object
E/mono ( 973): at (wrapper dynamic-method) object.fcb335d2-dcb2-4b48-86a1-3920f8c64df5 (intptr,intptr) <0x00000>
E/mono ( 973): at (wrapper native-to-managed) object.fcb335d2-dcb2-4b48-86a1-3920f8c64df5 (intptr,intptr) <0x00033>
E/mono ( 973):
It works fine in android 2.3 and 4.0 for x86.
Which Mono for Android version?
What's your app do? I'm unable reproduce the crash with the HelloWorld sample; are you?
If HelloWorld works on your emulator, could you attach a minimal test case that crashes at startup?
Created attachment 2384 [details]
Crashing Project - Hello World
Mono for Android: 188.8.131.52234518
It's not just my app, its any apps or code. Its also happening with the hello world sample.
For the record, when I said its happening in the x86 devices / emulators, its basically, an x86 virtual machine instance running in virtualbox.
The interesting thing is, I don't experience any issues what so-ever with the same setup when the virtual machine is for android x86 running 2.3, nor 4.0, it's currently only happening with version 4.0.3.
Just to be complete here, this link here shows a good guide to get an x86 version of android running in virtualbox: http://www.buildroid.org/blog/?page_id=121
The real problem is that I didn't properly read the subject of this bug, which is that the app fails to launch if the shared runtime is disabled for Debug builds.
Fixed in 57488e13.
In the meantime, Don't Do That. Why would you want fast deployment enabled with the shared runtime disabled, anyway? I'm not sure I understand that use-case...
Well, the issue isn't so much with Debug builds, but as the subject says, with Release builds.
Surely that's a valid use case?
Release builds are not a valid use case; the Project Options dialog says:
[ ] Use Fast Deployment (debug mode only)
The "debug mode only" means Debug builds only, not Release builds.
Using Fast Deployment with Release builds is not a supported combination, as it doesn't make sense: the point to Release builds is a unified package that you can (plausibly) provide to Google Play, Amazon Appstore, side-loading via a web-site, etc. "Fast Deployment" means "don't embed assemblies into the .apk, install them separately as part of the IDE install process." This is completely contrary to the "single-file/no dependencies" purpose for Release builds.
Sorry, I probably did not explain correctly. Now as far as I know it, Fast deployment only applies to debug builds, im not talking about Debug builds at all, im referring to Release. If I left the project I uploaded in Debug mode, sorry, for that.
The issue is, I do a release build for any app, for x86, for android 2.2, it works, android 4.0 it works, but not for android 4.0.3.
w = works
f = fails
|Android 2.2 | Android 4.0 | Android 4.0.4
shared mono runtime == true | w | w | w
shared mono runtime == false | w | w | f
Now correct me if I'm wrong, but what you want to send to google or amazon, or whatever, is the version where shared mono runtime == false, i.e. the app is not using shared mono run time, meaning its all in the same package, right?
This is the problem here, I'm unable to do that for Android 4.0.4.
Now Fast Deployment, is greyed out for Release builds, so I'm assuming It doesn't matter what it is set to for release, it is not used, right?
For the record I've not ever touched Fast deployment in any of these tests.
Correction: Its not Android 4.0.4 but Android 4.0.3 :)
I feel like I really need to work on my own reading comprehension...
I may have figured it out. It's a "configuration" issue -- your .csproj doesn't provide a <AndroidSupportedAbis/> element for the 'Release|AnyCPU' configuration. The result is that your Release build gets the default ABIs, which is only armeabi.
$ unzip -l bin/Release/mono.samples.helloworld-Signed.apk | grep lib/
2788712 08-22-12 11:57 lib/armeabi/libmonodroid.so
The result is that when I install a Release build of your app, the `adb logcat` output contains:
> I/ActivityThread( 1710): Pub mono.samples.helloworld.mono.MonoRuntimeProvider.__mono_init__: mono.MonoRuntimeProvider
> D/AndroidRuntime( 1710): Shutting down VM
> W/dalvikvm( 1710): threadid=1: thread exiting with uncaught exception (group=0xb412f180)
> E/AndroidRuntime( 1710): FATAL EXCEPTION: main
> E/AndroidRuntime( 1710): java.lang.UnsatisfiedLinkError: Couldn't load monodroid: findLibrary returned null
> E/AndroidRuntime( 1710): at java.lang.Runtime.loadLibrary(Runtime.java:365)
The fix (for me) was to add 'x86' to the list of Supported ABIs for your Release configuration, then rebuild + reinstall the app.
What's odd is that your original report didn't include the above logcat output, and the logcat output from your original report can't possibly be generated unless lib/x86/libmonodroid.so is present within the .apk!
So either I'm still unable to reproduce your exact scenario, or something else is going wrong...
Returning to the original report, try this:
adb shell setprop debug.mono.log all
Then re-run the app, and attach the (hugely long) `adb logcat` output.
Next, where are you getting an Android 4.0.3 x86 image? My Android SDK Manager has:
Android 4.0.3 (API 15)
Intel x86 Atom System Image API=15 Rev=1 Status=Installed
Furthermore, my Android Virtual Device Manager has:
AVD Name: Android-v15-x86
Target Name: Android 4.0.3
API Level: 15
CPU/ABI: Intel Atom (x86)
That said, when I launch my emulator, I get version 4.0.4, not 4.0.3!
$ adb -e shell getprop ro.build.version.release
Just so we're on the same page, what's the ro.build.version.release of your emulator?
Finally, this is how I'm building and installing, from the command line on OS X:
xbuild /t:Install *.csproj /p:Configuration=Release /p:AdbTarget=-e
Created attachment 2397 [details]
Hugely Long ADB Output :D
I've attached the adb output you wanted.
Here's ro.build.version.release of my device:
$ adb -e shell getprop ro.build.version.release
I build and install the project using the "Start program without debugging" button in MonoDevelop.
Next, where are you getting an Android 4.0.3 x86 image?
Its not an x86 image like you get from Google, I don't use those at all as I've found the standard android emulator way too slow for use.
I'm running a virtual machine instance of android using virtualbox. The thing is, as far as MonoDevelop is concerned, it's like running it on a real device, or as close to the fact, right? My guess is that if you were to run this on a real device, you would get the same behaviour I'm seeing. I'm not able to verify that hypothesis, because I don't actually have a device laying about :P
I got my Android "emulator" image here, using the instructions there, as well as some of my comments on that page:
Regarding the Google image, if you have an Intel CPU you can drastically speed up the emulator by using IntelHAXM:
Thank you for the log output. It certainly suggests that the correct libmonodroid.so is being installed and is executing.
The odd part is this:
> I/monodroid-assembly( 1053): open_from_update_dir: loaded assembly: HelloWorld.dll
That should only be printed if (1) there is an "update dir" (/data/data/your.package.name/flies/.__override__), and (2) the update dir contains HelloWorld.dll, NEITHER of which should be true for Release apps.
Are you sure this is a Release app? This is getting quite confusing...
Thus, two more questions:
(1) What are the contents of your .apk?
> $ unzip -l bin/Release/mono.samples.helloworld-Signed.apk
> Archive: bin/Release/mono.samples.helloworld-Signed.apk
> Length Date Time Name
> -------- ---- ---- ----
> 1280 08-22-12 11:57 META-INF/MANIFEST.MF
> 1401 08-22-12 11:57 META-INF/ANDROIDD.SF
> 782 08-22-12 11:57 META-INF/ANDROIDD.RSA
> 520 08-22-12 11:55 res/layout/main.xml
> 1992 08-22-12 11:55 AndroidManifest.xml
> 1144 08-22-12 11:55 resources.arsc
> 3966 08-22-12 11:55 res/drawable-hdpi/icon.png
> 1537 08-22-12 11:55 res/drawable-ldpi/icon.png
> 2200 08-22-12 11:55 res/drawable-mdpi/icon.png
> 158644 08-22-12 11:57 classes.dex
> 4096 08-22-12 11:57 assemblies/HelloWorld.dll
> 438784 08-22-12 11:57 assemblies/Mono.Android.dll
> 1275392 08-22-12 11:57 assemblies/mscorlib.dll
> 11776 08-22-12 11:57 assemblies/System.Core.dll
> 354304 08-22-12 11:57 assemblies/System.dll
> 156160 08-22-12 11:57 assemblies/Mono.Security.dll
> 2788712 08-22-12 11:57 lib/armeabi/libmonodroid.so
> 2767184 08-22-12 11:57 lib/armeabi-v7a/libmonodroid.so
> 3273444 08-22-12 11:57 lib/x86/libmonodroid.so
> -------- -------
> 11243318 19 files
Notice that in my output there are lots of assemblies within the Release .apk. Does your .apk contain the assemblies? (I added <AndroidSupportedAbis>armeabi,armeabi-v7a,x86</AndroidSupportedAbis> to my Release|AnyCPU .csproj section, which is why there are three libmonodroid.so files present.)
(2) Let's enable even more logging, then re-run and attach the logcat output ;-)
adb shell setprop debug.mono.env MONO_LOG_LEVEL=debug
Created attachment 2399 [details]
Even More Logging
Yes, positive I'm still doing a release build. Like I said before, I can do this and it works for 2.2, 4.0 but not 4.0.3, not changing anything at all in the project between builds and doing a clean build in each case.
I've attached even more logging.
Yeah my unzipped apk looks identical to yers:
unzip -l bin/Release/mono.samples.helloworld-Signed.apk
Length Date Time Name
-------- ---- ---- ----
1280 08-23-12 16:54 META-INF/MANIFEST.MF
1401 08-23-12 16:54 META-INF/ANDROIDD.SF
782 08-23-12 16:54 META-INF/ANDROIDD.RSA
520 08-22-12 16:00 res/layout/main.xml
1992 08-22-12 16:00 AndroidManifest.xml
1144 08-22-12 16:00 resources.arsc
3966 08-22-12 16:00 res/drawable-hdpi/icon.png
1537 08-22-12 16:00 res/drawable-ldpi/icon.png
2200 08-22-12 16:00 res/drawable-mdpi/icon.png
158644 08-23-12 13:27 classes.dex
4096 08-23-12 16:54 assemblies/HelloWorld.dll
436224 08-23-12 16:54 assemblies/Mono.Android.dll
1032704 08-23-12 16:54 assemblies/mscorlib.dll
11776 08-23-12 16:54 assemblies/System.Core.dll
259072 08-23-12 16:54 assemblies/System.dll
5120 08-23-12 16:54 assemblies/Mono.Security.dll
2791968 08-23-12 16:54 lib/armeabi/libmonodroid.so
2770488 08-23-12 16:54 lib/armeabi-v7a/libmonodroid.so
3275428 08-23-12 16:54 lib/x86/libmonodroid.so
10760342 19 files
The APK file looks ok at least, so thats something ;D
This is looking like something I'll need to debug locally; thank you for your assistance.
Unfortunately I can't provide a timeframe on that investigation. In the meantime I would suggest using the accelerated Android emulator.
Thanks Jon ;)
I get the exact same crash on a real x86 Android device.
->Shared Runtime == false -> crash with n_Activate(...)
->Shared Runtime == true -> works
Both are release builds, only shared runtime checkbox differs.
This only happens on current x86 firmware. Older ones work ok.
Some hints may be:
The latest x86 image has removed some memcopy safeguards (older images checked for source/destination overlaps and corrected them).
Maybe it has something to do with this?
Tested with current "Xamarin.Android 4.6.04000 (03814ac5)".
Did your research lead to anything?
Created attachment 3962 [details]
Mini logfile of program startup and crash
This also happens with current alpha:
Attached logfile for verification.
I was unable to find VirtualBox Android images for v4.0.3 (the URL in comment 2 no longer works) but I did test it in the Google Android emulator with the 4.0.3 x86 image and the test app works just fine there. As such, I'm closing this bug in hope that it never comes back :)
Tested with monodroid/master, commit ab8f5949bf6f54ce79266ca54fe94045710c0fe6