Hybrid AOT doesn't work on arm64 device if built with only armv7 architecture selected

[Belorus]

Steps to Reproduce

1. Create and Empty application
2. Add <AndroidAotMode>Hybrid</AndroidAotMode> to .csproj
3. Add <AotAssemblies>true</AotAssemblies> to .csproj

Repro

Expected Behavior

It works

Actual Behavior

It crashes

Version Information

Microsoft Visual Studio Professional 2017 Version 15.5.2 VisualStudio.15.Release/15.5.2+27130.2010 Microsoft .NET Framework Version 4.7.02046

Installed Version: Professional

Xamarin 4.8.0.753 (6575bd113) Xamarin.Android SDK 8.1.0.25 (HEAD/d8c6e504f)

Log File

hybridAOT.log

Other

In logs there are warnings like W linker : /data/app/App1.App1-1/lib/arm/libaot-mscorlib.dll.so: is missing DT_SONAME will use basename as a replacement: "libaot-mscorlib.dll.so"

F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x25f44a4c in tid 12103 (App1.App1)

01-22 20:27:13.783 12150 12150 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-22 20:27:13.784 12150 12150 F DEBUG   : Build fingerprint: 'samsung/heroltexx/herolte:7.0/NRD90M/G930FXXS1DQLC:user/release-keys'
01-22 20:27:13.784 12150 12150 F DEBUG   : Revision: '8'
01-22 20:27:13.785 12150 12150 F DEBUG   : ABI: 'arm'
01-22 20:27:13.785 12150 12150 F DEBUG   : pid: 12103, tid: 12103, name: App1.App1  >>> App1.App1 <<<
01-22 20:27:13.785 12150 12150 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x25f44a4c
01-22 20:27:13.785 12150 12150 F DEBUG   :     r0 00000000  r1 ffe674f4  r2 25f44a74  r3 d9f225f0
01-22 20:27:13.786 12150 12150 F DEBUG   :     r4 00000000  r5 e43f7f28  r6 ffe67908  r7 ffe674ec
01-22 20:27:13.786 12150 12150 F DEBUG   :     r8 d9f225f0  r9 d5a54690  sl ffe67a10  fp ffe67508
01-22 20:27:13.786 12150 12150 F DEBUG   :     ip ffe67494  sp 25f44a5c  lr d9f229c8  pc c64000c0  cpsr 600e0010
01-22 20:27:13.788 12150 12150 F DEBUG   : 
01-22 20:27:13.788 12150 12150 F DEBUG   : backtrace:
01-22 20:27:13.788 12150 12150 F DEBUG   :     #00 pc 001200c0  /data/app/App1.App1-1/lib/arm/libmonosgen-2.0.so

[Belorus]

Running on Samsung S7 with ARMv8 Exynos 8890 Octa My assumption was that ARMv8 devices support ARMv7 code (in a same way as x86_64 does that with x86 instructions).

If i select armv8 or both armv7+armv8- everything works.

[bulente]

@Belorus how are you building your project with Hybrid Aot? Mine was giving method not found error while stripping system.core.dll. Doesn't your project include system.core.dll?

[Belorus]

@bulente Nope. It compiles (use steps from first message), but crashes on start (while loading first library). If i choose armv8 architecture - it works on armv8 device.

[jonpryor]

@Belorus: what is "armv8"? arm64-v8a?

What's doubly odd is that it's consistency loading the 32-bit arm images, so it's not like it's a mixed 32-bit/64-bit problem:

70e27000-712a5000 r--p 00000000 fd:00 1249                               /system/framework/arm/boot-core-libart.oat
...
c4cff000-c4ff5000 r-xp 00000000 fd:01 197282                             /data/app/App1.App1-1/lib/arm/libaot-mscorlib.dll.so

[Belorus]

@jonpryor Binary compiled against armv7a ABI with AArch32 instructions crashes on device with armv8a CPU that natively supports both AArch64 and AArch32. And when compiled against either just arm64v8a or both armv7a & arm64-v8a it works properly on device with armv8a CPU.

[grendello]

It doesn't help much, alas, but it appears to be a problem with corrupt stack:

01-22 20:27:13.598 12103 12103 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x25f44a4c in tid 12103 (App1.App1)

