Forum Xamarin.Android

Announcement:

The Xamarin Forums have officially moved to the new Microsoft Q&A experience. Microsoft Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

To create new threads and ask questions head over to Microsoft Q&A for .NET and get involved today.

App Crashes After Installation on Android 2.3 Phone

I have two Android phones, one is 4.2.1 and the other is 2.3.1. I can debug on both with no problem. But when I create a package and install it manually, the app crashes on the 2.3.1 phone. It crashes no matter if the Mono libraries are installed or not. I have set the Target Framework in the Project's Options to Android 2.3 (Gingerbread). I also tried a fully signed and published version. The app installs fine but when you try to start it, it crashes immediately. The Gingerbread version does work fine on the 4.2.1 phone though. I have installed and executed successfully a similar app on the 2.3.1 phone using Eclipse. Any ideas what I'm doing wrong or am I missing a step or two?

Posts

  • rmaciasrmacias USBeta, University ✭✭✭✭✭

    I would run the android debug monitor. You can start it by running the following *.bat file.

    C:\Users\UserName\AppData\Local\Android\android-sdk\tools\monitor.bat
    
    • Where UserName is your login name.

    From there you should be able to see your plugged in devices. Select the device and start your app. Look at the LogCat and it will show you any errors that are happening. You can go from there. If you're having trouble deciphering the LogCat, post it here.

  • Below is the LogCat. What's interesting is that I successfully installed and executed the same package on another 2.3.6 phone albeit one that had more memory. But on the one that is failing I am able to debug the app on it. You can see from the LogCat it looks like there's a problem with the Mono libraries. Any thoughts?

    LogCat:

    06-28 20:47:28.680: E/AndroidRuntime(1479): FATAL EXCEPTION: main
    06-28 20:47:28.680: E/AndroidRuntime(1479): java.lang.UnsatisfiedLinkError: Couldn't load monodroid: findLibrary returned null
    06-28 20:47:28.680: E/AndroidRuntime(1479): at java.lang.Runtime.loadLibrary(Runtime.java:429)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at java.lang.System.loadLibrary(System.java:554)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at mono.MonoPackageManager.LoadApplication(MonoPackageManager.java:24)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at mono.MonoRuntimeProvider.attachInfo(MonoRuntimeProvider.java:22)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at android.app.ActivityThread.installProvider(ActivityThread.java:3557)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at android.app.ActivityThread.installContentProviders(ActivityThread.java:3312)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3268)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at android.app.ActivityThread.access$2200(ActivityThread.java:117)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:972)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at android.os.Handler.dispatchMessage(Handler.java:99)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at android.os.Looper.loop(Looper.java:130)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at android.app.ActivityThread.main(ActivityThread.java:3686)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at java.lang.reflect.Method.invokeNative(Native Method)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at java.lang.reflect.Method.invoke(Method.java:507)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:625)
    06-28 20:47:28.680: E/AndroidRuntime(1479): at dalvik.system.NativeStart.main(Native Method)
    06-28 20:47:28.690: E/(126): Dumpstate > /data/log/dumpstate_app_error
    06-28 20:47:37.989: E/msm7k.gralloc(126): [unregister] handle 0x4296a0 still locked (state=40000001)

  • rmaciasrmacias USBeta, University ✭✭✭✭✭

    On the failing device, have you tried uninstalling all mono libraries and runtimes? And then installing the *.apk afterwards? Also, is the *.apk built for RELEASE?

  • Yes, I uninstalled all Mono libraries and runtimes and the app is built for release. It did install just fine on another 2.3.6 version phone which never had Mono installed. Don't know what is different with the phone that crashes. As a last resort I can reset the phone back to factory settings and see if that makes any difference. Anything to check or log before I do this?

  • I solved the problem.

    First, I reset the phone to factory settings just to verify that it wasn't something already installed. In hindsight I did not need to do this but it was a spare phone (Samsung M580 Replenish)

    Next I deployed the app to the phone from the IDE (Xamarin Studio) in Release mode and got the following deployment errror:

    "The package does not support the device architecture (armeabi)."

    So I went into Project Options / Android Build / Advanced and checked the 'armeabi' box. After this the Release package worked.

    After doing some research on what 'armeabi' is, it looks like the reason it wasn't working is that the Replenish uses an ARM processor and the other phone a Cortex processor, with the ARM processor not supporting armeabi-v7a.

    I created a package with both armeabi and armeabi-v7a and the package size grew a little over 1 MB. I wonder which is the best strategy to support all Android phones - to create on application that is a little larger, or have two packages and somehow have the user install the correct one, or just use armeabi and forget about the benefits of v7a. Any thoughts on this?

  • rmaciasrmacias USBeta, University ✭✭✭✭✭

    If package size is an concern, create two versions. One that supports armeabi and the other that supports armeabi-v7a. If it is not that much of a concern, support both. It is recommended that you support armeabi-v7a though. Among other things, it contains extra floating point cpu instruction sets, which increases the performance of your application.

Sign In or Register to comment.