Enable CoreCLR runtime pack for android-arm (armeabi-v7a)

[simonrozsival]

Note

This PR was AI/Copilot-generated.

Summary

Enable the CoreCLR runtime flavor for the armeabi-v7a (android-arm) ABI, following the same pattern as android-arm64 and android-x64.

Changes

build-tools/scripts/Ndk.projitems.in

• Set SupportCoreCLR=True for armeabi-v7a (was False)
• Add ApiLevelNonMono metadata (referencing the new AndroidNdkApiLevelNonMono_Arm property)
• Add AndroidNdkApiLevelNonMono_Arm property with @NDK_ARMEABI_V7_API_NON_MONO@ placeholder

build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.cs

• Add @NDK_ARMEABI_V7_API_NON_MONO@ → NdkMinimumNonMonoAPI placeholder replacement

WorkloadManifest.in.json

• Add Microsoft.Android.Runtime.CoreCLR.36.1.android-arm to the workload packs list and pack definitions

Dependencies

• [android] Enable CoreCLR runtime pack production for android-arm runtime#127225 — CoreCLR build/CI enablement for android-arm
• Bump Android minimum API level from 21 to 24 runtime#126838 — Raise AndroidApiLevelMin to 24 (required for CoreCLR arm32)
• Add android-arm to CoreCLR runtime pack RIDs for .NET 11 sdk#54015 — SDK RuntimePackRids for android-arm CoreCLR

[Copilot]

Pull request overview

Enables CoreCLR runtime-pack support metadata for the android-arm (armeabi-v7a) ABI so the Android workload can include a CoreCLR pack for that RID, matching existing arm64/x64 patterns.

Changes:

• Add Microsoft.Android.Runtime.CoreCLR.36.1.android-arm to the Android workload manifest packs list and pack definitions.
• Update Ndk.projitems.in to mark armeabi-v7a as SupportCoreCLR=True and add an ApiLevelNonMono value for that ABI.
• Extend xaprepare placeholder generation to replace the new @NDK_ARMEABI_V7_API_NON_MONO@ placeholder.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/Xamarin.Android.Build.Tasks/Microsoft.NET.Sdk.Android/WorkloadManifest.in.json	Adds the CoreCLR android-arm runtime pack to the workload manifest.
build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.cs	Adds placeholder substitution for the new arm32 non-mono NDK API placeholder used by generated projitems.
build-tools/scripts/Ndk.projitems.in	Marks armeabi-v7a as CoreCLR-supported and introduces an arm32 non-mono API-level property/metadata.

[Copilot]

Setting True for armeabi-v7a makes the build/packs treat android-arm CoreCLR as supported, but the rest of the repo is not wired up for it yet: src/native/native-clr.csproj still restricts AndroidSupportedTargetJitAbis to arm64-v8a:x86_64, src/native/CMakePresets.json.in has no coreclr-* presets for armeabi-v7a, and the CoreCLR/NonMono min-API mapping in XABuildConfig.ArchToApiLevelNonMono has no AndroidTargetArch.Arm entry (MonoAndroidHelper.GetMinimumApiLevel will throw for CoreCLR+Arm). Either keep SupportCoreCLR=false for armeabi-v7a for now, or add the missing native presets/build support and the ArchToApiLevelNonMono entry so CoreCLR android-arm builds are actually possible.

Suggested change

	<SupportCoreCLR>True</SupportCoreCLR>
	<SupportCoreCLR>False</SupportCoreCLR>

[Copilot]

The workload manifest now declares Microsoft.Android.Runtime.CoreCLR.36.1.android-arm as part of the android workload. With the current repo state, CoreCLR native runtime builds/packs are only produced for arm64/x86_64 (see src/native/native-clr.csproj and CMake presets), so this entry is likely to make workload install/pack creation fail or produce an incomplete runtime pack for android-arm. Please ensure the CoreCLR android-arm runtime pack is actually generated and published by the build (native runtime build + runtime pack creation) before listing it here, or gate the manifest entry until those pieces are in place.

