Everything written this session that has not been through the device: rounds 43 to 48 (each patch adversarially verified, 43's transient-notice expectation fixed), a partial round 49, the pipeline scripts, the Android Auto design and the icon comparison mock. Also the two harness changes that were never A/B'd — adaptive waits, which may only shorten a declared wait and never lengthen it, and a ship that runs the mock walk and the deploy at the same time. The A/B and its 255-step baseline are in handoff/tools; main stays at what the phone has actually walked.
27 lines
1.7 KiB
Plaintext
27 lines
1.7 KiB
Plaintext
### What the walk proves about the card, and what it does not
|
|
|
|
**Proven, on the phone, by `node tests/mobile/smoke.mjs --phone`:** exactly
|
|
one card, on the `playback` channel, carrying the playing track's own title
|
|
(`media-card`, `one-card`); the system holding one media session for the app,
|
|
PLAYING (`media-session`, `one-session`); media keys reaching the player
|
|
through that session with the app in front (`media-keys`); ten seconds in the
|
|
background with the position still advancing (`background`); the paused
|
|
restore waited out past 25 s with the pid intact and no
|
|
`ForegroundServiceDidNotStartInTimeException` (`paused-restore`); and the
|
|
queue window arriving across the bridge, field for field (`queue-window`).
|
|
Printed but never failed, because their `dumpsys` formats have never been read
|
|
back from this phone: whether the service is foreground, whether our audio
|
|
focus is in the system's stack, and whether the becoming-noisy receiver is
|
|
registered (`media-plumbing`).
|
|
|
|
**Kyle's hands only. Nothing here can be automated, and the walk going green
|
|
says nothing about any of it.** Unplugging headphones pauses the music —
|
|
`ACTION_AUDIO_BECOMING_NOISY` is a protected broadcast, refused to the shell
|
|
uid, and our receiver is `RECEIVER_NOT_EXPORTED` besides. Another app taking
|
|
audio focus pauses this one, and giving it back resumes it. The card's LOOK:
|
|
the cover, and the falcon in the status bar — `dumpsys notification` prints a
|
|
resource id and never a pixel, so a correct glyph and a white rectangle read
|
|
identically. And a Bluetooth headset's own buttons, which take a path
|
|
`input keyevent` does not. These four are the first things to try after the
|
|
first deploy of anything that touches this plugin.
|