Move latest open Android queues from 29 to 36

[vcsjones]

This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.

Changes:

• Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
• Update the Android “latest” platform alias in helix-platforms.yml to point at the API 36 queue.
• Update CoreCLR template to use the API 36 open queue for public Android x64 runs.

Show a summary per file

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Switches Ubuntu Android Open queue used by libraries jobs to API 36.
eng/pipelines/helix-platforms.yml	Updates helix_android_ubuntu_latest alias and its comment to API 36.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates public Android x64 Helix queue to API 36 Open.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[simonrozsival]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.

[vcsjones]

@simonrozsival I think I addressed this?

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[akoeplinger]

I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue.

There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet.

[vcsjones]

@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically.

[akoeplinger]

yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival?

[vcsjones]

we could also move Android x86 instead

According to @simonrozsival

Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86

[simonrozsival]

@akoeplinger@vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a

[simonrozsival]

@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36.

[vcsjones]

I could also go as low as API Level 33, if 33, 34, or 35 has better availability.

[akoeplinger]

I think the last API level where Google published x86 images was 30.

it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower.

I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here.

[vitek-karas]

Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it).
That said, it won't run x86 (at least I don't think it will) since it has almost exclusively Pixel phones (so arm64).

Currently the devices we have in that queue (and their API level)

Model	API Levels	Count
Pixel 3a	29, 30, 32	45
Pixel 4a	30, 33	66
Pixel 6	32, 36	9
Pixel 6a	36	9
Pixel 9a	36	122
SM S931U1	36	2

And yes, I know it's a mess, I'm working on cleaning it up.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_reviewed_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_recorded_worker_run_id": "29675339961",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"review_id": 4730524141
}
]
}

[github-actions]

Holistic Review

Motivation: The PR bumps the public Ubuntu-based Android Helix test queues from API level 29 to API level 36. The goal is to gain CI coverage for cryptography APIs introduced in Android API 33+, which the project intends to support. This is a well-motivated, targeted infrastructure change.

Approach: Three pipeline YAML files are updated. In helix-platforms.yml, the single helix_android_ubuntu_latest variable is split into helix_android_ubuntu_x64_latest (API 36) and helix_android_ubuntu_x86_latest (API 29), with clarifying comments; the oldest (API 24) variable is retained. In libraries/helix-queues-setup.yml, android_x86 is separated out to remain on API 29 while android_x64, linux_bionic_x64, and the non-public arm/arm64/bionic queues move to API 36. In coreclr/templates/helix-queues-setup.yml, the public android_x64 queue moves to API 36 while the internal queue stays on API 29. The x86 exclusion is correct: API 36 emulators do not ship an android-x86 system image, so keeping x86 on API 29 avoids a broken queue.

Summary: This is a small, correct, and low-risk change. I verified that the renamed helix_android_ubuntu_* variables in helix-platforms.yml are documentation/reference-only — they are not consumed via $(...) anywhere in eng/, and no stale reference to the old helix_android_ubuntu_latest name remains at head, so the rename introduces no breakage. The x86/x64 split is applied consistently, and the x86-on-29 rationale is sound. The main residual risk is queue availability (whether Ubuntu.2204.Amd64.Android.36.Open is provisioned in Helix); this is validated by the PR's own CI runs rather than by static review. One intentional asymmetry worth noting: the internal coreclr and libraries Android queues remain on API 29 while public queues move to 36, consistent with the PR scope of "open" queues. No blocking issues found. LGTM.

Detailed Findings

No actionable code-correctness findings. The variable rename in helix-platforms.yml is safe because those variables are not referenced elsewhere in the pipeline tree. Confirm via CI that the API 36 open queue is provisioned before merging.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 75 AIC · ⌖ 10.4 AIC · ⊞ 10.6K

[vcsjones]

This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.

Changes:

• Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
• Update the Android “latest” platform alias in helix-platforms.yml to point at the API 36 queue.
• Update CoreCLR template to use the API 36 open queue for public Android x64 runs.

Show a summary per file

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Switches Ubuntu Android Open queue used by libraries jobs to API 36.
eng/pipelines/helix-platforms.yml	Updates helix_android_ubuntu_latest alias and its comment to API 36.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates public Android x64 Helix queue to API 36 Open.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[simonrozsival]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.

[vcsjones]

@simonrozsival I think I addressed this?

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[akoeplinger]

