Release 1.2.0: "Changed by the Buds", serial numbers, the worn line, two tab moves (ai-sessions/0082)

CAPTURE_BLUETOOTH_HCI_SNOOP.md

@@ -1775,6 +1775,29 @@ settings, 24 writes + 9 ANC `Set`s + 4 Ring/Stop byte-identical to their referen
 shows "Signal Catcher … reacting to signal 3" / "Wrote stack traces to tombstoned" once per pull — not an app fault (`CAP-071-FINDINGS.md` §0). **For the next
 run:** the case lid open before the update (P8), no app use before the film (P9), Do Not Disturb on (an incoming call put a third party's number on film).
 
+#### Group BH — the 1.2.0 release build: "Changed by the Buds", the serial numbers, the worn line, the two tab moves, plus the open film items (run as `CAP-072`, skeleton by `ai-sessions/0082`)
+
+Pixel 9a / GrapheneOS, the release-signed **1.2.0** APK (`DECISIONS.md` ADR-058, ADR-059; `ai-sessions/0082`) in the secondary user without Google Play,
+installed **over 1.1.1** (P1 records `firstInstallTime` and `lastUpdateTime` before and after). Scope chosen by the maintainer (chat 2026-10-09, the checkpoint
+of `ai-sessions/0082`). The skeleton `captures/CAP-072-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_BH/CAP-072-EVENT-NOTES.md` holds: **I** the update and the start — the
+Connect-time traffic now thirteen MAESTRO requests (the twelve settings reads, `SubscribeRuntimeInfo`, then **one `GetHardwareInfo`**, byte-identical to the
+official app's `CAP-036` 1415 / `CAP-024` 801), the Info tab's three serial lines (Case, Right bud, Left bud — redacted in every note), the Case sounds card on
+gear → Settings and the Conversation detection card on Controls, "Both buds in the case" on the battery card; **II** ADR-059's six readings against the ears
+on film with a pull on the Connection tab after every wear change (`INEAR-006`: both in the case, only the Left in, both in, the Left out with both worn on
+19 = lead L-1 `INEAR-005`, both on the table ⇒ "Not worn" and a refused ANC tap, in-ear detection off ⇒ "Worn: unknown — …", the `CAP-064` ≈ 28 s case
+watched for 60 s), a press-and-hold on a bud with the app open ⇒ the unprovoked `08 13` and the (i) line "Changed by the Buds at …", then a tap, a pull and
+the tile ⇒ no line; **III** every write once from its (new) place — the two case sounds with the sound observation, conversation detection, the EQ preset
+and a slider, H5, balance, mono, Volume EQ, touch controls, press and hold, the mode list without Off, head gestures, Multipoint, Ring/Stop — each compared
+byte for byte with `CAP-071`'s/`CAP-070`'s requests, and the read-back with the same serials after a reconnect; **IV** the case, Home, Bluetooth off/on with
+a grep of every export for a serial or the MAC; **V** (film 2) C12, S12 and T11 with three `uiautomator` dumps (Controls, Sound, Settings). Test-IDs:
+[`PAIR-003`], [`BATT-004`], [`FW-003`], [`INEAR-006`], [`INEAR-005`], [`INEAR-004`], [`ANC-001`]…[`ANC-004`], [`CASE-001`], [`CASE-002`], [`CONV-001`],
+[`EQP-001`], [`EQS-001`], [`AUDIO-001`]…[`AUDIO-003`], [`HOLD-005`], [`HEAD-001`], [`MULTI-001`], [`CASE-004`], [`CASE-005`], [`FIND-001`], [`FIND-002`].
+**Lessons of `CAP-067`…`CAP-071` built in:** film with sound, the screen recording on (S6, C12 and the (i) texts need it), the system log, Do Not Disturb,
+the lid open before the app starts, no rehearsal before the film, the `adb bugreportz` SIGQUIT note.
+
+**Status:** 🔲 planned. The analysing session writes the findings file (CAP-072-FINDINGS, as every analysed capture has), the `INEAR-006` table (time, ears, Settable byte, field 2, charging flags, the
+Worn text per pull) and proposes — never decides — any change to ADR-049 item 3, ADR-059 or `PROTOCOL.md` §2.2a (L-1); the release verdict for 1.2.0 is its.
+
 ### 4.3 Hardware Actions (either phone)
 
 **Source:** `TESTPLAN_BLUETOOTH_HCI_SNOOP.md` sections 2 (User Actions via the Case & Buds) and 4
@@ -2174,6 +2197,7 @@ is how the 2026-08-18 `CAP-005`/`CAP-007`/`CAP-010` ID-reuse incident (see
 | `CAP-069` | 2026-10-04 | Pixel 7a | 17 (build not on film) | `release_5.203` | official Pixel Buds app **1.0.990706425** (updated 2026-09-30, on film) | BE (new) | `HEAD-001`, `MULTI-001`, `HOLD-003`, `HOLD-004`, `HOLD-005`, `ANC-001`–`ANC-004`, `ANC-006`, `EQP-001`, `EQS-004`, `INEAR-002`–`INEAR-004`, `CASE-004`, `CASE-005`, `FIND-001` (via Find Hub, failed), `FIND-005` (not observable), `PAIR-003`, `BATT-004` | Head gestures (field 29: 1 off / 2 on, 6 filmed writes) and Multipoint (field 11 + SASS bit 2, 4 filmed writes) — ADR-052/053; assistant sessions open with GSND `01 09 … 0a 01 03`; no `Set` for the selected ANC mode (0/3); Default = 0.0 × 5; wear sequence vs GSND Code `0x05`; no Find device in the app; new service `0xbf6c9399` and JitterBuffer on the wire; `CAP-069-FINDINGS.md` | — (no bugreport archive; the raw log) | `CAP-069-btsnoop_hci.log` (from the Bluetooth switch-on; no `.log.last`) | analyzed |
 | `CAP-070` | 2026-10-07 | Pixel 9a (secondary user 10 without Google Play) | 17 (`CP3A.260905.009`) | `release_5.203` | OpenControl for Pixel Buds Pro 2 **1.1.0**, build `0323849`, release-signed (Info tab on film, no -dirty); a first install in user 10 (🟡), not an update | BF (new) | `MULTI-001`, `HEAD-001`, `CASE-001`, `CASE-002` (writes; the case-sound observation not recorded), `AUDIO-002` (writes; audibility not recorded), `AUDIO-003`, `INEAR-005` (wear not on film), `INEAR-002`–`INEAR-004` (ear changes not identifiable), `CASE-004`, `CASE-005`, `EQS-001`, `PAIR-003`, `BATT-004` | The 1.1.0 release test without Play services (`ai-sessions/0075`): 22 sessions each read exactly the twelve settings; 89 of 89 writes byte-identical to the expected frames and ACKed — incl. the first captures of 11 and 29 on channel 19 and `15:1` on channel 21; L-1: the Left taken off on 19 ⇒ `DISC` + 21; Bluetooth off/on + a new process; "—" on film; no audio, no screen recording, no `uiautomator` dumps; release verdict: release `0323849`. `CAP-070-FINDINGS.md` | — (no bugreport archive; the raw logs) | `CAP-070-btsnoop_hci1.log.last` (the unfilmed rehearsal, 05:44–06:10), `CAP-070-btsnoop_hci2.log.last` (06:10–06:37; `CAP-070-btsnoop_hci1.log` is its prefix), `CAP-070-btsnoop_hci2.log` (after the Bluetooth off/on) | analyzed |
 | `CAP-071` | 2026-10-08 | Pixel 9a (secondary user 10 without Google Play) | 17 (`CP3A.260905.009`) | `release_5.203` | OpenControl for Pixel Buds Pro 2 **1.1.1**, build `86a6fb3`, release-signed (Info tab on film, no -dirty; installed APK SHA-256 = `dist/1.1.1`), an update over 1.1.0 (`0323849`, itself added to user 10 at 17:40) | BG (new) | `PAIR-003`, `BATT-004`, `ANC-001`–`ANC-004`, `EQP-001` (preset Balanced), `EQS-001`, `AUDIO-001`–`AUDIO-003`, `CONV-001`, `HOLD-005`, `HEAD-001`, `MULTI-001`, `CASE-001`, `CASE-002` (writes; no chime recorded), `CASE-004`, `CASE-005`, `FIND-001`, `FIND-002`; `INEAR-004` not identifiable, `INEAR-005` not run | The 1.1.1 release test (`ai-sessions/0080`): the update kept data, dark mode and Debug mode; 11 sessions read the twelve settings in order; 24 writes, 9 ANC `Set`s (during playback) and 4 Ring/Stop byte-identical and answered; the read-back after a reconnect; 9 session ends recovered; no behaviour change from the toolchain; film with sound (the Find ring; no case chime), no screen recording, no film 2 (L-1, C12, S12, T11 open); release verdict: release `86a6fb3`. `CAP-071-FINDINGS.md` | — (two `bugreportz` archives, not kept; the raw logs) | `CAP-071-btsnoop_hci1.log.last` (17:37–17:51, before the film), `CAP-071-btsnoop_hci2.log.last` (17:51–18:26; `CAP-071-btsnoop_hci1.log` is its prefix), `CAP-071-btsnoop_hci2.log` (after the Bluetooth off/on) | analyzed |
+| `CAP-072` | *planned* | Pixel 9a (secondary user without Google Play) | 17 (expected) | `release_5.203` (expected) | OpenControl for Pixel Buds Pro 2 **1.2.0** (versionCode 10200), release-signed, an update over 1.1.1 (`86a6fb3`) | BH (new) | `PAIR-003`, `BATT-004`, `FW-003`, `INEAR-006`, `INEAR-005`, `INEAR-004`, `ANC-001`–`ANC-004`, `CASE-001`, `CASE-002`, `CONV-001`, `EQP-001`, `EQS-001`, `AUDIO-001`–`AUDIO-003`, `HOLD-005`, `HEAD-001`, `MULTI-001`, `CASE-004`, `CASE-005`, `FIND-001`, `FIND-002` | The 1.2.0 release test (skeleton by `ai-sessions/0082`): the one new request per Connect (`GetHardwareInfo`, ADR-058) and the serial lines; the worn line (ADR-059) against the ears on film incl. the `CAP-064` ≈ 28 s case; "Changed by the Buds" after a press-and-hold; the two moved switches byte-identical; every write once; the case, Home, Bluetooth off/on; film 2: C12, S12, T11 (three dumps). `captures/CAP-072-yyyy-MM-dd_HH-mm-ss_HH-mm-ss-Group_BH/CAP-072-EVENT-NOTES.md` | TBD | TBD | planned |
 
 **Column notes:**
 

CHANGELOG.md

@@ -11,6 +11,49 @@ build commit `0323849`, hardware run `CAP-070`, `ai-sessions/0075`). See `TODO.m
 
 ## [Unreleased]
 
+## [1.2.0] - not yet released
+
+Prepared in `ai-sessions/0082` (2026-10-09); its hardware run is `CAP-072` (Group BH), after which it is released — or rebuilt as the same version. Three new
+things to see, two switches in new places, and one study. Nothing new is written to the Buds; one new read per connection.
+
+### Added
+
+- **"Changed by the Buds"** in the noise-control card's (i) details: when the Buds report a mode the app did not ask for — a press-and-hold on a bud, or the
+  Buds' own change — the (i) says "Changed by the Buds at HH:MM:SS (a press-and-hold on a bud, or the Buds' own change)." A mode the app set, or read when it
+  connected or refreshed, has no such line. Nothing on the main surface, no notification. (`CAP-069` §12 item 8; fixtures `CAP-045`.)
+- **Serial numbers** on gear → Info, under the firmware (`DECISIONS.md` ADR-058): one `GetHardwareInfo` request per connection — the official app's own, sent
+  after the battery subscription, never retried — and the three strings of its answer, labelled Case / Right bud / Left bud by position, as the official app
+  labels them (the Buds list them in that order). "Not read" with the reason if the Buds do not answer. Serial numbers are never written to the app's log.
+- **"Probably worn"** on the Connection screen's battery card (`DECISIONS.md` ADR-059): from the Buds' last noise-control report (at Connect, Refresh and every
+  noise-control tap), the in-ear detection setting and whether the buds are charging: "Probably worn (checked HH:MM:SS)", "Not worn (checked HH:MM:SS)", "Both buds
+  in the case", or "Worn: unknown — in-ear detection is off". The (i) explains the two limits: the Buds say "at least one bud", never which; and once (`CAP-064`)
+  they reported "worn" for about half a minute with both buds on a table. Nothing new is sent for it.
+
+### Changed
+
+- The two **Case sounds** switches ("Earbuds replaced", "Other alerts") moved from Controls to gear → **Settings** (Dark mode · Case sounds · Use different Buds);
+  their (i) adds "These settings live on the case and are read when the app connects." The requests are unchanged.
+- **Conversation detection** moved from Sound to **Controls** (its own card after In-ear detection, the same subtitle). Sound keeps Balance, Mono audio and Volume
+  EQ. The request is unchanged.
+- The app sends thirteen requests at connect instead of twelve settings reads plus the EQ read and the subscription: the one `GetHardwareInfo` above.
+
+### Studied, not built
+
+- **Volume-level notifications** (the official app's "Volume level notifications" switch): the official app decides on the phone — once per connection it
+  sums seven days of the Buds' `Dosimeter` daily doses and notifies at 67 % of its own constant, at most once per week; the Buds never push a value by
+  themselves. A design with a draft ADR (ADR-060, proposed, not accepted) is in `ai-sessions/0082` and `DECISIONS.md`; it needs a capture with a sound-level
+  meter first (`WELL-002`). A 1.3.0 candidate.
+
+### Known issues
+
+- The worn indicator is a hedged reading of a hypothesis (`DECISIONS.md` ADR-049 item 3): "Probably worn" means the Buds allow a noise-control change, which on
+  film always meant at least one bud in an ear — the app cannot say which bud, and once the Buds reported it with both buds on a table for about half a minute.
+- The serial-number labels (Case / Right bud / Left bud) are the official app's reading of the answer's order, consistent with the strings' own marks; the Buds
+  do not name the parts.
+- The three items above are not hardware-verified before `CAP-072`; the 1.1.1 known issues stay: the app says what a switch sets; the screen-reader text for "—"
+  is checked by the unit tests, not yet on a phone; English only; after you stop a ring by touching the bud, the app keeps saying it is ringing until you tap
+  Stop.
+
 ## [1.1.1] - 2026-10-08
 
 A maintenance release: nothing changes in what the app does or shows. It is built with current build tools and libraries (Kotlin, Jetpack Compose,