note the fault address

01-22 20:27:13.785 12150 12150 F DEBUG   : pid: 12103, tid: 12103, name: App1.App1  >>> App1.App1 <<<
01-22 20:27:13.785 12150 12150 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x25f44a4c
01-22 20:27:13.785 12150 12150 F DEBUG   :     r0 00000000  r1 ffe674f4  r2 25f44a74  r3 d9f225f0
01-22 20:27:13.786 12150 12150 F DEBUG   :     r4 00000000  r5 e43f7f28  r6 ffe67908  r7 ffe674ec
01-22 20:27:13.786 12150 12150 F DEBUG   :     r8 d9f225f0  r9 d5a54690  sl ffe67a10  fp ffe67508
01-22 20:27:13.786 12150 12150 F DEBUG   :     ip ffe67494  sp 25f44a5c  lr d9f229c8  pc c64000c0  cpsr 600e0010

And note the value of the sp register here (stack pointer). The fault location is 16 bytes before the stack top, maybe a corrupt return address from a function?

[pjcollins]

I'm able to reproduce this using a d15-8 preview build (XA 8.4.0.6). I see a similar crash on both 32bit and 64bit devices if I select armeabi-v7a as my only supported architecture (release mode default).

https://gist.github.com/pjcollins/8a9c63ab2e66e6cd6567fbe234dcebc7

[tobiasschulz]

Any news?

[ysmoradi]

I reproduced this with latest version of mono (5.18) and xamarin android 9.1 preview (d16.0) @bulente I wasn't able to build my project using hybrid aot on Windows, but it gets compiled on mac os. As like as other notes in this issue, it crashes on start up. Normal aot is working fine, with or without llvm, but hybrid aot is the one I'm looking for, please fix it. Thanks )-:

This is what I'm getting:

mono-rt 9d9a5000-9d9a6000 r-xp 00000000 b3:0d 24178 /data/app/com.companyname.XamApp-1/lib/arm/libaot-Xamarin.Forms.Platform.dll.so

libc Fatal signal 11 (SIGSEGV), code 2, fault addr 0xa1758c04 in tid 21186 (panyname.XamApp)

[SprengerS]

How are the priorities to resolve this problem. we are developing an app for big company and need AOT with IL Strip for source code obfuscation. This bug is still present since 1.5 years.

[cjrvdev]

Exact same error message brendan mentions in #3367 here. Also using Hybrid mode. Any idea on when is this going to be fixed please?

[taublast]

As time passes pardon for asking, when this issue would be considered important?

[EDMIStephen]

I guess the work around is to compile for both armv7a & arm64-v8a. I will test this out and see if it works.

[EDMIStephen]

@taublast The work around for us is to build for both armv7a & arm64-v8a. The APK is huge but the CIL is stripped.

[nexxuno]

@EDMIStephen the bug is not about building the app but actually running the app.

[EDMIStephen]

Runs fine on the 10 or so Android devices we have ranging from an S6 running Android 7 up to Android 10 devices. With Hybrid AOT you need to also change your src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets to have the change from https://github.com/xamarin/xamarin-android/pull/4850/files. Sounds like the fix wont be in Visual Studio for a little while. Having <AndroidSupportedAbis> </AndroidSupportedAbis> seems to default to armv7a & arm64-v8a.

So there are 3 issues. An issue with mono and a CIL stripping issue solved by editing the Xamarin Android targets. and the Supported Abis issue. You need all the fixes for this to work.

` none

true

<AssemblyName>Mobile.Droid</AssemblyName>
<OutputPath>bin\Release\</OutputPath>
<AndroidUseSharedRuntime>False</AndroidUseSharedRuntime>
<EmbedAssembliesIntoApk>True</EmbedAssembliesIntoApk>
<Debugger>Xamarin</Debugger>
<RunCodeAnalysis>false</RunCodeAnalysis>
<AndroidSupportedAbis>
</AndroidSupportedAbis>
<AndroidEnableMultiDex>true</AndroidEnableMultiDex>
<AotAssemblies>true</AotAssemblies>
<EnableLLVM>true</EnableLLVM>
<AndroidAotMode>Hybrid</AndroidAotMode>
<AndroidEnableProfiledAot>false</AndroidEnableProfiledAot>
<AndroidDexTool>d8</AndroidDexTool>
<AndroidLinkTool>r8</AndroidLinkTool>
<AndroidEnableSGenConcurrent>true</AndroidEnableSGenConcurrent>
<DebugSymbols>false</DebugSymbols>
<AndroidLinkMode>SdkOnly</AndroidLinkMode>`

