ci(mobile): publish nightly Android APKs to a GitHub prerelease

[SunkenInTime]

What Changed

• New .github/workflows/mobile-android-apk.yml: runs hourly, plus manual dispatch.
• New .github/scripts/mirror-play-apk.cjs: plain Node, no dependencies.
• A short "Android APK mirror" section in docs/operations/release.md.

Each run reads the newest live build on the Play v2 closed testing track (where eas.json submits v2-preview builds) and downloads the universal APK that Google Play generated and signed for it. It then keeps that APK on a rolling android-nightly prerelease, with only the newest build kept. The release page, releases/tag/android-nightly, is a fixed link to hand to nightly users.

Why

Nightly servers run the Orchestrator V2 protocol, which the Play Store release of the app can't talk to. Nightly users need the v2-preview build from the Play testing group, but the group isn't letting people join right now, and we couldn't offer an APK because Play App Signing holds the key. Play already generates a universal APK signed with that key for every uploaded bundle (docs), so CI only has to fetch it. No signing key goes into GitHub, and the APK has the same signature as the Play Store install.

Design notes:

• Polls instead of chaining off mobile-eas-production.yml. EAS builds and submits with --no-wait, so CI never learns when the bundle reaches Play. A run with nothing new does no writes.
• Doesn't open a Play edit. It reads the track through the edit-free tracks.releases.list endpoint. Play allows one open edit per account, so an edit-based read could invalidate an in-flight EAS submission if the two shared a service account.
• Kept away from other release consumers. The prerelease's android-nightly tag doesn't start with v, and it's created with --latest=false. release.yml, the desktop updater, the CLI release lookup, and the marketing site's releases/latest all ignore it. Same idea as the existing desktop-preview release.
• Recovers from failed runs. An empty asset left by a failed upload doesn't count as published. Cleanup of the previous APK and the notes runs every time, so an interrupted run finishes on the next one.
• Refuses ambiguous signatures. If Play returns more than one universal APK (one per signing key, after a key rotation), the run fails instead of guessing.

Out of scope: a stable APK mirrored from the production track, and linking the APK from the Nightly tab on t3.codes/download. Both are easy follow-ups; this PR covers only the immediate problem.

Setup needed (maintainers)

Add a repo secret GOOGLE_PLAY_SERVICE_ACCOUNT_JSON with a Play service account key. The account needs the "Release to production, exclude devices, and use Play App Signing" permission to download generated APKs. Reusing EAS Submit's service account is fine. Until the secret exists, the job skips itself.

Verification

No Play credentials were available, so these checks stand in for a real Play run:

• Real GitHub Actions run. The workflow ran unchanged in a private scratch repo on a stock runner, with only Google's endpoints mocked. These passed:

  • no secret: the job skips itself
  • first publish
  • rerun with nothing new: no writes
  • leftover old APK and stale notes: repaired on the next run
  • newer build: replaces the old APK
  • two signing keys: fails and leaves the release untouched

  A decoy stable release stayed "Latest" throughout.

• Play API contract. Every endpoint, field, enum, and type was checked against Google's machine-readable API definition. Google's Go and Node clients and fastlane's download_universal_apk_from_google_play build the same download request (:download?alt=media).

• Token format. Sent to Google's real token endpoint with a throwaway key, it was rejected only for the unknown account ("account not found"). A malformed token gets invalid_request instead.

Not yet proven, and settled by the first real run after the secret is added:

• how Play responds while it's still generating the APK (an error rather than an empty list would fail that run, and the next hourly run retries)
• the exact release name EAS's submission service sets (cosmetic, it only affects the APK file name)

Run the workflow once with Run workflow after adding the secret.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (none)

Taken over and rebased onto current main by @juliusmarminge: the Play submit track was renamed from alpha to the v2 closed testing track in #2829, so the workflow and release docs now poll v2. The Play API contract and token smoke test were re-verified against Google's current API definition.

Done by Claude Opus 5.5 (1M context) in Claude Code, running in T3 Code, with review and research by gpt-6-astra.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This adds an hourly, credentialed Google Play-to-GitHub release pipeline that downloads signed Android APKs and mutates a rolling prerelease, creating a new distribution capability and operational side effects. The workflow and external integration warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: b44878da-e6b4-4525-89e0-77d686d23b72

---

---

📥 Commits

Reviewing files that changed from the base of the PR and between 0de3187 and f5688d7.

---

---

📒 Files selected for processing (1)

• .github/workflows/mobile-android-apk.yml

---

---

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/mobile-android-apk.yml

---

---

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

---

---

📝 Walkthrough

📝 Walkthrough

Walkthrough

Adds a scheduled and manually triggered workflow that checks the Google Play alpha track and mirrors its newest published universal APK to the rolling android-nightly GitHub prerelease.

Changes

