Run intrada on Android phones on the same core #2220

What you would notice

An Android musician cannot use intrada at all. When this epic closes, the Library shows on an Android emulator, driven by the same core as the iPhone app, and CI fails a core change that breaks the Android build.

Why it matters

The core is a pure Crux app with no I/O, so a second native shell is a port of the bridge and the screens, not a redesign. Building it beside the iPhone work proves the toolchain before the bigger phases (persistence, practice, capture) are planned.

What to do

Phase A, bridge and boot, from specs/android-shell.md, is done: the Kotlin bindings are generated, the Library shows on an emulator from the real core, and CI builds, tests and compares snapshots on every PR that touches Android. The Android design tokens, error banner, TalkBack labels and the agent rules for Kotlin are in too.

Phases B and C are done, and so is the Swift rules review (#2223 and its children). The rest of parity runs in four lanes side by side (agreed 2026-10-09), one session per lane, each lane in this order:

1. Player: Change the metronome's bar and pattern on Android, and drag to set its tempo #2476.
2. Add form: Split the Android add form into sections so its issues can run side by side #2492 (split the form first), then Choose a new piece's exercises on the Android add form #2478, Fill the Android add form from a photographed page #2479 (which takes Phase D's camera and page reading), then Suggest composers and tags on the Android form #2477 (its matching rule takes the core slot, shared with the iCloud sync work).
3. New screens, two at a time: Show Progress on Android, from the core's analytics #2493 Progress, List past practice sessions on Android and open one to see how it went #2494 practice history, Set your name and instrument on Android, with the profile screen #2495 profile, Welcome a new Android user with the first run steps #2496 first run, then the three iPhone actions Android still lacks, each bringing its skipped tap-through test with it: Rename a saved variation on Android from the item screen, as the iPhone does #2567 renaming a variation, Choose other keys to practise a piece in on Android, as the iPhone does #2568 choosing keys, Create a new exercise from a piece's screen on Android, as the iPhone does #2569 creating an exercise from a piece (not sub-issues, as this epic is at the limit).
4. Release: Send Android crashes and tester feedback to Sentry #2497 Sentry and feedback, Run the Android CI jobs on Ubuntu runners #2498 Ubuntu CI, then Show a fallen mark on Progress without the success colour #2551 (the last parity code), then the iPhone's checks brought to Android (Test adding a piece, its sections and variations on Android by tapping through, as the iPhone does #2562, Test building and playing a session on Android by tapping through, as the iPhone does #2563, Test the profile, past sessions and session recovery on Android by tapping through, as the iPhone does #2564 UI tests, Build Android release, launch it with a screenshot and check its release name on every PR, as the iPhone does #2565 release build and launch checks), then Walk every Android flow on the emulator and a real phone before any build is shared #2566 (the full test pass on the emulator and a phone; not a sub-issue, as this epic is at GitHub's limit of 100), then Save a signed Android APK from the release workflow so testers can install it without Play #2561 (a signed APK testers can install without Play), then Get the Android app to testers through Play internal testing #2499 Play internal testing.

The files every lane takes turns on are listed in the parallel streams skill. #2227 (the chord chart's text) moved to the parked chord charts epic #2025; Android leaves chord chart editing out until then. #2423 was split into the issues above.

This epic is not ranked in docs/roadmap.md, which lists the Android app as built alongside and not ranked against the product work.

Done looks like

• just android-run opens the emulator on a Library list rendered from the real core.
• CI runs an Android build and unit job on every PR.
• The Swift rules review has reported, and any rule it found is in the core.

Where it lives

specs/android-shell.md, crates/intrada-ffi/src/bin/codegen.rs, the android/ directory, justfile, .github/workflows/.