mirror of
https://github.com/d4rken-org/capod.git
synced 2026-09-15 02:36:12 -04:00
darken
edf84248ab
AirPods Pro 3 can answer a listening mode write with 0x0D 0x01 (Off) while audibly switching to the requested mode. Seen on firmware 81.2675000075000000.6503, intermittently, and not reproducible on demand. CAPod took that report at face value: it surfaced an Off button that isn't even in the device's listening mode cycle, selected it, and said nothing about the request not having been confirmed. - visibleAncModes no longer re-admits a mode purely because it is the current one. That escape clause was what conjured the extra button. - effectiveAncMode keeps showing the requested mode while our own request is outstanding and the device reports a mode it should not be able to reach. - A rejected listening mode request now surfaces a message for every mode, not only Off. Other modes were dropped silently. - The Allow Off inference ignores an Off report that arrived while a different mode was pending, so a single glitch cannot permanently persist "Off is allowed" into the device profile. An unsolicited Off still trains it, which is what keeps the option discoverable after it is enabled elsewhere. - Verification deadline moved from a hardcoded 1000ms to 2000ms, and a matching device report now settles the verification when it arrives. Measured reply latency is 833-1008ms, so the old deadline sat inside the device's normal spread and could fire a bogus divergence plus a redundant re-send. Settling verification on arrival is limited to SetAncMode deliberately. Every other verified command is optimistically written into state when it is queued, so its predicate is satisfied immediately and only the device's contradicting echo makes it fail. Settling those early would swallow the rejection. Note that AirPods never report AllowOffOption (0x34) or ListeningModeCycle (0x1A), so which modes are permitted is always inferred, never device truth.