[Java.Interop-Tests] Add CreatePeer_ReplaceableDoesNotReplace test #1323
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Context: 3043d89 Context: dotnet/android#9862 Context: dotnet/android#9862 (comment) In dotnet/android#9862, there is an observed "race condition" around `Android.App.Application` subclass creation. *Two* instances of `AndroidApp` were created, one from the "normal" app startup: at crc647fae2f69c19dcd0d.AndroidApp.n_onCreate(Native Method) at crc647fae2f69c19dcd0d.AndroidApp.onCreate(AndroidApp.java:25) at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1316) and another from an `androidx.work.WorkerFactory`: at mono.android.TypeManager.n_activate(Native Method) at mono.android.TypeManager.Activate(TypeManager.java:7) at crc647fae2f69c19dcd0d.SyncWorker.<init>(SyncWorker.java:23) at java.lang.reflect.Constructor.newInstance0(Native Method) at java.lang.reflect.Constructor.newInstance(Constructor.java:343) at androidx.work.WorkerFactory.createWorkerWithDefaultFallback(WorkerFactory.java:95) However, what was odd about this "race condition" was that the *second* instance created would reliably win! Further investigation suggested that this was less of a "race condition" and more a bug in `AndroidRuntime`, wherein when "Replaceable" instances were created, an existing instance would *always* be replaced. Aside: JniManagedPeerStates.Replaceable is from 3043d89: > `JniManagedPeerStates.Replaceable` … means > that the Peer instance was created through the activation constructor. > It additionally means that if two managed instances are created around > the same Java instance, the non-Replaceable instance will be the one > returned by JniRuntime.JniValueManager.PeekObject(). What we're observing in dotnet/android#9862 is that while the Replaceable instance is replaced, it's being replaced by *another* Replaceable instance! This feels bananas; yes, Replaceable should be replacable, but only by *non*-Replaceable instances. Update `JniRuntimeJniValueManagerContract` to add a new `CreatePeer_ReplaceableDoesNotReplace()` test to codify the desired semantic that Replaceable instances do not replace Replaceable instances. Surprisingly, this does not fail on java-interop! Apparently `ManagedValueManager.AddPeer()` bails early when `PeekPeer()` finds a value, while `AndroidRuntime.AddPeer()` does not bail early.
jonpryor
added a commit
to dotnet/android
that referenced
this pull request
Mar 14, 2025
Context: dotnet/java-interop#1323 Context: #9862 (comment) Does It Build™? (The expectation is that it *does* build -- only unit tests are changed in dotnet/java-interop#1323 -- but that the new `JniRuntimeJniValueManagerContract.cs.CreatePeer_ReplaceableDoesNotReplace()` test will fail.)`
|
Write access |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: 3043d89
Context: dotnet/android#9862
Context: dotnet/android#9862 (comment)
In dotnet/android#9862, there is an observed "race condition" around
Android.App.Applicationsubclass creation. Two instances ofAndroidAppwere created, one from the "normal" app startup:and another from an
androidx.work.WorkerFactory:However, what was odd about this "race condition" was that the second instance created would reliably win!
Further investigation suggested that this was less of a "race condition" and more a bug in
AndroidRuntime, wherein when "Replaceable" instances were created, an existing instance would always be replaced.Aside: JniManagedPeerStates.Replaceable is from 3043d89:
What we're observing in dotnet/android#9862 is that while the Replaceable instance is replaced, it's being replaced by another Replaceable instance! This feels bananas; yes, Replaceable should be replacable, but only by non-Replaceable instances.
Update
JniRuntimeJniValueManagerContractto add a newCreatePeer_ReplaceableDoesNotReplace()test to codify the desired semantic that Replaceable instances do not replace Replaceable instances.Surprisingly, this does not fail on java-interop! Apparently
ManagedValueManager.AddPeer()bails early whenPeekPeer()finds a value, whileAndroidRuntime.AddPeer()does not bail early.