I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue.

There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet.

[vcsjones]

@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically.

[akoeplinger]

yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival?

[vcsjones]

we could also move Android x86 instead

According to @simonrozsival

Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86

[simonrozsival]

@akoeplinger@vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a

[simonrozsival]

@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36.

[vcsjones]

I could also go as low as API Level 33, if 33, 34, or 35 has better availability.

[akoeplinger]

I think the last API level where Google published x86 images was 30.

it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower.

I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here.

[vitek-karas]

Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it).
That said, it won't run x86 (at least I don't think it will) since it has almost exclusively Pixel phones (so arm64).

Currently the devices we have in that queue (and their API level)

Model	API Levels	Count
Pixel 3a	29, 30, 32	45
Pixel 4a	30, 33	66
Pixel 6	32, 36	9
Pixel 6a	36	9
Pixel 9a	36	122
SM S931U1	36	2

And yes, I know it's a mess, I'm working on cleaning it up.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_reviewed_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_recorded_worker_run_id": "29675339961",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"review_id": 4730524141
}
]
}

[github-actions]

Holistic Review

Motivation: The PR bumps the public Ubuntu-based Android Helix test queues from API level 29 to API level 36. The goal is to gain CI coverage for cryptography APIs introduced in Android API 33+, which the project intends to support. This is a well-motivated, targeted infrastructure change.

Approach: Three pipeline YAML files are updated. In helix-platforms.yml, the single helix_android_ubuntu_latest variable is split into helix_android_ubuntu_x64_latest (API 36) and helix_android_ubuntu_x86_latest (API 29), with clarifying comments; the oldest (API 24) variable is retained. In libraries/helix-queues-setup.yml, android_x86 is separated out to remain on API 29 while android_x64, linux_bionic_x64, and the non-public arm/arm64/bionic queues move to API 36. In coreclr/templates/helix-queues-setup.yml, the public android_x64 queue moves to API 36 while the internal queue stays on API 29. The x86 exclusion is correct: API 36 emulators do not ship an android-x86 system image, so keeping x86 on API 29 avoids a broken queue.

Summary: This is a small, correct, and low-risk change. I verified that the renamed helix_android_ubuntu_* variables in helix-platforms.yml are documentation/reference-only — they are not consumed via $(...) anywhere in eng/, and no stale reference to the old helix_android_ubuntu_latest name remains at head, so the rename introduces no breakage. The x86/x64 split is applied consistently, and the x86-on-29 rationale is sound. The main residual risk is queue availability (whether Ubuntu.2204.Amd64.Android.36.Open is provisioned in Helix); this is validated by the PR's own CI runs rather than by static review. One intentional asymmetry worth noting: the internal coreclr and libraries Android queues remain on API 29 while public queues move to 36, consistent with the PR scope of "open" queues. No blocking issues found. LGTM.

Detailed Findings

No actionable code-correctness findings. The variable rename in helix-platforms.yml is safe because those variables are not referenced elsewhere in the pipeline tree. Confirm via CI that the API 36 open queue is provisioned before merging.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 75 AIC · ⌖ 10.4 AIC · ⊞ 10.6K

[vcsjones]

This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.

Changes:

• Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
• Update the Android “latest” platform alias in helix-platforms.yml to point at the API 36 queue.
• Update CoreCLR template to use the API 36 open queue for public Android x64 runs.

Show a summary per file

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Switches Ubuntu Android Open queue used by libraries jobs to API 36.
eng/pipelines/helix-platforms.yml	Updates helix_android_ubuntu_latest alias and its comment to API 36.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates public Android x64 Helix queue to API 36 Open.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[simonrozsival]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.

[vcsjones]

@simonrozsival I think I addressed this?

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[akoeplinger]

I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue.

There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet.

[vcsjones]

@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically.

[akoeplinger]

yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival?

[vcsjones]

we could also move Android x86 instead

According to @simonrozsival

Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86

[simonrozsival]

@akoeplinger@vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a

[simonrozsival]

@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36.

[vcsjones]

I could also go as low as API Level 33, if 33, 34, or 35 has better availability.

[akoeplinger]

I think the last API level where Google published x86 images was 30.

it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower.

I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here.

[vitek-karas]

Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it).
That said, it won't run x86 (at least I don't think it will) since it has almost exclusively Pixel phones (so arm64).