[ysmoradi]

@EDMIStephen It seems you're following that PR. Could you please let us know when that PR gets released in preview version of vs? I'd like to try your solution in upcoming days too. Hope this helps me. Thanks

[EDMIStephen]

@EDMIStephen It seems you're following that PR. Could you please let us know when that PR gets released in preview version of vs? I'd like to try your solution in upcoming days too. Hope this helps me. Thanks

https://github.com/xamarin/xamarin-android/issues/4818#issuecomment-654894887

[brendanzagaeski]

One other hint to help with getting notifications about availability of the fix for #4818 is if you click the Subscribe button in the right column of the page for #4818, you will get a notification for the comment that will be added to that item when the Preview version that includes the fix is published.

Here's an example of how the comment will look: https://github.com/xamarin/xamarin-android/issues/4409#issuecomment-615018927.

[EDMIStephen]

@brendanzagaeski Would it be possible in the interim to report a warning if hybrid AOT is enabled and only one of armv7a & arm64-v8a are chosen in AndroidSupportedAbis. That way even though this issue is not fixed people wont spend time trying to find out why. I know I spent a lot of time before I came across this bug from over 2 years ago.

[brendanzagaeski]

@EDMIStephen, thanks for the suggestion. I have submitted a pull request to add a build error for this scenario: https://github.com/xamarin/xamarin-android/pull/4966. Note that as currently written, the pull request will cause a build error for projects that have the armeabi-v7a target ABI enabled at all, even if they also have the arm64-v8a target ABI enabled. This seemed like the best approach because apps built with both armeabi-v7a and arm64-v8a target enabled still crash on armeabi-v7a devices, so there's currently no advantage of having the armeabi-v7a target ABI enabled when AndroidAotMode is set to Hybrid.

Assuming this pull request is accepted and merged, you can start preparing your projects for the upcoming build error now by removing the armeabi-v7a architecture from the AndroidSupportedAbis MSBuild property, leaving just arm64-v8a.

[jxbrenner]

I've seen a few comments mentioning that hybrid AoT for Xamarin.Android is experimental. I probably should have clued into that when using it required patching Xamarin.Android.Common.targets, manually setting AndroidAotMode to Hybrid in the project file, and only targeting arm64-v8a for supported ABIs. So, since hybrid AoT is required for CIL stripping, is CIL stripping for Xamarin.Android builds then experimental?

I am successfully CIL stripping my builds, which is great since unpacking an APK/libmonodroid_bundle_app.so and decompiling obfuscated IL is trivial; however, it's worrisome if being able to do that is just an experimental feature. Is there somewhere I can learn more about the current state of support for CIL stripping? Is moving from experimental to fully shipped on the roadmap? If not, is there a way to request that it does? Lastly, is there something on the roadmap to replace Mono AoT in .NET 5 that will provide CIL stripping for Xamarin?

[jxbrenner]

@EDMIStephen, thanks for the suggestion. I have submitted a pull request to add a build error for this scenario: #4966. Note that as currently written, the pull request will cause a build error for projects that have the armeabi-v7a target ABI enabled at all, even if they also have the arm64-v8a target ABI enabled. This seemed like the best approach because apps built with both armeabi-v7a and arm64-v8a target enabled still crash on armeabi-v7a devices, so there's currently no advantage of having the armeabi-v7a target ABI enabled when AndroidAotMode is set to Hybrid.

Assuming this pull request is accepted and merged, you can start preparing your projects for the upcoming build error now by removing the armeabi-v7a architecture from the AndroidSupportedAbis MSBuild property, leaving just arm64-v8a.

Are there any plans to support hybrid AoT or some other approach that allows CIL stripping (ex. profiled AoT) on armeabi-v7a?

[EDMIStephen]

