NoSuchFieldException on Samsung/5.0.x

[ppiech]

We're seeing a number of crashes related to use of Atomic*FieldUpdater. It's not a proguard issue, because decompiling the classes shows that proguard correctly updates the string used for reflection to match the renamed field. Also, the issue happens only on Samsung devices with 5.0.0, 5.0.1, and 5.0.2 firmware.

My best guess is that the art compiler on these devices incorrectly optimizes out the fields, which may appear like dead code if the Atomic*FieldUpdater usage is not accounted for. I tried a couple of experiments (https://github.com/ppiech/RxJava/commit/5abde3c5333edc699b7cfe4a32cb0f164b4634b7, https://github.com/ppiech/RxJava/commit/6703810ba36ff9d1b53029f8ad827948a80bc6b3) to see if I could avoid the crash by making the field public or referencing it in the class. The only thing that seems to work is converting the use of field updater to using AtomicLong/AtomicField/AtomicInteger.

Has anyone else observed these crashes, or has better ideas on how to work around them? Their incidence is high enough, that we can't just ignore them. Though eventually they will tail off as the devices get upgraded to 5.1+

[JakeWharton]

Since there's no use of the atomic field updaters in this repo, you'll want to communicate this upstream on the RxJava project where those types are actually used. In fact, there was a similar issue filed just recently at https://github.com/ReactiveX/RxJava/issues/3459.

[ppiech]

Thanks, i figured this was going to be specific to android.

[JakeWharton]

It is, but there's nothing we can really do about it unfortunately. It's important that the RxJava authors remain aware of the pain and problems of all platforms that they are targeting (and they are targeting Android with RxJava 1.x).