Currently the devices we have in that queue (and their API level)

Model	API Levels	Count
Pixel 3a	29, 30, 32	45
Pixel 4a	30, 33	66
Pixel 6	32, 36	9
Pixel 6a	36	9
Pixel 9a	36	122
SM S931U1	36	2

And yes, I know it's a mess, I'm working on cleaning it up.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_reviewed_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_recorded_worker_run_id": "29675339961",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"review_id": 4730524141
}
]
}

[github-actions]

Holistic Review

Motivation: The PR bumps the public Ubuntu-based Android Helix test queues from API level 29 to API level 36. The goal is to gain CI coverage for cryptography APIs introduced in Android API 33+, which the project intends to support. This is a well-motivated, targeted infrastructure change.

Approach: Three pipeline YAML files are updated. In helix-platforms.yml, the single helix_android_ubuntu_latest variable is split into helix_android_ubuntu_x64_latest (API 36) and helix_android_ubuntu_x86_latest (API 29), with clarifying comments; the oldest (API 24) variable is retained. In libraries/helix-queues-setup.yml, android_x86 is separated out to remain on API 29 while android_x64, linux_bionic_x64, and the non-public arm/arm64/bionic queues move to API 36. In coreclr/templates/helix-queues-setup.yml, the public android_x64 queue moves to API 36 while the internal queue stays on API 29. The x86 exclusion is correct: API 36 emulators do not ship an android-x86 system image, so keeping x86 on API 29 avoids a broken queue.

Summary: This is a small, correct, and low-risk change. I verified that the renamed helix_android_ubuntu_* variables in helix-platforms.yml are documentation/reference-only — they are not consumed via $(...) anywhere in eng/, and no stale reference to the old helix_android_ubuntu_latest name remains at head, so the rename introduces no breakage. The x86/x64 split is applied consistently, and the x86-on-29 rationale is sound. The main residual risk is queue availability (whether Ubuntu.2204.Amd64.Android.36.Open is provisioned in Helix); this is validated by the PR's own CI runs rather than by static review. One intentional asymmetry worth noting: the internal coreclr and libraries Android queues remain on API 29 while public queues move to 36, consistent with the PR scope of "open" queues. No blocking issues found. LGTM.

Detailed Findings

No actionable code-correctness findings. The variable rename in helix-platforms.yml is safe because those variables are not referenced elsewhere in the pipeline tree. Confirm via CI that the API 36 open queue is provisioned before merging.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 75 AIC · ⌖ 10.4 AIC · ⊞ 10.6K

[vcsjones]

This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.

Changes:

• Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
• Update the Android “latest” platform alias in helix-platforms.yml to point at the API 36 queue.
• Update CoreCLR template to use the API 36 open queue for public Android x64 runs.

Show a summary per file

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Switches Ubuntu Android Open queue used by libraries jobs to API 36.
eng/pipelines/helix-platforms.yml	Updates helix_android_ubuntu_latest alias and its comment to API 36.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates public Android x64 Helix queue to API 36 Open.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[simonrozsival]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.

[vcsjones]

@simonrozsival I think I addressed this?

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[akoeplinger]

I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue.

There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet.

[vcsjones]

@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically.

[akoeplinger]

yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival?

[vcsjones]

we could also move Android x86 instead

According to @simonrozsival

Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86

[simonrozsival]

@akoeplinger@vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a

[simonrozsival]

@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36.

[vcsjones]

I could also go as low as API Level 33, if 33, 34, or 35 has better availability.

[akoeplinger]

I think the last API level where Google published x86 images was 30.

it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower.

I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here.

[vitek-karas]

Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it).
That said, it won't run x86 (at least I don't think it will) since it has almost exclusively Pixel phones (so arm64).

Currently the devices we have in that queue (and their API level)

Model	API Levels	Count
Pixel 3a	29, 30, 32	45
Pixel 4a	30, 33	66
Pixel 6	32, 36	9
Pixel 6a	36	9
Pixel 9a	36	122
SM S931U1	36	2

And yes, I know it's a mess, I'm working on cleaning it up.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_reviewed_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_recorded_worker_run_id": "29675339961",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"review_id": 4730524141
}
]
}

[github-actions]

Holistic Review

Motivation: The PR bumps the public Ubuntu-based Android Helix test queues from API level 29 to API level 36. The goal is to gain CI coverage for cryptography APIs introduced in Android API 33+, which the project intends to support. This is a well-motivated, targeted infrastructure change.

