NoSuchFieldException with AtomicReferenceFieldUpdater on Samsung Android 5.0.x devices

[asfdfdfd]

This is known error.

Some libraries have not done anything (google/gson#924) other ones have implemented workaround (ReactiveX/RxJava#3459).

Couple of stacktraces from my project:
com.mirrorai.app_issue_crash_5D5E4CFA0353000119B5FCFF34F93B11_DNE_0_v2.txt
com.mirrorai.app_issue_crash_5D61DBF600A40001134DD9BDD9BD8B29_DNE_0_v2.txt

I'm not convincing you to implement workaround like RxJava did but i think that at least it will be convenient to keep this issue to prevent questions from other users of coroutines library.

Proguard is turned off.

Coroutines version is 0.24.0.
Kotlin version is 1.2.60.

[elizarov]

Let's discuss how we might approach working around this problem. We don't directly use Atomic*FieldUpdater classes. We rely on https://github.com/kotlin/kotlinx.atomicfu to "include" them via bytecode transformation. It is relatively straightforward for us to create a new transformation variant that changes atomic fields to a regular Atomic* classes. But how do we deliver the corresponding binaries? I see two options:

1. Deliver a single multi-release jar that have "Samsung-friendly" classes (using only Atomic*) in the main code and VarHandle version in META-INF/version/9 for server-side folks running on JDK 9+.

Pro: Everything works for everybody by default.
Con: Anyone running on JDK 8 or anyone targeting non-affected Android >5.0 will get slightly worse performance than they have now(sic!), because of additional dereference in Atomic* classes versus optimized Atomic*FieldUpdater code that we have now.

2. Deliver a single multi-release jar that have Atomic*FieldUpdater classes in the main code and VarHandle version in META-INF/version/9 and a separate "Samsung-fiendly" jar file with a different classifier.

Pro: By default if you depend on kotlinx-coroutines-core:<version> you get the best possible performance for your platform.
Con: If you target Android <= 5.0 with affected devices, you'll have to specify kotlinx-coroutines-core:<version>:samsung-workaround in your dependencies (might need a better name for a classifier).

What do you think?

[elizarov]

Additional question: Anyone knows more details on the conditions under which Samsung devices crash with Atomic*FieldUpdater? What if we make those fields public, for example? Would it help? Are there any details on what exactly is broken on those Samsung Android 5.x devices?

[LouisCAD]

It seems it happens on Samsung Android 5.0.x, not 5.x. If I'm not mistaken, the issue title should be edited accordingly.

Regardless, I think @digitalbuddha may have some additional information (or not) about this issue, he said he reached out to Samsung.

[digitalbuddha]

I was never able to get any info from Samsung as to why this issue occurred. Once rxjava applied their fix we never saw issue again

[LouisCAD]

I strongly dislike the idea of making kotlinx.coroutines performance worse on all devices and JDK < 9 projects just because Samsung f*****d up.

Android app bundles may, probably with Google's collaboration, support different compiled code for different android versions. If this can be done in some way, then apps published with app bundles may use a version free of problematic code for API 21 devices, and use the regular version for all other versions (API 20 and lower, and API 22 and up).

This would work with the second option @elizarov mentioned.

I know this is more complex than the RxJava approach, but it's less compromising.

Another solution is to compile a version of the app with the samsung workaround with a minSdk and a maxSdk of 21, and publish two other versions, one for maxSdk 19 (20 being Android Wear…), and one for minSdk 22. But here again, I think it should be automated using app bundles (which can probably be extended since they use protobuf internally), so we don't have to manage three different version codes.

Where I'm starting to wonder how a samsung api 21 workaround version would work though, is when it comes to libraries. I don't want to have to publish multiple versions of my android libraries that use kotlinx.coroutines because of Samsung, and I would even less want to do it on a non Android library. Would there be a way to avoid transitive dependencies hell when using the samsung workaround?

[fvasco]

In the case 2, the kotlinx-coroutines-core:<version>:samsung-workaroundis the only viable option for an Android developer

[JakeWharton]

I continue to vote for doing nothing. This is not a library's problem.

If someone wants to fix this, write an Android Gradle plugin transform that bytecode-rewrites these into the slower format such that you fix all libraries at once and can opt-in and out based on things like minSdkVersion, splits, and bundles.

[LouisCAD]

@JakeWharton I think you're right. I just submitted an issue on Android's issue tracker for this fix to be integrated into Android Gradle plugin: https://issuetracker.google.com/issues/112526256

[JakeWharton]

That's not quite what I said... AGP already has a pluggable bytecode transformation model so this doesn't need to (and likely won't) be implemented by Google. Anyone can do this who is willing. Samsung should do it, actually.

[LouisCAD]

Google certified these devices, and Samsung didn't even respond to Mike when he was working for New York Times.

So "anyone" willing can do it (as long as you are fluent in bytcode among other things), yes.
However, I think at the moment, only Google can integrate such a solution targeting only certain devices with app bundles, so other devices (or other API levels at least) don't pay the performance hit.

[JakeWharton]

Transforms have access to variant information so again I disagree and hope the Android Gradle team doesn't do it. Variants have the API information which is the best you'll get in terms of targeting. It has nothing to do with app bundles other than that makes it easier to deal with the API splits.

[LouisCAD]

hope the Android Gradle team doesn't do it

Why so?