-
Notifications
You must be signed in to change notification settings - Fork 526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DirectBoot execution fails with java.lang.UnsatisfiedLinkError #2081
Comments
I am having the same issue, on Huawei P20 Lite. Did you find some workaround? |
No, nothing. just waiting for any response before I can implement the feature that I want to add |
Ok, so after digging deeper, I've discovered that the mono stuff defined in So basically to fix this, Xamarin.Android project properties should offer some DirectBootAware option and when activated, all those providers/receivers etc. should use the This seems to be mostly related to a file Meanwhile, would you be able to help us with some workaround? I tried to add So please, would you know of any other way how to force the |
And just to explain why all of this matter - since Android 7.0, an alarm clock app needs to use DirectBootAware, because if user sets an alarm and the device restarts itself (for whatever reason) during the night, the alarm will fail to go off, because the device is booted in a locked state and only DirectBootAware apps can do anything in this state. About 50% Android users are on 7.0+, so this might affect a lot of people who use Xamarin-built alarm clock apps. Of course, the DirectBootAware does not apply only to alarm clocks, other types of apps might use it as well. |
Here is a simpler workaround until we can get some code into a release.
Just drop this xml into the bottom of your |
@rihadavid a quick question. I'm in favour of the automatic detection of the The question is, is searching for the
[1] https://developer.android.com/guide/topics/manifest/application-element |
"You can pick the subset of your app components that need to be Direct Boot aware, but if you are using a custom Application class, it is assumed to be Direct Boot aware if any component inside your app is marked as Direct Boot aware." So, unless the directBootAware is added automatically to a custom Application class during build time (which I am not sure), it should not rely on the application element because developer might read this and do not add the directBootAware to the custom Application class. |
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`.
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`.
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`.
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`.
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`.
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/
…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/
#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/
When trying to use any Xamarin tool in the DirectBoot pre-login session I get:
Steps to Reproduce
logcat
and you'll find the error aboveAlso raised this issue against the sample dotnet/android-samples#277, but it looks more like a Xamarin bug to me.
https://developer.xamarin.com/samples/monodroid/android-n/DirectBoot/DirectBoot.zip
Expected Behavior
To be able to use DirectBoot like other apps can. I've been able to use native apps like google clock and they work fine.
Actual Behavior
Xamarin actions such as simple notifications do not fire and an error is logged
Device
My phone is a Huawei Honor 9 with Android 8.0.0
Version Information
Microsoft Visual Studio Enterprise 2017
Version 15.8.1
VisualStudio.15.Release/15.8.1+28010.2003
Microsoft .NET Framework
Version 4.7.03056
Installed Version: Enterprise
Application Insights Tools for Visual Studio Package 8.13.10627.1
Application Insights Tools for Visual Studio
ASP.NET and Web Tools 2017 15.8.05074.0
ASP.NET and Web Tools 2017
ASP.NET Core Razor Language Services 15.8.31590
Provides languages services for ASP.NET Core Razor.
ASP.NET Web Frameworks and Tools 2012 4.0.30625.0
For additional information, visit https://www.asp.net/
ASP.NET Web Frameworks and Tools 2017 5.2.60618.0
For additional information, visit https://www.asp.net/
Azure App Service Tools v3.0.0 15.8.05023.0
Azure App Service Tools v3.0.0
C# Tools 2.9.0-beta8-63208-01
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.
Cookiecutter 15.8.18201.1
Provides tools for finding, instantiating and customizing templates in cookiecutter format.
GitHub.VisualStudio 2.5.4.3349
A Visual Studio Extension that brings the GitHub Flow into Visual Studio.
JavaScript Language Service 2.0
JavaScript Language Service
JavaScript Project System 2.0
JavaScript Project System
JetBrains ReSharper Ultimate 2018.1.4 Build 112.0.20180731.142027
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2018 JetBrains, Inc.
Merq 1.1.38 (5b3c069)
Command Bus, Event Stream and Async Manager for Visual Studio extensions.
Microsoft Azure Tools 2.9
Microsoft Azure Tools for Microsoft Visual Studio 2017 - v2.9.10730.2
Microsoft Continuous Delivery Tools for Visual Studio 0.4
Simplifying the configuration of continuous build integration and continuous build delivery from within the Visual Studio IDE.
Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines
Microsoft Library Manager 1.0
Install client-side libraries easily to any web project
Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers
Microsoft Visual Studio Tools for Containers 1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.
Mono Debugging for Visual Studio 4.11.7-pre (8955b2a)
Support for debugging Mono processes with Visual Studio.
Node.js Tools 1.4.20802.1 Commit Hash:97e1085d8b4b8e3e51c398e910177f87e86d135e
Adds support for developing and debugging Node.js apps in Visual Studio
NuGet Package Manager 4.6.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.
Open Command Line 2.1.216
Opens a command line at the root of the project. Support for all consoles such as CMD, PowerShell, Bash etc. Provides syntax highlighting, Intellisense and execution of .cmd and .bat files.
ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed Info
Python 15.8.18201.1
Provides IntelliSense, projects, templates, debugging, interactive windows, and other support for Python developers.
Python - Django support 15.8.18201.1
Provides templates and integration for the Django web framework.
Python - IronPython support 15.8.18201.1
Provides templates and integration for IronPython-based projects.
Python - Profiling support 15.8.18201.1
Profiling support for Python projects.
R Tools for Visual Studio 1.3.40517.1016
Provides project system, R Interactive window, plotting, and more for the R programming language.
ResourcePackage Extension 1.0
ResourcePackage Visual Studio Extension Detailed Info
ResourcePackage Extension 1.0
ResourcePackage Visual Studio Extension Detailed Info
Snapshot Debugging Extension 1.0
Snapshot Debugging Visual Studio Extension Detailed Info
SQL Server Data Tools 15.1.61808.07020
Microsoft SQL Server Data Tools
TypeScript Tools 15.8.20801.2001
TypeScript Tools for Microsoft Visual Studio
Visual Basic Tools 2.9.0-beta8-63208-01
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Visual F# Tools 10.2 for F# 4.5 15.8.0.0. Commit Hash: c55dd2c3d618eb93a8d16e503947342b1fa93556.
Microsoft Visual F# Tools 10.2 for F# 4.5
Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio
Visual Studio Tools for Containers 1.0
Visual Studio Tools for Containers
VisualStudio.Mac 1.0
Mac Extension for Visual Studio
WiX Toolset Visual Studio Extension 0.9.21.62588
WiX Toolset Visual Studio Extension version 0.9.21.62588
Copyright (c) .NET Foundation and contributors. All rights reserved.
Xamarin 4.11.0.732 (d15-8@33e83e124)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.
Xamarin Designer 4.14.218 (79f535bdd)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.
Xamarin Templates 1.1.113 (e1d02a7)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.
Xamarin.Android SDK 9.0.0.18 (HEAD/3d8a28f1a)
Xamarin.Android Reference Assemblies and MSBuild support.
Xamarin.iOS and Xamarin.Mac SDK 11.14.0.13 (373c313)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
The text was updated successfully, but these errors were encountered: