The BuildAotApplicationWithNdkAndBundleAndÜmläüts test in AotTests.cs was removed because it was Mono-only (it set AndroidRuntime.MonoVM, EnableLLVM, and AndroidUseAssemblyStore, and asserted on Mono LLVM AOT artifacts like aot/UnnamedProject.dll.so). None of those have a direct CoreCLR equivalent — on CoreCLR, AOT maps to NativeAOT, which produces different artifacts and needs separate NDK/bundle wiring.
We should add equivalent coverage for the supported runtimes as a follow-up.
What the old test covered (for reference)
- AOT build through the Android NDK (
AndroidNdkDirectory), release mode.
- Multi-ABI builds across
armeabi-v7a;arm64-v8a;x86;x86_64.
- Assembly-store/bundle on vs LLVM on, via two
TestCaseSource rows:
usesAssemblyBlobs = true, enableLLVM = falseusesAssemblyBlobs = false, enableLLVM = true
- A project path/name with non-ASCII characters (
BuildAotNdk AndÜmläüts) to catch path/encoding issues.
- Per-ABI assertions that the AOT native library and the assembly are present in the signed APK.
Proposed work
Add equivalent NDK + bundle coverage for both supported runtimes:
- NativeAOT: release-mode NDK + bundle test across the supported ABIs (
arm64-v8a, x86_64), asserting on the NativeAOT artifacts and APK contents.
- CoreCLR: release-mode NDK + bundle test across the supported ABIs (
arm64-v8a, x86_64), asserting on the CoreCLR artifacts and APK contents.
- Use a non-ASCII project name so the special-character coverage is preserved.
Notes
- Special-character project-name coverage already exists on CoreCLR in
BuildAotApplicationWithSpecialCharactersInProject (テスト / 随机生成器 / 中国), so this issue is specifically about the NDK + bundle + AOT artifact validation, not the Unicode-name angle.
- The AOT-on-CoreCLR combination is currently skipped in
BuildAotApplicationWithSpecialCharactersInProject ("AOT + CoreCLR == NativeAOT; Not supported yet here"); the NativeAOT portion of this work depends on that NativeAOT path being wired up in the test infra.
The
BuildAotApplicationWithNdkAndBundleAndÜmläütstest inAotTests.cswas removed because it was Mono-only (it setAndroidRuntime.MonoVM,EnableLLVM, andAndroidUseAssemblyStore, and asserted on Mono LLVM AOT artifacts likeaot/UnnamedProject.dll.so). None of those have a direct CoreCLR equivalent — on CoreCLR, AOT maps to NativeAOT, which produces different artifacts and needs separate NDK/bundle wiring.We should add equivalent coverage for the supported runtimes as a follow-up.
What the old test covered (for reference)
AndroidNdkDirectory), release mode.armeabi-v7a;arm64-v8a;x86;x86_64.TestCaseSourcerows:usesAssemblyBlobs = true,enableLLVM = falseusesAssemblyBlobs = false,enableLLVM = trueBuildAotNdk AndÜmläüts) to catch path/encoding issues.Proposed work
Add equivalent NDK + bundle coverage for both supported runtimes:
arm64-v8a,x86_64), asserting on the NativeAOT artifacts and APK contents.arm64-v8a,x86_64), asserting on the CoreCLR artifacts and APK contents.Notes
BuildAotApplicationWithSpecialCharactersInProject(テスト/随机生成器/中国), so this issue is specifically about the NDK + bundle + AOT artifact validation, not the Unicode-name angle.BuildAotApplicationWithSpecialCharactersInProject("AOT + CoreCLR == NativeAOT; Not supported yet here"); the NativeAOT portion of this work depends on that NativeAOT path being wired up in the test infra.