Follow-up from #376.
ApprovalFlowKillSwitchInstrumentedTest mutates the production KeepMobileApp singleton's Rust-core kill switch, which is persisted state (a kill switch must survive restart). It engages the switch in @Before and unconditionally restores the disengaged baseline in @After; because the switch fails closed it can only ever over-disable signing, never leak a signature.
Residual gap
The androidTest module runs under a plain AndroidJUnitRunner with no Test Orchestrator and no clearPackageData. If the process dies strictly between setKillSwitch(true) and the @After restore, the engaged state persists into the next test process and would fail later signing tests (for example FrostSigningIntegrationTest.killSwitch_isDisabledByDefault). This is a test-isolation hazard, not a production security hole (fail-closed), but the blast radius is an entire subsequent test class, not just this one.
Work
- Enable Android Test Orchestrator with
clearPackageData for the androidTest run, or add a suite-level @BeforeClass baseline reset that forces the disengaged switch before any kill-switch-mutating class runs.
- Note this is a module-wide execution change: it affects all instrumented tests and their timing, so it is deliberately kept out of the per-test PR that surfaced it.
Acceptance
- A process death mid-test cannot leak an engaged kill switch (or any per-test mutated core state) into a subsequent test class.
Follow-up from #376.
ApprovalFlowKillSwitchInstrumentedTestmutates the productionKeepMobileAppsingleton's Rust-core kill switch, which is persisted state (a kill switch must survive restart). It engages the switch in@Beforeand unconditionally restores the disengaged baseline in@After; because the switch fails closed it can only ever over-disable signing, never leak a signature.Residual gap
The androidTest module runs under a plain
AndroidJUnitRunnerwith no Test Orchestrator and noclearPackageData. If the process dies strictly betweensetKillSwitch(true)and the@Afterrestore, the engaged state persists into the next test process and would fail later signing tests (for exampleFrostSigningIntegrationTest.killSwitch_isDisabledByDefault). This is a test-isolation hazard, not a production security hole (fail-closed), but the blast radius is an entire subsequent test class, not just this one.Work
clearPackageDatafor the androidTest run, or add a suite-level@BeforeClassbaseline reset that forces the disengaged switch before any kill-switch-mutating class runs.Acceptance