PlatformDependent.resolveAndroidApiVersion() fails when running under Robolectric

[cesar1000]

PlatformDependent.resolveAndroidApiVersion() tries to determine the Android SDK version by reading the android.os.Build$VERSION#SDK_INT field:

        try {
            return (Integer) Class
                    .forName("android.os.Build$VERSION", true, getSystemClassLoader())
                    .getField("SDK_INT")
                    .get(null);
        } catch (Exception e) {
            // Can not resolve version of Android API, maybe current platform is not Android
            // or API of resolving current Version of Android API has changed in some release of Android
            return ANDROID_API_VERSION_IS_NOT_ANDROID;
        }

When running under Robolectric, the class will be found (since Robolectric bundles an original android.jar). However, the method is using the system class loader for loading it (instead of the Robolectric instrumenting class loader), which will not instrument the class to run in the JVM. As a result, static initialization of the class fails with an UnsatisfiedLinkError when calling SystemProperties.get(), which calls native method native_get.

PlatformDependent.resolveAndroidApiVersion() should use the default class loader or discard UnsatisfiedLinkErrors (or all throwables).

[akarnokd]

Thanks for reporting this. I don't know enough about the platform so PR welcome.

[cesar1000]

Sure.

[akarnokd]

If I remember correctly, this android check is used for setting the default buffer size to 16 on Android. I don't know how drastic would it be to use 128 (desktop default) from now on? Alternative would be to detect small max memory via some management bean.

[jwedel]

This is really a problem. Is there any progress or work-around? E.g. downgrading RxJava etc? Thx!

[cesar1000]

Sorry for the late reply.

@jwedel I patched by copying the android.os.Build class from the Android framework to my test source set. RxJava finds that instead and doesn't throw an exception.

@akarnokd The fix is straightforward: just catch Throwable instead of Exception. That'll cover the cases where the class can't be found (not Android) or the class can be found but not loaded (Robolectric). I'll send a PR.

[jwedel]

@cesar1000 Hi, thanks for your reply.
I copied the Build.java file from our Andoid 22 sdk source to test/android/os/Build.java. I see that this file is being used, but it still fails:

java.lang.UnsatisfiedLinkError: android.os.SystemProperties.native_get(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
	at android.os.SystemProperties.native_get(Native Method)
	at android.os.SystemProperties.get(SystemProperties.java:64)
	at android.os.Build.getString(Build.java:693)
	at android.os.Build.<clinit>(Build.java:38)
	at android.os.Build$VERSION.<clinit>(Build.java:152)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:348)
	at rx.internal.util.PlatformDependent.resolveAndroidApiVersion(PlatformDependent.java:69)
	at rx.internal.util.PlatformDependent.<clinit>(PlatformDependent.java:33)
	at rx.internal.util.RxRingBuffer.<clinit>(RxRingBuffer.java:246)
	at rx.Observable.observeOn(Observable.java:7613)

I see that the copied file is used.

[cesar1000]

@jwedel this is the class I used: https://gist.github.com/cesar1000/06139a68d5c062beaecbd26d52c3563d. You should put it under src/test/java/android/os in the module containing your tests.

[cesar1000]

One concern with addressing this issue by discarding the UnsatisfiedLinkError is that RxJava will not run in Android mode when under Robolectric. This feels wrong, since Robolectric is meant to simulate an Android environment in the JVM.

@akarnokd, the root cause of this problem is that using the system class loader fails when in Robolectric. I see that the code was copied from Netty. Do you know if using the system class loader for loading the class is strictly needed in this case? Using the default class loader would fix the bug here.

[akarnokd]

I don't know.

[cesar1000]

Ok, I'll do this: I'll try using the default class loader and validate both on an Android device and in Robolectric.

@benjchristensen, you added this code originally. Do you have any concerns about switching to using the default class loader instead of the system class loader for trying to load the Build$VERSION class on Android?

[akarnokd]

Ben is no longer active in this project and he may not answer.

[cesar1000]

Yeah, I thought it wouldn't hurt to try :). I'll test my changes locally. I suspect that using the default class loader will suffice for our purposes.