I think VS will change the android project by removing armeabi-v7a if you build from the UI. You might need to set AndroidSupportedAbis>armeabi-v7a;arm64-v8a</AndroidSupportedAbis

to

AndroidSupportedAbis></AndroidSupportedAbis

That seems to default to armeabi-v7a;arm64-v8a

[EDMIStephen]

This work around does not work on armeabi-v7a devices like the Samsung XCover 4 (Android 9). So it will only work on arm64-v8a devices.

[taublast]

If i understand correctly Hybrid used to work on on armeabi-v7a in-before? If so what changed and why?..

[nexxuno]

In my experiments hybrid aot hasn't been working for years on armeabi-v7a (it crashed at runtime). The point is that MS doesn't seem to care much about these problems, I can only guess that they want to push dotfuscator. But pushing dotfuscator with its very high license costs (just try and get a quote from them and you'll see) means that Xamarin as a platform is much less attractive if compared with developing native android which lets you obfuscate code very easily and for free. An official word from Microsoft on this topic would be nice.

Having at least a working solution for 64bit devices (which are the present and future of android) would be nice. The above solution is just a workaround for local builds if I understand correctly.

[tobiasschulz]

We've been trying to get hybrid AOT to work for years. The problem seems to be that nobody from Xamarin/Microsoft ever seems to test if it works at all. Just a feature that has been developed long ago and completely abandoned.

[taublast]

Really weird situation then.. MS using react and dotfuscator themselves for commercial projects, while spending internal time and money developping xamarin/maui. What do i miss?

[tobiasschulz]

As I understand it, Xamarin never had the resources to make non-essential features like Hybrid AOT actually work. And that did not change when Xamarin was purchased by Microsoft. I don't understand why, but they don't really seem to have more resources.

[taublast]

Ok, dunno if this post would be allowed, but while this bug is active, i have come to use .net reactor for xamarin, licence is around 200$. To use create a special project in their ide (main project is obviously yourApp.Android.dll, add additional files like yourApp.dll), install VS extension, then in VS Tools->.net reactor automation select this project and use it for Release. That's basically it, ignore legacy stackoverflow posts "how to make it work with xamarin" editing cproj files, they are outdated. You can play with renaming obfuscation options (unreadable characters, on for public methods..), tested with necrobit on, looks decent to me in JustDecompile. Also have set control flow to lvl 3 for higher execution (startup) speed.. Update: found in their ide menu they have even Xamarin presets! :) Tested along with aot enabled, runs fine on real device.

[EDMIStephen]

al project in their ide (main project is obviously yourApp.Android.dll, add additional files like yourApp.dll), install VS extension, then in VS Tools->.net reactor automation select this project and use it for Release. That's basically it, ignore legacy stackoverflow posts "how to make it work with xamarin" editing cproj files, they are outdated. You can play with renaming obfuscation options (unreadable characters, on for public methods..), tested with necrobit on, looks decent to me in JustDecompile. Also have set control flow to lvl 3 for higher execution (startup) speed.. Update: found in their ide menu they have even Xamarin presets! :) Tested along with aot enabled, runs fine on real devic

Is that just to avoid dotfuscator or will that allow the app to somehow work on ARM v7?

[EDMIStephen]

sed by Micro

I'm not sure Hybrid AOT should be considered non essential. It seems like the only solution for CIL stripping on Android.

[nexxuno]

sed by Micro

I'm not sure Hybrid AOT should be considered non essential. It seems like the only solution for CIL stripping on Android.

Yet they consider it non essential... Good for obfuscation solution producers. We're going the Babelfor.net way, it works very well with Xamarin.Forms (even DevOps) and has a decent licensing (low price, lifetime purchase). A real shame MS is not supporting such an essential feature properly.

[jxbrenner]

sed by Micro

I'm not sure Hybrid AOT should be considered non essential. It seems like the only solution for CIL stripping on Android.

Obscurity is not a legitimate way to protect your source code. Decompiling obfuscated IL back to C# is trivial. Dotfuscator, .NET Reactor, or Babelfor.NET are not replacements for CIL stripping. CIL stripping reduces the IL in your APK from your full source to the C# equivalent of a C++ header file, ex. method prototypes, non-local variable names, etc. Method bodies are completely stripped. As I understand it, it basically just leaves enough IL to support the relevant System.Reflection namespaces.

To put a finer point on it, I think that the crux of the issue is that CIL stripping needs to be fully supported for both armeabi-v7a and arm64-v8a by any approach. Without CIL stripping, we either have to be incredibly risk tolerant or just ignorant to publish apps to Google Play. Even private distribution is sketchier. It's really hard to justify the major effort it takes to build an app when someone can have a copy of all your hard work with minimal effort.

I've seen tons of posts on SO, Reddit, Xamarin Community Forums, etc. asking about why we don't see more Xamarin apps on the app stores, I'd say this has plenty to do with it.

I'm very grateful for Xamarin, and for the experimental support of the hybrid MSBuild property that lets us strip IL from arm64-v8a APKs. Thanks to everyone that's made that possible. I just wanted to share my experience as a developer, specifically that it's painful to have to choose between the armeabi-v7a user base and securing my source code, as I believe there are many others that feel similarly. Maybe the best way to bring attention to the specific issue, that is, fully supported CIL stripping for both armeabi-v7a and arm64-v8a devices, is to open a new feature request? Or does someone already know of a such a request?

[EDMIStephen]

sed by Micro

I'm not sure Hybrid AOT should be considered non essential. It seems like the only solution for CIL stripping on Android.

Obscurity is not a legitimate way to protect your source code. Decompiling obfuscated IL back to C# is trivial. Dotfuscator, .NET Reactor, or Babelfor.NET are not replacements for CIL stripping. CIL stripping reduces the IL in your APK from your full source to the C# equivalent of a C++ header file, ex. method prototypes, non-local variable names, etc. Method bodies are completely stripped. As I understand it, it basically just leaves enough IL to support the relevant System.Reflection namespaces.

To put a finer point on it, I think that the crux of the issue is that CIL stripping needs to be fully supported for both armeabi-v7a and arm64-v8a by some approach to AOT. I wouldn't care if it comes by way of fully supporting hybrid AOT, profiled AOT, or some other AOT approach, as long as any one of them is fully supported. Without CIL stripping, we either have to be incredibly risk tolerant or just ignorant to publish apps to Google Play. Even private distribution is sketchier. It's really hard to justify the major effort it takes to build an app when someone can have a copy of all your hard work with minimal effort.

I've seen tons of posts on SO, Reddit, Xamarin Community Forums, etc. asking about why we don't see more Xamarin apps on the app stores, I'd say this has plenty to do with it.

I'm very grateful for Xamarin, and for the experimental hybrid AOT compilation that lets us strip IL from arm64-v8a APKs. Thanks to everyone that's made that possible. I just wanted to share my experience as a developer, specifically that it's painful to have to choose between the armeabi-v7a user base and securing my source code, as I believe there are many others that feel similarly. Maybe the best way to bring attention to the specific issue, that is, fully supported CIL stripping for both armeabi-v7a and arm64-v8a devices, is to open a new feature request? Or does someone already know of a such a request?

I completely agree. The amount of time I have spend tracking through the Xamarin Android code to try find work arounds is insane. Managing to get CIL stripping working on arm64-v8a is a life saver. We could not release without it. Our customer base is limited by us not being able to support armeabi-v7a. Hybrid AOT really needs to come out of experimental and become a first class citizen with support for armeabi-v7a in the roadmap.

[EDMIStephen]

be nice. The above solution is just a workaround for local builds if I understand correctly

It will work in all builds where you can edit src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets. Once this PR makes it all the way through then hybrid aot should start building everywhere to run on arm64-v8a without manually editing that file.

[nexxuno]

sed by Micro

I'm not sure Hybrid AOT should be considered non essential. It seems like the only solution for CIL stripping on Android.

Obscurity is not a legitimate way to protect your source code. Decompiling obfuscated IL back to C# is trivial. Dotfuscator, .NET Reactor, or Babelfor.NET are not replacements for CIL stripping. CIL stripping reduces the IL in your APK from your full source to the C# equivalent of a C++ header file, ex. method prototypes, non-local variable names, etc. Method bodies are completely stripped. As I understand it, it basically just leaves enough IL to support the relevant System.Reflection namespaces.

To put a finer point on it, I think that the crux of the issue is that CIL stripping needs to be fully supported for both armeabi-v7a and arm64-v8a by some approach to AOT. I wouldn't care if it comes by way of fully supporting hybrid AOT, profiled AOT, or some other AOT approach, as long as any one of them is fully supported. Without CIL stripping, we either have to be incredibly risk tolerant or just ignorant to publish apps to Google Play. Even private distribution is sketchier. It's really hard to justify the major effort it takes to build an app when someone can have a copy of all your hard work with minimal effort.

I've seen tons of posts on SO, Reddit, Xamarin Community Forums, etc. asking about why we don't see more Xamarin apps on the app stores, I'd say this has plenty to do with it.

I'm very grateful for Xamarin, and for the experimental hybrid AOT compilation that lets us strip IL from arm64-v8a APKs. Thanks to everyone that's made that possible. I just wanted to share my experience as a developer, specifically that it's painful to have to choose between the armeabi-v7a user base and securing my source code, as I believe there are many others that feel similarly. Maybe the best way to bring attention to the specific issue, that is, fully supported CIL stripping for both armeabi-v7a and arm64-v8a devices, is to open a new feature request? Or does someone already know of a such a request?

We all know what AOT does and that cil stripping would be better. But at the moment obfuscation is the only solution. This is not a feature request, they had the feature we need but it was bugged and at MS they decided it's not a priority to keep it working.

[hyo1411]

how complicated of fixing this bug? maybe someone looking rather than waiting for Microsoft

[nexxuno]

how complicated of fixing this bug? maybe someone looking rather than waiting for Microsoft

Please submit your PR when you've managed to fix it.

[simon10says]

@brendanzagaeski , based on your above commits, am I right to say that Microsoft decided not to support/fix hybrid AOT for armebi-v7a?

[brendanzagaeski]

@simon10says, as far as I know, there hasn't been a decision against solving the hybrid AOT compatibility issue on armeabi-v7a. That said, I think it's unlikely hybrid AOT will become compatible with armeabi-v7a before .NET 6. Most of the new work on the Mono runtime is now in the combined dotnet/runtime codebase that will be used to run Android applications in .NET 6. (For a little background info about Xamarin.Android in .NET 6, see the blog post from May about "What’s Next for Xamarin")

One next question would then be how AOT will work for Android apps with the Mono runtime in .NET 6. Unfortunately, I'm not familiar with the details of the AOT story for Android apps in .NET 6 or how the plan for it is evolving.

[jxbrenner]

@simon10says, as far as I know, there hasn't been a decision against solving the hybrid AOT compatibility issue on armeabi-v7a. That said, I think it's unlikely hybrid AOT will become compatible with armeabi-v7a before .NET 6. Most of the new work on the Mono runtime is now in the combined dotnet/runtime codebase that will be used to run Android applications in .NET 6. (For a little background info about Xamarin.Android in .NET 6, see the blog post from May about "What’s Next for Xamarin")

One next question would then be how AOT will work for Android apps with the Mono runtime in .NET 6. Unfortunately, I'm not familiar with the details of the AOT story for Android apps in .NET 6 or how the plan for it is evolving.

Based on this response I've created a feature request for AoT compilation and CIL stripping in the .NET runtime repo: dotnet/runtime#44855. If the feature is important to you, please upvote or comment to illustrate that to the development team. Please take the time share your thoughts and experience in the issue. As far as I can tell, it's our best shot at ensuring IL stripping is fully supported for Android in .NET 6.

[ghost]

Hello! Is there anything new on the topic? Any workaround for Hybrid AOT on armeabi-v7a?

[ghost]

I like how fast my app performs with Hybrid AOT. Also, not f....ing with Dotfuscator is even better, than performance improvements. This feature must be supported by Microsoft.

[ghost]

We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

[MaximMikhisor]

Are you going do not support Hybrid AOT on armeabi-v7a?

[jpobst]

With support for Classic Xamarin.Android ended May 1st, 2024, this issue is likely no longer relevant.

If this still persists in .NET 8+, please open a new issue with updated information based on net8.0-android or greater. Please include a link to this issue for context.