Approach: Three pipeline YAML files are updated. In helix-platforms.yml, the single helix_android_ubuntu_latest variable is split into helix_android_ubuntu_x64_latest (API 36) and helix_android_ubuntu_x86_latest (API 29), with clarifying comments; the oldest (API 24) variable is retained. In libraries/helix-queues-setup.yml, android_x86 is separated out to remain on API 29 while android_x64, linux_bionic_x64, and the non-public arm/arm64/bionic queues move to API 36. In coreclr/templates/helix-queues-setup.yml, the public android_x64 queue moves to API 36 while the internal queue stays on API 29. The x86 exclusion is correct: API 36 emulators do not ship an android-x86 system image, so keeping x86 on API 29 avoids a broken queue.

Summary: This is a small, correct, and low-risk change. I verified that the renamed helix_android_ubuntu_* variables in helix-platforms.yml are documentation/reference-only — they are not consumed via $(...) anywhere in eng/, and no stale reference to the old helix_android_ubuntu_latest name remains at head, so the rename introduces no breakage. The x86/x64 split is applied consistently, and the x86-on-29 rationale is sound. The main residual risk is queue availability (whether Ubuntu.2204.Amd64.Android.36.Open is provisioned in Helix); this is validated by the PR's own CI runs rather than by static review. One intentional asymmetry worth noting: the internal coreclr and libraries Android queues remain on API 29 while public queues move to 36, consistent with the PR scope of "open" queues. No blocking issues found. LGTM.

Detailed Findings

No actionable code-correctness findings. The variable rename in helix-platforms.yml is safe because those variables are not referenced elsewhere in the pipeline tree. Confirm via CI that the API 36 open queue is provisioned before merging.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 75 AIC · ⌖ 10.4 AIC · ⊞ 10.6K

[vcsjones]

This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.

Changes:

• Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
• Update the Android “latest” platform alias in helix-platforms.yml to point at the API 36 queue.
• Update CoreCLR template to use the API 36 open queue for public Android x64 runs.

Show a summary per file

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Switches Ubuntu Android Open queue used by libraries jobs to API 36.
eng/pipelines/helix-platforms.yml	Updates helix_android_ubuntu_latest alias and its comment to API 36.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates public Android x64 Helix queue to API 36 Open.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[simonrozsival]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.

[vcsjones]

@simonrozsival I think I addressed this?

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[akoeplinger]

I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue.

There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet.

[vcsjones]

@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically.

[akoeplinger]

yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival?

[vcsjones]

we could also move Android x86 instead

According to @simonrozsival

Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86

[simonrozsival]

@akoeplinger@vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a

[simonrozsival]

@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36.

[vcsjones]

I could also go as low as API Level 33, if 33, 34, or 35 has better availability.

[akoeplinger]

I think the last API level where Google published x86 images was 30.

it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower.

I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here.

[vitek-karas]

Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it).
That said, it won't run x86 (at least I don't think it will) since it has almost exclusively Pixel phones (so arm64).

Currently the devices we have in that queue (and their API level)

Model	API Levels	Count
Pixel 3a	29, 30, 32	45
Pixel 4a	30, 33	66
Pixel 6	32, 36	9
Pixel 6a	36	9
Pixel 9a	36	122
SM S931U1	36	2

And yes, I know it's a mess, I'm working on cleaning it up.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_reviewed_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_recorded_worker_run_id": "29675339961",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"review_id": 4730524141
}
]
}

[github-actions]

Holistic Review

Motivation: The PR bumps the public Ubuntu-based Android Helix test queues from API level 29 to API level 36. The goal is to gain CI coverage for cryptography APIs introduced in Android API 33+, which the project intends to support. This is a well-motivated, targeted infrastructure change.

Approach: Three pipeline YAML files are updated. In helix-platforms.yml, the single helix_android_ubuntu_latest variable is split into helix_android_ubuntu_x64_latest (API 36) and helix_android_ubuntu_x86_latest (API 29), with clarifying comments; the oldest (API 24) variable is retained. In libraries/helix-queues-setup.yml, android_x86 is separated out to remain on API 29 while android_x64, linux_bionic_x64, and the non-public arm/arm64/bionic queues move to API 36. In coreclr/templates/helix-queues-setup.yml, the public android_x64 queue moves to API 36 while the internal queue stays on API 29. The x86 exclusion is correct: API 36 emulators do not ship an android-x86 system image, so keeping x86 on API 29 avoids a broken queue.

