[Xamarin.Android.Build.Tasks] Add directBootAware if needed.
#2621
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
There was a problem hiding this comment.
In one of the comments on #2081 they linked to: https://android-developers.googleblog.com/2016/04/developing-for-direct-boot.html
That might be a good link to add to the commit message.
jonathanpeppers
approved these changes
Jan 16, 2019
|
build |
jonpryor
reviewed
Jan 17, 2019
jonpryor
reviewed
Jan 17, 2019
|
@dellis1972 one of the test failures on Windows seems new. It might be worth rebasing on master for the SwitchBetweenDesignTimeBuild test, too. |
Fixes dotnet#2081 If a user needs to use the `directBootAware` attribute on an `application`, `activity` or `service` we also need to include it on the `MonoRuntimeProvider` so that native libraries can be resolved correctly. Not doing so results in the following java.lang.UnsatisfiedLinkError: No implementation found for void mono.android.Runtime.register This commit looks to see if any elements in the manifest contain `directBootAware`. If there are , then we also include it in the `provider`.
jonathanpeppers
approved these changes
Jan 18, 2019
There was a problem hiding this comment.
The Windows test failure here should be fixed by: #2631
It is unrelated to this PR.
jonpryor
pushed a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jan 18, 2019
…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/
jonpryor
added a commit
that referenced
this pull request
Jan 21, 2019
#2637) Fixes: #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/
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
If a user needs to use the
directBootAwareattribute onan
application,activityorservicewe also needto include it on the
MonoRuntimeProviderso thatnative libraries can be resolved correctly. Not doing
so results in the following
This commit looks to see if any elements in the manifest
contain
directBootAware. If there are , then we alsoinclude it in the
provider.