Android APK mirror

Layer / File(s)	Summary
Workflow entry and configuration .github/workflows/mobile-android-apk.yml, docs/operations/release.md	The workflow runs hourly or on manual dispatch. It skips checkout and mirroring when the service-account secret is absent. The documentation describes the track, prerelease, signing, and permission requirements.
Play authentication and build selection .github/scripts/mirror-play-apk.cjs	The script authenticates with a service-account JWT and reads published releases and active artifacts. It selects the build with the greatest version code.
APK and prerelease update .github/scripts/mirror-play-apk.cjs	The script downloads the build’s universal APK and creates or updates the prerelease. It skips an existing nonempty matching asset, removes other APK assets, and updates changed release notes.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant Workflow as Mobile Android APK workflow
  participant Script as mirror-play-apk.cjs
  participant OAuth as Google OAuth token endpoint
  participant Play as Android Publisher API
  participant Release as GitHub Release
  Workflow->>Script: Run with package, track, release tag, and credentials
  Script->>OAuth: Exchange signed service-account JWT
  OAuth-->>Script: Return access token
  Script->>Play: Read published track releases
  Play-->>Script: Return active artifacts and version codes
  Script->>Play: Download selected build's universal APK
  Play-->>Script: Return APK
  Script->>Release: Create or update release and APK assets
  Script->>Release: Update release notes when they differ

Loading

---

---

Merge Risk: ⚪ Minimal · up to f5688

No actionable merge-blocking issue was identified in the nightly APK workflow. It is ready for normal checks and the planned credential setup.

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to 0de31

The publication and recovery design includes useful safeguards, but manual execution can run selected-branch code with both Play credentials and repository write authority. The permissions and branch protections governing that access remain unverified, so the security assessment is conditional rather than a confirmed vulnerability.

Retained concerns

• Medium · security · inferred: Manual dispatch introduces a conditional source-ref-to-credential boundary: the selected ref supplies executable script code that receives both the Play service-account key and repository write authority. No trusted-ref restriction or protected environment is declared in this workflow. This is an unresolved control concern, not a verified externally reachable attack.

Security review details

Security Blast Radius

• inferred — Compromised execution could affect repository contents and releases within the GitHub token’s effective authority, and every Play application authorized to the supplied service account. Fixed package and tag values constrain honest execution, not malicious checked-out code. Actual Play grants and repository restrictions are unavailable.

Security Findings and Attack Paths

• inferred — The conditional attack path requires control of a selected ref, permission to dispatch it, and credential availability during execution. There is no pull-request trigger or public workflow input. The supplied candidate remains deferred because these authorization conditions are unresolved; no verified Security finding is established.

Trust Boundaries and Controls

• observed — The service-account JSON is trusted configuration: its token_uri becomes both JWT audience and POST destination without endpoint validation. The request sends a signed assertion, not the private key itself. No attacker-controlled source for that secret value is established.
• observed — Fresh downloads use an authenticated fixed Google API base, reject multiple universal APK candidates, sanitize the release-name portion of the filename, and invoke the GitHub CLI through argument arrays rather than shell interpolation.

Resilience and Maintainability Implications

• observed — The repeat path trusts an existing asset by filename, uploaded state, and nonzero size; it does not revalidate Play signing-key ambiguity or cryptographic provenance. Existing release state is accepted by tag without an ownership marker or prerelease-status check. No poisoned asset, ownership collision, or already-published key-rotation case is established.

Hardening Proposals

• proposed — Make the privileged execution boundary explicit by restricting manual runs to trusted workflow and script revisions or a protected environment, and confirm that effective Play grants and repository permissions match the intended publication scope.
• proposed — Consider validating the Google token endpoint and documenting exclusive ownership of the rolling release. If independent release writers are permitted, add ownership and APK provenance checks before trusting or deleting existing assets.

---