[simonrozsival]

@copilot address the review and make sure the rest of the repo is ready for armeabi-v7a support

[Copilot]

@copilot address the review and make sure the rest of the repo is ready for armeabi-v7a support

Wired up the remaining pieces in 84c9882:

• src/native/CMakePresets.json.in: added nonmono-common-armeabi-v7a and coreclr-default-{debug,release}-armeabi-v7a presets so --preset coreclr-default-*-armeabi-v7a resolves during _ConfigureRuntimes.
• build-tools/xaprepare/xaprepare/Steps/Step_GenerateFiles.cs: added @NDK_ARMEABI_V7_NONMONO_API_NET@ (CMakePresets) and @NDK_ARMEABI_V7_NONMONO_API@ (XABuildConfig) placeholder substitutions, both mapping to BuildAndroidPlatforms.NdkMinimumNonMonoAPI.
• build-tools/scripts/XABuildConfig.cs.in: added AndroidTargetArch.Arm to ArchToApiLevelNonMono so MonoAndroidHelper.GetMinimumApiLevel no longer throws for CoreCLR + Arm.
• src/native/native-clr.csproj: added armeabi-v7a to AndroidSupportedTargetJitAbis so the CoreCLR native runtime is actually built and packaged for that ABI. AOT abis are left as arm64:x86_64.

[simonrozsival]

@copilot build failed:

Build Summary: Failed ❌
Build ID: 13956134
Definition: Xamarin.Android-PR
Branch: dev/simonrozsival/coreclr-android-arm
Commit: 84c988208a894ea1c04aa19c1d8502e1c776915a
Reason: batchedCI

All three platform stages (Linux, macOS, Windows) failed with the same root cause: a C++ compilation error in the native CLR host.

Failed Stages
Linux > Build (make jenkins)
macOS > Build (make jenkins)
Windows > Build (Build Solution)
All three stages fail identically during the _BuildAndroidRuntimes target in native-clr.csproj.

Root Cause: C++ Type Mismatch in typemap.cc
File: src/native/clr/host/typemap.cc line 149

error: no matching function for call to 'hash'
Code:

hash_t mvid_hash = xxhash::hash (mvid, 16z);
The mvid parameter is const uint8_t * (const unsigned char *), but xxhash::hash() only accepts const char *.

Candidate not viable (from src/native/common/include/shared/xxhash.hh:61):

candidate function template not viable: no known conversion from
  'const uint8_t *' (aka 'const unsigned char *') to 'const char *'
  for 1st argument
Fix Needed
The call at typemap.cc:149 needs a reinterpret_cast<const char *>(mvid), or xxhash::hash() needs an overload accepting const uint8_t *.

Additional Warning (macOS & Linux only)
src/Mono.Android/metadata(389,3): error BG4304: Invalid XPath specification:
  /api/package[@name='android.graphics.pdf.component']/*/method[...]
This metadata binding error also fires on macOS and Linux builds but is secondary to the native compilation failure that causes the overall build to fail.

Failed Tests
No test results available — the build failed before reaching the test execution phase.

[Copilot]

@copilot build failed:

Build Summary: Failed ❌

...

Fixed in 483822f. Root cause: on 32-bit (armeabi-v7a) xamarin::android::xxhash aliases to xxhash32, whose hash overloads only take const char *. On 64-bit it aliases to xxhash64, which has a template<typename T> hash(const T*, size_t) overload — which is why this compiled fine before arm32 was enabled. Added a reinterpret_cast<const char*>(mvid) at the call site, matching the existing pattern in mono/monodroid/embedded-assemblies.cc:787.

The BG4304 metadata error (/api/package[@name='android.graphics.pdf.component']/...) is unrelated to this PR (it's about Android API metadata, not arm32) and per the build summary is secondary to the native compilation failure, so I'm leaving it alone.