Add Pixel 10a mobile performance coverage

[LoopedBard3]

Summary

• add Pixel 10a to all existing Pixel SDK/MAUI performance test matrices
• run the runtime Android JIT, static-linking, and R2R variants on Pixel 10a
• map the new queue to the Pixel10a device name while preserving Pixel 8 coverage

Testing

• parsed the changed YAML files
• validated Python syntax and Pixel 8/Pixel 10a matrix parity

Internal Run: https://dev.azure.com/dnceng/internal/_build/results?buildId=3063540&view=results

[Copilot]

Pull request overview

This PR extends the repo’s mobile performance infrastructure to include Pixel 10a alongside existing Pixel coverage by introducing a new Helix queue mapping and wiring a machinePool value through pipeline/job matrices.

Changes:

• Added a new logical-machine → Helix queue mapping for perfpixel10a and treated the new Pixel 10a queue as a mobile queue for device-name env var handling.
• Updated Helix/pipeline templates and matrices to pass machinePool (e.g., Pixel8, Pixel10a) and schedule Pixel 10a runs across existing SDK/MAUI matrices.
• Refactored runtime Android perf jobs to iterate over a configurable androidMachines list (Pixel + Pixel 10a).

Reviewed changes

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

Show a summary per file

File	Description
scripts/run_performance_job.py	Adds Pixel 10a queue mapping and includes the queue in mobile DEVICE_NAME handling.
helix.yml	Adds machinePool variable and a Pixel 10a profile that passes --machine-pool.
eng/pipelines/templates/run-performance-job.yml	Updates the machinePool parameter comment to include Pixel 10a.
eng/pipelines/templates/build-machine-matrix.yml	Adds a private-build machine matrix entry for Pixel 10a with machinePool: Pixel10a.
eng/pipelines/sdk-perf-jobs.yml	Adds the Pixel 10a machine to multiple existing SDK scenario matrices.
eng/pipelines/runtime-perf-jobs.yml	Introduces androidMachines and loops Android runtime perf jobs over Pixel + Pixel 10a.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (2)

eng/pipelines/templates/build-machine-matrix.yml:137

• The comment says "Windows ARM64 Pixel 10a", but this matrix entry is using archType: x64 and vmImage: windows-2022 (Windows x64 host) and targets an Android ARM64 device. This can mislead future edits/debugging.

- ${{ if and(containsValue(parameters.buildMachines, 'win-x64-android-arm64-pixel10a'), not(eq(parameters.isPublic, true))) }}: # Windows ARM64 Pixel 10a only used in private builds currently

scripts/run_performance_job.py:1151

• The Pixel 10a DEVICE_NAME special-case is unnecessarily tied to both logical_machine and the queue string. If a Pixel 10a run is configured via --queue Windows.11.Amd64.Pixel.10.Perf (without --logical-machine/--machine-pool), DEVICE_NAME will not be set even though this queue is treated as a mobile queue below.

    # Pixel 10a runtime jobs use a logical machine rather than a machine pool.
    if args.logical_machine == "perfpixel10a" and args.queue == "Windows.11.Amd64.Pixel.10.Perf":
        args.run_env_vars["DEVICE_NAME"] = "Pixel10a"
    elif args.machine_pool and args.queue and args.queue in (
        "Windows.11.Amd64.Pixel.Perf",

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[LoopedBard3]

While this PR is good, there are some on machine changes that need to be made to get these devices fully working, so waiting on those changes before merging.

[matouskozak]

Would it make sense to add the devices also to the MAUI SDK scenario runs or is this a staged deployment and testing it on runtime runs first?

[LoopedBard3]

Would it make sense to add the devices also to the MAUI SDK scenario runs or is this a staged deployment and testing it on runtime runs first?

Are you talking about in runtime or the dotnet-performance runs? This should be added to both, but I may have missed somewhere.

[matouskozak]

Are you talking about in runtime or the dotnet-performance runs? This should be added to both, but I may have missed somewhere.

I meant dotnet-performance but discard my comment, I read the PR wrong (I saw the bigger changes for runtime runs and was looking for the same in Maui SDK but didn't realize the one-line change is enough). Sorry

[LoopedBard3]

I meant dotnet-performance but discard my comment, I read the PR wrong (I saw the bigger changes for runtime runs and was looking for the same in Maui SDK but didn't realize the one-line change is enough). Sorry

All good, just confirming that the devices are properly setup to upload results then will merge 👍.

[Copilot]

Pull request overview

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

Suppressed comments (4)

eng/pipelines/runtime-perf-jobs.yml:127

• This runtime job passes only logicalMachine, so machinePool remains empty in run-performance-job.yml and run_performance_job.py does not emit DEVICE_NAME for the new mobile queue. The job will select the Pixel 10a queue without identifying the Pixel10a device in machine setup/results. Pass machinePool: Pixel10a here (and in the other two Pixel 10a runtime blocks).

            logicalMachine: 'perfpixel10a'

eng/pipelines/runtime-perf-jobs.yml:167

• This runtime job passes only logicalMachine, so machinePool remains empty in run-performance-job.yml and run_performance_job.py does not emit DEVICE_NAME for the new mobile queue. The job will select the Pixel 10a queue without identifying the Pixel10a device in machine setup/results. Pass machinePool: Pixel10a here (and in the other two Pixel 10a runtime blocks).

            logicalMachine: 'perfpixel10a'

eng/pipelines/runtime-perf-jobs.yml:207

• This runtime job passes only logicalMachine, so machinePool remains empty in run-performance-job.yml and run_performance_job.py does not emit DEVICE_NAME for the new mobile queue. The job will select the Pixel 10a queue without identifying the Pixel10a device in machine setup/results. Pass machinePool: Pixel10a here (and in the other two Pixel 10a runtime blocks).

            logicalMachine: 'perfpixel10a'

src/scenarios/shared/runner.py:470

• If the new settings get command fails, this exception is raised before setup_device initializes stopappcommand; the finally block then calls close_device(), whose unconditional RunCommand(self.stopappcommand, ...) raises ValueError and masks the original adb failure. Move this call after setup_device (it only needs to run before the procstats clear), or make teardown tolerate an incomplete setup.

                androidHelper.enable_pss_profiling()

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

[LoopedBard3]

Latest run from yesterday is looking much better: https://dev.azure.com/dnceng/internal/_build/results?buildId=3063540&view=results, only one failure that does need to be investigated, but going to merge this once approved so we can figure out if it is transient and to get the rest of the tests running.