Summary: This is a small, correct, and low-risk change. I verified that the renamed helix_android_ubuntu_* variables in helix-platforms.yml are documentation/reference-only — they are not consumed via $(...) anywhere in eng/, and no stale reference to the old helix_android_ubuntu_latest name remains at head, so the rename introduces no breakage. The x86/x64 split is applied consistently, and the x86-on-29 rationale is sound. The main residual risk is queue availability (whether Ubuntu.2204.Amd64.Android.36.Open is provisioned in Helix); this is validated by the PR's own CI runs rather than by static review. One intentional asymmetry worth noting: the internal coreclr and libraries Android queues remain on API 29 while public queues move to 36, consistent with the PR scope of "open" queues. No blocking issues found. LGTM.

Detailed Findings

No actionable code-correctness findings. The variable rename in helix-platforms.yml is safe because those variables are not referenced elsewhere in the pipeline tree. Confirm via CI that the API 36 open queue is provisioned before merging.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 75 AIC · ⌖ 10.4 AIC · ⊞ 10.6K

[vcsjones]

This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.

Changes:

• Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
• Update the Android “latest” platform alias in helix-platforms.yml to point at the API 36 queue.
• Update CoreCLR template to use the API 36 open queue for public Android x64 runs.

Show a summary per file

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Switches Ubuntu Android Open queue used by libraries jobs to API 36.
eng/pipelines/helix-platforms.yml	Updates helix_android_ubuntu_latest alias and its comment to API 36.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates public Android x64 Helix queue to API 36 Open.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[simonrozsival]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.

[vcsjones]

@simonrozsival I think I addressed this?

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[akoeplinger]

I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue.

There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet.

[vcsjones]

@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically.

[akoeplinger]

yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival?

[vcsjones]

we could also move Android x86 instead

According to @simonrozsival

Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86

[simonrozsival]

@akoeplinger@vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a

[simonrozsival]

@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36.

[vcsjones]

I could also go as low as API Level 33, if 33, 34, or 35 has better availability.

[akoeplinger]

I think the last API level where Google published x86 images was 30.

it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower.

I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here.

[vitek-karas]

Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it).
That said, it won't run x86 (at least I don't think it will) since it has almost exclusively Pixel phones (so arm64).

Currently the devices we have in that queue (and their API level)

Model	API Levels	Count
Pixel 3a	29, 30, 32	45
Pixel 4a	30, 33	66
Pixel 6	32, 36	9
Pixel 6a	36	9
Pixel 9a	36	122
SM S931U1	36	2

And yes, I know it's a mess, I'm working on cleaning it up.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_reviewed_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_recorded_worker_run_id": "29675339961",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"review_id": 4730524141
}
]
}

[github-actions]

Holistic Review

Motivation: The PR bumps the public Ubuntu-based Android Helix test queues from API level 29 to API level 36. The goal is to gain CI coverage for cryptography APIs introduced in Android API 33+, which the project intends to support. This is a well-motivated, targeted infrastructure change.

Approach: Three pipeline YAML files are updated. In helix-platforms.yml, the single helix_android_ubuntu_latest variable is split into helix_android_ubuntu_x64_latest (API 36) and helix_android_ubuntu_x86_latest (API 29), with clarifying comments; the oldest (API 24) variable is retained. In libraries/helix-queues-setup.yml, android_x86 is separated out to remain on API 29 while android_x64, linux_bionic_x64, and the non-public arm/arm64/bionic queues move to API 36. In coreclr/templates/helix-queues-setup.yml, the public android_x64 queue moves to API 36 while the internal queue stays on API 29. The x86 exclusion is correct: API 36 emulators do not ship an android-x86 system image, so keeping x86 on API 29 avoids a broken queue.

Summary: This is a small, correct, and low-risk change. I verified that the renamed helix_android_ubuntu_* variables in helix-platforms.yml are documentation/reference-only — they are not consumed via $(...) anywhere in eng/, and no stale reference to the old helix_android_ubuntu_latest name remains at head, so the rename introduces no breakage. The x86/x64 split is applied consistently, and the x86-on-29 rationale is sound. The main residual risk is queue availability (whether Ubuntu.2204.Amd64.Android.36.Open is provisioned in Helix); this is validated by the PR's own CI runs rather than by static review. One intentional asymmetry worth noting: the internal coreclr and libraries Android queues remain on API 29 while public queues move to 36, consistent with the PR scope of "open" queues. No blocking issues found. LGTM.

