.NET 7 UnsatisfiedLinkError to native OnCreate() coming from Java Binding #8675
Comments
bloomer-joe
added
Area: App Runtime
|
@bloomer-joe could you try turning linking off (set the |
grendello
added
need-info
|
@bloomer-joe: a repro would also be handy. Full (-ish) The My suspicion is that
<provider android:name="mono.MonoRuntimeProvider" android:exported="false" android:initOrder="1999999999" android:authorities="Mono.Android.NET_Tests.mono.MonoRuntimeProvider.__mono_init__" />I see from the Java-side callstack that |
|
@grendello , I was thinking the same thing about the "PublishTrimmed" property, but modifying that did not change the outcome. A more complete logcat: |
microsoft-github-policy-service
bot
added
need-attention
|
@jonpryor , Update: I've been working through the steps you wrote. I am seeing "com.bloomerang.stripe.demo.mono.MonoRuntimeProvider.mono_init" That seems nominal though. |
|
Bump. I received approval to create a public repro. It may be a little while though. |
I am a team-mate of @bloomer-joe and have been following the issue, and trying to resolve it as well. I posted a repro-repo here and gave you access. I can add others or make it public if that helps. |
|
Here's a little more context from LogCat (before the error). It seems to be the case that a service is trying to start, and that service is what cannot find our app's Note: I did open the .dex files generated from our build with Android Studio, and was able to find |
|
@jasells: what do I need to do to repro the crash? Release config build of % cd Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android
% dotnet build -c Release -f
% adb install bin/Release/net7.0-android33.0/com.bloomerang.stripe.demo-Signed.apk
% adb shell am start com.bloomerang.stripe.demo/crc6443da931ec5bafba4.MainActivityImmediately launches -- no apparent crash -- and prompts me to allow the app to access device location (don't allow), then prompts to allow the app to find the position of nearby devices (don't allow), then re-asked access to location (?!) (don't allow), then re-asks for permission for the position of nearby devices (don't allow), and then I see a screen. How do I make this crash? |
I suppose maybe? Probably more 06b1d7f. However, as I can't repro the crash, I can neither confirm nor deny speculation. :-) If it is 06b1d7f, then setting But right now, we have no such indication. |
|
@bloomer-joe, @jasells: try this:
Then upload |
The crash (or, more precisely, the UnsatisfiedLinkError) occurs when attempting to enable/configure the NFC hardware, so by not allowing "position of nearby devices" you can't repro the issue, you must allow this permission, and in a RELEASE build. After allowing all the requested permissions, Stripe.Terminal SDK will attempt to initialize and configure the NFC radio from a service, which is when Android will show the "app stopped responding" pop-up, and you can find the error in logcat. I guess I may have hidden the Required Permissions in the Readme a little too far down... |
I can do that |
|
@grendello: this feels unrelated to 06b1d7f, and more related to the fact that their service is in a separate process: <activity android:name="my.Activity.Name" android:exported="false" android:process="com.excample.process_name" android:theme="@style/Theme.CotsApp">
<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
<service android:name="some.external.ServiceType" android:exported="false" android:process="com.excample.process_name" />Now that I know I need all the permissions -- my bad for not properly reading |
|
@jasells: thank you for the logs, and the info for how to repro locally. |
|
@grendello: about my prior suggestion that it's related to From We're getting messages from PID 29890. Lots of messages from PID 29890 (which is to be expected with Skip ahead to the Different PID! This is 30117. What else came from 30117? PID 30117 first appears on line 11561, and looking at lines that only pertain to PID 30117: …plus many more. However, of interest to me is that none of the messages from PID 30117 mention "monodroid". There is no equivalent to line 7481, or to line 19473: (which is probably a different attempt to run the main process.) In short, it doesn't look like the service process is invoking What's really interesting is that What's also interesting is that we don't appear to have a unit test that uses A(n) (untested) possibility is that the |
|
@jasells, @bloomer-joe, @grendello: On the assumption the [Activity(Label = "do not use", Exported = false, Process = "com.stripe.cots.aidlservice")]
public class JonpDummyActivity : Activity {
}After rebuilding, this results in a <provider android:name="mono.MonoRuntimeProvider" android:authorities="com.bloomerang.stripe.demo.mono.MonoRuntimeProvider.__mono_init__" android:exported="false" android:initOrder="1999999999" />
<provider android:name="mono.MonoRuntimeProvider_1" android:authorities="com.bloomerang.stripe.demo.mono.MonoRuntimeProvider_1.__mono_init__" android:exported="false" android:initOrder="1999999998" android:process="com.stripe.cots.aidlservice" />Additionally, when I run this app locally, I no longer get That's the good news. The bad news is that it still doesn't "work": …getting rather repetitive at this point. The good news is that I just have no idea why I can say that Perhaps we just need a reference to Xamarin.Google.Android.Play.Integrity? /me tries that… |
|
@jasells, @bloomer-joe: @jonpryor suggested:
After building it, It "works"…kinda. Patch: diff --git a/Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android/MainActivity.cs b/Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android/MainActivity.cs
index 7709385..6a51e35 100644
--- a/Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android/MainActivity.cs
+++ b/Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android/MainActivity.cs
@@ -88,4 +88,7 @@ namespace Stripe.Terminal.Demo.Droid
//}
}
}
+ [Activity(Label = "do not use", Exported = false, Process = "com.stripe.cots.aidlservice")]
+ public class JonpDummyActivity : Activity {
+ }
}
diff --git a/Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android/Stripe.Terminal.Demo.Android.csproj b/Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android/Stripe.Terminal.Demo.Android.csproj
index 86f145a..e1b7c5e 100644
--- a/Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android/Stripe.Terminal.Demo.Android.csproj
+++ b/Stripe.Terminal.Demo/Stripe.Terminal.Demo.Android/Stripe.Terminal.Demo.Android.csproj
@@ -71,6 +71,7 @@
<PackageReference Include="Xamarin.Android.ReactiveX.RxJava3.RxKotlin" Version="3.0.1.8" />
<PackageReference Include="Xamarin.Android.ReactiveX.RxKotlin" Version="2.4.0.8" />
+ <PackageReference Include="Xamarin.Google.Android.Play.Integrity " Version="1.2.0.3" />
<PackageReference Include="Xamarin.Google.Guava" Version="32.0.1" />
<PackageReference Include="Xamarin.AndroidX.DataBinding.ViewBinding" Version="8.0.0" />
However… It still crashes for me: I am not debugging an |
|
@dellis1972: notwithstanding all of the (very verbose) above, one thing currently feels "off" about all this. My previous comment noted the What's funny is that it looks like it should have been there? The build tree contains a But Why is that? Is that a bug? My (incomplete) memory forgetting something? |
|
TL;DR, we have (at least?) three TODOs here:
|
|
For the record, we are seeing that It does seem to be something in the native Stripe libs for this version (2.23.3). And we've found this post that seems to discuss the issue in the tape2 lib. From that thread, it looks like there's some thread contention on a queue that is not thread safe? It doesn't seem to be .Net/Mono related, unless it is a mis-matched nuget pulling in the wrong native lib for one of jar's? You guys have a better idea? |
Could it be R8 is stripping the class out? |
|
@jonpryor one problem I remember from years ago with regards to monodroid in a separate process was that our runtime was never initialized in that process, only in the "main" process. If the separate process, however, was forked off of the main one after the latter was initialized, everything worked fine. But, if the isolated process was somehow initialized before we finished initializing our runtime (I think mostly in the narrow window between when the OS calls our Java startup sequence and we load libmonodroid.so), then things would mostly crash. |
|
@grendello: indeed, we don't -- can't, as far as I currently know -- support |
|
@jonpryor so if the code which uses the |
Just throwing this out there: In the previous version of our code (XForms) using an older version of the native SDK (2.20.0) I used the custom -trying that now |
Sratch all that. I misread the |
|
@jonpryor TY! I pushed a new branch with the patch applied. re: OOM error. The first build after applying the patch I also saw the OOM error and crash, though after connecting the NFC hardware successfully. After manually deleting all I'm not asking for you to debug that, just sharing in case it rings a bell, or others find this thread. See this comment for more details on the OOM. |
Maybe? However, when I try to provide a ProGuard.txt file to preserve those types, they're still not preserved. I'm not sure what I'm doing wrong. |
@jasells |
|
re: @ciuffo81
I'm not sure what your issue is, but odds are > 90% not this issue if you have an unsatisfied link error. Odds are you're simply missing a package. However, if you have a similar situation where you have a native Android service launching from a package lib, then the following snippet to a new activity that essentially registers the service with app-code (or vice-versa) so it can call back was the solution. You'll need to change the process name to match your situation unless you're also dealing with Stripe.Terminal SDK. [Activity(Label = "do not use", Exported = false, Process = "com.stripe.cots.aidlservice")]
public class JonpDummyActivity : Activity { } |
Hi @jasells, thanks for your quick reply. I am a @ciuffo81 team-mate: we are facing the same identical issue with the same callstack regarding Stripe.Terminal SDK so far, we are trying to develop an integration of TerminalSDK (MAUI). Even with snippet provided we are not able to resolve the problem. It would be useful to analyze your repo to compare your solution with our issue. Thank you in advance. |
|
I recommend checking out this repo, as maintaining the bindings are quite a task (Stripe has a 2-release per month cadence): I have a few comments on one of the issue threads here, but I haven't had time to get more familiar with this repo. However, trying to retire the private binding repo referenced here and use envoc-stripe-binding is certainly something I am considering long term for the project I am supporting. The Stripe.Terminal binding repo referenced in this thread is a private repo that I do not own. It is owned by my employer, and I don't have permission at this time to release it publicly. I am only maintaining that private repo because I inherited it when I took this job, and it is going to be a major effort to replace it at this point, and we're in the middle of porting the app that uses it from XForms to Maui. If I were just now adding Stripe.Terminal support to an app as a new feature, I would at least try to use the envoc-stripe-binding before trying to build my own bindings, since as you likely know, the Terminal-Android SDK is fairly complex, as often happens in java projects 😒. What I can tell you is that the repro-repo referenced is a multi-project Maui solution: i.e. it has an Android and an iOS project, structed like a typical XForms app solution, not the typical single-project Maui (shared code) solution used in most examples on MSDN, etc, and may be related to the issue? This template package may be of use if you want to pursue setting up a Maui-multiproject solution. Some of the dependencies and build tools used in the private terminal binding repo are now public, and contributions are welcomed, if you are determined to build your own version of Stripe.Terminal for .NET. My long - term aim would be to contribute to the envoc-stripe-binding by referencing some or all of the dependencies here: All the packages produced by repos in that project are available on Nuget.Org, and I do expect at least one more update/upgrade of my private bindings from Stripe.Terminal v2.23.3 to v3.x before switching to the Envoc bindings, unless that turns out to be much more work than I expect. That would mean updating most or all of those dependency repos, I'm just not sure what versions. |
|
if your binding repo is public... I might have a few minutes here or there to take a look and see if I can help... I would be interested in other collaborative options to maintain a public Stripe-terminal binding package, if the Envoc repo owner is not receptive to collaboration/contribution. |
Android application type
.NET Android (net7.0-android, net8.0-android, etc.)
Affected platform version
Android 12
Description
App shows UnsatisfiedLinkError after migrating from Mono.Android v12.0 (API 31) to net7.0-android. The app contains multiple projects to link in 3rd party Java bindings. The app (including bindings) runs smoothly except for one feature. When that feature is called from the Java binding, it attempts to call the app's OnCreate() and fails.
It seems as if OnCreate() might not be registered or otherwise accessible from the Java code,.
Advice from these documents was introduced as a possible fix, but the error persists:
https://learn.microsoft.com/en-us/dotnet/maui/android/internals/java-interop?view=net-maui-7.0#registration
https://learn.microsoft.com/en-us/dotnet/maui/platform-integration/native-embedding?view=net-maui-7.0
Due to the nature of the 3rd party library, this bug is only caught in Release mode, as the library's Debug mode implementation does not allow hardware activation of the NFC reader.
Steps to Reproduce
No repro.
Did you find any workaround?
No response
Relevant log output
The text was updated successfully, but these errors were encountered: