[cdeutsch]

Two commits, one for each half of how an Android build now moves through Play.

Each merge goes to internal testing

Every merge that touched apps/android/ was released to Play's closed testing track. Play reviews each closed release, and a newer submission replaces one still in review, so a day with several merges asked for reviews of builds no tester ever received, and testers could wait on a queue that kept restarting.

• A push to main now releases to the internal track, which Play does not review and which reaches testers within minutes.
• Closed testing gets a build when the Android workflow is started by hand on main with the new closed_testing box ticked. The input is a checkbox rather than a track name, so internal and alpha stay the only tracks android.yml can reach.

Promoting to production

Production meant opening Play Console and promoting by hand. "Android promote" (android-promote.yml) is started by hand on main and asks Play to release a bundle it already has: the newest build on internal testing, or a named version code, to a percentage of production. Running it again with a larger percentage widens the rollout. Nothing is rebuilt.

• Its own workflow, so the one that runs on every merge still cannot name the production track.
• Its key lives on a new play-production Environment with a required reviewer: starting the run is a request, approving it is the release.
• The work is .github/scripts/play-promote.mjs, plain Node with no dependencies, so no third-party action or package handles the production key. Its tests run against a stand-in for Play in a new play-promote CI job, and again in the workflow before the release step.

For the reviewer

• Neither publish path has run against Play. The release job only runs on main, and the promote script has only met a stand-in. This PR touches android.yml, so merging it uploads a build to internal: that merge is the first real test.
• Track names. Google's API reference names the internal track qa; the upload action and other tools call it internal. android.yml uses internal, as the action documents, and the promote script lists tracks and accepts either.
• One-off setup in Play Console before merging: the internal track needs its own tester list (Internal testing, Testers). It is separate from the closed track's, so until it has people on it a merge reaches nobody.
• One-off setup in GitHub before the first promotion, in this order: create the play-production Environment with a required reviewer and deployment branches limited to main, and only then put PLAY_SERVICE_ACCOUNT_JSON on it. GitHub creates an Environment the first time a job names it, with no rules, which is harmless only while it holds no key. The details are in docs/android.md.
• Closed testers stop getting a build per merge.
• No release note change: nothing differs on anyone's phone.

🤖 Generated with Claude Code