Detailed Findings

No actionable code-correctness findings. The variable rename in helix-platforms.yml is safe because those variables are not referenced elsewhere in the pipeline tree. Confirm via CI that the API 36 open queue is provisioned before merging.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 75 AIC · ⌖ 10.4 AIC · ⊞ 10.6K

[vcsjones]

This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.

Changes:

• Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
• Update the Android “latest” platform alias in helix-platforms.yml to point at the API 36 queue.
• Update CoreCLR template to use the API 36 open queue for public Android x64 runs.

Show a summary per file

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Switches Ubuntu Android Open queue used by libraries jobs to API 36.
eng/pipelines/helix-platforms.yml	Updates helix_android_ubuntu_latest alias and its comment to API 36.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates public Android x64 Helix queue to API 36 Open.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[simonrozsival]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.

[vcsjones]

@simonrozsival I think I addressed this?

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[akoeplinger]

I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue.

There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet.

[vcsjones]

@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically.

[akoeplinger]

yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival?

[vcsjones]

we could also move Android x86 instead

According to @simonrozsival

Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86

[simonrozsival]

@akoeplinger@vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a

[simonrozsival]

@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36.

[vcsjones]

I could also go as low as API Level 33, if 33, 34, or 35 has better availability.

[akoeplinger]

I think the last API level where Google published x86 images was 30.

it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower.

I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here.

[vitek-karas]

Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it).
That said, it won't run x86 (at least I don't think it will) since it has almost exclusively Pixel phones (so arm64).

Currently the devices we have in that queue (and their API level)

Model	API Levels	Count
Pixel 3a	29, 30, 32	45
Pixel 4a	30, 33	66
Pixel 6	32, 36	9
Pixel 6a	36	9
Pixel 9a	36	122
SM S931U1	36	2

And yes, I know it's a mess, I'm working on cleaning it up.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_reviewed_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_recorded_worker_run_id": "29675339961",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"review_id": 4730524141
}
]
}

[github-actions]

Holistic Review

Motivation: The PR bumps the public Ubuntu-based Android Helix test queues from API level 29 to API level 36. The goal is to gain CI coverage for cryptography APIs introduced in Android API 33+, which the project intends to support. This is a well-motivated, targeted infrastructure change.

Approach: Three pipeline YAML files are updated. In helix-platforms.yml, the single helix_android_ubuntu_latest variable is split into helix_android_ubuntu_x64_latest (API 36) and helix_android_ubuntu_x86_latest (API 29), with clarifying comments; the oldest (API 24) variable is retained. In libraries/helix-queues-setup.yml, android_x86 is separated out to remain on API 29 while android_x64, linux_bionic_x64, and the non-public arm/arm64/bionic queues move to API 36. In coreclr/templates/helix-queues-setup.yml, the public android_x64 queue moves to API 36 while the internal queue stays on API 29. The x86 exclusion is correct: API 36 emulators do not ship an android-x86 system image, so keeping x86 on API 29 avoids a broken queue.

Summary: This is a small, correct, and low-risk change. I verified that the renamed helix_android_ubuntu_* variables in helix-platforms.yml are documentation/reference-only — they are not consumed via $(...) anywhere in eng/, and no stale reference to the old helix_android_ubuntu_latest name remains at head, so the rename introduces no breakage. The x86/x64 split is applied consistently, and the x86-on-29 rationale is sound. The main residual risk is queue availability (whether Ubuntu.2204.Amd64.Android.36.Open is provisioned in Helix); this is validated by the PR's own CI runs rather than by static review. One intentional asymmetry worth noting: the internal coreclr and libraries Android queues remain on API 29 while public queues move to 36, consistent with the PR scope of "open" queues. No blocking issues found. LGTM.

Detailed Findings

No actionable code-correctness findings. The variable rename in helix-platforms.yml is safe because those variables are not referenced elsewhere in the pipeline tree. Confirm via CI that the API 36 open queue is provisioned before merging.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 75 AIC · ⌖ 10.4 AIC · ⊞ 10.6K

[vcsjones]

This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.

Changes:

• Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
• Update the Android “latest” platform alias in helix-platforms.yml to point at the API 36 queue.
• Update CoreCLR template to use the API 36 open queue for public Android x64 runs.

Show a summary per file

File	Description
eng/pipelines/libraries/helix-queues-setup.yml	Switches Ubuntu Android Open queue used by libraries jobs to API 36.
eng/pipelines/helix-platforms.yml	Updates helix_android_ubuntu_latest alias and its comment to API 36.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates public Android x64 Helix queue to API 36 Open.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[simonrozsival]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[simonrozsival]

It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.

[vcsjones]

@simonrozsival I think I addressed this?

[vcsjones]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[akoeplinger]

I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue.

There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet.

[vcsjones]

@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically.

[akoeplinger]

yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival?

[vcsjones]

we could also move Android x86 instead

According to @simonrozsival

Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86

[simonrozsival]

@akoeplinger@vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a

[simonrozsival]

@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36.

[vcsjones]

I could also go as low as API Level 33, if 33, 34, or 35 has better availability.

[akoeplinger]

I think the last API level where Google published x86 images was 30.

it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower.

I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here.

[vitek-karas]

Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it).
That said, it won't run x86 (at least I don't think it will) since it has almost exclusively Pixel phones (so arm64).

Currently the devices we have in that queue (and their API level)

Model	API Levels	Count
Pixel 3a	29, 30, 32	45
Pixel 4a	30, 33	66
Pixel 6	32, 36	9
Pixel 6a	36	9
Pixel 9a	36	122
SM S931U1	36	2

And yes, I know it's a mess, I'm working on cleaning it up.

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
"version": 5,
"last_dispatched_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_dispatched_base_ref": "main",
"last_dispatched_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_reviewed_commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"last_reviewed_base_ref": "main",
"last_reviewed_base_sha": "0f01d22be46fc2daa2cee0c86b467a60d654afc6",
"last_recorded_worker_run_id": "29675339961",
"review_attempt_commit": "",
"review_attempt_base_ref": "",
"review_attempt_count": 0,
"max_review_attempts": 5,
"review_history_format": "holistic-review-disclosure-v1",
"review_history": [
{
"commit": "e2204bd14641a44d987dd6aba37b79b4d49c73e5",
"review_id": 4730524141
}
]
}

[github-actions]

Holistic Review

Motivation: The PR bumps the public Ubuntu-based Android Helix test queues from API level 29 to API level 36. The goal is to gain CI coverage for cryptography APIs introduced in Android API 33+, which the project intends to support. This is a well-motivated, targeted infrastructure change.

Approach: Three pipeline YAML files are updated. In helix-platforms.yml, the single helix_android_ubuntu_latest variable is split into helix_android_ubuntu_x64_latest (API 36) and helix_android_ubuntu_x86_latest (API 29), with clarifying comments; the oldest (API 24) variable is retained. In libraries/helix-queues-setup.yml, android_x86 is separated out to remain on API 29 while android_x64, linux_bionic_x64, and the non-public arm/arm64/bionic queues move to API 36. In coreclr/templates/helix-queues-setup.yml, the public android_x64 queue moves to API 36 while the internal queue stays on API 29. The x86 exclusion is correct: API 36 emulators do not ship an android-x86 system image, so keeping x86 on API 29 avoids a broken queue.

Summary: This is a small, correct, and low-risk change. I verified that the renamed helix_android_ubuntu_* variables in helix-platforms.yml are documentation/reference-only — they are not consumed via $(...) anywhere in eng/, and no stale reference to the old helix_android_ubuntu_latest name remains at head, so the rename introduces no breakage. The x86/x64 split is applied consistently, and the x86-on-29 rationale is sound. The main residual risk is queue availability (whether Ubuntu.2204.Amd64.Android.36.Open is provisioned in Helix); this is validated by the PR's own CI runs rather than by static review. One intentional asymmetry worth noting: the internal coreclr and libraries Android queues remain on API 29 while public queues move to 36, consistent with the PR scope of "open" queues. No blocking issues found. LGTM.

Detailed Findings

No actionable code-correctness findings. The variable rename in helix-platforms.yml is safe because those variables are not referenced elsewhere in the pipeline tree. Confirm via CI that the API 36 open queue is provisioned before merging.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 75 AIC · ⌖ 10.4 AIC · ⊞ 10.6K