How quickly does Xamarin support new Android OS updates?

DavidSchwegler.8050DavidSchwegler.8050 USMember
edited December 2013 in Xamarin.Android

I'm a lead developer on my company's mobile team, and we're considering switching to Xamarin for the next version of our mobile apps.

One of the great things about Android is the ability to quickly iterate and release new functionality to customers when new OS versions are released. iOS takes longer with the app store, but even they provide ways of releasing updated apps when customers get the upgrades to their devices.

As such, I cannot emphasize how highly concerning it is that it appears Xamarin hasn't completed their KitKat support a month and a half after its release.

This raises serious concerns about the viability of utilizing Xamarin in a fast-paced market, and/or the commitment Xamarin has to Android.

Is it so difficult for Xamarin to update its code, or does Xamarin not allocate much resources to Android? Is this delay normal/to be expected? What sort of timetables should we expect for being able to release updated apps to our customers if we switch to Xamarin?

Thank you!

Edit: I just saw the blog post for the v7 support library...released by Xamarin 5 months after Android released it. Yikes...

Best Answers

Answers

  • GerryHighGerryHigh ✭✭✭ USBeta ✭✭✭

    @jonp Thanks for a quick response and openly sharing your pain and release issues with Android. I think it would help if your marketing statements were clearer on this. When people read:

    "Always up-to-date.
    Xamarin stays up-to-date with the latest APIs from Apple and Google. We released same-day support for iOS 7.

    "

    they hear the iOS story but wonder or assume incorrectly that Android will be the same as iOS.

    I will say that it does seem like your support 4.4 is much slower than past releases. Right now it is 6 weeks since kitkat came out and it sounds like it will be 8+ weeks for 4.4 support; With 4.3 it seemed to be within a few weeks but perhaps I am remembering it wrongly.

    Thanks-Gerry

  • What is preventing you from being an prerelease pdk partner?

    Also, is there a doc somewhere on what Xamarin does in order to provide support for an OS version?

    Thanks.

  • BrianBowmanBrianBowman USMember

    @jonp Thanks for your response. I am also evaluating Xamarin for my company and would like to echo the concerns of others here. I hope support for the latest Android OS versions can be prioritized higher in the future.

  • AndreasSelleAndreasSelle ✭✭ DEBeta ✭✭

    @jonp Will the next release also include support for the ART runtime? Currently all our apps crash when ART runtine is enabled, which already gave us several one star ratings in the Google Play Store.

  • CheesebaronCheesebaron mod DKInsider, University mod

    Afaik ART is only enabled through the developer options on the phone, if users are enabling this they are asking for instabilities.

    Miguel has said they are looking at ART, however there has been no information about if it will be supported right away.

  • JonathanPryorJonathanPryor Xamurai USXamarin Team Xamurai

    Will the next release also include support for the ART runtime?

    No.

    Miguel has said they are looking at ART

    Specifically, I have been looking at art. I am 99% sure that this is an ART bug, though it's taking me a minor eternity to create a small repro. I'm at the point of giving up on the "small" part of the repro.

    Why do I think it's an ART bug? Enable GREF logging, cause it to crash, and then look backwards for the offending GREF:

    I/monodroid-gref(19483): +g+ grefc 45 gwrefc 19 obj-handle 0x400003/W -> new-handle 0x20054e/G from take_global_ref_jni
    ...
    E/art     (19483): JNI ERROR (app bug): accessed deleted global reference 0x0020054e
    F/art     (19483): art/runtime/check_jni.cc:64] JNI DETECTED ERROR IN APPLICATION: native code passing in reference to invalid global reference: 0x20054e
    F/art     (19483): art/runtime/check_jni.cc:64]     in call to NewWeakGlobalRef
    F/art     (19483): art/runtime/check_jni.cc:64]     from void xamarin.android.nunitlite.TestSuiteInstrumentation.n_onStart()
    

    In the above, we're calling JNIEnv::NewWeakGlobalRef() as part of a GC, and the JNI handle passed into ART is 0x20054e. Note, however, that we never deleted that handle. (If we had, there'd be a -g- message for handle 0x20054e/G, which there isn't.)

    So I'm already immediately suspecting an ART bug.

    Then it gets even crazier, but some background: within ART, a JNI handle is a 32-bit value which contains three parts: a serial number, a table index, and the handle type (see ToIndirectRef() on indirect_reference_table.h line 337). This means there's structure to the handle, from which we can determine that our "bad" handle 0x20054e is GREF table index 339. Is GREF table index 339 used anywhere else?

    As it turns out, yes:

    I/monodroid-gref(19483): +g+ grefc 45 gwrefc 19 obj-handle 0x400003/W -> new-handle 0x20054e/G from take_global_ref_jni
    I/monodroid-gref(19483): +g+ grefc 46 gwrefc 18 obj-handle 0x300007/W -> new-handle 0x30054e/G from take_global_ref_jni
    I/monodroid-gref(19483): +g+ grefc 47 gwrefc 17 obj-handle 0x10000b/W -> new-handle 0x40054e/G from take_global_ref_jni
    I/monodroid-gref(19483): +g+ grefc 48 gwrefc 16 obj-handle 0x10000f/W -> new-handle 0x50054e/G from take_global_ref_jni
    I/monodroid-gref(19483): +g+ grefc 49 gwrefc 15 obj-handle 0x100013/W -> new-handle 0x60054e/G from take_global_ref_jni
    I/monodroid-gref(19483): +g+ grefc 50 gwrefc 14 obj-handle 0x100017/W -> new-handle 0x70054e/G from take_global_ref_jni
    I/monodroid-gref(19483): +g+ grefc 51 gwrefc 13 obj-handle 0x10001b/W -> new-handle 0x80054e/G from take_global_ref_jni
    I/monodroid-gref(19483): +g+ grefc 52 gwrefc 12 obj-handle 0x10001f/W -> new-handle 0x90054e/G from take_global_ref_jni
    

    What we have here is a bunch of JNIEnv::NewGlobalRef() calls to convert a JNI Weak ref into a JNI Global ref. For example, the first line is using weak ref 0x400003 and getting a GREF value of 0x20054e.

    However, now we bring on the crazy: all of those +g+ messages are GREF handles with the same JNI table index of 339 (which can be determined by hand by just reading the last 6 characters -- they all end in 0x0054e; the value before the 0x0054e is the serial number, not the table index).

    That's where I was last Friday. I've as yet been unable to create a small non-Xamarin-using sample. Argh.

  • AndreasSelleAndreasSelle ✭✭ DEBeta ✭✭

    @Cheesebaron But this doesn't prevent them to write 1-star troll reviews and effectively kill all App sales.

    :-(

  • JonathanPryorJonathanPryor Xamurai USXamarin Team Xamurai

    I am 99% sure that this is an ART bug

    I am absolutely sure it's an ART bug, which I've filed as Android issue 63929.

    The scenario is this: you have a Java weak reference to an object, then perform a GC. This should collect the referenced object.

    The problem is finding out that the instance has been collected. The proper way is to use JNIEnv::NewGlobalRef() over the weak reference, and JNIEnv::NewGlobalRef() should return NULL when the object has been collected.

    This is what Dalvik does.

    This is not what ART does. ART returns a non-NULL value from JNIEnv::NewGlobalRef() for instances which have been collected. The result is that our code to check for Java-side object invalidation is busted, and things get worse from there.

    It may be possible -- but unverified -- to use JNIEnv::IsSameObject() to also check for object invalidation, but as the docs point out, this is not thread-safe, and thus isn't adequate.

  • DavidSchwegler.8050DavidSchwegler.8050 USMember
    edited December 2013

    Wow, the Google ART team fixed the bug within 2hrs of your report -- good job on your research, Jon! :)

    To reiterate my earlier question -- what's preventing you guys from being pre-release partners?

  • GerryHighGerryHigh ✭✭✭ USBeta ✭✭✭

    @jonp Thanks for releasing KitKat support!
    http://docs.xamarin.com/releases/android/xamarin.android_4/xamarin.android_4.11/

    I've been doing iOS dev the last week or so and didn't notice when I got this update in the alpha channel.

  • GerryHighGerryHigh ✭✭✭ USBeta ✭✭✭

    @jonp So the docs are confusing--http://docs.xamarin.com/releases/android/xamarin.android_4/xamarin.android_4.11/

    Title says 4.12 but page is for 4.11?

    API Level changes only show for up to level 17.

    Also, it appears that Android.Provider.Telephony was not bound? Is it possible to find a list of what was bound?

    Thanks.

  • GerryHighGerryHigh ✭✭✭ USBeta ✭✭✭

    @Jonp can disregard my prior post--the new API works fine; I was compiling on a new machine and didn't have the latest SDK so my JNI code was blowing up; after figuring that out I switched back to the bound APIs and everything is good now.

    Thanks.

  • JonathanPryorJonathanPryor Xamurai USXamarin Team Xamurai

    Title says 4.12 but page is for 4.11?

    Common convention is that stable releases have a minor version number while unstable releases have an even minor version number.

    The version number will be bumped to 4.12 when it's ready for the beta channel.

    API Level changes only show for up to level 17.

    Thank you for mentioning this. This has been corrected.

  • MatteoNicolotti.3744MatteoNicolotti.3744 ✭✭ ITMember ✭✭

    I'm having this issue where during collection the app crashes with "JNI DETECTED ERROR IN APPLICATION: native code passing in reference to invalid global reference".
    If the issue is with the ART compiler can i be confident that future updates from Google will fix my app without the need to update it?

  • IliassIliass USMember

    Me too, having same issue
    03-22 20:42:25.077: E/art(5147): 0x41d8af40 large object space:GcRetentionPolicyAlwaysCollect 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] JNI DETECTED ERROR IN APPLICATION: native code passing in reference to invalid weak global reference: 0x300f07 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] in call to CallObjectMethod 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] from android.os.IBinder android.os.Parcel.nativeReadStrongBinder(long) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] "Binder_3" prio=5 tid=19 Runnable 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] | group="main" sCount=0 dsCount=0 obj=0x12c017c0 self=0x5f521910 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] | sysTid=5192 nice=0 cgrp=apps sched=0/0 handle=0x61945308 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] | state=R schedstat=( 25435000 19103000 171 ) utm=1 stm=1 core=0 HZ=100 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] | stack=0x78535000-0x78537000 stackSize=1012KB 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] | held mutexes= "mutator lock"(shared held) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #00 pc 00004ce4 /system/lib/libbacktrace_libc++.so (UnwindCurrent::Unwind(unsigned int, ucontext*)+23) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #01 pc 00003531 /system/lib/libbacktrace_libc++.so (Backtrace::Unwind(unsigned int, ucontext*)+8) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #02 pc 0023fdad /system/lib/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, int, char const*, art::mirror::ArtMethod*)+68) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #03 pc 00224f6f /system/lib/libart.so (art::Thread::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) const+146) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #04 pc 000b0443 /system/lib/libart.so (???) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #05 pc 000b0b7d /system/lib/libart.so (art::JniAbortF(char const*, char const*, ...)+60) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #06 pc 000b2f05 /system/lib/libart.so (???) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #07 pc 000b83bd /system/lib/libart.so (???) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #08 pc 000028fb /system/lib/libnativehelper.so (jniGetReferent+106) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #09 pc 00085e3f /system/lib/libandroid_runtime.so (android::javaObjectForIBinder(_JNIEnv*, android::sp<android::IBinder> const&)+74) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #10 pc 00080795 /system/lib/libandroid_runtime.so (???) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] native: #11 pc 00017641 /data/dalvik-cache/arm/[email protected]@boot.oat (Java_android_os_Parcel_nativeReadStrongBinder__J+88) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] at android.os.Parcel.nativeReadStrongBinder(Native method) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] at android.os.Parcel.readStrongBinder(Parcel.java:1607) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] at android.app.ApplicationThreadNative.onTransact(ApplicationThreadNative.java:665) 03-22 20:42:25.128: A/art(5147): art/runtime/check_jni.cc:65] at android.os.Binder.execTransact(Binder.java:446)

Sign In or Register to comment.