Put different arches in different yml for NativeAOT Android pipelines

[jtschuster]

Should fix #118621

runtime-extra-platforms pulls in both runtime-android and runtime-androidemulator. NativeAOT has runs for the same arches in both of those, creating duplicates. This follows the CoreCLR pattern and runs one arch in runtime-android and one in tuneim-androidemulator.

[jtschuster]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull Request Overview

This PR reorganizes Android platform builds by separating different architectures into different pipeline YAML files. The change moves android_x64 exclusively to the Android emulator pipeline and android_arm64 exclusively to the main Android pipeline.

Key Changes:

• Removes android_arm64 from the Android emulator pipeline
• Removes android_x64 from the main Android pipeline
• Creates architecture-specific separation between emulator and device builds

Reviewed Changes

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

File	Description
eng/pipelines/extra-platforms/runtime-extra-platforms-androidemulator.yml	Removes android_arm64 platform from emulator builds
eng/pipelines/extra-platforms/runtime-extra-platforms-android.yml	Removes android_x64 platform from main Android builds

[jtschuster]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dotnet-policy-service]

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

[jtschuster]

/ba-g All failures unrelated

[elinor-fung]

Splitting to only arm64 for regular and only x64 for emulator makes sense. But in general, should we have the emulator jobs include emulator in the name? Not allowing the same architecture in regular and emulator seems like a weird limitation just due to how those jobs are named. And emulator seems like reasonable information to have in the title.