Hook up more integrations to NativeAOT with Android RIDs

[jkoritzinsky]

Try hooking up the Android crypto stack, GC integration, and logging to NativeAOT correctly.

cc: @filipnavara @jtschuster

[jonathanpeppers]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[filipnavara]

This will produce conflict with #10385. Not a big deal, just wanted to avoid dragging unused code into newly supported runtimes.

[filipnavara]

There are some usages of _OriginalRuntimeIdentifier below that need to be updated.

[filipnavara]

This line and the one above need to use RuntimeIdentifier instead of _OriginalRuntimeIdentifier.

[filipnavara]

I'll need to dig a bit deeper but the subset linking of the native lib is still not quite correct:

08-12 10:30:01.122 26235 26235 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_monodroid_detect_cpu_and_architecture" referenced by "/data/app/~~grvY0oxLa6M-yS3DDLG0hg==/com.emclient.mailclient-XUnDyFyf6XZEZfGtl53aBg==/lib/x86_64/libMailClient.Mobile.Android.so"...
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at java.lang.Runtime.loadLibrary0(Runtime.java:1090)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at java.lang.Runtime.loadLibrary0(Runtime.java:1012)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at java.lang.System.loadLibrary(System.java:1765)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at net.dot.jni.nativeaot.JavaInteropRuntime.<clinit>(JavaInteropRuntime.java:8)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at net.dot.jni.nativeaot.NativeAotRuntimeProvider.attachInfo(NativeAotRuntimeProvider.java:43)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.app.ActivityThread.installProvider(ActivityThread.java:8642)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.app.ActivityThread.installContentProviders(ActivityThread.java:8157)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7814)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2546)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:110)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.os.Looper.loopOnce(Looper.java:248)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:338)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:9067)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:593)
08-12 10:30:01.122 26235 26235 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:932)

...and even if it tried to link to the native library we are still missing some bits:

    ld.lld : error : undefined hidden symbol: xamarin::android::Helpers::abort_application(_LogCategories, char const*, bool, std::__ndk1::source_location)

UPD: Nvm, I was missing xa-shared-bits in the second attempt.

[filipnavara]

I have a heavily hacked up build locally that was able to pass startup of our app:

Aside from all the comments above and solving general linking breakage / undefined symbols, we will need to embrace GCUserPeerable because NativeAOT builds use different interop generation mode (XAJavaInterop1 vs JavaInterop1).

The garbage collection part seems to work but for some reason it's triggered way too often to the point of feeling like running all the time. It will need to be investigated, the startup takes literally minute[s] because of all the triggered collections. (UPD: Could be It is just uninitialized value for GREF threshold).

[filipnavara]

Here's a rough commit with the changes I have locally to get this working: filipnavara@4a59c50

It still needs a lot of cleanup. We also need updated runtime packs to get it working end-to-end.

[jonathanpeppers]

@jkoritzinsky FYI the latest Maestro bump, it seems like we need to make changes like:

• e79c904

This allows the NativeAOT runtime packs (with proper Android RIDs!) to work.

Do we need to add the two Android RIDs to this line:

• https://github.com/dotnet/sdk/blob/2a4195bb70f47c15ff9e6d848c59517dc873e0f4/src/Layout/redist/targets/GenerateBundledVersions.targets#L397-L403

That made things work for me locally, but CI is ongoing.

[jonathanpeppers]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[akoeplinger]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkoritzinsky]

I'm looking at the NAOT failures and it looks like it can't find the native files in the package even though they are present in the NativeAOT runtime package.

I did notice that the runtime package is built with a -ci version and the test expects it to have a stable version. Is that expected?

[jonathanpeppers]

Ok, the data/RuntimeList.xml file looks OK:

<FileList TargetFrameworkIdentifier=".NETStandard" TargetFrameworkVersion="2.0" FrameworkName="Microsoft.Android.Runtimes" Name=".NET 10.0 - Microsoft.Android.Runtimes">
  <File Type="Managed" Path="runtimes/android-arm64/lib/net10.0/Microsoft.Android.Runtime.NativeAOT.dll" AssemblyName="Microsoft.Android.Runtime.NativeAOT" PublicKeyToken="84e04ff9cfb79065" AssemblyVersion="1.0.0.0" FileVersion="1.0.0.0" Profile="Android" />
  <File Type="Native" Path="runtimes/android-arm64/native/libnet-android-nativeaot-debug.a" FileVersion="0.0.0.0" Profile="Android" />
  <File Type="Native" Path="runtimes/android-arm64/native/libnet-android-nativeaot-release.a" FileVersion="0.0.0.0" Profile="Android" />
  <File Type="Native" Path="runtimes/android-arm64/native/libxa-shared-bits-debug.a" FileVersion="0.0.0.0" Profile="Android" />
  <File Type="Native" Path="runtimes/android-arm64/native/libxa-shared-bits-release.a" FileVersion="0.0.0.0" Profile="Android" />
</FileList>

But then I noticed:

The arm and x86 packs are smaller, so they are missing the new files.

But we should probably just stop producing the arm and x86 packs completely, and then see if some of the failing tests were targeting x86 or something.

[jonathanpeppers]

I tried to push a change (says I can't push to jkoritzinsky/dotnet-android), but I sent a different PR for main:

• [build] stop producing android-arm and android-x86 for unsupported runtimes #10432

[jkoritzinsky]

You should be able to push to my fork (I have the "allow edits by maintainers" checkbox checked), weird. Thanks for looking into this for me.