ci(android): publish tagged releases to the closed testing track

Internal testing is a separate track and does not count toward the
12-tester, 14-day requirement for production access -- only a closed
test does. Releases were landing on internal, so reaching the testers
meant promoting each build by hand in the Console.

Point tracks: at alpha, the closed track, and update the publishing
guide and android README to match. An unknown track id fails the step
with the list of valid tracks rather than publishing somewhere
unintended, so the id is checked at upload time.

Builds up to v0.1.1 remain on the internal track.

.github/workflows/android-release.yml

@@ -66,8 +66,11 @@ jobs:
       # Auto-publish to Google Play (gated on the service-account secret).
       # Skips silently if PLAY_SERVICE_ACCOUNT_JSON is not configured, so
       # tagging a release before Play setup still produces a GH Release.
-      # Default track is "internal" — change to alpha/beta/production
-      # once you trust the pipeline.
+      # Uploads to "alpha", the closed-testing track. Internal testing is a
+      # separate track and does not count toward the 12-tester requirement
+      # for production access, so releases have to land here to reach the
+      # testers. An unknown track name fails the step with the list of
+      # valid tracks rather than publishing somewhere unintended.
       - name: Check Play Store config
         id: play
         env:
@@ -80,14 +83,14 @@ jobs:
             echo "::notice::PLAY_SERVICE_ACCOUNT_JSON not set; skipping Play Store upload."
           fi
 
-      - name: Upload to Google Play (internal track)
+      - name: Upload to Google Play (closed testing track)
         if: steps.play.outputs.configured == 'true'
         uses: r0adkll/upload-google-play@e738b9dd8f2476ea806d921b64aacd24f34515a5 # v1.1.5
         with:
           serviceAccountJsonPlainText: ${{ secrets.PLAY_SERVICE_ACCOUNT_JSON }}
           packageName: com.miti99.loto
           releaseFiles: android/android/app/build/outputs/bundle/release/*.aab
-          tracks: internal
+          tracks: alpha
           status: completed
           # Bumps versionCode automatically? No — must be incremented
           # manually in android/android/app/build.gradle before tagging.

android/README.md

@@ -196,9 +196,10 @@ full walkthrough: service-account creation, granting Play Console permissions,
 setting the GitHub secrets (bash + PowerShell commands), cutting a release,
 and troubleshooting. Short version: once `PLAY_SERVICE_ACCOUNT_JSON` is set,
 every `v*.*.*` tag builds a signed AAB + APK, attaches both to a GitHub
-Release, and uploads the AAB to the Play Console **Internal track**. Promote
-internal → closed → open → production via the Play Console UI (or change
-`tracks: internal` in `android-release.yml` to automate further).
+Release, and uploads the AAB to the Play Console **closed testing track**
+(`alpha`), which is the one whose testers count toward production access.
+Promote closed → open → production via the Play Console UI (or change
+`tracks:` in `android-release.yml` to automate further).
 
 **Important:** every release must increment `versionCode` in `android/app/build.gradle` before tagging — Play Console rejects duplicate versionCodes.
 

docs/play-store-publishing.md

@@ -2,11 +2,12 @@
 
 How to configure GitHub secrets so pushing a `v*.*.*` tag builds a signed
 AAB/APK, attaches both to a GitHub Release, and uploads the AAB to the Play
-Console **Internal track** automatically. Driven by
+Console **closed testing track** automatically. Driven by
 [`.github/workflows/android-release.yml`](../.github/workflows/android-release.yml).
 
-Verified working: tag `v0.0.2` (2026-08-05) built, released, and uploaded to
-the internal track end-to-end.
+Verified working: tag `v0.0.2` (2026-08-05) built, released, and uploaded
+end-to-end. Uploads targeted the internal track until v0.1.1; from v0.1.2 the
+workflow publishes to `alpha`, the closed-testing track.
 
 ## Prerequisites (one-time, manual)
 
@@ -118,7 +119,7 @@ users):
    - **View app information and download bulk reports (read-only)** — the
      API needs it to read the app's edit state
    - **Release apps to testing tracks** — enough for the workflow's
-     `tracks: internal` upload
+     `tracks: alpha` upload
    Leave everything else (production releases, store presence, financial
    data, user management) unchecked. If you later automate production rollout
    (`tracks: production`), come back and add **Release to production, exclude
@@ -176,9 +177,8 @@ work before Play setup is finished.
    gh release view v0.0.3 -R tiennm99/loto
    ```
 
-Promotion beyond the internal track (closed → open → production) stays manual
-in the Play Console UI, or change `tracks: internal` in
-`android-release.yml` to automate further.
+Promotion beyond closed testing (open → production) stays manual in the Play
+Console UI, or change `tracks:` in `android-release.yml` to automate further.
 
 ## Closed testing → production access
 
@@ -208,13 +208,17 @@ What counts:
 
 Review of the production application typically takes up to 7 days.
 
-**The CI track does not feed the closed test.** `android-release.yml`
-uploads to `tracks: internal`. Internal testing is a separate track and
-does **not** count toward the 12-tester requirement — only a closed test
-does. So today a tagged release reaches the internal track, and someone
-must promote that build to the closed track in the Play Console for
-testers to receive it. Either promote manually each release, or switch
-`tracks:` in the workflow to the closed track's name.
+**CI publishes straight to the closed test.** `android-release.yml`
+uploads to `tracks: alpha`, so every tagged release reaches the testers
+whose opt-ins count toward the 14-day window. This matters because
+internal testing is a separate track that does **not** count toward the
+requirement — only a closed test does. Builds tagged before v0.1.2 went
+to the internal track and need promoting by hand if they are wanted in
+the closed test.
+
+An unknown track id fails the upload step with `Track(s) "..." could not
+be found. Available tracks are: [...]` rather than publishing somewhere
+unintended, so a typo here is loud, not silent.
 
 ## Troubleshooting
 

plans/todo.md

@@ -72,12 +72,16 @@ and which features they exercised while the test runs — the production
 application asks for both, and Play has been rejecting thin engagement
 since April 2026.
 
-Blocker to resolve first: CI uploads to the **internal** track, which does
-not count toward the requirement. Builds must reach the **closed** track —
-promote each release in the Console, or repoint `tracks:` in
-`.github/workflows/android-release.yml`. See
+Delivery is wired: `android-release.yml` uploads to `tracks: alpha`, the
+closed track, as of 2026-08-20. Tagged releases now reach the testers
+directly. v0.1.1 and earlier went to the internal track — promote them by
+hand if any is wanted in the closed test. See
 `docs/play-store-publishing.md` → "Closed testing → production access".
 
+- [ ] Cut v0.1.2 to confirm the first upload actually lands on `alpha`.
+      Untested until a tag runs; the track id is unverified against the
+      Console. A wrong id fails the step and prints the valid tracks.
+
 ### Clipped web PWA icons
 
 `web/static/icons/*.png` are visibly clipped. Root cause is