R04: Promote one exact APK into an immutable Android Release Set

[TheDarkSkyXD]

Parent

Build StreamFusion Mobile for Android

What to deliver

Protected second-approval promotion of one EAS build ID into a matched immutable Release Set, plus metadata withdrawal and same-key forward-fix rehearsal.

Capability IDs

• app-updates

Code ownership

• publisher
• release
• verification

Acceptance criteria

• The behavior above works through the real Android application or the named verification/release path; code presence alone is insufficient.
• Each affected capability has an updated Android Parity Record bound to the current Desktop Baseline and Android candidate.
• The implementation respects the approved responsibility layers and adapter boundaries owned by this ticket.
• Required evidence is indexed: exact-apk-identity, eas-provenance, signed-manifest, sbom, immutable-release, rollback-rehearsal.
• External, lifecycle, persistence, native, or release boundaries define and verify safe failure containment, retry, fallback, disablement, rollback, or forward-fix behavior as applicable.
• The normal Change Gate passes with no untracked architecture exception, quarantined required test, or Development Exception.

Blocked by

• Complete mobile UI/UX, mockup, action, and business-logic coverage
• R02: Deliver the signed GitHub APK updater
• R03: Automate the four Android verification gates

Sources

• Approved implementation specification
• Approved implementation roadmap
• Machine-readable ticket graph

UI and UX must already be complete

Every implementing feature issue owns its complete UI, UX, actions, business rules and evidence before closure, under PRD section 6.7 and the normative screen/control contract. #195 reviews each slice continuously and must finish integrated development-candidate UI/UX acceptance before #178 production artifact promotion. Release verification revalidates the completed experience against the exact artifact; this issue is not a backlog for building missing screens or polishing unfinished features.

• Verify feature-owned UI/UX completion and the Mobile: Complete mockup, UI/UX, action, and business-logic coverage #195 integrated report. No required placeholder, inert control, deferred UI finding or unresolved action rule remains.
• Revalidate evidence affected by candidate changes rather than accepting a historical screenshot or a closed feature issue as proof.

Release sequencing

#195 must be completed before this issue starts. All feature-owned design and UI/UX work, mockup gaps, required actions and logic findings must already be implemented and verified. M6 completes the experience; M7 promotes and verifies the release artifact. If release testing finds a new required UI/UX defect, fix it in its owning feature and refresh the affected #195 evidence before proceeding. No release or signing action is authorized by this sequencing update.