Android TargetApi annotation and the Just-In-Time compiler

Question

I'm including Android Beam support for our app. But because we're still support 2.2 * cough cough die froyo, die gingerbread, cough * I've packed all the NFC code in the class NfcHandler with the TargetApi annotation to avoid lint warnings like this:

    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    public class NfcHandler implements NfcAdapter.CreateNdefMessageCallback

then from the MainActivity during onCreate I build the object if necessary like this:

    if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH)
        nfcHandler = new NfcHandler(this);

in the constructor it does all the necessary NFC stuff and later in the code if( nfcHandler != null ) I pass the intent to it, so it can check if it's receiving a beam.

All good and great and it works most of the time. But in rarely occasions Gingerbread devices crash with:

10-22 16:08:01.022 1734-1734/com.baseapp.eyeem.p0 E/dalvikvm﹕ Could not find class 'com.baseapp.eyeem.os.NfcHandler', referenced from method com.foo.MainActivity.onCreate

I mean, the class does exist and it's just a null object of it there.

Because our app on XXHDPI devices is 23mb and on the ldpi Gingerbread 5mb, I can see that the Just in time compiler (JIT) or some other runtime optimization is deleting the unnecessary resources. I wonder if it could be the same case of my NfcHandler class, because it's annotate for ICE_CREAM_SANDWICH it deletes it.

So the question is:

• what is happening actually happening and why am I getting this crash just once in a while and not every time?

Answer 1

I mean, the class does exist and it's just a null object of it there.

NfcAdapter.CreateNdefMessageCallback was added in API Level 14. Hence, it is not possible for Dalvik on older devices to load it successfully, as it will fail to resolve that interface.

Now, in principle, Dalvik should never try to load your NfcHandler handler class on Gingerbread devices, if the code snippet you show above is the only place that you are referring to it, or if all other occurrences have the same if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) Java version guard block defending it.

What it suggests is that on these devices, Build.VERSION.SDK_INT is not returning the expected value, either because of a firmware bug or, conceivably, something some rooted device user did to tweak their environment.