[Xamarin.Android.Build.Tasks] Add directBootAware if needed. (#2621)
#2637
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
…t#2621) Fixes: dotnet#2081 Context? http://work.devdiv.io/727120 The [`//application/@android:directBootAware`][0] attribute *changes* how process startup semantics work, in [non-obvious ways][1]. Consider the following: 1. Start with an Android v7.0 Nougat device. 2. Build, Install, & Run the [Direct Boot Sample][2] 3. Create an alarm within the Direct Boot Sample app. 4. Reboot the Android device. 5. Wait for the alarm to go off without unlocking the device. Expected results: An alarm goes off. Actual results: Nothing happens, and `adb logcat` contains: java.lang.UnsatisfiedLinkError: No implementation found for void mono.android.Runtime.register(java.lang.String, java.lang.Class, java.lang.String) (tried Java_mono_android_Runtime_register and Java_mono_android_Runtime_register__Ljava_lang_String_2Ljava_lang_Class_2Ljava_lang_String_2) at mono.android.Runtime.register(Native Method) at md511db93b05d0fbee144be45ad6fb54d50.BootBroadcastReceiver.(BootBroadcastReceiver.java:15) at java.lang.Class.newInstance(Native Method) at android.app.ActivityThread.handleReceiver(ActivityThread.java:3671) ... One of the apparent changes when `directBootAware` is used is that `<provider/>`s must *also* "opt-in" to `directBootAware`. If a `<provider/>` *isn't* also `directBootAware`, then the `<provider/>` can't be used before the device is unlocked. Our Bootstrap code within `MonoRuntimeProvider` is "injected" via `<provider/>`. Meaning if the app uses `directBootAware` but the `MonoRuntimeProvider` *isn't* `directBootAware`, then the app can't use any managed code before the device has been unlocked. Which is why the `UnsatisfiedLinkError` is generated: the `MonoRuntimeProvider` hasn't been created, meaning `mono` hasn't been initialized, meaning nothing can work *until the device is unlocked*. The fix? If *anything* within `AndroidManifest` sets `//*[@android:directBootAware='true']`, then add a `@android:directBootAware="true"` attribute to the generated `<provider/>` for `mono.MonoRuntimeProvider`. This will ensure that managed code is properly initialized and can execute after the device has been rebooted and before the user has unlocked the device. [0]: https://developer.android.com/guide/topics/manifest/application-element#directBootAware [1]: https://android-developers.googleblog.com/2016/04/developing-for-direct-boot.html [2]: https://developer.xamarin.com/samples/monodroid/android-n/DirectBoot/
jonathanpeppers
approved these changes
Jan 18, 2019
dellis1972
approved these changes
Jan 21, 2019
|
Hmm two build failures are we missing a commit from master I wonder? |
|
@dellis1972 asked:
Probably? Hopefully? However, the 'obvious' candidate for "missing commit" is PR #2598, which has been cherry-picked to d16-0. Additionally, the current d16-0 HEAD build has these same failures, so the failures were not introduced by this PR. Merging this PR for now, but we need to investigate & fix the failures on d16-0 pronto. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fixes: #2081
Context? http://work.devdiv.io/727120
The
//application/@android:directBootAwareattribute changeshow process startup semantics work, in non-obvious ways.
Consider the following:
Expected results: An alarm goes off.
Actual results: Nothing happens, and
adb logcatcontains:One of the apparent changes when
directBootAwareis used is that<provider/>s must also "opt-in" todirectBootAware.If a
<provider/>isn't alsodirectBootAware, then the<provider/>can't be used before the device is unlocked.Our Bootstrap code within
MonoRuntimeProvideris "injected" via<provider/>. Meaning if the app usesdirectBootAwarebut theMonoRuntimeProviderisn'tdirectBootAware, then the app can'tuse any managed code before the device has been unlocked.
Which is why the
UnsatisfiedLinkErroris generated: theMonoRuntimeProviderhasn't been created, meaningmonohasn't beeninitialized, meaning nothing can work until the device is unlocked.
The fix? If anything within
AndroidManifestsets//*[@android:directBootAware='true'], then add a@android:directBootAware="true"attribute to the generated<provider/>formono.MonoRuntimeProvider. This will ensure thatmanaged code is properly initialized and can execute after the device
has been rebooted and before the user has unlocked the device.