[WIP] Drop libc++ from Android NativeAOT linking

[simonrozsival]

Summary

This draft explores removing the Android NativeAOT link-time dependency on libc++.

The branch now:

• removes the explicit NativeAOT libc++_static.a and libc++abi.a link inputs;
• removes libc++ packaging from the Android native runtime component list;
• keeps the final NativeAOT app link on the direct ld.lld/NativeLinker path from main;
• reduces NativeAOT-reachable host code that pulled in C++ runtime/STL symbols;
• adds NativeAOT-local C++ allocation/nothrow shims for the remaining runtime-pack allocation references;
• fixes trimmable NativeAOT startup/linking by making generated per-assembly __ArrayMapRank* typemap anchors public, because the root typemap assembly references them across assembly boundaries.

Context

This is related to #9926 and the NDK r29 NativeAOT linking work.

The relevant background is that the NativeAOT Android runtime should avoid depending on libc++ instead of working around duplicate libunwind symbols or switching to shared libc++. Related references:

• [NativeAOT] Fix application linking with API level > 21 #10812 fixed NativeAOT linking with API levels above 21 by making sure the final link uses the correct Android API level/toolchain invocation.
• [NAOT][android] Application linking breaks with NDK r29 because of duplicated libunwind symbols runtime#121172 tracks the NDK r29 duplicate libunwind symbol failure and discusses removing the libc++ dependency from Android NativeAOT.
• [Android NDK] Make API level configurable runtime#124461 makes the NativeAOT Android API level configurable so runtime and app links use matching Android API levels.
• Remove libstdc++ dependency from NativeAOT runtime#76705 is prior art for removing a C++ standard-library dependency from NativeAOT.

Size impact

Earlier measurements on this branch used samples/NativeAOT/NativeAOT.csproj built in Release with _AndroidTypeMapImplementation=trimmable.

Artifact	Parent libc++ baseline	No-libc++ build	Difference
arm64 APK	1,575,849 B	1,296,320 B	-279,529 B (-17.74%)
x64 APK	1,639,459 B	1,353,661 B	-285,798 B (-17.43%)
arm64 libNativeAOT.so	3,481,880 B	2,727,936 B	-753,944 B (-21.65%)
x64 libNativeAOT.so	3,404,896 B	2,664,048 B	-740,848 B (-21.76%)

libNativeAOT.so is the per-ABI native shared library packaged in the APK, for example lib/arm64-v8a/libNativeAOT.so. It is not the whole Android app package; the APK also contains manifest, resources, Java stubs/classes, signatures, and packaging assets.

Validation

Validated locally during the latest iteration:

• dotnet test tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests.csproj --no-restore — 457 passed.

Previous branch validation:

• rebuilt src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.csproj;
• rebuilt NativeAOT runtime archives for android-arm64 and android-x64;
• built samples/NativeAOT/NativeAOT.csproj with _AndroidTypeMapImplementation=trimmable for android-arm64 and android-x64;
• verified generated NativeAOT link response files contain no libc++/libc++abi inputs;
• verified produced APKs contain no libc++ entries;
• verified llvm-nm -u reports no undefined C++ runtime-looking symbols in the final libNativeAOT.so outputs;
• smoke-tested the arm64 APK on an arm64 emulator: libNativeAOT.so loaded without libc++, MainApplication and MainActivity native callbacks ran, MainActivity.OnCreate() logged, and the process remained alive.

Current status

The PR is still draft/WIP. A CI follow-up fixed the NativeAOT trimmable typemap build failures caused by private __ArrayMapRank* anchors producing invalid NativeAOT metadata and unresolved link symbols.

The x64 APK builds and packages without libc++, but local x64 runtime validation still needs an x64 emulator host because Android emulator x86_64 system images are not accepted on Apple Silicon/aarch64 hosts.

[simonrozsival]

Emulator validation update

I tested the signed NativeAOT + trimmable typemap sample APK on an arm64 emulator after rebuilding/overlaying the local validation packs.

What works:

• The arm64 APK installs and launches on emulator-5554.
• lib/arm64-v8a/libNativeAOT.so loads successfully with no libc++ packaged in the APK.
• Startup reaches managed code: MainApplication and MainActivity native callbacks run, MainActivity.OnCreate() logs, and the process remains alive.

Important caveats:

• This arm64 smoke currently requires trimmable NativeAOT startup fixes plus two validation-only workarounds:
  • pointing ILC TypeMapEntryAssembly at the app typemap (_NativeAOT.TypeMap) instead of the root _Microsoft.Android.TypeMaps, because scanning _Mono.Android.TypeMap currently fails on Android.Text.IInputType being present in the ref assembly but absent from the runtime assembly;
  • skipping UncaughtExceptionMarshaler setup for trimmable NativeAOT to avoid the IUncaughtExceptionHandler/JavaProxyThrowable startup path.
• I do not consider those two workarounds shippable as-is; they need separate root-cause fixes before this can be more than a feasibility proof.
• x64 builds and packages without libc++ (-nostdlib++ is in the link response and no libc++ entries are in the APK), but I could not run the x64 APK locally: the Android emulator rejects x86_64 system images on this Apple Silicon host (Avd's CPU Architecture 'x86_64' is not supported by the QEMU2 emulator on aarch64 host). x64 runtime behavior still needs validation on an x64 emulator host.