Pre-merge checks | 3 | 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 37.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 8 functions across 1 files. (1 skipped: 1…	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check		The description explains the problem, implementation, scope, setup, verification, limitations, and agent usage. However, it does not include the required Scope and approval section or link a triaged i…	Add a Scope and approval section. Link the triaged issue or discussion that approved the direction and scope, including the maintainer approval comment. If no prior approval exists, obtain it or explain why this change qualifies for an exem…

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly and concisely identifies the main change: publishing nightly Android APKs through CI to a GitHub prerelease.

---

Full details: Docstring Coverage

Explanation

Docstring coverage is 37.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 8 functions across 1 files. (1 skipped: 1 unsupported.)

---

Full details: Description check

Explanation

The description explains the problem, implementation, scope, setup, verification, limitations, and agent usage. However, it does not include the required Scope and approval section or link a triaged issue or explicit maintainer approval for this broader workflow change.

Resolution

Add a Scope and approval section. Link the triaged issue or discussion that approved the direction and scope, including the maintainer approval comment. If no prior approval exists, obtain it or explain why this change qualifies for an exemption.

---

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

---

---

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[SunkenInTime]

@coderabbitai Re the retained manual-dispatch concern: not changing this. Only users with write access can dispatch a workflow, and the same users can already push a branch whose workflow reads any repository secret, since GOOGLE_PLAY_SERVICE_ACCOUNT_JSON is a repository secret rather than an environment-protected one. A ref check in this workflow would not close that path. mobile-eas-production.yml follows the same model with EXPO_TOKEN and accepts branch dispatches. If maintainers want the key scoped tighter, the right fix is a protected environment, which is a repo settings change, not a code change.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail
fd --hidden --type f '^(mobile-eas-production|mobile-android-apk)\.yml$' . --exec bash -c '
for file do
  printf "\n--- %s ---\n" "$file"
  ast-grep outline "$file" || true
  sed -n "1,240p" "$file"
done
' bash {} +

Length of output: 13199

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail
fd --hidden --type f '^(mobile-eas-production|mobile-android-apk)\.yml$' . --exec bash -c '
set -euo pipefail
file="$1"
printf "\n--- %s ---\n" "$file"
ast-grep outline "$file"
sed -n "1,155p" "$file"
' bash {}

Length of output: 8927

---

@SunkenInTime Thanks for the clarification. I checked both workflows. .github/workflows/mobile-eas-production.yml explicitly supports branch dispatches and uses EXPO_TOKEN without a protected environment.

You are right: a ref check in this workflow would not prevent a write-access user from creating another workflow that reads the repository secret. I withdraw the manual-dispatch finding. No change is needed for this concern.

A tighter secret-access boundary would require an environment-scoped secret with protection rules configured in repository settings.

---

✏️ Learnings added

Learnt from: SunkenInTime
URL: https://github.com/pingdotgg/t3code/pull/16271

Timestamp: 2026-10-06T17:32:56.679Z
Learning: In pingdotgg/t3code, `.github/workflows/mobile-android-apk.yml` intentionally permits manual branch dispatches with the repository-level `GOOGLE_PLAY_SERVICE_ACCOUNT_JSON` secret. `.github/workflows/mobile-eas-production.yml` follows the same trust model with `EXPO_TOKEN` and explicitly supports branch dispatches. Do not recommend a workflow-local ref check as a boundary against repository-secret access by write-access users, who can create another workflow that reads the secret. Stronger isolation requires moving the secret to a protected environment and configuring its protection rules in repository settings.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

You are interacting with an AI system.

[juliusmarminge]

Note

This comment is posted by Julius' dot

This adds an hourly Play-to-GitHub APK distribution workflow and a new rolling release, but the PR has no linked maintainer approval for that direction and scope. Closing under the prior-approval rule. Discuss the release channel and credential requirements with maintainers in Ideas, then link their approval when requesting reconsideration.

[juliusmarminge]

Taking this over — thanks for building it, @SunkenInTime. Rebased onto current main (828 commits of drift, cherry-picks were clean) with one fix on top:

• Track rename: this branch was cut when eas.json submitted v2-preview builds to the alpha track. feat(orchestrator): introduce new orchestrator #2829 changed the submit target to the v2 closed testing track, so polling alpha would never see a v2-preview build. PLAY_TRACK and the release docs now say v2 (77c49ce).

Re-verified while rebasing, since the original checks predate the rebase:

• Play API contract re-checked against Google's current discovery document: applications.tracks.releases.list returns ReleaseSummary (releaseLifecycleState, activeArtifacts[].versionCode as int32), and generatedapks.download is the media-download endpoint the script uses. All fields and enums match.
• Token smoke test reran with a throwaway key against Google's real token endpoint: rejected with Invalid grant: account not found, not invalid_request, so the JWT grant is still well-formed.
• vp fmt --check and vp lint clean on the three changed files.

Still needed from maintainers before this does anything:

• Add the GOOGLE_PLAY_SERVICE_ACCOUNT_JSON repo secret (confirmed it doesn't exist yet). Until then the job skips itself, as designed.
• After merge + secret, run Mobile Android APK once via Run workflow; that first real run is what settles the two unknowns called out in the description.

Follow-ups deliberately left out, same as the original scope: link the android-nightly release from the Nightly mobile beta callout (apps/web/src/components/NightlyMobileBeta.tsx) and docs/user/install.md, which still send Android users to the Play testing group, and a stable APK mirrored from the production track.

[juliusmarminge]

Update: GOOGLE_PLAY_SERVICE_ACCOUNT_JSON is now set (the existing Play Console service account EAS Submit uses; verified read-only against the Play API — track read and generatedApks list both return 200). So after merge, all that's left is one manual Run workflow for Mobile Android APK.