[android] Enable CoreCLR runtime pack production for android-arm

[simonrozsival]

Note

This PR was created with the assistance of GitHub Copilot.

Summary

Enable the CoreCLR runtime pack for android-arm (armeabi-v7a) by removing the ARM architecture restriction and adding CI pipeline support.

Changes

• eng/Subsets.props — Remove arm from the blocked Android architectures list (keep x86 blocked). The original blocker was fseeko/ftello not being available below API level 24 ([Android] fseeko and ftello not supported on arm32 & x86 below API level 24 without disabling _FILE_OFFSET_BITS=64 #111665). With the minimum API level being raised to 24 in Bump Android minimum API level from 21 to 24 #126838, this no longer applies.
• eng/pipelines/runtime.yml — Add android_arm to the CoreCLR Android CI platform list.
• eng/pipelines/extra-platforms/runtime-extra-platforms-android.yml — Add android_arm to the extra-platforms CoreCLR job.
• eng/pipelines/coreclr/templates/helix-queues-setup.yml — Add android_arm Helix queue mapping using the same Windows.11.Amd64.Android queues as android_arm64.

What already works (no changes needed)

• Platform matrix definition (android_arm already defined in platform-matrix.yml)
• Native build tooling (NDK arm → armeabi-v7a mapping)
• Packaging RIDs (linux-bionic-arm in netcoreappRIDs.props and KnownFrameworkReference)
• Libraries Helix queues (already handle android_arm)
• CoreCLR CMake/JIT (no ARM32+Android-specific blocks)

Dependencies

This PR depends on #126838 (raise AndroidApiLevelMin from 21 to 24) and should be merged after it.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[jkotas]

Suggested change

<!-- Android x86 builds are still blocked by https://github.com/dotnet/runtime/issues/111665 -->

This issue will be resolved by #126838 . We do not need to comment on the condition

[Copilot]

Pull request overview

Enables CoreCLR runtime pack production and CI coverage for android-arm (armeabi-v7a) by unblocking the architecture in build subsets and wiring android_arm into the Android CoreCLR pipeline/platform lists and Helix queue selection.

Changes:

• Unblock CoreCLR support for Android arm by adjusting the Android architecture gating in eng/Subsets.props (while keeping x86 blocked).
• Add android_arm to Android CoreCLR platform matrices in main and extra-platform pipelines.
• Add Helix queue mapping for android_arm in the CoreCLR Helix queue setup template.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
eng/Subsets.props	Updates CoreCLR support gating so Android arm32 is allowed (x86 remains blocked).
eng/pipelines/runtime.yml	Adds android_arm to the CoreCLR Android CI platform list and updates the header comment.
eng/pipelines/extra-platforms/runtime-extra-platforms-android.yml	Adds android_arm to the extra-platforms CoreCLR Android job platforms list.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Adds Helix queue mapping for android_arm (aligned to android_arm64).

[github-actions]

🤖 Copilot Code Review — PR #127225

Note

This review was AI-generated by Copilot. Models contributing: Claude Opus 4.6 (primary), GPT-5.3-Codex, Claude Haiku 4.5.

Holistic Assessment

Motivation: Enabling CoreCLR for android-arm is a reasonable step toward full Android platform support. The PR is well-scoped to CI/build infrastructure changes only.

Approach: The changes are mechanical and consistent — unblocking the architecture in Subsets.props and wiring up the CI pipelines/Helix queues. The pattern matches sibling platforms (android_arm64).

Summary: ⚠️ Needs Human Review. The stated rationale ("minimum API level being raised to 24") is factually incorrect in the current codebase — AndroidApiLevelMin is still 21. However, investigation suggests the build likely succeeds anyway because CoreCLR and its native dependencies do not actually call fseeko/ftello. CI results will be the definitive answer. A maintainer (@jkotas) has already engaged with feedback.

---

Detailed Findings

⚠️ PR Rationale — API level has not been raised to 24 (flagged by all 3 models)

The PR description states: "With the minimum API level being raised to 24, this blocker no longer applies." However:

• Directory.Build.props:42 — <AndroidApiLevelMin>21</AndroidApiLevelMin>
• eng/native/build-commons.sh:104 — local ANDROID_API_LEVEL=21
• eng/native/gen-buildsys.cmd:79 — set __ANDROID_API_LEVEL=21

The API level bump is in a separate draft PR (#126838). If this PR is intended to land before #126838, the commit message should be corrected to state the actual reason arm is being unblocked (e.g., that no CoreCLR code actually depends on fseeko/ftello). If it depends on #126838 landing first, that ordering dependency should be documented.

⚠️ Comment clarity — Why arm but not x86?

Both arm and x86 are 32-bit Android architectures equally affected by issue #111665 (fseeko/ftello unavailability below API 24). The updated comment says "Android x86 builds are still blocked by #111665" but does not explain why arm is exempt from the same blocker. This could confuse future readers. Note that @jkotas has already suggested removing the comment entirely since #126838 will resolve the underlying issue.

✅ CI pipeline configuration — Correct and consistent

The Helix queue mapping for android_arm in coreclr/templates/helix-queues-setup.yml correctly mirrors the android_arm64 pattern (Windows.11.Amd64.Android.Open for public, Windows.11.Amd64.Android for internal). The platform is already defined in platform-matrix.yml (line 623) and the libraries Helix queue setup already handles android_arm, so only the CoreCLR-specific queue mapping was missing — which this PR adds.

✅ No public API changes

No changes to ref/ assemblies or public API surface. No API approval verification needed.

💡 Build validation — CI will be definitive

Investigation shows that neither CoreCLR native code nor its vendored dependencies (zlib-ng, zstd) actually call fseeko/ftello in compiled C/C++ sources. The zlib-ng.cmake wrapper hardcodes HAVE_FSEEKO=1 but the library does not use the function; zstd's cmake sets LIBC_NO_FSEEKO for API < 24 but also does not call the function. This suggests the original arm block was conservative and the build should succeed at API 21. CI results from this draft will confirm.

Generated by Code Review for issue #127225 · ◷