Investigation — Final Status

This document grew organically over the 2026-05-02 / 2026-05-03 sessions. Read this top section first — sections below preserve the original investigation narrative including hypotheses that were later refuted, so reading top-down without this summary is misleading.

Final state — what ships today

Wire target: AVRCP 1.3 / AVCTP 1.2 (V1+V2 SDP byte patches), implemented via a JNI-side trampoline chain in libextavrcp_jni.so that bypasses mtkbt's compiled-1.0 AVRCP command dispatcher. Full per-patch reference in PATCHES.md; ICS Table 7 scorecard in BT-COMPLIANCE.md §2.

Current shipped patches by binary:

Pre-v2.0.0 the project shipped a different set against the same binaries (B1-B3 / C1-C3 / A1 / D1 / E3 / E4 / E8 in mtkbt; C2a / b / C3a / b in libextavrcp_jni.so; C4 in libextavrcp.so; H1-H3 in /sbin/adbd) that advertised AVRCP 1.4 / AVCTP 1.3 / SupportedFeatures 0x0033 on the SDP wire but couldn't deliver on the claim — mtkbt's compiled-1.0 dispatcher NACK'd every metadata COMMAND a 1.4-class CT then sent. The Conclusion (2026-05-04) section below documents that pivot. The legacy patch IDs remain referenced throughout the audit trail (Traces #1 etc) but no longer exist in the shipped tree; git log is the authoritative byte-level archive.

Static-analysis findings still load-bearing

• mtkbt IS the AVRCP processor on this device. (Earlier in this doc I hypothesized the BT chip firmware was the processor — that was wrong. The chip firmware blob is the WMT common subsystem, contains zero AVRCP code.)
• mtkbt's documented AVRCP / AVCTP functions are NOT dead code. Earlier scans (Trace #1 / 1b / 1c) missed the indirect-call mechanism — 0x29e98 is reached via PIC-style callback registration through register_callback at 0x2fecc, called from 0x28a5e; 0x3096c is reached via R_ARM_RELATIVE relocation into a 3-slot fn-ptr table at vaddr 0xf94b0..0xf94bc. Trace #1d / 1e / 1f / 1g resolved this. The AV/C parser at 0x6d04a is the only function still confirmed dead.
• Y1MediaBridge.apk is correctly implemented as a dual-interface (IBTAvrcpMusic + IMediaPlaybackService) Binder bridge. The bridge + V1/V2/S1/P1 + F1/F2 + cardinality NOPs + the trampoline chain together form the user-space command-handling pipeline that mtkbt's compiled-1.0 native dispatcher cannot deliver on its own.

The cardinality:0 gate question — resolved by the v2.0.0 pivot

Pre-v2.0.0 traces tried to find where in mtkbt's native AVRCP layer inbound REGISTER_NOTIFICATION events were being dropped (the "cardinality:0 gate") so that the legacy SDP-claim approach could deliver actual COMMANDs. Conclusion (2026-05-04, below) showed the gate could not be located within static-analysis budget. v2.0.0 pivoted to the user-space proxy approach: P1 reroutes inbound VENDOR_DEPENDENT frames into the JNI emit path (msg=519), where the trampoline chain in libextavrcp_jni.so synthesises the AVRCP 1.3 responses directly — bypassing mtkbt's dispatcher entirely. Static-analysis traces on the gate (Trace #1 / 1b / 1c / 1d / 1e / 1f / 1g, plus #4 / #7) are preserved below as historical context but the question they investigated is no longer load-bearing for the shipped pipeline.

Original narrative (preserved for audit trail)

What follows is the original investigation order. Some sections contain hypotheses that were later refuted — those refutations are in subsequent sections. Read the Final Status above for the corrected picture.

Planned Traces

1. mtkbt format-string xref scan (highest value, pure static analysis)

Every [AVCTP]/[AVRCP] format string in mtkbt is referenced from somewhere via PC-relative addressing (ldr rN, [pc, #imm]; add rN, pc). Compute literal-pool entries that resolve to each string's address and find every callsite.

Likely to reveal:

• The function containing [AVCTP] cmdFrame->ctype:%d cmdFrame->opcode:%d — the AV/C command dispatcher entry; the choke point we've been missing.
• The function containing [AVCTP] AVCTP_ConnectRsp not in incoming state:%d — mtkbt's AVCTP state machine.
• The function containing [AVRCP][WRN] AVRCP receive too many data. Throw it! — the silent-drop point.

Output: a map of every [AVCTP]/[AVRCP] log point in the binary, with surrounding function context.

2. ACTIVATE_REQ (msg=500) handler in mtkbt

When the JNI sends msg=500, payload[6]=0x0e (tg_feature), payload[7]=ct_feature, mtkbt receives this on the abstract bt.ext.adp.avrcp socket and dispatches to a handler. The handler stores the TG feature globals on mtkbt's side. Find that handler. Verify whether the stored globals persist across connect_ind/CONNECT_RSP or get cleared per-connection.

3. CONNECT_RSP (msg=507) handler in mtkbt

Same path. JNI sends accept-flag-only via msg=507 (bytes [6][7]=0). Find mtkbt's response handler. If it has a code path like "if features == 0 then mark connection as 1.0" — that's the gate.

4. AVCTP PSM-registration path

[AVCTP] register psm 0x%x status:%d is a log string in mtkbt. Find the registration function — verify it actually registers L2CAP PSM 0x17 for inbound and what callback it installs. If the callback is missing or wrong-pointer, no AVCTP frames ever get parsed.

5. Decompile MtkBt.apk (Java side)

Only two methods are patched in MtkBt.odex (F1 getPreferVersion, F2 disable() reset). The full BluetoothAvrcpService Java class includes the connect-event listener, the play-service interface, and any feature-gate logic on the Java side. May reveal additional version checks not yet touched.

6. Inspect Y1MediaBridge.apk and verify it plays nicely with the patches

The mediabridge service is what supplies metadata to the AVRCP service. Confirm it implements the right callbacks and doesn't unintentionally suppress events that would otherwise propagate to a registered controller. (Source available — first-party app.)

7. Inspect libbluetoothdrv.so

mtkbt links against this. It almost certainly contains the actual L2CAP send / receive primitives. The [AVCTP] register psm call from mtkbt resolves into this library. If the bug lives there, mtkbt is innocent and we've been chasing the wrong binary.

Findings (2026-05-03): see "Trace #7 — Findings" below. All four libbluetooth* libs are HCI / transport-only — zero AVRCP / AVCTP code. The hypothesis was wrong; mtkbt is not innocent.

8. Verify /system/etc/bluetooth/ config end-state on device

audio.conf, auto_pairing.conf, blacklist.conf are touched by the bash flasher but the on-device final state has never been read back. Confirm the patches landed and there's no Disable= or similar override.

Trace #1 — Findings (2026-05-02)

Format-string xref scan complete. All 26 [AVCTP]/[AVRCP] log strings located, every callsite mapped via ldr+add r,pc literal-pool resolution.

Surprising finding: six of eight key documented functions in mtkbt have zero static references — not direct bl / blx targets, not branch targets, not stored as 4-byte literals anywhere, and not computed via ADR / ADD-PC / movw-movt arithmetic visible to static scan.

Implications:

• The AV/C command parser at 0x06d04a (which we patched the surrounding logic of via E5) appears to be unreachable code from anywhere in mtkbt's static call graph. The [AVCTP] cmdFrame->ctype:%d cmdFrame->opcode:%d format string exists, the function exists, but no path leads to it.
• Same for the operation dispatcher containing the E5 patch site — also zero callers.
• mtkbt has no AVRCP / AVCTP exports in dynsym, so libbluetoothdrv.so can't resolve these by name at load time.
• libbluetoothdrv.so itself is only 9,280 bytes and contains zero AVRCP / AVCTP strings — it's a thin shim, not the processor.

Working hypothesis: the AVRCP / AVCTP code visible in mtkbt is dead code (leftover from a prior build that had the daemon do the processing). The actual AVRCP processing is happening either inside the Bluetooth chip firmware or via a path we haven't traced yet. This would explain:

• Why no AVRCP commands ever reach the JNI dispatch socket — mtkbt isn't the dispatcher.
• Why every patch we've made to mtkbt's command path (E5, E7) had no behavioral effect — those code paths are never executed.
• Why tg_feature:0 persists in CONNECT_CNF — mtkbt's view, but the actual TG state lives elsewhere.

This makes patches like B1-B3, C1-C3 (SDP descriptors, which mtkbt is responsible for serving) genuinely effective on the wire (sdptool confirms), while the runtime command-path patches are necessarily inert.

Trace #1b — Walk back from the 12 callers of 0x028c98 (executed 2026-05-02)

Find the actual entry point of mtkbt's connection logic. The 12 callers tell us where "new connection" events come from. Tracing the call chain back finds either an internal entry (in which case the dispatcher chain does exist somewhere in mtkbt that we haven't traced) or a PLT call into libbluetoothdrv.so (in which case the connection event originates from outside mtkbt and our search expands to firmware / IPC).

Findings:

• 12 callers in 12 distinct containing functions.
• Walking back 4 levels: 11 distinct top-level entry points (functions with 0 callers themselves) all eventually call state=1.
• Critically: fn@0x029e98 (the "callback dispatcher TBH" identified in earlier analysis) appears at depth 2 in the walk — it's a top-level entry (0 direct callers) whose descendants include the state=1 setter. So 0x029e98 IS in the live call graph, reached from outside mtkbt as a callback.
• The deepest entry found is fn@0x06adee at depth 4, which has 0 callers but 3 call sites going down.
• None of the "AV/C parser" / "op dispatcher" / "AVCTP RX handler" / "AVCTP register PSM" appear anywhere in this call tree. They are not on the path from any top-level entry to the state=1 setter.

Trace #1c — Scan for runtime writes to BSS function-pointer slots (executed 2026-05-02)

If the 0-caller functions are reached via callbacks, the registration site MUST write the function pointer somewhere. Scan for add rN, pc, #imm; str rN, [rA, #imm] patterns where the computed PC-relative target equals any of the 0-caller function addresses. Captures runtime callback registration sites missed by the literal-pool search.

Findings:

• Zero add rN, pc, #imm; str patterns matching any of the 0-caller function addresses.
• Full scan of .data (385 function pointers) and .data.rel.ro.local (1282 function pointers): none point to the AV/C parser, op dispatcher, AVCTP RX handler, AVCTP register PSM, or AVCTP_ConnectRsp containing fn.
• Full RX-segment scan for any 4-byte literal pointing to any of those addresses: zero hits.

Trace #1 — interpretation

Three independent signals show that several of mtkbt's documented AVCTP / AVRCP functions have no static back-reference to live code:

1. No direct or indirect callers for the AV/C parser, op_code dispatcher (E5 patch site), AVCTP register PSM, AVCTP RX handler, or AVCTP_ConnectRsp containing fn.
2. No stored function pointers to any of these addresses in .data, .data.rel.ro.local, or any literal pool in the RX segment.
3. Not on the live call graph that drives the connection state setters reached at runtime (state=1/3/5 sites all have real callers; the "command path" code does not).

Initial interpretation (REVISED — see below)

I initially concluded these were dead code and that the BT chip firmware was the actual AVRCP TG processor, with mtkbt only managing connection lifecycle. That conclusion is wrong, as confirmed by inspecting the actual chip firmware on disk.

Why the firmware-does-AVRCP claim is wrong

The Y1 BT chip is MT6627 (combo: BT + Wi-Fi + FM + GPS, on MT6572 SoC). The firmware blob is /etc/firmware/mt6572_82_patch_e1_0_hdr.bin, 39,868 bytes, build dated 20130523. Inspecting its strings reveals it is the WMT (Wireless/MediaTek) common subsystem firmware — sleep states, coredump, queue management, GPS desense, Wi-Fi power on/off. It contains zero AVRCP / AVCTP/L2CAP-level strings and no profile-stack code. Confirmed by strings over the blob: only chip-level housekeeping content.

The actual stack architecture:

[mtkbt + libextavrcp_jni.so + MtkBt.apk]   ← Bluetooth profile stack, USERSPACE
        |   AVRCP / AVCTP / L2CAP / HCI parser, all in userspace
        v
[/dev/stpbt]
        |   HCI transport
        v
[mtk_stp_bt.ko]                            ← kernel module
        |
        v
[MT6627 chip]                              ← only handles radio + HCI commands

So mtkbt is the AVRCP processor. There's nowhere else the AVRCP frame parsing can live. Which means the "0-caller" functions in mtkbt must be reached at runtime through some mechanism static analysis missed.

What this implies for the open question

• What we got right: SDP-layer patches (B1-B3, C1-C3, E3, E4, A1, D1) are genuinely effective — sdptool confirms the bytes land on the wire, and mtkbt is what serves SDP. These remain in the script.
• What we got wrong: removing E5 and E7 was the right operational call (they had no observable effect), but the reason I gave was incorrect. The real reason is most likely that my static analysis missed the indirect-call mechanism that wires up mtkbt's AVRCP dispatcher functions to its live code path. Trace #1c looked for a specific pattern (add rN, pc, #imm; str rN, [rA, #imm]) and found nothing, but there are other plausible mechanisms: function-pointer tables in .rodata indexed by op_code, vtable-style indirect dispatch through a struct field initialized at runtime by code I didn't trace, or a TBB / TBH-driven jump table whose target table is built dynamically.
• The gate is still in mtkbt, somewhere we haven't found. It's not in firmware.

Trace #1d / #1e — Findings (executed 2026-05-02)

What was missed in earlier traces

mtkbt is a PIE executable (ET_DYN with e_entry=0xb558, ARM mode). The dynamic loader applies relocations to its .data.rel.ro section at startup. Previous static-only function-pointer searches (literal pools, add+str patterns, movw+movt pairs) completely missed this because:

• .rel.dyn has 3982 entries: 374 ABS32 + 4 GLOB_DAT + 3604 RELATIVE.
• For PIE binaries with load_base=0 (mtkbt's case), R_ARM_RELATIVE entries effectively store addend at r_offset at load time — and the addend lives in the file as a raw 4-byte word at r_offset itself, indistinguishable from data until the loader runs.
• 2392 of those RELATIVE addends point into the RX segment (i.e., function pointers), forming function-pointer tables in .data.rel.ro.

Concrete finding: the op-code dispatcher IS reachable

A 3-slot function-pointer table sits at vaddr 0xf94b0..0xf94bc:

All three are populated at load time by R_ARM_RELATIVE relocations. 0x3096c is the op_code=4 dispatcher (the function E5 patches inside). It's a real runtime target, not dead code. My previous "dead code" verdict for E5 was based on incomplete static analysis — the relocation-driven mechanism wasn't searched.

A larger cluster at vaddr 0xf94c0..0xf954c holds ~75 more Thumb function pointers — likely an op-code-indexed dispatch table for a different protocol layer.

Status of the other "0-caller" functions

Even after the relocation scan, zero R_ARM_RELATIVE relocations install pointers to: AV/C parser (0x6d040/0x6d04a), AVCTP RX handler (0x6d9ba), AVCTP register PSM (0x6d25c), AVCTP_ConnectRsp containing fn (0x6cf30), callback dispatcher TBH (0x29e1c/0x29e98), or AVRCP 1.3/1.4 init (0x02fd02/0x02fd34). They're absent from every reference mechanism we know how to scan: direct branches, literal pools, ADR/ADD-PC arithmetic, MOVW+MOVT pair, R_ARM_ABS32, R_ARM_RELATIVE.

There's a contradiction with Trace #1b: the call-tree walk back from 0x028c98 (state=1 setter) showed fn@0x029e98 (callback dispatcher TBH body) appearing at depth 2 as a top-level entry whose descendants include the state=1 setter. So 0x29e98 IS in the live call graph somehow, even though no relocation mechanism we've checked installs a pointer to it.

Implications for E5

Reverting E5 may have been premature on the operational side — the function it patches IS reachable at runtime. But E5 still made no observable behavioral difference on three different controllers, which suggests one of:

1. The E5 patch site (the BNE inside the version-comparison logic) doesn't get exercised because mtkbt's runtime version classification for our peers takes a different branch before reaching the BNE.
2. The function 0x3096c is reached only for specific op_codes that our peers don't send, so the patched code path never executes.
3. Our peers DO reach 0x3096c at the right moment but with version data that bypasses the patch's effect.

We can't distinguish these without runtime visibility — and the chip-firmware-does-AVRCP theory is now ruled out, so we know mtkbt IS the processor; we just don't see what it does.

Updated open question

The remaining cardinality:0 gate is somewhere inside mtkbt's userspace AVRCP / AVCTP code path. The previous walls all still apply (no root, no btsnoop, daemon-side logs gated to __xlog_buf_printf). Concrete next steps that might break the impasse:

• Trace #1f: Find the code that LOADS pointers from the table at vaddr 0xf94b0..0xf94bc. The literal 0xf94b4 is stored at file_off 0x7cc0 — find the LDR that reads it, find the surrounding function, and follow upward to the caller chain. That chain is the actual op-code dispatch entry into mtkbt's AVRCP processing.
• Trace #1g: Scan ALL blx rN instructions in mtkbt where rN was loaded from [rA + offset] for some memory location, and resolve which load addresses correspond to the function-pointer tables we've identified. This builds an indirect call graph.
• Trace #1h: For the AV/C parser specifically — it parses cmdFrame bytes that originate from inbound AVCTP frames. Find the function that receives AVCTP frames (likely a state machine in the L2CAP receive path) and trace forward to where it dispatches by cmdFrame[3] (opcode byte). That's the AV/C demux. Even if 0x6d04a is dead code, something parses incoming AV/C frames.

These all extend Trace #1 — pure static analysis, no flash cycles.

Trace #1f — Findings (executed 2026-05-02)

0x29e98 IS reachable — confirmed

Traced the callback registration mechanism for the field [conn+0x5cc] (the per-connection callback fn ptr documented in earlier analysis as being read at 0x02fd74 and blx'd to dispatch the AVRCP layer).

Chain found:

register_callback (0x2fecc):
  takes (conn_ptr, fn_ptr, sub_arg) and stores fn_ptr at [conn+0x5cc].

Caller (1 site only): 0x28a5e
  Sets up r1 (the fn_ptr argument) via PIC-style PC-relative computation:
    0x028a56:  ldr r1, [pc, #0x17c]    ; r1 = literal 0x1439  ← offset, not address
    0x028a5c:  add r1, pc               ; r1 = 0x1439 + 0x28a60 = 0x29e99
    0x028a5e:  bl 0x2fecc               ; register_callback(r0=conn, r1=0x29e99, r2=...)

The literal 0x1439 is not a function address — it's a PC-relative offset. The function address is computed at runtime by add rN, pc. Disassembly at the resolved target 0x29e98 matches the documented "callback dispatcher TBH" character-for-character (push.w {...,lr}; tbh [pc, r3, lsl #1]). So:

• 0x29e98 is reachable.
• The earlier analysis of its role is correct.
• The function 0x3096c (E5 patch site) is also genuinely reachable — it lives in the live call chain that this dispatcher reaches via TBH.

Why earlier traces missed this

Trace #1c looked for the wrong shape. The pattern in the binary is:

ldr rN, [pc, #imm]    ; load PC-rel offset literal
add rN, pc             ; compute fn_ptr = literal + PC + 4
bl <register_func>     ; pass fn_ptr as argument

…not the add+str pattern I was scanning for. Also, the literal value (e.g. 0x1439) is a small offset, not a Thumb-LSB-set function address, so the filter (v & 1) and v < 0xf3000 excluded it.

Implication

The "dead code" framing has been wrong twice over: first I attributed the un-trackable references to chip firmware (refuted by inspecting the firmware blob), then to my own static-analysis blind spot (now refuted by finding the actual mechanism). The remaining "0-caller" functions in the AVCTP / AVRCP layer (0x6d04a AV/C parser, 0x6d25c AVCTP register PSM, 0x6d9ba AVCTP RX handler, 0x6cf30 AVCTP_ConnectRsp containing fn) are very likely registered through the same PIC-style mechanism via different register_* functions I haven't enumerated yet. They're not dead.

Why E5 still didn't help operationally

E5's patch site (0x309ec: BNE 0x30aca → B 0x30aca) is inside 0x3096c, which IS reachable. Three remaining possibilities for the lack of behavioral effect:

1. 0x3096c is reached, but its TBH dispatch only routes specific op-codes through the branch we patched; for all other op-codes the BNE site is never reached.
2. The patch correctly forces the branch to 0x30aca, but 0x30aca's downstream logic doesn't actually fire AVRCP 1.4 features for our peer state.
3. Something further upstream (the AV/C parser? the AVCTP RX handler?) is gating whether 0x3096c ever sees a GetCapabilities op-code from our peer in the first place.

Distinguishing these requires runtime visibility we don't have. But the gate is somewhere in this code path, not in firmware or dead code.

Suggested next step (if continuing)

Run the trace #1f mechanism (find PIC-style ldr+add-pc; bl <reg_fn> patterns and resolve the resulting fn pointers) against ALL register-callback-style functions in mtkbt — not just 0x2fecc. That gives a comprehensive map of which "0-caller" functions are actually wired up, and where. From there we can compare to the call chain that processes inbound AVCTP frames and identify the true gate site for cardinality:0.

Trace #1f (full) — Comprehensive PIC fn-ptr enumeration (executed 2026-05-02)

Scanned all 14,417 add rN, pc Thumb-1 sites in mtkbt's .text and resolved 13,825 PIC-style address constructions. 245 of those resolve to addresses that are plausible function entries (have a push prologue at the resolved address).

Classification of the 245 fn-ptr constructions by what immediately follows:

• 63 are bl <register_func> — fn ptr passed as arg to a registration function
• 155 are str rN, [rA, #imm] — fn ptr stored directly into a struct field
• 7 are direct blx rN (rare, indirect tail-call)
• 20 are "other" patterns

Findings vs our 0-caller key functions

Out of the 245 constructions, exactly 4 target our key 0-caller functions — and all 4 target the AVRCP callback dispatcher (0x29e1c / 0x29e98):

The other "0-caller" functions show zero PIC constructions, zero R_ARM_RELATIVE, zero literal pool entries, zero direct callers:

• 0x6d04a AV/C parser → confirmed dead code (never reachable by any mechanism scanned).
• 0x6d25c AVCTP register PSM, 0x6d9ba AVCTP RX handler, 0x6cf30 AVCTP_ConnectRsp containing fn → likely also dead code (alternate implementations).
• 0x02fd34 AVRCP 1.3/1.4 init body → reached via internal b.w tail-call from inside the live function 0x3096c at offset 0x030aca (per earlier analysis). Not registered, just a sub-path within a live function.

The three op-code=4 dispatchers

A 3-slot function-pointer table at vaddr 0xf94b0..0xf94bc holds:

All three are op-code=4 (GetCapabilities) dispatchers for different sub-contexts. They each read different combinations of [conn+0x149] (version) and [conn+0x5d0] (state code) and dispatch differently:

• 0x3060c: 3 reads of [+0x149]; cmps against #0xa0, #0x82
• 0x30708: 2 reads of [+0x149]; cmps [+0x5d0] against #0x82, #0x81, #0x20
• 0x3096c: 1 read of [+0x149]; classic version-dispatch (cmp #0x10 / #0x20)

E5 patched only the 0x3096c branch. If runtime selection picks 0x3060c or 0x30708 for our peers (driven by some other state), the patch never fires.

Why we can't proceed via static analysis alone

To know which of the three dispatchers gets invoked for our peers, we'd need to know:

1. The runtime value of [conn+0x5d0] (state code) when GetCapabilities arrives.
2. The runtime value of [conn+0x149] (version field).
3. Which slot the upstream code reads from the 3-slot table — i.e., which struct field at +0x20/+0x34/+0x44/+0x5cc is consulted.

These are runtime state. Without HCI snoop, daemon log access (xlog buffer), or device-side debugging, we can't observe them. The static call graph branches at this node and we can't predict which branch fires.

Trace #1g (full) — Indirect-call resolution complete (2026-05-02)

The 7 callback-invoker functions

Mapped all 14 readers of [conn+0x5cc] (the callback fn ptr slot holding 0x29e98). 10 are non-PC-relative (genuine struct-field reads); they live in 7 distinct functions that invoke the AVRCP callback dispatcher:

All three op-code=4 dispatchers (0x3060c, 0x30708, 0x3096c) reach the callback — they're not mutually exclusive paths. So the question of "which one fires" is really "which one runs the path that does invoke the callback for this connection". Each has different gating logic before the [+0x5cc] read.

Concrete patch candidate found in fn 0x3060c

The cleanest gate site is in fn 0x3060c:

0x030658:  ldrsb.w r0, [r4, #0x149]      ; SIGNED load
0x03065c:  cmp r0, #0
0x03065e:  bge #0x30688                   ; ★ if [+0x149] >= 0 (high bit clear), bypass 1.4
0x030660:  ...
0x030684:  b.w #0x2fd34                   ; tail-call AVRCP 1.3/1.4 init

Single-byte patch (E8 candidate): 0x3065e: 13 da → 00 bf (NOP the BGE).

Caveat: every immediate write to [conn+0x5d9] (which feeds [+0x149]) sets the high bit (0x90, 0xa0, 0xc0, 0xd0, ...), so for normal peers [+0x149] is negative as a signed byte and the BGE is NOT taken — the gate doesn't fire. The patch only matters if our peers' [+0x149] somehow ends up with high bit clear (uninitialized, or written via an untraced code path). We can't determine this statically.

Trace #4 — Java decompilation of MtkBt.apk (executed 2026-05-02)

Tooling and access

MtkBt.dex (extracted from MtkBt.odex at offset 0x28) contains ODEX-optimized opcodes (e.g., invoke-virtual-quick, iget-quick, vtable@N) that pure DEX parsers reject. Disassembly required:

java -jar baksmali-2.5.2.jar disassemble --allow-odex-opcodes -a 17 MtkBt.dex

(Plain androguard fails with InvalidInstruction: opcode '0xf7' is unused; baksmali with the --allow-odex-opcodes flag and Android 4.2 API level (17) handles them.)

Key class structure

In com.mediatek.bluetooth.avrcp:

• BluetoothAvrcpService — top-level service. Has all *Native() JNI methods plus matching event handlers (connectInd, connectCnf, activateCnf, registerNotificationInd, etc.).
• BTAvrcpMusicAdapter — bridge to the music play service. Owns the cardinality bitset (field@0x90 = mRegBit) and the EventList (field@0x78). Handles registerNotification(B, I)Z per-event.
• BTAvrcpProfile.getPreferVersion()B — F1 patch site, returns 0xe after patch.
• IBTAvrcpMusic$Stub and IBTAvrcpMusicCallback$Stub — IPC interfaces to / from Y1MediaBridge.

BTAvrcpMusicAdapter.getSupportVersion()B

getSupportVersion():
    if (sPlayServiceInterface) return 0x0e   ; AVRCP 1.4
    else                       return 0x0d   ; AVRCP 1.3

Confirms F2's importance: disable() resetting sPlayServiceInterface = false is required so that re-activation doesn't see stale state.

BTAvrcpMusicAdapter.checkCapability()V

v2 = getSupportVersion()    ; v2 = 0xe (1.4) or 0xd (1.3)
if (field@0xf4 == 1):
    log "version: <v2>"     ; second-call: just log and return
    return
log "init capability version: <v2>"   ; ★ matches our logcat: "version:14"
field@0xf4 = 1                          ; mark initialized

if (v2 == 0xe):
    field@0x78 = new byte[5]            ; 1.4 EventList
else:
    field@0x78 = new byte[2]            ; 1.3 EventList

field@0x78[0] = 1   ; PLAYBACK_STATUS_CHANGED
field@0x78[1] = 2   ; TRACK_CHANGED
if (v2 == 0xe):
    field@0x78[2] = 9   ; NOW_PLAYING_CONTENT_CHANGED  (1.4)
    field@0x78[3] = 0xa ; AVAILABLE_PLAYERS_CHANGED   (1.4)
    field@0x78[4] = 0xb ; ADDRESSED_PLAYER_CHANGED    (1.4)

field@0x90 = new BitSet(16)    ; cardinality bitset (mRegBit)
[email protected]()

Logcat confirms init capability version:14 so the 1.4 path runs and EventList is populated correctly.

BTAvrcpMusicAdapter.registerNotification(B, I)Z

This is the cardinality update site:

switch (eventId):
    case 1, 2, 9:    handle (delegate to BluetoothAvrcpService notification* method) → bReg = true
    case 3, 4, 5, 8: log "[BT][AVRCP] MusicAdapter blocks support register event:%d", bReg = false
    case 6, 7:       delegate to BluetoothProfileManager (vtable@15)
    case 10, 11, 12: fall through, bReg unchanged (= false)
    case 13:         log "blocks", bReg = false

if (bReg):
    synchronized (field@0x90):
        [email protected](eventId)              ; ★ THE cardinality update
        log "[BT][AVRCP] mRegBit set %d Reg:%b cardinality:%d"
return bReg

BluetoothAvrcpService.registerNotificationInd(B, I)V

Calls BTAvrcpMusicAdapter.registerNotification(eventId, interval) (via field@0x24 = music adapter, vtable@75) for any eventId not in the special set {0xa, 0xb, 0xc}. Logs [BT][AVRCP](test1) registerNotificationInd eventId:%d interval:%d on entry.

Definitive verdict

The user's logcat over multiple sessions shows:

• Neither [BT][AVRCP](test1) registerNotificationInd eventId:%d (the registration entry log)
• Nor [BT][AVRCP] mRegBit set %d Reg:%b cardinality:%d (the cardinality update log)
• Nor [BT][AVRCP] MusicAdapter blocks support register event:%d (the rejection log)

Therefore registerNotificationInd never fires — i.e., the JNI never receives a "REGISTER_NOTIFICATION arrived" event from mtkbt. Combined with our prior observation that no inbound AVRCP Recv AVRCP indication msg_ids beyond 501/505/506/512 are seen, this definitively locates the cardinality:0 gate inside mtkbt's native AVRCP layer, between the AVCTP receive path and the JNI dispatch socket.

Java layer ruled out

The Java layer:

• Initializes correctly (1.4 EventList ready).
• Handles incoming subscriptions correctly (events 1/2/9 succeed; 3/4/5/8/13 explicitly blocked; the others no-op).
• Has no version gate or capability check that would suppress events when they DO arrive.

No additional Java / smali patches will help. F1 + F2 are necessary AND sufficient on the Java side. The gate is unambiguously below.

The honest end of the static investigation

After Trace #1f the architectural picture is finally complete and consistent:

• mtkbt IS the AVRCP processor (not chip firmware). ✓ confirmed by inspecting firmware blob.
• The documented dispatchers (0x29e98, 0x02fd34, 0x3096c) are all reachable at runtime — via PIC-style callback registration that earlier traces missed. ✓ confirmed.
• 0x6d04a "AV/C parser" is dead code — multiple independent searches confirm no caller mechanism reaches it. ✓ confirmed.
• The cardinality:0 gate is in the runtime decision tree of [conn+0x5d0] × [conn+0x149] × dispatcher-table selection, somewhere in the 0x29e98 → 0x3060c/0x30708/0x3096c family of paths.
• Static analysis cannot determine which decision point fires for our peers without observing runtime values. Every structural and addressable element has been mapped.

The remaining diagnostic options (HCI snoop / chip firmware modification / runtime instrumentation patches that emit observable side effects) are all out of scope per the constraints established at session start.

The repo (B1-B3, C1-C3, A1, D1, E3, E4, plus C2a / b, C3a / b, C4, F1, F2 across the four binaries) represents the complete set of demonstrably-effective patches reachable through static analysis. Y1MediaBridge is correctly implemented and ready to fire the moment the runtime gate releases.

Trace #7 — Findings (2026-05-03): MT6572 BT lib stack is HCI-only

The four libbluetooth* shared objects in /system/lib were inspected end-to-end (sizes, dynsyms, full strings):

Combined strings search across all four libraries returned ZERO hits for avrcp, avctp, profile, capability, notif, metadata, cardinal. They are exclusively HCI / transport — UART connection to the MT6627 chip, BD-address management from NVRAM, and chip-bringup HCC commands. Nothing above HCI.

Implication. The cardinality:0 gate cannot live in any userland library other than mtkbt. mtkbt does not call back through any of these libraries for AVCTP / AVRCP processing — it uses them only for HCI transport via bt_send_data/bt_receive_data. AVCTP framing, L2CAP demux, and AVRCP command dispatch all happen inside mtkbt's own code segment. This narrows the search space conclusively to mtkbt.

This trace was deferred during 2026-05-02 work as low-priority ("almost certainly a thin shim"). Confirmed 2026-05-03; the deferral was correct but the verification was cheap and worth doing before considering root.

Out of Scope (eliminated)

• HCI snoop / btsnoop — no root, eliminated in earlier passes.
• mtkbt instrumentation patches (insert log calls at choke points) — possible but very high effort, low marginal value over #1 + #2.
• boot.img init scripts — won't reveal anything about the AVRCP path.

Conclusion (2026-05-04) — byte-patch path exhausted, proxy work needed

After the original investigation in this document concluded the gate was upstream of the op_code=4 dispatcher, post-root work in May 2026 added the diagnostic infrastructure to actually see what mtkbt and peers were doing on the wire (@btlog tap, dual-capture, btlog-parse, probe-postroot — all in tools/ and src/btlog-dump/) and ran a series of byte-patch experiments to test increasingly informed hypotheses about the SDP-record shape required by working AVRCP CTs.

The byte-patch hypothesis is conclusively dead. Five distinct (version, features) combinations were tested:

Reference: Pixel 4 ↔ Sonos works at every AVRCP version 1.3-1.6 (per user-supplied sdptool browse F0:5C:77:E4:30:62 outputs at each Developer-Options-forced version, captured 2026-05-04). The Pixel at 1.3 advertises features 0x0001 — the same value Y1 stock advertises — and Sonos receives full title / artist / album metadata + responds correctly to PASS_THROUGH play / pause. The difference is not the SDP advertisement. It is mtkbt's command-handling layer.

mtkbt is internally an AVRCP 1.0 implementation. Compile-time string [AVRCP] AVRCP V10 compiled + runtime log AVRCP register activeVersion:10 are accurate. The opcode dispatchers identified earlier in this document (0x3060c, 0x30708, 0x3096c at op_code=4 = GetCapabilities) exist in the binary, but no inbound packet from any peer ever reaches them, regardless of how we shape the SDP record. The earlier "the gate is upstream of the dispatcher table" framing was correct; the missing piece was that there is no upstream gate that byte-patches can flip — mtkbt's AVCTP RX simply does not classify AVRCP COMMAND PDUs as anything its 1.0 dispatcher recognises, and silently drops them.

The previously-listed primary lead, MSG_ID_BT_AVRCP_CONNECT_CNF result:4096, was also disproven during this work: the same 0x1000 value is emitted at MSG_ID_BT_AVRCP_ACTIVATE_CNF time 3 ms after the JNI sends ACTIVATE_REQ, before any peer is involved. 0x1000 is mtkbt's standard "request acknowledged" status code, not a peer-feedback or "feature degraded" indicator.

Repo state after the conclusion (commits 2690d05 → 7077b5a → bd36160 → this one)

• --avrcp is now a known-broken opt-in. It runs if explicitly requested (useful for the proxy work below) and prints a startup warning. Excluded from --all.
• --bluetooth no longer sets persist.bluetooth.avrcpversion=avrcp14. The remaining audio.conf / auto_pairing.conf / blacklist.conf / ro.bluetooth.class / ro.bluetooth.profiles.*.enabled properties are pairing-essential and stay.
• The recommended baseline is --all (without --avrcp): pairing works, A2DP audio works, AVRCP 1.0 PASSTHROUGH (play / pause / skip) works, no metadata over BT.
• Diagnostic infrastructure remains in-tree: src/btlog-dump/ (no-libc ARM ELF that taps mtkbt's @btlog socket), tools/btlog-parse.py (frame decoder), tools/dual-capture.sh (btlog + logcat correlated capture), tools/probe-postroot.sh + tools/probe-postroot-device.sh (one-shot post-root sanity probe).
• Failed-experiment scripts (Browsing-bit, Pixel-shape, Pixel-1.3 mimic, features-only) have been removed from tools/. Their results are summarised in the table above and in CHANGELOG.md.

Path forward — user-space AVRCP proxy

Three architecture sketches were considered when the byte-patch path was first ruled out (see commit messages around bd36160). The smallest viable one is sketched below.

Approach: trampoline mtkbt's silent-drop site to forward unhandled AVRCP COMMANDs raw to the JNI; respond from Java.

The work is roughly four phases.

Phase 1 — Identify the silent-drop site (gdbserver, ~1-2 days)

Push an API-17 ARM AOSP-prebuilt gdbserver to /data/local/tmp/, attach to the live mtkbt PID. PIE base is 0x400c1000 (per tools/probe-postroot.sh §1; verify on each session — the base is per-process not per-firmware). Set breakpoints on the candidate drop sites identified in the appendix below:

• 0x6d9ba (live 0x40128d9a) — AVCTP RX handler
• 0x6cf30 (live 0x40128f30) — AVCTP_ConnectRsp
• 0x0513a4 (live 0x401123a4) — [AVRCP][WRN] AVRCP receive too many data. Throw it! log site
• 0x29e98 (live 0x400d2e98) — TBH callback dispatcher

Trigger the failure scenario (Y1 ↔ Sonos with --avrcp on so peer engages enough to send a COMMAND). Whichever breakpoint fires when the single AVCTP_EVENT:4 arrives is the candidate drop site. Dump the inbound packet bytes from r0 / r1 / stack at that point and confirm they're a real AVRCP COMMAND PDU (op_code 0x4 = GetCapabilities is the most likely first command).

tools/probe-postroot.sh §11 confirmed SELinux is absent on this firmware and §12 confirmed /proc/sys/kernel/yama/ptrace_scope doesn't exist either, so ptrace attach is unblocked.

Phase 2 — Patch a trampoline (~3-5 days)

At the identified drop site, replace the silent-drop branch with a bl <trampoline>. The trampoline (in a code-cave or appended to mtkbt's .text) marshals the inbound packet into a new IPC message — e.g., msg_id 999 — and writes it to the existing bt.ext.adp.avrcp abstract socket that already carries msg_ids JNI↔mtkbt. The IPC framing and the existing send wrapper at vaddr 0x511c0 are documented in the appendix below.

Verification: tools/btlog-parse.py should now show the AVRCP COMMAND bytes flowing through the new msg_id; logcat should show the JNI receiving msg_id 999 (or whatever ID we pick).

Phase 3 — Java AVRCP COMMAND parser / responder (~1-2 weeks)

Extend Y1MediaBridge (or add a sibling Java component) to:

1. Receive the new msg_id from the JNI via the existing Binder path.
2. Parse the AVCTP+AVRCP frame: AV/C control header, op_code, PDU ID, transId, params.
3. Build the appropriate AVRCP RSP for at minimum:
   • GetCapabilities (PDU 0x10)
   • RegisterNotification (PDU 0x31) for EVENT_TRACK_CHANGED (0x05) and EVENT_PLAYBACK_STATUS_CHANGED (0x01)
   • GetPlayStatus (PDU 0x30)
   • GetElementAttributes (PDU 0x20)
4. Use the existing IBTAvrcpMusic / IBTAvrcpMusicCallback plumbing for the actual track / state data — Y1MediaBridge already sources this from the music player via broadcast intents and RCC.

PASS_THROUGH (op_code 0x7C) commands should pass through to the existing 1.0 path so play / pause keeps working — don't intercept those.

Phase 4 — Outbound RSP path (~3-5 days)

Patch a second trampoline (or extend the first) that takes a Java-built AVRCP RSP frame, marshals it into an outbound msg_id, and routes it through mtkbt's existing AVCTP TX path so it reaches the peer's AVCTP channel. The IPC dispatcher map in the appendix below (msg_ids 500-611, second TBH at vaddr 0x518ac) names the candidate slots.

Verification target

tools/dual-capture.sh against Sonos should show:

• cardinality:N non-zero in MMI_AVRCP: ACTION_REG_NOTIFY for notifyChange ... cardinality:N
• MMI_AVRCP: registerNotificationInd eventId: firing for events 1/2/9
• Sonos app showing title / artist / album for the currently-playing track
• Y1MediaBridge log lines notifyAvrcpCallbacks code=N targets=>=1 (currently always logs targets=0 because MtkBt never registers a callback — the proxy work fixes this by routing peer-side RegisterNotification through Java)
• Physical play / pause from Sonos still working (PASSTHROUGH path unbroken)

Known prerequisites for the next agent

• Read this entire document top-down — the failure modes earlier in the doc (G1 / G2 SIGSEGV at NULL, blanket xlog redirect being too fragile, etc.) are real and re-tripping them wastes days.
• Re-verify tools/probe-postroot.sh outputs against the device before assuming PIE base / PSM list / SELinux state. The probe is idempotent and cheap.
• The diagnostic tooling (@btlog tap, dual-capture, parser) was developed against firmware 3.0.2. If KNOWN_FIRMWARES gains a new entry, re-verify the framing against that firmware before trusting parsed output.
• --avrcp MUST be enabled to test the proxy work (otherwise the Y1MediaBridge bridge isn't installed and there's no Java endpoint for the proxy to deliver to). The startup warning is informational; ignore it for the duration of the proxy work.

Estimated total

2-4 weeks of focused work for someone with ARM Thumb-2 binary RE + Android Bluetooth experience. The diagnostic infrastructure is in place; the gating risk is finding a viable drop site in mtkbt that we can hook without destabilising AVCTP. If no clean site exists (e.g., the drop happens inline rather than at a callable choke point), the alternative is the larger Option 2 — disable mtkbt's AVRCP entirely and bind PSM 0x17 from Java — which is a multi-month rewrite.

Appendix — Reference detail (originally maintained as the working-notes brief, archived 2026-05-04)

This appendix preserves the granular detail from a working-notes brief that was maintained externally to the repo during the 2026-05-02 → 2026-05-04 investigation. The narrative above (top of doc) is the canonical history; the conclusion above is the canonical end-state. This appendix is reference data: byte-level patch tables, MD5s, function offsets, ILM layouts, msg_id maps, log tag conventions, and the post-root traces (#8–#11) that complement the original Traces #1–#7. Future work should consult both halves of this document. The brief itself is no longer maintained.

Device Context

Architecture

[Car Stereo CT] <--SDP / AVRCP--> [mtkbt daemon] <--socket bt.ext.adp.avrcp--> [libextavrcp.so]
                                       |                                           ^
                                       | HCI / UART                     [libextavrcp_jni.so]
                                       v                                           ^
                                  [/dev/stpbt]                            [MtkBt.apk Java layer]
                                       |
                                       v
                              [mtk_stp_bt.ko (kernel)]
                                       |
                                       v
                                [MT6627 chip — HCI / radio only]

The socket bt.ext.adp.avrcp lives in ANDROID_SOCKET_NAMESPACE_ABSTRACT (namespace=0). Abstract sockets have no filesystem file and are auto-released on FD close; no stale socket is possible across BT toggle cycles.

Trace #7 confirmed all four libbluetooth*.so libs (libbluetoothdrv.so, libbluetooth_mtk.so, libbluetoothem_mtk.so, libbluetooth_relayer.so) are HCI / transport-only. Combined strings search returned zero hits for avrcp / avctp / profile / capability / notif / metadata / cardinal. The cardinality:0 gate cannot live anywhere except inside mtkbt.

Additionally, mtkbt exposes an undocumented SOCK_STREAM listener at the abstract socket @btlog (created by socket_local_server("btlog", ABSTRACT, SOCK_STREAM) at vaddr 0x6b4d4). Connecting to it as root yields a stream of mtkbt's __xlog_buf_printf output plus decoded HCI command / event traffic — the diagnostic capability used by tools/dual-capture.sh and Trace #9. See src/btlog-dump/README.md for the framing format.

The legacy 11-patch --avrcp byte-patch set — DELETED in v2.0.0

The pre-v2.0.0 --avrcp flag shipped 11 byte patches against mtkbt (B1-B3 AVCTP version, C1-C3 AVRCP version, A1 runtime SDP MOVW, D1 registration-guard NOP, E3/E4 SupportedFeatures, E8 op_code=4 dispatcher gate) plus 4 against libextavrcp_jni.so (C2a/b/C3a/b) plus 1 against libextavrcp.so (C4 version constant). All advertised AVRCP 1.4 / AVCTP 1.3 / SupportedFeatures 0x0033 on the wire (sdptool-confirmed) but mtkbt's compiled-1.0 command-handling layer NACK'd every metadata COMMAND that 1.4 controllers then sent — net regression vs stock 1.0 PASSTHROUGH.

The Browsing-bit experiment (Trace #11) and Pixel-shape experiment (set features 0xd1 including Browsing + Multi-Player) closed the question: when we advertised Browse, Sonos opened browse PSM 0x1B, mtkbt's L2CAP rejected (+@l2cap: cannot find psm:0x1b!), and Sonos gave up on AVRCP altogether. Since v2.0.0 the served record advertises AVRCP 1.3 / AVCTP 1.2 (V1+V2) with no 0x000d AdditionalProtocolDescriptorList — see PATCHES.md for the current shipped set.

Several reverted-during-development entries (E1, E2, E5, E7a/b state-gate / op_code-dispatcher NOPs; G1 / G2 xlog-redirect thunks that broke BT init) were closed mid-stream during the legacy era and don't survive in the current tree either. Conclusion specifically for the xlog-redirect line of work: blanket redirect at the consolidated wrapper at vaddr 0x675c0 is too fragile (hit ~3000 times in mtkbt's lifecycle including very early init). The @btlog passive tap from Trace #9 supersedes the read-only-observation need entirely; behavioural instrumentation, if ever needed, must be surgical (hardcoded tag / fmt strings via a trampoline at a small number of high-value sites).

Byte-level offsets and tables for any of these patches: git log --all -- src/patches/patch_mtkbt.py src/patches/patch_libextavrcp_jni.py src/patches/patch_libextavrcp.so covers the full edit history through the v2.0.0 deletion commit.

adbd Root Patches (H1 / H2 / H3) — Closed 2026-05-03 (failed on hardware), superseded by setuid /system/xbin/su

Status: closed. Both attempted revisions caused "device offline" on hardware. --root flag removed from apply.bash in v1.7.0 then reintroduced in v1.8.0 against /system/xbin/su instead. The standalone patch_adbd.py and patch_bootimg.py scripts (kept in the tree until v2.0.0) were removed in v2.1.0; the analysis below is preserved for whoever picks up the root pass with a different mechanism.

The OEM adbd has stripped the standard AOSP should_drop_privileges() gating. strings adbd returns ZERO references to ro.secure. The drop_privileges block at vaddr 0x94b8 runs unconditionally on every adbd startup.

0x94b8:  movs   r0, #0xb           ; arg0 = count = 11               ← H1
0x94ba:  add    r1, sp, #0x24      ; arg1 = gid_array on stack
0x94bc:  blx    #0x17038           ; setgroups(11, gids)
0x94c0:  cmp    r0, #0
0x94c2:  bne.w  #0x97ea            ; on failure → exit(1)
0x94c6:  mov.w  r0, #0x7d0         ; arg0 = AID_SHELL = 2000          ← H2
0x94ca:  blx    #0x1701c           ; setgid(2000)
0x94ce:  cmp    r0, #0
0x94d0:  bne.w  #0x97ea
0x94d4:  mov.w  r0, #0x7d0         ; arg0 = AID_SHELL = 2000          ← H3
0x94d8:  blx    #0x19418           ; setuid(2000) wrapper → bl 0x27b30; eventually mov r7,#0xd5; svc 0
0x94dc:  mov    r3, r0
0x94de:  cmp    r0, #0
0x94e0:  bne.w  #0x97ea

Final approach (arg-zero, 2026-05-03 revision): change only the argument loads so the syscalls execute with arguments of 0. All bionic bookkeeping (capability bounding-set, thread-credential sync) runs normally; the process ends up at uid=0/gid=0 with no supplementary groups.

Confirmed blx targets:

• 0x17038 → ARM-mode mov r7, #0xce ; svc 0 (setgroups32 EABI #206)
• 0x1701c → ARM-mode mov r7, #0xd6 ; svc 0 (setgid32 EABI #214)
• 0x19418 → ARM wrapper that does bl 0x27b30 before reaching mov r7, #0xd5 ; svc 0 at 0x31a70 (setuid32 EABI #213) — the bl 0x27b30 is the load-bearing bookkeeping (likely capability bounding-set / thread-credential sync) that the original NOP-the-blx revision skipped.

Why default.prop edits alone don't work. Empirical confirmation 2026-05-03: adb shell id returned uid=2000(shell) despite ro.secure=0/ro.debuggable=1/ro.adb.secure=0 correctly set per getprop. adb root is also actively harmful on the un-patched binary — adbd accepts the request (ro.debuggable=1 passes the permission check), sets service.adb.root=1, exits to be respawned, hits the same unconditional drop_privileges path again, and the self-restart triggers a USB rebind that the stock MTK adbd handles poorly (host loses the device until reboot).

Why arg-zero, not NOP-the-blx (history). An earlier revision NOPed the three blx calls outright. On hardware, however, adb shell and adb root both returned "device offline" — adbd starts and the USB endpoint enumerates, but the ADB protocol handshake never completes. The bionic setuid wrapper at 0x19418 does bl 0x27b30 before reaching the actual syscall stub, doing capability bounding-set / thread-credential bookkeeping that downstream adbd code depends on. NOPing the call entirely skips that bookkeeping → process is uid 0 nominally but has inconsistent credentials / capabilities → the USB ADB protocol layer never fully initializes. The arg-zero revision keeps every syscall and every bionic wrapper intact; setuid(0) when EUID is already 0 is a no-op that runs all the same bookkeeping. Same for setgid(0). setgroups(0, _) clears supplementary groups, which is the desired end state anyway. Even so, arg-zero ALSO failed on hardware ("device offline"); root cause never fully diagnosed because losing ADB makes diagnosis circular.

patch_bootimg.py extracted /sbin/adbd from the boot.img ramdisk cpio in-place, applied H1 / H2 / H3 via patch_adbd.patch_bytes(), and wrote it back. Same file size (223,132 bytes) so cpio record offsets are unchanged.

Root via setuid /system/xbin/su — v1.8.0 (verified on hardware 2026-05-04)

Status: hardware-verified 2026-05-04. First flash + adb shell → su → id returned uid=0(root) gid=0(root). Replaces the failed H1 / H2 / H3 adbd byte-patch path; got us out of the "patched adbd is broken / can't even diagnose because we just broke ADB" trap.

Verification log:

$ adb devices
List of devices attached
0123456789ABCDEF    device

$ adb shell
shell@android:/ $ id
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),...
shell@android:/ $ su
shell@android:/ # id
uid=0(root) gid=0(root) groups=1003(graphics),1004(input),...

su resolved without explicit path → /system/xbin/su is on $PATH. Prompt flipped $→#. No password prompt, no manager APK gating. The 892-byte direct-syscall escalator works exactly as designed.

Strategy

Sidestep adbd entirely. Stock /sbin/adbd is left untouched and continues to drop privileges to uid 2000 (shell) at boot — ADB protocol handshake comes up cleanly, identical to stock behavior. Root is then obtained per-session by exec'ing a setuid-root binary at /system/xbin/su.

The binary is built from src/su/su.c (~80 lines of C) + src/su/start.S (~10 lines of ARM Thumb-2 assembly), entirely in-tree:

• No libc dependency — direct ARM-EABI syscall implementation. setgid(0) → setuid(0) → execve("/system/bin/sh", …). Three invocation forms: bare su (interactive root shell), su -c "<cmd>" (one-off), su <prog> [args…] (exec-passthrough).
• No supply chain beyond GCC + this source. No SuperSU / Magisk / phh-style binary imported, no manager APK, no whitelist.
• Build via cd src/su && make. Output: 892-byte statically-linked ARMv7 ELF, soft-float, EABI v5, no NEEDED entries. Output MD5 (current): a87dc616085e1a0e905692a628e747e7.

The bash patcher's --root flag does:

sudo install -m 06755 -o root -g root src/su/build/su /mnt/y1-devel/xbin/su

against the mounted system.img. No boot.img extraction, no ramdisk repack, no /sbin/adbd byte-patches.

Trade-offs

• Anyone who can exec /system/xbin/su becomes root. No permission-prompt UI, no whitelist. Acceptable for a single-user research device. Not appropriate for a consumer ROM.
• The binary is intentionally tiny + direct so every byte is auditable. Statically linked means a future bionic mismatch can't brick the escalator.

Why this should work where H1 / H2 / H3 didn't

The H1 / H2 / H3 failure mode was: patched /sbin/adbd got into a state where ADB protocol initialization failed, and once you've shipped a broken adbd you can't diagnose what broke it (you've lost ADB). The su install touches NOTHING in the boot path — adbd, init, ramdisk, even default.prop are all stock. If /system/xbin/su somehow doesn't work post-flash, ADB still works fine; we can pull /system/xbin/su and check what's wrong (perms? mode bits? signing? wrong arch?) without losing visibility.

Watch-items on the root install itself

• SELinux / /system enforcement. The current su works because Android 4.2.2 + this OEM build apparently allows setuid binaries on /system to escalate. If a future firmware update hardens this, the manager-APK-paired SuperSU/Magisk fallback would become necessary.
• Cross-firmware portability. su is verified on v3.0.2 only. If the KNOWN_FIRMWARES manifest gains other firmware versions (e.g. a hypothetical 3.0.3), re-verify --root against each.
• Kernel-level fallback (CVE-based exploits against the 3.4-era kernel) and MTK-specific accessory binaries (mtk_mtkbt_root etc.) remain available if the setuid path is ever closed.

mtkbt AVRCP State Machine Analysis

Key Globals

State Machine Values

Three op_code=4 dispatchers (3-slot fn-ptr table at vaddr 0xf94b0..0xf94bc)

Confirmed reachable via R_ARM_RELATIVE relocations populated at load time.

All three reach the AVRCP callback via [conn+0x5cc] (mapped to fn 0x29e98) — they're not mutually exclusive paths, but each has different upstream gating logic. Post-E8 testing definitively showed none of the three are reached for our peers: only msg_ids 505 and 506 ever arrive, never op_code=4. This is now understood (per the 2026-05-04 conclusion) as mtkbt's AVCTP RX silently dropping unrecognized AVRCP COMMANDs at a layer upstream of the dispatcher table, because mtkbt's compiled command set is 1.0-only.

Callback registration mechanism (Trace #1f)

0x028a56:  ldr r1, [pc, #0x17c]    ; r1 = literal 0x1439 (PC-rel offset)
0x028a5c:  add r1, pc               ; r1 = 0x1439 + 0x28a60 = 0x29e99
0x028a5e:  bl 0x2fecc               ; register_callback(conn, 0x29e99, ...)

register_callback (0x2fecc):
  takes (conn_ptr, fn_ptr, sub_arg) and stores fn_ptr at [conn+0x5cc].

The literal 0x1439 is not a function address — it's a PC-relative offset. Earlier static-analysis searches missed this pattern. The earlier documented analysis of 0x29e98 (callback dispatcher TBH) elsewhere in this document is correct; the function is reachable, just registered through a PIC-style mechanism.

The remaining "0-caller" functions (0x6d04a AV/C parser, 0x6d25c AVCTP register PSM, 0x6d9ba AVCTP RX handler, 0x6cf30 AVCTP_ConnectRsp) show zero PIC constructions, zero R_ARM_RELATIVE, zero literal pool entries, zero direct callers. Likely registered through similar mechanisms via different register_* functions not yet enumerated.

Post-D1 Analysis — Why tg_feature:0 Persists in CONNECT_CNF

CONNECT_CNF handler dissection (libextavrcp_jni.so)

The receive loop (FUN_0x5f0c) dispatches on msg_id using a TBH at 0x60B8. Resolved jump table:

CONNECT_CNF handler at 0x62EA:

1. Reads result from ILM+0x02, conn_id from ILM+0x01 → log
2. Reads bws from ILM+0x0c, tg_feature from ILM+0x0e, ct_feature from ILM+0x10 → log
3. Loads global flag; if flag=1: sends browse connect req; else: exits to function epilogue

tg_feature is read and logged, then discarded. Whether 0 or non-zero, behavior is identical. cardinality is not set here.

connect_ind handler and CONNECT_RSP payload

connect_ind handler (0x619C) calls btmtk_avrcp_send_connect_ind_rsp (PLT 0x3618) at 0x62A8:

0x62a0:  ldrb.w r1, [sp, #0x170]   ; r1 = conn_id
0x62a6:  movs r2, #1                ; r2 = 1 (accept)
0x62a8:  blx #0x3618                ; btmtk_avrcp_send_connect_ind_rsp(conn_ptr, conn_id, 1)

CONNECT_RSP payload (msg_id=507):

byte[0..3]  0x00000000
byte[4]     conn_id
byte[5]     0x01     (accept flag, hardcoded)
byte[6]     0x00     (no tg_feature_code sent to mtkbt)
byte[7]     0x00

g_tg_feature (set to 0x0e by C2b) is not included in the CONNECT_RSP payload. mtkbt's CONNECT_CNF tg_feature field is populated from mtkbt's own internal SDP registration state — D1 enables that registration, but mtkbt reports tg_feature=0 regardless.

Java layer audit (Trace #4 cross-reference)

(See the Trace #4 section earlier in this document for the full decompilation. Summary preserved here for reference:)

• BTAvrcpMusicAdapter.getSupportVersion()B returns 0x0e if sPlayServiceInterface is true, else 0x0d. Confirms F2's importance: disable() must reset the flag so re-activation doesn't see stale state.
• BTAvrcpMusicAdapter.checkCapability()V builds the 1.4 EventList [1, 2, 9, 10, 11] (PLAYBACK_STATUS_CHANGED, TRACK_CHANGED, NOW_PLAYING_CONTENT_CHANGED, AVAILABLE_PLAYERS_CHANGED, ADDRESSED_PLAYER_CHANGED) when v=0xe.
• BTAvrcpMusicAdapter.registerNotification(B, I)Z (the cardinality update site): events 1/2/9 → handle (bReg=true); 3/4/5/8/13 → blocked (bReg=false); 10/11/12 → fall through. If bReg: [email protected](eventId) and log [BT][AVRCP] mRegBit set %d Reg:%b cardinality:%d.

Definitive verdict (Trace #4): logcat across multiple sessions shows neither [BT][AVRCP](test1) registerNotificationInd eventId:%d nor the cardinality update log. registerNotificationInd never fires — the JNI never receives a "REGISTER_NOTIFICATION arrived" event from mtkbt. Java layer is definitively ruled out.

Where the cardinality:0 gate is

The gate is unambiguously inside mtkbt's native AVRCP layer, between AVCTP RX and the JNI dispatch socket. Per the 2026-05-04 conclusion, this is because mtkbt's compiled command set is 1.0-only — AVRCP 1.3+ COMMANDs from peers reach the AVCTP layer but are not classified by mtkbt as anything its 1.0 dispatcher recognises, and are silently dropped. Candidate drop sites identified for the user-space proxy work:

• mtkbt's AVCTP receive handler at fn 0x6d9ba (live 0x40128d9a per probe v3 PIE base 0x400c1000) — silently drops the inbound L2CAP frame before dispatch.
• The silent-drop site at 0x0513a4 (live 0x401123a4) — [AVRCP][WRN] AVRCP receive too many data. Throw it!.
• The L2CAP→AVCTP demux logic upstream of 0x6d9ba — wrong PSM routing, missing peer-state guard, etc.
• 0x6cf30 (live 0x40128f30) — AVCTP_ConnectRsp.

These are the gdbserver targets for Phase 1 of the proxy work (see "Path forward" section above).

All Patches — Complete Status

This section's table previously enumerated the legacy 11-patch --avrcp set against mtkbt plus the C2a/b/C3a/b in libextavrcp_jni.so plus C4 in libextavrcp.so plus H1-H3 in /sbin/adbd — every entry of which has since been deleted (the legacy --avrcp set in v2.0.0; H1-H3 in v1.7.0, then patch_adbd.py / patch_bootimg.py deleted in v2.1.0). The current shipped patch set is in PATCHES.md Patch ID Legend. F1 and F2 against MtkBt.odex survive into the current tree (with current docstrings reflecting the 1.3 wire shape, not the legacy 1.4 framing) — see PATCHES.md §patch_mtkbt_odex.py.

Binary Reference Data

Stock MD5s and structural reference for every binary the patcher chain touches. Output (patched) MD5s are not pinned here — each src/patches/patch_*.py carries its own STOCK_MD5 + OUTPUT_MD5 constants and updates them in lockstep with the patch logic; that's the authoritative source.

mtkbt

ELF segment map:

MtkBt.odex

libextavrcp_jni.so

ILM layout in CONNECT_CNF receive loop stack frame:

libextavrcp.so

(libextavrcp.so carried the legacy C4 patch through v1.x; deleted in v2.0.0. Stock now ships unmodified.)

libaudio.a2dp.default.so

(The legacy /sbin/adbd Binary Reference Data subsection — Stock + arg-zero + NOP-the-blx Patched MD5s — was removed when patch_adbd.py / patch_bootimg.py were deleted in v2.1.0. See "adbd Root Patches (H1 / H2 / H3)" earlier in this doc for the historical analysis. Current root mechanism is /system/xbin/su per src/su/.)

Eliminated Paths — Do Not Pursue

Post-Flash Verification Checklist

After apply.bash --avrcp [other flags] lands on the device, sanity-check from a host with adb shell:

• SDP record shape — sdptool browse <Y1_BT_ADDR> from a paired peer:
  • AVRCP TG record (UUID 0x110c): AV Remote (0x110e) Version: 0x0103 (V1) and AVCTP uint16: 0x0102 (V2)
  • Attribute 0x0100 ServiceName "Advanced Audio" present (S1); attribute 0x0311 SupportedFeatures absent (S1 swap)
• Patcher output MD5 ↔ on-device MD5 — pull each patched binary and compare against the OUTPUT_MD5 constant pinned in the corresponding patcher:
  • mtkbt → src/patches/patch_mtkbt.py::OUTPUT_MD5
  • libextavrcp_jni.so → src/patches/patch_libextavrcp_jni.py::OUTPUT_MD5 (regenerated when the trampoline blob changes)
  • MtkBt.odex → src/patches/patch_mtkbt_odex.py::OUTPUT_MD5
  • libaudio.a2dp.default.so → src/patches/patch_libaudio_a2dp.py::OUTPUT_MD5
• Y1MediaBridge installed and running — dumpsys package com.y1.mediabridge | grep versionCode matches src/Y1MediaBridge/app/build.gradle; ps | grep com.y1.mediabridge shows the service.
• Trampoline chain emitting metadata — tools/dual-capture.sh against a peer CT exercising play/pause + metadata fetch; in the resulting btlog look for outbound msg=540 (GetElementAttributes response) frames carrying the seven §5.3.4 attributes after a CT-side metadata query.
• AVRCP NACKs absent — same capture, count of inbound msg=520 (NOT_IMPLEMENTED) reject frames should be zero (or scoped to the explicit T_continuation reject for unsolicited 0x40 / 0x41).
• AH1 holding A2DP up across pauses — pause + wait ≥3 s + resume from peer; capture should show zero [A2DP] a2dp_stop. is_streaming:1 lines around the pause/resume window.
• Root works — adb shell → su → id returns uid=0(root) gid=0(root); prompt $→#.

Log Tags

Trace #8 (2026-05-04, post-root) — MSG_ID_BT_AVRCP_CONNECT_CNF emit-path map in mtkbt

Pure static analysis on stock mtkbt MD5 3af1d4ad…, driven by the post-root pivot to "find where result=0x1000 is set" before reaching for gdbserver. The result:4096 lead was disproven by Trace #10; this trace's emit-chain map is preserved because it documents the IPC dispatcher structure that the user-space proxy work's Phase 4 (outbound RSP path) will need.

Emit chain identified end-to-end:

Where the 0x1000 enters the system (sibling path): Same code-region neighbour 0x0000f83c calls helper 0x00010404 with r1 = 0x1000 (bytes verified: 4f f4 80 51 at 0xf8a6). Helper 0x10404 lays out an event on a 1872-byte stack frame: strh.w r1, [sp, #6] (=event[2:4] = 0x1000) and strb.w r5, [sp, #4] where r5 = #8 — so it dispatches event_code=8, not 3. The dispatcher's case-8 handler at 0x00051622 reads event[8..12] but does not read event[2:4]. So this 0x1000-injection path does not directly reach CONNECT_CNF's result field — it produces a different msg_id with a 0x1000 status payload.

Second TBH dispatcher at 0x000518ac (msg_ids 500-611, JNI→mtkbt direction):

• 500: ACTIVATE_REQ
• 502: DEACTIVATE_REQ
• 504: connect-related
• 507: CONNECT_RSP
• 508/513: disconnect-related
• 511, 515, 517, 520, 522, 524…560+: various AVRCP COMMAND-class messages
• The full TBH map is in the binary; consult via Trace #8's tooling (objdump -d + Python xref pass) when needed.

Negative results (so the next person doesn't redo them):

• No site in the binary directly stores 0x1000 to [rN, #2] of any struct (zero hits across all mov*/strh* pair scans in .text).
• 28 sites store 0x1000 to [rN, #0xe] (= ILM+0x0e = tg_feature) — concentrated in the 0x13xxx–0x15xxx range. Fits the bit-12 = "feature degraded" hypothesis but doesn't directly set CONNECT_CNF result.
• Dispatcher 0x000514a4 has zero direct callers and zero R_ARM_RELATIVE relocs and zero word-aligned hits in .data/.data.rel.ro — registered via the same PIC add Rn, pc callback-registration pattern documented for 0x29e98 (Trace #1f).
• The second msg_id-505 hit at 0x00071ffa is a false positive — 505 there is the source line number passed to __xlog_buf_printf (signature xlog(level, line_no, fmt, …)), not an ILM msg_id.

Tooling: linear objdump -d of the whole binary into /tmp/mtkbt.dis (~290k lines) plus a small Python pass that parses mn/rest/addr and resolves PC-relative xrefs by walking back from add Rn, pc to the prior ldr Rn, [pc, #N]. Confirmed correct against known-good xrefs to [AVRCP] avctpCB AVCTP_EVENT:%d (0xc8c7e) and bt.ext.adp.avrcp (0xda7f9).

Trace #9 (2026-05-04, post-root) — @btlog passive tap unlocks __xlog_buf_printf + HCI snoop in one stream

The post-root probe (tools/probe-postroot.sh + …-device.sh) found that mtkbt runs socket_local_server("btlog", ABSTRACT, SOCK_STREAM) at vaddr 0x6b4d4 and that the abstract socket @btlog (inode 1497, mtkbt fd 13) is a SOCK_STREAM listener with SO_ACCEPTCON set. Built src/btlog-dump/ — a 1016-byte no-libc ARM ELF using the same direct-syscall style as src/su/ — that opens an AF_UNIX/SOCK_STREAM socket, connect()s to the abstract @btlog address, and pipes read() to stdout. Connect requires no handshake; mtkbt starts pushing the moment a client attaches.

First capture confirms the stream contains both layers we needed:

• HCI command / event traffic — fully decoded: HCC_INQUIRY, HCC_CREATE_CONNECTION, HCC_WRITE_SCAN_ENABLE, HCC_AUTH_REQ, HCC_READ_REMOTE_FEATURES, HCC_READ_REMOTE_VERSION, HCC_READ_REMOTE_EXT_FEATURES, HCE_COMMAND_COMPLETE, HCE_READ_REMOTE_FEATURES_COMPLETE, HCE_READ_REMOTE_VERSION_COMPLETE, [BT]GetByte: / [BT]PutByte: byte-level transport.
• __xlog_buf_printf output — every [AVRCP]…, [AVCTP]…, [L2CAP]…, [ME]…, [BT]…, SdpUuidCmp:…, ConnManager: event=… log line that's invisible to logcat.

Framing format (preliminary, by inspection):

Severities seen: 0x12 (xlog text) and 0x07 / 0x08 / 0xb4 (HCI snoop / module-specific).

See src/btlog-dump/README.md for the maintained version of this format documentation.

What this tooling collapsed from the prior plan:

• HCI snoop / btsnoop: DONE via @btlog. No need to push hcidump or fight with persist.bt.virtualsniff.
• __xlog_buf_printf capture: DONE via @btlog. Same stream.
• Surgical __android_log_print instrumentation: no longer needed for read-only observation. The xlog tag IS the log; we just had no way to read it before.

Trace #10 (2026-05-04, post-root) — first dual capture (Sonos Roam) kills the result:4096 lead

Captured tools/dual-capture.sh against Sonos Roam at /work/logs/dual-sonos-attempt1/ — 1.5 MB btlog.bin, 159-line logcat.txt. The smoking-gun line landed cleanly:

05-03 23:29:43.371   710   710 I JNI_AVRCP: [BT][AVRCP]+_activate_1req index:0 version:14 sdpfeature:35
05-03 23:29:43.371   710   710 I EXTADP_AVRCP: msg=500, ptr=0xBEA64D30, size=8        ← JNI sends ACTIVATE_REQ
05-03 23:29:43.373   710  2451 I JNI_AVRCP: [BT][AVRCP] Recv AVRCP indication : 501   ← JNI receives ACTIVATE_CNF
05-03 23:29:43.374   710  2451 V EXT_AVRCP: [BT][AVRCP] activate_cnf index:0 result:4096   ★

… 22 seconds later, peer initiates connect …

05-03 23:30:06.084   710  2451 I JNI_AVRCP: [BT][AVRCP] Recv AVRCP indication : 506   ← CONNECT_IND from mtkbt
05-03 23:30:06.085   710  2451 I EXTADP_AVRCP: msg=507, ptr=0x523D3A98, size=8        ← JNI sends CONNECT_RSP
05-03 23:30:06.139   710  2451 I JNI_AVRCP: [BT][AVRCP] MSG_ID_BT_AVRCP_CONNECT_CNF conn_id:1  result:4096   ★
05-03 23:30:06.139   710  2451 I JNI_AVRCP: [BT][AVRCP] MSG_ID_BT_AVRCP_CONNECT_CNF bws:0 tg_feature:0 ct_featuer:0

result:4096 appears 3 ms after the JNI sends ACTIVATE_REQ — purely local mtkbt processing, before any peer is involved. The same result:4096 then re-appears at CONNECT_CNF time. 0x1000 is mtkbt's standard "request acknowledged" status code, set on every CNF mtkbt emits to the JNI — not a "feature degraded" or peer-feedback indicator at all.

This kills the previously-listed primary lead. The Trace #8 emit-chain map is still useful (the IPC dispatcher structure is needed for the proxy work) but no longer aimed at "find where 0x1000 is set" — that question is answered.

What the dual capture actually shows about the peer:

• Sonos Roam (38:42:0B:38:A3:3E) initiates the connection 22 s after the JNI activate completes — likely after Sonos's own scan / discover cycle.
• L2CAP / AVCTP come up cleanly: 3× l2cap conn_rsp result:0, 7× handleconfigrsp result:0 on psm:0x19, then [AVCTP] chid:66 (channel ID varies between captures — was 0x67 in Trace #9).
• AVRCP profile-level connect succeeds end-to-end: connect_ind (msg 506) → CONNECT_RSP (msg 507) → CONNECT_CNF (msg 505).
• After the connect, only one AVCTP_EVENT:4 (RECV_DATA-class event) fires from the peer, accompanied by [AVRCP] transId:0, then silence — no further AVCTP RX activity, no GetCapabilities, no RegisterNotification. Sonos is not following up the basic AVRCP-profile connect with the AVRCP COMMAND PDUs a 1.4 controller should send.
• The Y1 stays in this connected-but-silent state indefinitely until A2DP drops, at which point mtkbt cleans up via AVRCP: disconnect because a2dp is lost.
• Java-side cardinality:0 in ACTION_REG_NOTIFY lines is exactly what we'd expect from this state — mRegBit is empty because no peer has issued REGISTER_NOTIFICATION.

Trace #11 (2026-05-04, post-root) — Browsing-bit experiment failed, real-world reference peer comparisons settle the gate-location question

Three independent threads, one conclusion.

Thread A: Browsing-bit experiment

Hypothesis: served SupportedFeatures = 0x0033 omits Browsing bit (0x40); some 1.4 controllers may decline AVRCP COMMANDs against a TG that doesn't claim Browsing.

Built a non-destructive bash wrapper that swaps src/patches/patch_mtkbt.py for an alternate that overrides E3 / E4 after bytes from 0x33 → 0x73, runs the standard --avrcp --bluetooth flow, then restores the original on EXIT. Flashed and re-captured against Sonos.

Direct evidence the experiment landed on the wire: btlog SdpUuidCmp:uuid1, len=2, (11 e, 9 1, 4 9, 0 73) — the served bytes for AVRCP TG (0x110e) are now Version=0x0104 + SupportedFeatures=0x0073. Compare to Trace #9's 0x0033.

Result: peer behaviour identical to baseline. 14× cardinality:0 lines, none non-zero. Same single [AVRCP] avctpCB AVCTP_EVENT:4 → [AVRCP] transId:0 → silence. Same MSG_ID_BT_AVRCP_CONNECT_CNF result:4096 bws:0 tg_feature:0 ct_featuer:0. L2CAP / AVCTP config exchange clean.

Hypothesis #1 dead. Tooling deleted on cleanup.

Thread B: hypothesis-#3 static ([AVRCP] transId:0)

Two callers of the [AVRCP] transId:%d log function (0x11374 static / 0x400d2374 live). Both read transId directly from inbound packet bytes (event[1] in caller 0x1457c..0x1458a; event[5] in caller 0x51a20). The transId:0 we observe is the actual transId byte the peer sent on the wire — not mtkbt mangling the value. transId is a 4-bit AVCTP-header field; 0 is a perfectly valid value for the first packet on a fresh AVCTP channel. Hypothesis #3 dead.

Bonus from the same pass: @btlog's [BT]GetByte: / [BT]PutByte: lines around the AVCTP_EVENT:4 timestamp give a per-byte HCI trace. Decoded, mtkbt sends an outbound L2CAP CONFIG_REQ; Sonos sends back its own CONFIG_REQ for our cid 0x42 carrying MTU=1024 — standard AVCTP control-channel config. Then AVCTP_EVENT:4 fires once and AVRCP-layer activity stops.

Thread C: real-world reference-peer comparisons (the decisive evidence)

User-supplied empirical data:

The play / pause break is the load-bearing finding. Play / pause flows car→Y1 as AVRCP PASS_THROUGH commands. Functional break in the CT→TG command path — not just notification-cosmetic. Same root cause as cardinality:0.

Combined verdict

The gate is on the Y1 side, not on any peer. Sonos's "single AVCTP_EVENT:4 then silence" pattern is Sonos sending its first AVRCP command (likely GetCapabilities), getting nothing usable back from Y1, and giving up.

Pixel 4 SDP record across all four AVRCP versions (Pixel Developer-Options-forced, captured 2026-05-04):

User-confirmed: at every Pixel-AVRCP-version setting (1.3 / 1.4 / 1.5 / 1.6), Sonos receives full title / artist / album metadata + responds correctly to play / pause from Pixel. Cover art doesn't transfer (Sonos-side limitation).

This is what makes the 2026-05-04 conclusion definitive: at AVRCP 1.3, the bare-minimum SDP record (Cat1 features, no AdditionalProtocolDescriptorList, AVCTP 1.2) is sufficient for Sonos to engage AVRCP COMMAND traffic — if the implementation actually responds to those commands. Y1 stock advertises features 0x0001 exactly like Pixel-1.3 but at AVRCP 1.0; Sonos doesn't bother sending COMMANDs because AVRCP 1.0 is too primitive. Y1 patched to 1.3+ advertises a richer record but mtkbt drops the COMMANDs Sonos then sends. mtkbt is a 1.0-class implementation regardless of SDP advertisement.

Trace #12 (2026-05-05, post-root) — full silent-drop chain mapped end-to-end via gdbserver

This trace settled the silent-drop architecture conclusively. Five gdb capture iterations narrowed the problem from "somewhere in mtkbt" to a 2-byte patch site, then exposed the next gate one binary upstack.

Setup

Built tools/install-gdbserver.sh (fetches a sha256-pinned ARM 32-bit static gdbserver from aosp-mirror/platform_prebuilt, commit f5033a8c, sha256 1c3db6a3..., 186112 bytes — last touched upstream 2010) and tools/attach-mtkbt-gdb.sh (pushes gdbserver, attaches to live mtkbt PID, computes PIE base, generates a commands-driven gdb command file with breakpoints at the critical sites and silent printf+continue blocks). Watch-items learned the hard way:

• mtkbt is all Thumb-2. Plain even-addressed BPs make gdb plant 4-byte ARM BKPTs that corrupt Thumb instructions → mtkbt SIGSEGV at NULL on the first BP hit. Fix: set arm fallback-mode thumb + set arm force-mode thumb in the gdb file (NOT addr | 1 — that breaks gdb's trap-time PC lookup).
• After mtkbt SIGSEGV mid-debug, gdbserver wedges with the dead PID's ptrace slot. Fix: clean up stale gdbserver via /proc walk before each attach, drop the adb forward.
• mtkbt respawns automatically on crash; BT off→on resets cleanly.

What --avrcp (V1+V2+S1, then --avrcp-min in the historical iter1) shows

With AVRCP 1.3 + AVCTP 1.2 + a 0x0100 ServiceName attribute on the served SDP record, Sonos sends a real AV/C VENDOR_DEPENDENT GetCapabilities (op_code 0x00, vendor BT-SIG 0x001958, PDU 0x10, capability_id 0x02 = EVENTS_SUPPORTED). Confirmed by gdb breakpoint dumps of the inbound L2CAP frame bytes. This contradicts the earlier 2026-05-04 reading of Trace #10's capture, which assumed the inbound was a malformed/dropped command — it was actually a 14-byte real GetCapabilities all along.

The full mtkbt RX chain (PASSTHROUGH vs VENDOR_DEPENDENT)

Both frame types follow the same path through:

1. AVCTP RX inner TBH at file 0x6da7a — keyed on [r5,#0] (event subtype 0..8); subtype 3 routes to the AV/C-bearing path.
2. Classifier at 0x6db7c — ldrb r0, [r5,#5]; cmp r0, #1; bhi 0x6dc3a. For both PASSTHROUGH and VENDOR_DEPENDENT, [r5,#5]=0 so AV/C parse path taken.
3. AV/C parse at 0x6dba0+ — extracts ctype/subunit_type/subunit_id/op_code from frame bytes 0..2, stores at conn+160..163.
4. event_code=4 setter at 0x6dc36.
5. Dispatch at 0x6de64 via [r4+244] callback (= fn at file 0xfb04, set up via register_callback fn at 0x6ce78 from caller at 0xeaec with PSM=0x17 and a callback-fn-ptr literal).
6. Inside fn 0xfb04's default arm, → bl 0x145b0 (the AV/C-event handler in fn 0x147dc's case 4 = TBH index 3).
7. fn 0x145b0 stores frame bytes at conn+2956.. and conn+2400+9; calls bl 0x144bc.
8. fn 0x144bc op_code dispatch at 0x144e8 — ldrb r3, [r6,#3] reads op_code from conn+163:
   • r3 == 0x7c (PASSTHROUGH) → b.n 0x14528 → bl 0x10404 → emits msg_id 519 to JNI.
   • r3 < 0x30 or r3 != 0x7c (VENDOR_DEPENDENT op_code 0x00, also UNIT_INFO 0x30, SUBUNIT_INFO 0x31, etc.) → bcc 0x1454a or bne 0x1454a → bl 0x11374 → log only, silent drop.

The captured r2 at fn 0x144bc entry differs (3 for PASS, 9 for VENDOR), but that's downstream of the gate at 0x144e8. The actual gate is the op_code branch.

P1 patch (mtkbt, file offset 0x144e8)

Two-byte rewrite of cmp r3, #0x30 → b.n 0x14528:

Forces all AV/C frames through the bl 0x10404 → msg 519 emit path regardless of op_code. Hardware-verified 2026-05-05: VENDOR_DEPENDENT GetCapabilities now reaches JNI as MSG_ID_BT_AVRCP_CMD_FRAME_IND size:9 rawkey:0 data_len:9 with the AV/C-body bytes intact.

Ships as the fourth patch in src/patches/patch_mtkbt.py. Stock mtkbt md5 3af1d4ad8f955038186696950430ffda → output a37d56c91beb00b021c55f7324f2cc09.

What's NOT yet solved — the JNI's "unknow indication" path

The JNI receive function in libextavrcp_jni.so is _Z17saveRegEventSeqIdhh at file 0x5ee4. It dispatches msg 519 on frame size:

• cmp.w lr, #3 at 0x6452 — size 3 → PASSTHROUGH path; calls btmtk_avrcp_send_pass_through_rsp
• cmp.w lr, #8 at 0x6524 — size 8 → branch with a BT-SIG vendor check (cmp r1, #0x5819 at 0x656a); on match, jumps to 0x65a4 (VENDOR_DEPENDENT handling)
• otherwise → 0x65bc → "unknow indication" + dump first 16 bytes + default reject (msg_id 520 CMD_FRAME_RSP with NOT_IMPLEMENTED)

P1 produces size=9 frames (the 14-byte AV/C frame minus 3-byte AV/C header minus 2 leading bytes — the trampoline path strips slightly differently from the size=8 path). Size=9 falls into "unknow indication", and the inbound is auto-rejected before reaching Java's BTAvrcpMusicAdapter.

The candidate next patch is at file 0x6526 of libextavrcp_jni.so: cmp.w lr, #8 → cmp.w lr, #9 (single byte 0x08 → 0x09). That'd route size-9 frames into the size-8 branch and onward to the BT-SIG vendor check at 0x656a. Risk: the size-8 branch's downstream reads (sp+381, sp+382, sp+385) assume a specific stack layout that size-9 frames may not satisfy, AND the path eventually calls btmtk_avrcp_send_pass_through_rsp which is the wrong response builder for a VENDOR_DEPENDENT command. May need additional patches to skip the pass_through_rsp call and / or to invoke Java's BTAvrcpMusicAdapter.checkCapability() via JNI.

A clean patch will require static-analyzing what 0x65a4+ actually does (whether it reaches Java or just logs+returns) before committing to a byte rewrite.

2026-05-05 follow-up. The single-byte J1 (cmp 8 → 9) was tried and rolled back — it routed size-9 frames through the PASSTHROUGH dispatch, generating fake key=1 isPress=0 events and never reaching Java. Path forward (now in patch_libextavrcp_jni.py) is trampoline T1: redirect bne.n 0x65bc at file 0x6538 to a code-cave at file 0x7308 (overwriting the unused JNI debug method testparmnum). The trampoline checks the PDU byte at sp+382, and on 0x10 (GetCapabilities) calls btmtk_avrcp_send_get_capabilities_rsp directly via PLT 0x35dc, then exits.

Iter5 capture (2026-05-05) — T1 confirmed working. /work/logs/dual-sonos-avrcp-min-iter5/ shows: 1 size:9 inbound (GetCapabilities) → 1 outbound msg=522 (size 30, the response) → 4 size:13 inbound (Sonos's first-ever follow-up VENDOR_DEPENDENT commands, 2-second retry pattern indicating RegisterNotification with no INTERIM ACK). For comparison, iter4 (J1) had the same size:9 inbound but msg=520 NOT_IMPLEMENTED instead of msg=522, and zero size:13 follow-ups — Sonos gave up. T1 is the first patch that gets Sonos past the GetCapabilities gate.

T2 added 2026-05-05. Trampoline T2 at file 0x72d0 (overwriting unused classInitNative debug method) handles inbound RegisterNotification(EVENT_TRACK_CHANGED). T1's fall-through arm (originally b.w 0x65bc) now bridges to T2 stage 2 at 0x72d4. T2 verifies the PDU is 0x31 and event_id is 0x02, then calls btmtk_avrcp_send_reg_notievent_track_changed_rsp (PLT 0x3384) with INTERIM (reasonCode 0x0F) and track_id = 0xFFFFFFFFFFFFFFFF ("no track"). Other registered events (0x01, 0x09, 0x0a, 0x0b) fall through to the original "unknow indication". T3/T4/T5/T6/T8/T9 follow-ups are now live in src/patches/_trampolines.py; see ARCHITECTURE.md for the current trampoline chain and BT-COMPLIANCE.md for the current spec-coverage state.

Iter6 capture (2026-05-05) — T2 confirmed working. /work/logs/dual-sonos-avrcp-min-iter6/ shows: 1× size:9 → 1× msg=522 (T1 GetCapabilities response, same as iter5); 5× size:13 inbound (RegisterNotification for the 5 advertised events); 2× msg=544 size=40 outbound firing in the same millisecond as inbound size:13 with event_id=0x02 (T2's TRACK_CHANGED INTERIM response — first-ever AVRCP 1.3-shape metadata response built by mtkbt for this device); Sonos accepted and immediately started sending size:45 GetElementAttributes (PDU 0x20, 26 retries at 2-second intervals). The size:45 retries continue indefinitely because we don't have a T4 trampoline yet — Sonos is asking "give me the track metadata!" and getting no answer. Y1MediaBridge's MediaBridgeService is being connected (PlayService onServiceConnected) so track strings are plumbed and ready; the remaining work is T4 (call btmtk_avrcp_send_get_element_attributes_rsp with the strings). T4 is the last remaining patch in the metadata path.

Iter7 / iter8 / iter9 — fix the unknow-indication path via ELF-extension T4 stub. iter6 also surfaced a separate problem: unhandled inbound frames (size:13 events ≠ TRACK_CHANGED, size:45 GetElementAttributes) generated zero outbound responses. The b.w 0x65bc fall-through from T1 / T2 was reaching the original "unknow indication" code, but that code requires r0 = r5+8 (conn buffer; set at 0x6528 in original flow) AND lr = halfword at sp+374 (= SIZE; loaded at 0x644e) — both of which the trampolines clobber. Iter7 restored r0 only (no msg=520 yet); iter8 added the lr restore (8 → 12 bytes at the 0xac54 stub). Iter9 hardware test: msg=520 NOT_IMPLEMENTED now flows for unhandled frames. Major side effect: AVRCP service stops restart-looping (iter6 had 30 PIDs cycling; iter9 has 2 stable), so PASSTHROUGH play / pause / skip now actually works on Sonos. First-ever transport-control delivery to a peer for this device.

Iter10 — single-event advertised. Iter9 surprise: Sonos aborts the entire RegisterNotification loop on its first NOT_IMPLEMENTED reply. Pre-iter9 the broken unknow path silently dropped the first reject, so Sonos timed out and accidentally tried event 0x02 (TRACK_CHANGED) anyway, which T2 acked. With proper msg=520 flowing, Sonos respects the rejection — meaning it never reaches event 0x02 unless we ack 0x01 (PLAYBACK_STATUS_CHANGED) too. Cheapest fix: advertise only event 0x02 in T1's GetCapabilities response (events count: 5 → 1; events_data: 01 02 09 0a 0b → 02). Sonos then registers only TRACK_CHANGED, T2 acks, Sonos proceeds to GetElementAttributes. Iter10 confirmed: Sonos sent 1265 size:13 + 1264 size:45 frames in a tight 70Hz loop — full path engaged but no real T4 yet to break the loop.

Iter11 — first metadata on Sonos screen. T4 implemented at vaddr 0xac54 in extended LOAD #1 (the 4276-byte page-padding region between the original LOAD #1 and LOAD #2). Single-attribute hardcoded "Y1 Test" Title response, 68 bytes. Argument layout for btmtk_avrcp_send_get_element_attributes_rsp (PLT 0x3570) inferred empirically:

• r0 = conn buffer (= r5+8)
• r1 = 0 (string-follows flag — JNI wrapper at 0x56dc dispatches on this)
• r2 = transId (jbyte at caller_sp+368; same convention as track_changed_rsp)
• r3 = 0 (placeholder; meaning unknown but works)
• sp[0] = attribute_id LSB (1=Title, 2=Artist, 3=Album, 4=TrackNumber, …)
• sp[4] = 0x6a (UTF-8 charset; JNI hardcodes this)
• sp[8] = string length (in bytes)
• sp[12] = pointer to UTF-8 string data

Iter11 hardware-verified 2026-05-05: "Y1 Test" displayed on Sonos Now Playing screen. First ever AVRCP metadata delivery from this device to a peer. Loop continues at 70Hz because the TRACK_CHANGED INTERIM with track_id=0xFFFFFFFFFFFFFFFF tells Sonos to keep re-querying (no stable identity), but the metadata path itself works.

Iter12 — multi-attribute T4 dispatch (loop, separate frames). Extended T4 to 152 bytes with a dispatch loop: parse num_attributes from inbound at sp+394, walk requested attribute_ids at sp+395+, and for each one match against {0x01, 0x02, 0x03} — calling the response builder once per supported attribute with hardcoded strings ("Y1 Title", "Y1 Artist", "Y1 Album"). Unsupported attributes (0x04-0x07) silently skipped. Hardware-verified iter12 2026-05-05: ratio 3:1 of msg=540 to size:45 — three frames per query. Sonos accepted the first frame and displayed "Y1 Title" only; subsequent frames with same transId were ignored as duplicates. Output md5 fa6191d6ce8170f5ef5c8142202c8ba5.

Iter13 — multi-attribute single-frame response (correct semantics, breakthrough). After disassembling btmtk_avrcp_send_get_element_attributes_rsp at libextavrcp.so:0x2188, decoded the function's actual contract:

• arg1 (r1) = "with-string / reset" flag (0 = with string, append; !=0 = no-string finalize)
• arg2 (r2) = attribute INDEX in this response (0..N-1) — NOT transId
• arg3 (r3) = TOTAL number of attributes in this response
• sp[0] = attribute_id LSB
• sp[4] = 0x6a (UTF-8, JNI-hardcoded)
• sp[8] = string length
• sp[12] = string pointer

The function maintains an internal 644-byte static buffer that's reset when (arg1!=0 OR arg2==0). It emits the IPC frame only when (arg2+1)==arg3 AND arg3!=0 (last attribute) — earlier calls accumulate. iter11/12 worked by accident because passing arg3=0 triggered the legacy single-shot send path. iter13 makes 3 sequential calls with arg2=0/1/2, arg3=3 → first two accumulate, third emits ONE frame containing all 3 attributes.

transId is NOT an argument — the function reads it from conn[17] automatically.

iter13 output md5: 56d9d8514f30a12aaf2303b7a7f6a067. Hardware-verified 2026-05-05: ratio 1:1 of msg=540 to size:45 (672 each) — exactly one emit per inbound GetElementAttributes containing all three attributes. Sonos displays Title + Artist + Album simultaneously. First time the Y1 has ever delivered a multi-attribute AVRCP 1.3 metadata response. (--avrcp-min advertises AVRCP 1.3 over AVCTP 1.2; GetElementAttributes PDU 0x20 is the 1.3 metadata-transfer feature.)

The reverse-engineered argument layout is now empirically confirmed correct. The architectural work is done. Remaining work is pure data plumbing — replacing the hardcoded "Y1 Title"/"Y1 Artist"/"Y1 Album" strings with real metadata from Y1MediaBridge (iter14: file-based plumbing via /data/local/tmp/y1-track-info).

Iter14 → 14b → 14c (data plumbing). Y1MediaBridge writes Title\0…Artist\0…Album\0… (768 B fixed-layout) to a file; T4 opens, syscall-reads, and uses the strings instead of the hardcoded ones. Iter14 (/data/local/tmp/y1-track-info) regressed Y1MediaBridge — uid 10000 has no write permission to /data/local/tmp/ (mode 0771 owner=shell), and the silent EACCES on FileOutputStream opening propagated past the IOException catch and killed the service. Iter14b moved the path to /data/data/com.y1.mediabridge/files/y1-track-info, with a setExecutable(true,false) chmod on the dir at startup so the BT process (uid bluetooth) could traverse and read. Iter14c added __android_log_print after open() to surface the fd/errno, which confirmed T4 was firing successfully on every poll — but Sonos's display still showed first-track strings on track change. The actual diagnosis: Sonos caches GetElementAttributes responses keyed by the TRACK_CHANGED INTERIM track_id. Since T2 always sent 0xFF×8, Sonos thought it was the same track forever, even though our T4 was happily delivering fresh strings.

Iter15 — state-tracked CHANGED notifications. Output md5 92bcac1ab99d7fd0e263b712f9abb2d4. Three architectural changes:

1. File format: y1-track-info grows to 776 B with the mCurrentAudioId (big-endian) at bytes 0..7 ahead of the 3 × 256 B Title / Artist / Album slots. Y1MediaBridge writes the track_id alongside the strings.
2. State file: a 16 B y1-trampoline-state file (mode 0666, pre-created by Y1MediaBridge at startup) lets the BT process remember (a) the last track_id we told Sonos about (bytes 0..7) and (b) the last RegisterNotification transId (byte 8). The extended_T2 trampoline writes both fields on every RegisterNotification(TRACK_CHANGED); the T4 trampoline reads them on every GetElementAttributes.
3. Trampoline rewrite: T2's logic moves out of the cramped 44-byte classInitNative slot into LOAD #1's page-padding region. T2 stub at 0x72d4 becomes a single b.w extended_T2. extended_T2 dispatches PDU/event-id internally and falls through to T4 for PDU 0x20 or to 0x65bc otherwise. T4 is rewritten cleanly (memset → open/read y1-track-info → open/read y1-trampoline-state → cmp track_id → conditionally emit track_changed_rsp CHANGED with state[8] as transId + write new state → 3× get_element_attributes_rsp). The whole blob is now built dynamically from a tiny Thumb-2 assembler in src/patches/_thumb2asm.py + _trampolines.py, rather than hand-encoded as a hex array. Total 572 bytes of trampoline + paths; LOAD #1 grows from 0xac54 → 0xae90 (still well under the 0xbc08 LOAD #2 boundary).

Hardware-tested 2026-05-06: deadlocked Sonos. Returning the file's real track_id in the INTERIM(TRACK_CHANGED) response flipped Sonos into "stable identity per track, only refresh on CHANGED" mode. Our T4 only fires when Sonos polls GetElementAttributes; Sonos won't poll until it sees a CHANGED. After the first RegisterNotification (transId=0x00, track_id=0x147), Sonos went silent for 14+ minutes despite 10 track changes. Forensics confirm:

• y1-trampoline-state mtime 14 min before capture-end; bytes 0..7 = 0x147 (audioId 327)
• y1-track-info track_id at capture time = 0x151 (audioId 337) — 10 tracks ahead
• 0 inbound VENDOR_DEPENDENT commands across 60 s capture (vs 2,933 in iter14c)
• AVCTP control channel up; only PASSTHROUGH (PLAY / PAUSE) flowed
• Sonos display: "No Content" / "Unknown Content" / stale "Trouble Maker" cached from the previous iter14c session

Cause: AVRCP 1.3 §5.4.2 Table 5.30 + ESR07 §2.2 / AVRCP 1.5 §6.7.2 — peer behaviour depends critically on whether the TG advertises a stable track identity in the EVENT_TRACK_CHANGED Identifier field. With a real id we entered a CT / TG handshake that requires us to push asynchronous CHANGED edges, but our trampolines are reactive only.

Iter16 — same architecture, INTERIM / CHANGED track_id pinned to 0xFF×8. Output md5 5d74443293f663bcd3765721bb690479. The change-detection bookkeeping (file bytes 0..7 vs state bytes 0..7) is preserved; only the wire-level track_id field in the response is hardcoded to the 0xFFFFFFFFFFFFFFFF "not bound to a particular media element" sentinel. Implementation: an 8-byte 0xFF constant labelled sentinel_ffx8 is appended after the path strings; extended_T2's INTERIM emit and T4's CHANGED emit both ADR.W r3, sentinel_ffx8 instead of computing a stack address. Trampoline blob grows 572 → 580 bytes; LOAD #1 ends at 0xae98.

Hardware-tested 2026-05-06: iter16 protocol layer fully working. Sonos engaged (115 inbound CMD_FRAME_INDs in 71 s, 67 RegisterNotification responses, 43 GetElementAttributes responses). Forensic dump of y1-track-info (audioId 360 = "The Kintsugi Kid (Ten Years)" / Fall Out Boy) and y1-trampoline-state (audioId 358 = "Bleed American" / Jimmy Eat World, transId=0x00) confirmed Y1MediaBridge writes the file correctly and the trampolines update state when fired. The remaining defect is polling cadence: Sonos polled aggressively for the iter16 capture window (UI was being viewed) but its idle poll rate is too slow for shuffle-heavy playback. State froze 2 audioIds behind reality, so display was stuck on "Bleed American" while the current track was "The Kintsugi Kid". The iter16 reactive trampolines can't push CHANGED without an inbound query — fundamentally a chicken-and-egg with Sonos's polling.

Iter17a — proactive CHANGED via Java→JNI hook. Output md5s libextavrcp_jni.so 37ad4394efe7686d367d08f20e6f623b, MtkBt.odex ca23da7a4d55365e5bcf9245a48eb675. Adds asynchronous CHANGED emission triggered by Y1MediaBridge's existing track-change broadcast, independent of Sonos's polling rate.

Y1MediaBridge sends com.android.music.metachanged → MtkBt's BluetoothAvrcpReceiver intercepts → updates internal state and calls BTAvrcpMusicAdapter.passNotifyMsg(2, 0) (Message what=34, arg1=2 = TRACK_CHANGED) → handleKeyMessage's sparse-switch lands at sswitch_1a3 → cardinality check BitSet.get(2) (Java-side bookkeeping; never populated because our JNI trampolines bypass the Java path → permanently 0) → if-eqz skips the native call.

Patch A (MtkBt.odex @ 0x03c530): NOP the if-eqz v5, :cond_184 (4 bytes 38 05 da ff → 00 00 00 00). The native call now fires on every track-change broadcast.

Patch B (libextavrcp_jni.so @ 0x3bc0): replace notificationTrackChangedNative's stmdb prologue with a 4-byte b.w T5. T5 lives in LOAD #1 padding alongside T4 / extended_T2 / sentinel_ffx8 and:

1. Calls the JNI helper at 0x36c0 (same one the stock native used) to obtain the BluetoothAvrcpService per-conn struct → conn buffer at +8.
   1. Reads y1-track-info first 8 bytes (current track_id from Y1MediaBridge).
   2. Reads y1-trampoline-state 16 bytes (last-synced track_id at bytes 0..7, last RegisterNotification transId at byte 8).
   3. If the track moved since the last sync, calls btmtk_avrcp_send_reg_notievent_track_changed_rsp via PLT 0x3384 with reason=CHANGED, transId=state[8], track_id=&sentinel_ffx8 (same iter16 sentinel — keeps Sonos in poll-on-each-event mode), then writes the new track_id back to state[0..7].
   4. Returns jboolean(1).

Trampoline blob grows 580 → 768 bytes; LOAD #1 ends at 0xaf54. The reactive T4 and extended_T2 are unchanged — iter17a layers proactive CHANGEDs on top, so we get both reactive (Sonos polls) and proactive (Y1 changes track) refresh paths.

Iter17a hardware test (2026-05-06): proactive layer working, T4 multi-attribute regression discovered. Capture under /work/logs/dual-sonos-avrcp-min-iter17a/. The proactive CHANGED path is firing — msg=544 outbound count reached 4172 over the test window vs ~30 in iter16 — confirming the Java cardinality NOP + notificationTrackChangedNative → T5 chain works end-to-end. But Sonos is rendering metadata field-by-field with visible flicker (Title appearing intermittently while Artist/Album swap in/out). Diagnosed from logcat: 1299 outbound msg=540 (get_element_attributes_rsp) for ~433 inbound GetElementAttributes queries — exactly 3:1 — meaning T4 is emitting three separate msg=540 frames per query instead of one frame containing all three attributes packed in. This is the iter12 bug that iter13 had originally fixed: T4's three calls to PLT 0x3570 had arg2 = transId, arg3 = 0, hitting the function's legacy arg3 == 0 → EMIT each call path. The dynamically-assembled T4 in _trampolines.py regressed it during iter15's rewrite. The reactive change-detection logic, the file I/O, the proactive CHANGED via T5 — all working. Just the response packing is wrong.

Iter17b: T4 multi-attribute single-frame fix. Restored iter13's calling convention in _trampolines.py::_emit_t4:

• r1 = 0 (with-string flag, accumulate)
  • r2 = idx (per-iteration: 0, 1, 2 — was transId)
  • r3 = 3 (total attribute count — was 0)

The function only emits when (arg2+1) == arg3 AND arg3 != 0, so calls 1+2 accumulate into the internal 644-byte buffer and call 3 packs Title+Artist+Album into a single msg=540 outbound. Trampoline blob shrinks 768 → 760 B (the 4-byte ldrb.w to load transId becomes a 2-byte movs r2, #imm); LOAD #1 ends at 0xaf4c. Stock fd2ce74db9389980b55bccf3d8f15660 → 91833d6f41021df23a8aa50999fcab9a. The multi-attribute calling convention is documented in docs/ARCHITECTURE.md "Reverse-engineered semantics: btmtk_avrcp_send_get_element_attributes_rsp"; the iter17b commit message in this section's git history explains the diagnosis. Pending hardware verification.

For full architectural detail (ELF segment-extension trick, calling conventions, msg-id taxonomy, Thumb-2 encoding gotchas), see docs/ARCHITECTURE.md.

Empirics + tooling for the next session

• Five gdbserver capture logs in /work/logs/mtkbt-gdb-{getcap,passthrough,handler,narrow,drill}.log
• Iter3 dual-capture under --avrcp-min post-P1 in /work/logs/dual-sonos-avrcp-min-iter3/ — shows the first-ever MSG_ID_BT_AVRCP_CMD_FRAME_IND for a non-PASSTHROUGH frame plus JNI's "unknow indication" log + 9-byte hex dump.
• All gdb infrastructure (tools/attach-mtkbt-gdb.sh, tools/install-gdbserver.sh) committed and re-runnable.
• Stock libextavrcp_jni.so disassembly: arm-linux-gnu-objdump -d -M force-thumb /work/v3.0.2/system.img.extracted/lib/libextavrcp_jni.so. Has C++ symbols (unlike mtkbt). Function _Z17saveRegEventSeqIdhh is the receive loop; first 1700 bytes from 0x5ee4 cover the size-dispatch.

End of appendix. The brief at /root/briefs/Innioasis_Y1_AVRCP_Unified_Brief.md is now redundant with this document and may be deleted.

Hardware test history per CT

Per the spec-compliance directive (every Koensayr/AVRCP change must move toward strict AVRCP-spec compliance — spec-permissible options can be chosen for CT-compat reasons, but the chase starts from "what does the spec say"), per-device test results live here as research context, not in active code or implementation docs. Implementation files (patch_*.py, _trampolines.py, MediaBridgeService.java, docs/PATCHES.md, docs/BT-COMPLIANCE.md) cite AVRCP spec sections for rationale and reference this section for empirical validation.

CTs referenced below were used during pre-iter22 development. Future CT additions append here without changing implementation files.

Sonos Roam (deprioritized 2026-05-06 — unreliable pairing)

A2DP Bluetooth speaker. Used as the most-permissive reference baseline for iter5 → iter18d hardware verifications (/work/logs/dual-sonos-avrcp-min-iter*/). Notable observations:

• Stays in poll-on-each-event mode when TRACK_CHANGED carries the 0xFF×8 sentinel (AVRCP 1.3 §5.4.2 Table 5.30 + ESR07 §2.2 / AVRCP 1.5 §6.7.2 8-byte clarification — "not bound to a particular media element"). T4's reactive emit fires per-poll, metadata refreshes on every track change.
• iter15 deadlock: real synthetic track_id in INTERIM flipped Sonos into "stable identity, refresh on CHANGED" mode, but iter15's T4 was reactive only — Sonos waited for a CHANGED edge that never came (Sonos didn't poll). 14-min zero-AVRCP-traffic confirmed via state-file forensics. Resolution: iter17a added T5 for proactive CHANGED.
• iter17b verified flicker-free: msg=540:size:45 ratio held 1:1, all three attributes pack into single frame.
• iter18d verified synthetic audioId fix: three track changes captured with synthetic audioIds, real metadata via FD path, msg=544 = 1071 INTERIM + 3 CHANGED (one per track change), ratios 1:1 with no flicker.
• 2026-05-06 onwards: pairing became unreliable in user testing. Dropped from active test matrix; past captures retained as reference.
• 2026-05-08 postflash (/work/logs/dual-sonos-postflash/): resume-from-pause needed double-tap. AVRCP 0x44 PLAY arrived at the kernel as KEY_PLAYCD (7 events confirmed in getevent.txt) but Y1Patch: PlayerService.play(Z) entry never fired in the music app. PlaySongReceiver.MEDIA_BUTTON keyCode= forwarding log fired zero times either — the registered MediaButton dispatch ended up in a hole somewhere between AudioService and PlaySongReceiver. Open investigation. Attempted-fix on 2026-05-09 (drop registerMediaButtonEventReceiver so AudioService's broadcast fallback could deliver to the music app's manifest-filter receiver) was reverted same-day after Kia confirmed it broke metadata delivery (MtkBt uses the registered MediaButton client to find Y1MediaBridge's IBTAvrcpMusic Binder). Need to gdb-attach AudioService and watch where the PendingIntent send goes for KEYCODE_MEDIA_PLAY (126), or whether some other component is bumping us off the slot.

Samsung The Frame Pro (active — TV / indoor)

Smart-TV head unit. Subscribes to event 0x02 TRACK_CHANGED only (3919 RegisterNotifications in /work/logs/dual-tv-iter22b/, all event 0x02). Notable observations:

• iter19b real track_id in INTERIM destabilized the TV: ~90 Hz RegisterNotification subscribe storm against TRACK_CHANGED INTERIMs (3401 inbound size:13 over 38 seconds, sustained ~7 ms inter-frame). AVCTP saturated; PASSTHROUGH release frames dropped, producing held-key fast-forward at ~32× speed and stuck-haptic "vibrate-loop" symptoms. iter19d reverted to the 0xFF×8 sentinel which restores the spec-permissible "no media bound" mode and avoids the storm.
• iter21 (Patch D in patch_y1_apk.py) was a music-app-side defense: the FF/RW seek lambda bounded at 50 iters × 100 ms ≈ 5 s, clearing fastForwardLock on cap. Reverted in iter24 — iter23/U1 fixes the AVRCP-side trigger at the kernel input layer (no more auto-repeat on /dev/input/event4), and iter21's cap was bounding local hardware-button hold-FF/RW too, breaking long scrubs through audiobooks/DJ mixes. iter21 captures (/work/logs/dual-tv-iter21/) remain useful as the empirical baseline for the dropped-release symptom.
• Does not subscribe to event 0x01 PLAYBACK_STATUS_CHANGED — uses TRACK_CHANGED edges only for any state inference. T9 (iter22b) is forward-compat for this CT.
• 2026-05-08 postflash (/work/logs/dual-tv-postflash/): stuck KEY_PAUSECD DOWN in getevent.txt for ~15 s before the matching UP arrived (epoch 1778236775 → 1778236830). High RegisterNotification subscribe-storm cardinality (size:13 to size:45 ratio ≈ 3.7:1) suggests the TV is re-subscribing because expected CHANGED edges aren't arriving fast enough. Likely shares root cause with the Sonos / Kia discrete-key chain-break (TG missing PASSTHROUGH releases under load) but with subscribe-storm amplification. Both still open — same investigation as Sonos's 2026-05-08 postflash entry above.
• iter22d still produced the haptic loop (/work/logs/dual-tv-iter22d-vibloop/). getevent -lt capture pinned the source: a single PASSTHROUGH FORWARD (0x4B) press whose RELEASE was dropped emitted KEY_NEXTSONG DOWN once on /dev/input/event4 ("AVRCP" uinput, BUS_BLUETOOTH), then 458 KEY_NEXTSONG REPEAT events at strict 40 ms intervals until something else cancelled the held-key state. KEY_PAUSECD showed identical kernel-side behavior (1 DOWN, 0 UP, 126 REPEATs). At the mtkbt boundary the ratio was strict 1:1 between PASSTHROUGH PRESS frames and MMI_AVRCP KEY_INFO emissions — the amplification lives below mtkbt, in the kernel's evdev EV_REP soft-repeat timer (REP_DELAY=250ms, REP_PERIOD=33ms Linux defaults). Closed by iter23 / U1: NOP the UI_SET_EVBIT(EV_REP) ioctl at file offset 0x74e8 inside libextavrcp_jni.so's avrcp_input_init so the device never claims EV_REP and input_register_device() never enables soft-repeat for it. Spec-correct per AVRCP 1.3 §4.6.1 (PASS THROUGH command, defined in AV/C Panel Subunit Specification ref [2]): CT is responsible for periodic re-send during held button; TG should forward one event per frame, not synthesize extras at the input layer.
• 2026-05-09 stock baseline (/work/logs/dual-tv-20260509-2217/). TV connecting to a Y1 running stock firmware (no Koensayr patches). Confirms the TV-side AVRCP path is healthy by itself. Wire shape: 190 AVRCP-tagged log lines; msg=507 ×3 (connect_ind → outbound CONNECT_RSP); CONNECT_CNF returned the legacy result:4096 bws:0 tg_feature:0 ct_feature:0 shape (= mtkbt-1.0 default); msg=520 ×20 (all PASSTHROUGH key acks — clean play/pause traffic, zero NOT_IMPLEMENTED rejects); zero msg=519 (no inbound META PDUs reaching JNI visibility); zero msg=540 / msg=544 (no META responses emitted). Confirms the structural finding: TV doesn't probe a 1.0 TG with 1.3 META commands, so stock can't surface the bridge-app metadata even if the TV's UI would render it. Once --avrcp advertises 1.3 (V1/V2 SDP bumps), the TV begins firing the META PDUs that the trampoline chain handles. Use as the canonical "TV-side-healthy, issue-on-our-end" reference when triaging post-flash regressions.

Chevrolet Bolt EV (active — car / highway)

GM Infotainment 3 head unit. Strict CHANGED-driven CT (doesn't poll metadata; relies on TRACK_CHANGED edges + targeted GetElementAttributes). Fully META + PApp capable. Notable observations:

• Bolt EV /work/logs/dual-bolt-iter18d/ showed PDU 0x17 InformDisplayableCharacterSet (UTF-8) issued once at connect; our pre-iter19a TG NACKed with msg=520. Bolt then registered TRACK_CHANGED 30 times but only ever issued a single GetElementAttributes — consistent with "the TG won't acknowledge my charset declaration so I distrust subsequent metadata." iter19a closed by adding T_charset.
• iter19b confirmed the TRACK_CHANGED wire-shape correctness fix (r1=0 to take the response builder's spec-correct path) on Bolt: first CHANGED edge fetched metadata, but every subsequent CHANGED edge after the first was ignored. UI-side block at a layer not visible in our captures; remains an open investigation.
• 2026-05-08 postflash (/work/logs/dual-bolt-postflash/): three findings. (1) Pause-during-play does not pause the Y1, but pause works fine from Pixel 4 ↔ Bolt (user-confirmed 2026-05-08 — Bolt is not at fault). Whatever the Bolt sends as PAUSE never surfaces in our MSG_ID_BT_AVRCP_CMD_FRAME_IND logs as rawkey:70 / 0x46, and getevent.txt over the entire session shows only KEY_PLAYCD, KEY_NEXTSONG, KEY_PREVIOUSSONG on /dev/input/event4 — never KEY_PAUSECD or KEY_PLAYPAUSE from event4. Some path inside mtkbt's AVCTP RX is dropping the Bolt's pause primitive before it reaches our logged INDs. Open investigation: dump mtkbt's AVCTP frame parser via tools/attach-mtkbt-gdb.sh while pressing pause from the Bolt to capture the raw bytes, and compare against the Pixel 4's framing for the same action. Candidate hypotheses: (a) Bolt uses an AVRCP 1.4+ Browse-channel command (PSM 0x1B) we don't expose; (b) Bolt issues a vendor-specific PASSTHROUGH op_id outside the standard 0x44 / 0x45 / 0x46 range; (c) AVDTP-level SUSPEND that the Pixel propagates to its AVRCP layer but we don't. (2) PLAY-resume still broken — the 2026-05-08 attempted fix (drop registerMediaButtonEventReceiver from Y1MediaBridge) was reverted 2026-05-09 after a Kia metadata regression confirmed MtkBt depends on the registered MediaButton client to find the bridge's IBTAvrcpMusic Binder. (3) No metadata displayed by the Bolt despite msg=540 GetElementAttributes being emitted with all 7 §5.3.4 attrs — separate Bolt-side ingestion issue, open investigation.
• Pre-iter25: Bolt is a strict CT and issues discrete PASSTHROUGH 0x44 PLAY (not the toggle 0x46 PAUSE). dual-bolt-iter23 capture shows 5 discrete PLAY presses while Y1 was already PLAYING. iter22d's Patch E routed all of KEY_PLAY (85), KEYCODE_MEDIA_PLAY (126), and KEYCODE_MEDIA_PAUSE (127) through playOrPause() (toggle), which inverted Bolt's intent on each press — toggling away from PLAYING when Bolt asked for PLAY. User perceived the PLAY button as unresponsive. Closed by iter25: Patch E split into three discrete arms — KEY_PLAY → playOrPause() (toggle, legacy MediaButton); KEYCODE_MEDIA_PLAY → play(false) (discrete); KEYCODE_MEDIA_PAUSE → pause(0x12, true) (discrete). Spec-aligned with AVRCP 1.3 §4.6.1 + AV/C Panel Subunit Spec [ref 2]: PLAY (op_id 0x44) transitions to PLAYING from any state; PAUSE (op_id 0x46) transitions to PAUSED from any state. Concrete frame in AVRCP 1.3 §19.3 Appendix D.
• 2026-05-09 F4-iter1 postflash (/work/logs/dual-bolt-20260509-2249/) — first capture against the V1/V2/V3/V4/V5 SDP shape + the full F4-iter1 trampoline chain (T_papp + T8 event 0x08). Reframes prior "Bolt is PASSTHROUGH-only" framing as wrong: the earlier pre-V1/V2 captures simply hadn't advertised AVRCP 1.3, so Bolt never had a reason to issue META commands against us. With the 1.3 advertisement live, Bolt fully exercises the META + PApp surface:
  • Connect → GetCapabilities (msg=522, T1 fired) → PDU 0x17 InformDisplayableCharacterSet (msg=536, T_charset fired) → 5× RegisterNotification → PASSTHROUGH play/forward press/release pairs (clean 1:1) → GetElementAttributes once (msg=540, T4 fired with all 7 attrs in 644 B IPC frame) → continuous RegisterNotification re-subscribes (20 inbound size:13, 72 outbound msg=544 with 52 proactive emits from T5/T9/extended_T2).
  • PDU 0x14 SetPlayerApplicationSettingValue retry storm. Starting ~21 s after connect, Bolt issues a size:11 PDU 0x14 every 3 s — 14 retries across the capture, all rejected by iter1's T_papp Set arm with 0x06 INTERNAL_ERROR (msg=530, 8-byte reject frame). This is the first concrete evidence that a real CT in our matrix actively wants PApp Set support; iter1's reject path is exactly what's gating Bolt's PApp flow. Iter3 (real Set support) is therefore the high-priority next move; iter2's read pipeline (T_papp 0x13 + state observation) is lower-priority for Bolt because Bolt skips ListAttrs (PDU 0x11) and GetCurrent (PDU 0x13) entirely — goes straight to blind Set, suggesting Bolt's behavior is "set Repeat / Shuffle to a known state at connect" rather than "discover what's supported then mirror".
  • 2026-05-09 gdb-capture (/work/logs/papp-gdb.log) — tools/attach-libextavrcp-gdb-papp.sh attached to the patched library, broke at papp_set (file 0xb13c), and dumped 14 inbound PDU 0x14 frames with the following distribution:

| attr_id | value | hits | meaning |
|---|---|---:|---|
| 0x02 Repeat | 0x01 | 2 | OFF |
| 0x02 Repeat | 0x02 | 2 | SINGLE TRACK REPEAT |
| 0x02 Repeat | 0x03 | 2 | ALL TRACK REPEAT |
| 0x03 Shuffle | 0x02 | 8 | ALL TRACK SHUFFLE |

Every frame is `n=1` (single attr/value pair). Bolt issues each Set ×2 (one on user press + one auto-retry after our reject). User cycled Repeat through all three supported values (OFF/SINGLE/ALL — never the AVRCP 0x04 GROUP value Y1 doesn't model), then pressed Shuffle ON four times. Confirms the Trace #18 enum mapping is correct and complete: AVRCP Repeat `0x01/0x02/0x03` ↔ Y1 `musicRepeatMode` `0/1/2`; AVRCP Shuffle `0x02` ↔ Y1 `musicIsShuffle=true`, `0x01` ↔ `musicIsShuffle=false`. Bolt is spec-conformant — no vendor-specific values, no GROUP variants, no multi-pair Sets. Iter3 can ship with the documented mapping and not have to defensively handle GROUP/oversized-n cases.

• PASSTHROUGH path healthy: 7 press/release pairs (rawkey 68 PLAY ↔ 196 RELEASE; 75 FORWARD ↔ 203 RELEASE) all delivered. Y1MediaBridge state-tracking shows PLAYING/PAUSED transitions firing in lockstep — discrete-key chain is now correctly handled.
  • Subscribe re-registration cadence: 20 RegisterNotification inbounds across ~2 min (~10 s mean inter-frame) — much lower than the TV's storm shape, consistent with Bolt being a CHANGED-driven CT that re-subscribes on natural intervals rather than on every CHANGED edge.

Kia EV6 (active — car / highway)

Hyundai Motor Group head unit. Polls GetPlayStatus (PDU 0x30) at ~1 Hz, subscribes to event 0x02 TRACK_CHANGED only. Notable observations:

• iter22b/22c capture (/work/logs/dual-kia-iter22{b,c}/): all 5 RegisterNotifications were event 0x02; uses GetPlayStatus polling for play_status display rather than subscribing to event 0x01.
• Pre-iter22c: T6 GetPlayStatus returned stale playing_flag because Y1MediaBridge's onStateDetected (play / pause path) wasn't refreshing y1-track-info before broadcast. Symptom: car-side icon stuck on initial value until next track change. Closed by iter22c.
• Pre-iter22d: Kia HMI's discrete PLAY button (PASSTHROUGH 0x44 → uinput KEY_PLAYCD → KEYCODE_MEDIA_PLAY 126) found no music-app handler; only KEYCODE_MEDIA_PLAY_PAUSE (85) was wired. Symptom: pressing PLAY while paused did nothing; Kia eventually fell back to PAUSE (which toggles via 85) after ~11 s and 4 button presses. iter22d Patch E added a handler for keycode 126 but routed it through playOrPause() (toggle); refined in iter25 to call play(false) (discrete) per AVRCP 1.3 §4.6.1 + AV/C Panel Subunit Spec — see Bolt EV section above for the empirical reason for the iter25 refinement.
• Pre-iter22d: Kia hid the playback-progress scrubber during playback because T6 returned static position_at_state_change_ms (iter20a deferral). Closed by iter22d's clock_gettime(CLOCK_BOOTTIME)-based live extrapolation.
• mIBTAvrcpMusic binder doesn't connect — zero IBTAvrcpMusic.* log entries in iter22c / d captures. AVRCP transport commands reach the music app via the libextavrcp_jni avrcp_input_sendkey → uinput path only. Open investigation.
• 2026-05-08 postflash (/work/logs/dual-kia-postflash/): play-during-pause broken on the discrete-key chain (same symptom as Sonos — KEY_PLAYCD reaches kernel cleanly, play(Z) never fires in music app). 2026-05-09 re-test of an attempted fix (drop registerMediaButtonEventReceiver) confirmed MtkBt depends on the registered MediaButton client to locate Y1MediaBridge's IBTAvrcpMusic Binder — the change broke metadata delivery on Kia entirely (no Title / Artist / Album), and AVRCP behavior degraded toward 1.0 fallback. Reverted. The discrete-key chain-break remains open; whatever fix we try has to keep the registration intact. Track playing time + scrub-bar advance verified working pre-revert.

Lower BT profile-stack disassembly (2026-05-09)

Trigger: scoping the per-profile ICS-scoreboard pass (BT-COMPLIANCE.md §9.9). Goal: byte-level inventory of A2DP / AVDTP / AVCTP / GAVDP version + capability surfaces in the stock binaries so the existing AVRCP-1.3-paired V1 / V2 patches sit alongside an explicit map of the audio-triad gap.

Reads against /work/v3.0.2/system.img.extracted/. Current patch set (V1 / V2 / S1 / P1 + trampolines, post-v2.0.0) is the known-good wire baseline — V1 = AVRCP 1.0 → 1.3, V2 = AVCTP 1.0 → 1.2, both confirmed effective on the wire (Trace #12). Triad upgrade scope is the residual A2DP / AVDTP gap, not anything AVRCP / AVCTP.

Binary inventory

In-scope BT-related ELFs in stock v3.0.2:

Every profile from L2CAP up through AVRCP TG lives in mtkbt. Of the surrounding lib*.so files only libaudio.a2dp.default.so carries a BT-protocol-relevant function (standby_l → a2dp_stop → AVDTP SUSPEND on the wire), now covered by patch_libaudio_a2dp.py (AH1) — see §9.2 in BT-COMPLIANCE.md.

Static SDP record region

Profile-version bytes in stock mtkbt's SDP source live at file offset 0xeb9d0..0xebd00 (LOAD #1 rodata, vaddr == file_off). DataElement-decoder walk finds eight UUID-paired version entries (35 06 19 HH LL 09 VH VL shape), all but one reading 0x0100 in stock:

Stock [AVRCP] AVRCP V10 compiled build banner + dispatch behaviour (PASSTHROUGH-only, all metadata commands NACK) match these stock byte values: AVRCP 1.0 / AVCTP 1.0 / A2DP 1.0 / AVDTP 1.0 across the board, with one already-1.3 AVRCP entry (which the V1 site mirrors post-patch).

A 12-byte-stride attribute table at vaddr 0xfa700..0xfa9c0 indexes these byte ranges by SDP attribute ID ({ uint32 ptr; uint32 reserved; uint16 attr_id; uint16 length }). The current served record set deliberately omits attribute 0x000d (AdditionalProtocolDescriptorList — Browse PSM 0x001b) per the disproven Browsing-bit / Pixel-shape experiments above — staying off-Browse keeps Sonos and similar CTs from opening a channel mtkbt can't service.

V1 and V2 are wire-confirmed (Trace #12, line 1346). The remaining seven version sites (six unpatched + one stock-1.3 mirror) are not currently consulted by any peer in the test matrix, but the AVCTP-multiplicity question is open: only one of the three AVCTP sites is V2-patched, and whether the unpatched two would matter against a stricter CT than we've tested is unverified.

A2DP / AVDTP advertised at 1.0 — gap, not deviation

Both bytes at 0xeb9f2 and 0xeba09 read 0x0100 in stock and remain unpatched in the current --avrcp set. Spec-acceptable (we ship the SBC-only TG behaviour A2DP 1.0 demands), but spec-incomplete — features added in A2DP 1.2 (Content Protection / SCMS-T) and 1.3 (DELAY_REPORT) are off the table at the advertisement layer.

AVDTP signal coverage — codepoints vs handlers

ARCHITECTURE.md §"AVDTP signal codes" lists sig_id 0x01..0x0d as confirmed in mtkbt code. Provisional read superseded — the dispatcher disassembly in Trace #13 below shows real handler entries for all of sig 0x01..0x0d. Sig 0x0c (GET_ALL_CAPABILITIES) reaches a stub at 0xab4de that always returns BAD_LENGTH; sig 0x0d (DELAYREPORT) reaches 0xab540 with substantive logic. Sig 0x08 (CLOSE) and sig 0x09 (SUSPEND) jump-table entries point to the dispatcher's epilogue (0xab786) — handled elsewhere or trivially.

The pre-Trace-#13 read ("no log strings → silent drop") was wrong because:

1. radare2's aaa linear sweep failed to analyse the dispatcher at 0xaa72c (invalid bytes at 0xaa720 trapped its analyser → it silently skipped the function).
2. grep for log strings doesn't pick up handlers that don't emit log lines for the per-sig case (the dispatcher logs via fcn.000675c0 with a small per-sig string-id inside the prologue, before the TBH dispatch).

Implication for AVDTP version-byte bump (V3+V4 — AVDTP 1.0→1.3 in served A2DP Source SDP): now corroborated by disassembly. Advertising AVDTP 1.3 is not a pure paper claim — sigs 0x0c (GET_ALL_CAPABILITIES, AVDTP 1.3 ICS Acceptor Mandatory row 9) and 0x0d (DELAYREPORT, Optional) both have dispatch entries, though sig 0x0c's stub fails the response. V5 (sig 0x0c → sig 0x02 alias) closes the row 9 gap.

A2DP codec scope

Confirmed SBC-only. GavdpAvdtpEventCallback rejects non-SBC SEPs ([AVDTP_EVENT_CAPABILITY]not AVDTP_CODEC_TYPE_SBC → "try another SEP" fallback). No AAC / MP3 / ATRAC strings in mtkbt or libmtkbtextadpa2dp.so. SBC is Mandatory for A2DP 1.0+ TGs, so this is spec-compliant; AAC is Optional and not advertised.

Trace #13 (2026-05-09) — AVDTP signal dispatcher disassembled, V5 design candidate identified

Why this trace exists

Open-question items 1+2 ("AVDTP DELAY_REPORT and GET_ALL_CAPABILITIES handler — real or NOT_IMPLEMENTED stub?") and the V3+V4 SDP version bumps (A2DP/AVDTP 1.0→1.3) needed empirical answers from the binary. Static analysis using grep / objdump had been inconclusive because mtkbt is stripped + heavily MOVW/MOVT-encoded.

Tooling pivot

Per feedback_install_proper_tools.md memory rule, switched from grep-grinding to dnf install -y radare2 (one command, ~30 s), then used axt xref analysis on candidate per-sig handler functions. radare2's auto-analysis (aaa) had silently SKIPPED the dispatcher function because invalid bytes at 0xaa720 trapped its linear-sweep analyser — manual disassembly via r2 -c "pd 200 @ 0xaa72c" was needed.

The dispatcher

Located at file offset 0xaa72c in stock mtkbt (md5 3af1d4ad…). Prologue:

0xaa72c: push.w {r4-r8,sb,sl,fp,lr}    ; full-context save
0xaa73a: ldrb.w sb, [r1]               ; sig_id = first byte of cmd struct
0xaa7f6: add.w sb, sb, -1              ; sb = sig_id - 1 (TBH index)
0xaa812: cmp.w sb, 0x28                ; bounds check (accepts 0..0x28 = 41 entries)
0xaa816: bhi.w 0xab786                 ; OOB → epilogue
0xaa81a: tbh [pc, sb, lsl 1]           ; jump-table dispatch
0xaa81e: <halfword table>              ; entry n*2 → target = 0xaa81e + 2*halfword

Decoded jump table (sig_id 1..13)

Sig 0x0c stub anatomy (file 0xab4de)

0xab4de: ldrb.w lr, [r4, 8]      ; load response-buffer state byte
0xab4e2: cmp.w lr, 8
0xab4e6: bls 0xab51a              ; if state <= 8 → error path
0xab4e8: ldrb.w r8, [r4, 9]
0xab4ec: cmp.w r8, 0
0xab4f0: bne 0xab51a               ; if [r4+9] != 0 → error path
... (small "main" path that just calls a logger and returns to epilogue —
     no actual capability-list construction)
0xab51a: <error path>
  movs r0, 8 ; strb [r4, 8]    ; "8" stored
  movs r1, 6 ; strb [r6, 1]    ; "6" stored — internal state code
  bl fcn.000af4cc               ; error-response sender
  b 0xab786                     ; epilogue

A fresh inbound GET_ALL_CAPABILITIES has [r4+8] (response-buffer length) initially 0 or small → bls 0xab51a taken → error response. In effect mtkbt advertises sig 0x0c as supported but always rejects it.

V5 design candidate — 2-byte jump-table alias

Cleanest V5: change the halfword at file offset 0xaa834 from 60 06 (target 0xab4de stub) to 83 00 (target 0xaa924 sig 0x02 handler).

Pros:

• 2 bytes total. No code injection / trampoline needed.
• Sig 0x0c response body is a wire-compatible subset of GET_ALL_CAPABILITIES per V13 §8.8 (response = GET_CAPABILITIES content + optional service capabilities; we send only the GET_CAPABILITIES core, peer reads it as "no extended caps").
• Closes GAVDP 1.3 ICS Acceptor Table 5 row 9 (GET_ALL_CAPABILITIES_RSP).

Risk — unverified as of 2026-05-09: response wire sig_id may be hardcoded to 0x02 by the sig 0x02 handler. At 0xaa9fa the handler does strb r2, [r6, 1] with r2=2. Whether [r6+1] is the response wire sig_id field or an internal state byte is ambiguous from static analysis alone. Other per-sig handlers also write to [r6+1] (sig 5 writes 5, sig 0x0c stub writes 6) suggesting it's a state code, but the response wire sig_id origin needs runtime confirmation before V5 lands.

Validation plan

tools/attach-mtkbt-gdb-avdtp.sh updated to BP at:

• 0xaa72c (dispatcher entry — captures sig_id from [r1] and full cmd-buffer first 16 B)
• 0xaa924 (sig 0x02 handler entry — captures r4/r5/r6/r1 for state struct mapping)
• 0xab4de (sig 0x0c stub entry — confirms which inbound triggers it)
• 0xab51a (sig 0x0c error path — confirms always-reject behavior)
• 0xaeb9c (response sender called from sig 0x02 — captures sig_id arg location)
• 0xaf4cc (error response sender called from sig 0x0c — captures error format)

Drive a fresh pair attempt against any A2DP Sink CT (Sonos / Bolt / TV); the BPs at 0xaa72c will fire for every inbound AVDTP signal and let us cross-correlate sig_id source with the response builder's input.

Trace #13c (2026-05-09 night) — 0xaa72c reconfirmed as AVDTP dispatcher; full TBH table decoded

The 8-BP run (with peer driving a pair attempt) captured 13 wire-tagged dispatch fires through 0xaa72c with [r1] carrying AVDTP wire signal_ids. Sequence (chronological from /work/logs/mtkbt-gdb-avdtp.log):

Notably absent: sig 0x02 (GET_CAPABILITIES) and sig 0x0c (GET_ALL_CAPABILITIES) — peer skipped capability probing entirely. Likely cached capabilities from a prior pair, or the peer trusts the SDP record. This means V5 (sig 0x0c handler) is mechanically valid (dispatcher confirmed; jump-table entry at 0xaa834 routes sig 0x0c to 0xab4de stub) but won't be empirically tested against this CT — needs a stricter peer or unprimed re-pair to fire.

Struct geometry (constant across all dispatch fires):

• [r1+0]: msg/sig_id byte (the dispatched value)
• [r1+4..7]: pointer back to r0 (state struct ref, always 0x415e92b8)
• [r1+8..11]: function pointer (0x4028b8d4 = file 0xb8d4 — likely a shared completion callback)
• [r1+12..15]: per-msg payload (e.g., 0x14 for OPEN, 0x18 for sig 0x18)
• [r1+24..27]: 0x40290d29 (file 0x19cd29) — common state struct ptr

So [r1] is an internal mtkbt event message tagged with AVDTP wire-format sig_ids, not a raw L2CAP frame. The dispatcher routes 41 codepoints: sig_id 1-13 (AVDTP wire) + sig_id 14+ (internal events 0x17 background, 0x18 / 0x0f synthetic). Same TBH function handles both — V5's jump-table alias edit is geometrically sound.

Reverting Trace #13 follow-up's claim that fcn.000b0c30 is the real dispatcher: that function fired but only as the AVDTP state-machine driver (positive control), not as the wire-RX path. r1 args at fcn.000b0c30 had state=0x00 (7 fires) and state=0x03 (7 fires) with [r1+1] varying — internal state transitions, not signal frames. fcn.000b0c30 is a state-handler called BY the dispatcher's per-sig handlers, not the dispatcher itself.

Trace #13 follow-up (2026-05-09 evening) — 0xaa72c hypothesis invalidated, real dispatcher relocated to fcn.000b0c30

The 6-BP run captured in /work/logs/mtkbt-gdb-avdtp.log (828 lines) shows:

• 267 fires at 0xaa72c with [r1] = 0x17 (dec 23) — out of AVDTP wire signal range (0x01..0x0d). Single fire with [r1] = 0x10 (dec 16). Same r0 across all hits (r0 = 0x415e92b8, equal to [r1+4]).
• Zero fires at 0xaa924 (sig 0x02 handler), 0xab4de / 0xab51a (sig 0x0c stub + error path), 0xaeb9c, 0xaf4cc.

Conclusion: 0xaa72c is NOT the AVDTP wire-signal dispatcher. It's BlueAngel's internal task-message dispatcher — the function pointer at [r4+0x464] referenced from the orchestrator at 0xb1bc2 (a blx r3 indirect call). The TBH at 0xaa81a routes 41 internal task-message types, of which AVDTP wire signals are not one. My V5 design (jump-table alias at 0xaa834) was therefore based on the wrong jump table — patching it would change internal-message-type-12 routing, not AVDTP sig 0x0c.

The real AVDTP RX dispatcher: fcn.000b0c30 (file 0xb0c30). 6482 bytes, 239 basic blocks, 152 cyclomatic complexity — radare2's aaa linear sweep had silently skipped it because invalid bytes at 0xb0c20-0xb0c2e trap the analyser. Manual disasm at 0xb0c30:

0xb0c30: push.w {r4-r8,sb,sl,fp,lr}
0xb0c34: mov r8, r0                    ; r0 = stream / channel struct
0xb0c40: mov r5, r1                    ; r1 = AVDTP signal frame ptr
0xb0c44: ldrb r3, [r1]                 ; r3 = AVDTP byte 0 (header[0])
0xb0c4c: cmp r3, 7                     ; bound check
0xb0c4e: bhi.w 0xb19c8                 ; oob error
0xb0c52: tbh [pc, r3, lsl 1]           ; state-machine dispatch

Confirmed dispatcher because:

1. fcn.000afeec (AvdtpSigParseConfigCmd — confirmed via the [AvdtpSigParseConfigCmd]insert stream to channl stream list log string at 0xea67a) is called from bl at 0xb1012, which lies inside fcn.000b0c30's body.
2. Six other avsigmgr.c-tagged functions (0xafd5c, 0xb01b4, 0xb0270, 0xb0468, 0xaedd8, 0xafeec) are reachable from inside this function.
3. The byte-0 dispatch (cmp r3, 7) appears to be on AVDTP state code (8 states), not on signal_id — the signal_id parse happens after state selection. This matches BlueAngel's "stream signaling state machine" architecture.

Per AVDTP V13 §8.5, sig_id lives in byte 1 (low 6 bits) of the signal frame, not byte 0. Earlier interpretation (sig_id = [r1+0]) was geometrically wrong — that would have been transaction-label/packet-type/msg-type, not signal_id. The new BPs read [r1+1] & 0x3f for the wire signal_id.

tools/attach-mtkbt-gdb-avdtp.sh re-targeted at 0xb0c30 + 0xafeec + 0xb1012 + 0xb0b50. Re-run on next pair attempt will show:

• Sig_id of every inbound AVDTP signal (decoded from wire byte 1).
• AVDTP state code on each dispatch.
• SET_CONFIGURATION path (b1012 → afeec) for cross-confirmation.

V5 design TBD — depends on next capture's data on how sig 0x0c is currently rejected (or if it is at all) inside fcn.000b0c30.

Trace #14 (2026-05-10) — L2CAP PSM 0x19 callback registration located in mtkbt

Hunt: locate where mtkbt registers its inbound L2CAP callback for PSM 0x19 (AVDTP signaling/media), to anchor the RX chain that ultimately drives the dispatcher at 0xaa72c.

Method. AVCTP has the log string [AVCTP] register psm 0x%x status:%d at 0xdbea0; AVDTP doesn't have an equivalent log line, so the AVCTP register call site was used as the fingerprint. radare2 axt @ 0xdbea0 resolves to a PC-relative ADD at 0x6d2de inside an init function. The instruction immediately preceding is bl fcn.0007c78c at 0x6d2c8 — that's BlueAngel's L2CAP_RegisterPsm. Confirmed by inspecting fcn.0007c78c: it logs Protocol->inLinkMode:%d / Protocol->outLinkMode:%d, validates MTU between 0x12 and 0xfff9, and walks a 20-slot global registration table looking for an empty slot.

15 callers of fcn.0007c78c (all distinct profiles registering different PSMs). The AVDTP candidate is fcn.000ae9bc — sits in the AVDTP code region (0xae9bc in mtkbt), single-caller (bl at 0xab8a8 inside a larger init sequence). Disassembly confirms PSM 0x19:

0x000ae9bc      push.w {r4..fp, lr}
0x000ae9c2      bl fcn.000b54ec                 ; alloc / lookup PsmCtx
0x000ae9ca      bl fcn.000afb34                 ; init AVDTP local state
0x000ae9d0      movw r0, #0x69b                  ; MTU = 1691  (struct[+0x30])
0x000ae9d6      movs r3, #0x30                   ; channel mode flags (struct[+0x32])
0x000ae9d8      mov.w sb, #0x19                  ; PSM = 0x19  (struct[+0x2c])
0x000ae9dc      add r4, pc; ldr r4, [r4]         ; r4 = *(GOT slot 0xf9c38) = AVDTP state struct (R_ARM_RELATIVE → BSS @ link-vaddr 0x1b7d28)
0x000ae9e0      add r1, pc; ldr r1, [r1]         ; r1 = *(GOT slot 0xf9c3c) = AVDTP L2CAP callback fnptr (R_ARM_RELATIVE → 0xafc69, thumb-bit fnptr to fcn at 0xafc68)
0x000ae9e4      strh r0, [r4, #0x30]             ; PsmCtx.MTU = 0x69b
0x000ae9e6      str  r1, [r4, #0x28]             ; PsmCtx.callback_struct = r1
0x000ae9e8      add.w r0, r4, #0x28              ; r0 = &PsmCtx[0x28] (= L2CAP register arg)
0x000ae9ec      strh.w sb, [r4, #0x2c]           ; PsmCtx.PSM = 0x19
0x000ae9f0      strh r3, [r4, #0x32]             ; PsmCtx.flags = 0x30
0x000ae9f6      strb.w r7, [r4, #0x36]           ; outLinkMode = 1
0x000ae9fa      strb.w r7, [r4, #0x35]           ; inLinkMode  = 1
0x000aea06      bl fcn.0007c78c                  ; L2CAP_RegisterPsm(&PsmCtx[0x28])
0x000aea0a      mov r5, r0                        ; r5 = register status (0 = OK)
0x000aea0e      bne 0x000aea7c                   ; on error → return r8
0x000aea10..7a                                   ; success: 4-iteration SEP-init loop, stride 0x18

L2CAP register-arg layout (relative to r0 passed into fcn.0007c78c):

Caller context (0xab8a8 in some larger AvdtpInit-like entry, hosted inside r2's mis-spanning fcn.0000d98c):

0x000ab884      bl fcn.0004ca90                 ; memset some ctx region
0x000ab88a      add.w r0, r4, #0x1ac
0x000ab88e      str r3, [r4, #4]                ; flag = 1
0x000ab890      strb r3, [r4, #1]               ; flag = 1
0x000ab892      strb r5, [r4]                    ; type = arg
0x000ab894      bl fcn.0006ce5c                 ; init list / queue ×3 at +0x1ac, +0x1b4, +0x1bc
0x000ab8a8      bl fcn.000ae9bc                 ; ← AVDTP L2CAP register
0x000ab8ac      mov r0, r5; pop {r4, r5, r6, pc}

Implications.

1. Single registration, single PSM (0x19) — AVDTP signaling and media share PSM 0x19 per AVDTP V13 §6 (multiplexed via L2CAP CIDs at runtime). No separate "media-channel" register exists.
2. MTU advertised: 1691 (0x69b). AVDTP V13 §6.4.1 mandates ≥ 672 for signaling; 1691 is consistent with BasePoint default. Sufficient for AVDTP 1.3 GET_ALL_CAPABILITIES_RSP (worst case ~50 B per Service Capability × N caps, well under 1691).
3. Mode flags 0x30 + inLinkMode/outLinkMode = 1 — Basic L2CAP mode (no ERTM/streaming-mode), consistent with stock A2DP 1.0 era. ERTM is optional per AVDTP V13 §A.2 ICS row M.4 — not advertised here.
4. The callback table at PIE-resolved address 0xf9c3c contains AVDTP signaling layer's connect/disconnect/data-indication entry points. The data-indication path is what eventually feeds fcn.000b0c30 (the stream signaling state machine) and the per-signal handlers (0xaa924 sig 0x02, 0xab4de sig 0x0c stub, etc.) — closing the upstream side of the RX chain Trace #13c established the downstream side of.

Anchors for future work (this register call is not patched today; documented for completeness in case a future deviation requires altering MTU, channel mode, or the callback set):

• AVDTP register fcn: file offset 0xae9bc (one caller at 0xab8a8)
• L2CAP_RegisterPsm: file offset 0x7c78c (15 callers covering all profiles)
• AVCTP register caller: 0x6d2c8 (PSM 0x17, MTU 0x69b same advertised cap, inside fcn.0000f79c-region init)
• AVDTP state-struct GOT slot: vaddr 0xf9c38 → R_ARM_RELATIVE addend 0x001b7d28 (link-time vaddr in .bss; fcn.000b54ec memsets 0x8fc=2300 bytes there at boot; 16 internal AVDTP module fns reference this slot for state access — confirmed via axt @ 0xf9c38)
• AVDTP L2CAP callback GOT slot: vaddr 0xf9c3c → R_ARM_RELATIVE addend 0x000afc69 (thumb-bit fnptr to fcn at 0xafc68 — the inbound-L2CAP-frame handler installed in the BlueAngel global PSM registry)

The L2CAP callback (fcn at 0xafc68) — entry point for every inbound AVDTP frame on PSM 0x19. r2 doesn't recognise it as a function (no fcn label) but disasm is clean from 0xafc68 onward with a standard prologue. Signature: (arg0, arg1) where arg1 is an L2CAP event/frame struct (arg1[0] = event-type byte, arg1[+4] = payload pointer). Body:

0x000afc68      push {r4, r5, r6, lr}
0x000afc6a      mov r6, r1                       ; arg1 = event/frame struct
0x000afc6c      ldr r4, [r1, #4]                 ; r4 = arg1[+4] = payload ptr
0x000afc6e      mov r5, r0                       ; arg0 = channel/conn handle
0x000afc72      bl fcn.000afb7c                  ; helper (reads AVDTP state via slot 0xf9c38)
0x000afc76      ldrb r3, [r6]                    ; r3 = event_type byte
0x000afc78      cbz r0, 0xafca0                  ; helper returned 0 → connection-init path
0x000afc7a      cmp r3, #1                        ; event_type == 1?
0x000afc7c      beq 0xafc8c                       ; 1 → config_ind / specific event
                                                  ; else → fcn.000afbfc (data dispatch)
0x000afc8c..afc9e                                 ; case-1: fcn.000afbfc(0); store r5 → r4[+0]
0x000afca0..afcc4                                 ; helper-returned-0 path: alloc via fcn.000afba0 OR recurse via fcn.000afc2c
0x000afcb8      pop {r4, r5, r6, lr}
0x000afcbc      b.w fcn.0007d624                 ; tail call back into L2CAP module
0x000afccc..end                                   ; common success path: bl fcn.00084240 (alloc?), TBH dispatch via slot at [r3 + r0 lsl 2]

Helper map (all read AVDTP state via slot 0xf9c38):

• fcn.000afb7c (in-degree 1): channel/SEP lookup helper, called once per inbound frame from 0xafc72.
• fcn.000afbfc (in-degree 3): data-handler, fires from 0xafc80 (event_type ≠ 1) and 0xafc8e (event_type == 1). Likely the path that walks per-channel state and dispatches into fcn.000b0c30 (the AVDTP state machine) — verifiable via gdb breakpoint.
• fcn.000afba0 (in-degree 1): allocator, fires from 0xafca4 on connection-init path.
• fcn.000afc2c (in-degree 1): recursive sub-handler, fires from 0xafcc4.

Indirect dispatch into 0xb0c30 / 0xaa72c. r2 reports zero direct callers for both fcn.000b0c30 (state-machine dispatcher) and 0xaa72c (GavdpAvdtpEventCallback) — they're invoked exclusively via function pointer fields in the AVDTP state struct (offset 0x464 for the event callback, per the blx r2 indirect pattern noted earlier in fcn.000b09fc). Those fnptrs are written to the BSS state struct during AVDTP layer init — at link time the struct is zero, so init-time stores set them up. The chain is therefore:

inbound L2CAP frame on PSM 0x19
  → BlueAngel L2CAP RX (fcn.0007d624 region)
  → registered PSM-callback dispatch
  → fcn at 0xafc68              [the AVDTP L2CAP callback, this trace]
  → fcn.000afbfc / afb7c         [helpers; resolve channel from frame]
  → channel-specific data-ind    [stored fnptr in per-channel struct, set at config time]
  → fcn.000b0c30                 [AVDTP signaling state machine, Trace #13c]
  → per-signal handler            [0xaa924 sig 0x02, 0xab4de sig 0x0c stub, etc.]
  → AVDTP state struct callback at offset 0x464
  → 0xaa72c (GavdpAvdtpEventCallback) [GAVDP-layer event dispatch, Trace #13c]

Empirical close-out left for hardware. The fnptr stored at AVDTP-state[0x464] is the only remaining gap and it's runtime-populated. Adding two BPs to the existing tools/attach-mtkbt-gdb-avdtp.sh — one at 0xafc68 (logging arg0 / arg1[0] / arg1[+4]) and one at the indirect blx r2 site at 0xb0b46 (logging r2 = the resolved fnptr) — would print the full chain on the next pair attempt. No patch action implied; this is map-completion work.

Trace #15 (2026-05-10) — GET_CAPABILITIES response builder calling convention; V5 risk re-evaluated

Hunt: characterise the call signature of fcn.000aeb9c (the function the sig 0x02 handler at 0xaa924 calls to "send the response") so we can validate whether V5's redirect of sig 0x0c into the same handler produces a wire-correct response or breaks signal-id pairing per V13 §8.5.

Calling convention.

int fcn_000aeb9c(AvdtpChannel *channel, uint8_t ack_flag);

• r0 (channel): pointer to AVDTP signaling channel context. Validated non-null; offset+8 looked up against a global registry via fcn.0006ccdc. Returns 0x12 on null, 0xd on lookup-miss, 0xb on state error from fcn.0006d9ac. Otherwise tail-calls fcn.000afd40(channel+8, ack_flag).
• r1 (ack_flag): u8. Observed values at the sig 0x02 handler call sites:
  • 0 at 0xaa948 — error path ("no registered SEP" log, follows the search for a SEP that found none).
  • 1 at 0xaa9fe — success path (taken after the handler builds the per-SEP capability payload and stores the request sig_id into the global state).

Tail chain.

fcn.000aeb9c (channel, ack_flag)
  → bl fcn.0006ccdc       [registry lookup]
  → bl fcn.0006d9ac        [state validate]
  → b.w fcn.000afd40       [tail call]

fcn.000afd40 (channel, ack_flag)
  → r0 = *(channel)        [halfword: L2CAP CID]
  → if (ack_flag == 0) r1 = 0, r2 = 0   [reject path]
  → else                  r1 = 4, r2 = ack_flag   [accept path]
  → bl fcn.0007d624

fcn.0007d624 (cid, accept_flag, link_modes)
  → log "l2cap: Upper accept" (or "Upper reject")
  → look up channel via fcn.00083014
  → if channel state != 0xa: dispatch to fcn.000860d8 ("createchannel"), log "l2cap: pass to createchannel status:%d"
  → else: validate, store config bytes (link_modes[0..0x14]) into channel ctx at offsets 0xd4/0xd8/0xe0/0x104/0x108/0x143
  → tail-call fcn.0007d500 (L2CAP signal-frame TX dispatch)

The reframe: fcn.0007d624 is BlueAngel's L2CAP_ConnectRsp — the upper-layer accept/reject for an inbound L2CAP CONNECT_REQ. It is not the AVDTP signal-frame TX path. So fcn.000aeb9c is the GAVDP-to-AVDTP-layer handshake function: GAVDP says "I accept this signaling channel" (or rejects it), and BlueAngel's AVDTP layer emits the corresponding L2CAP CONNECT_RSP.

The pre-call state setup (memcpy into [channel + 0xc4] from [msg.field_at_0x1c + 0xc0], stores at [channel + 0xa4] / [channel + 0xa8], write to [GlobalAvdtpState + 1] = 2) is not wire-frame construction — it's per-channel context setup so that BlueAngel's AVDTP layer can subsequently parse and respond to in-band signal frames.

Where the actual GET_CAPABILITIES_RSP wire frame is built: not yet localised. The sig 0x02 handler at 0xaa924 prepares state, then calls fcn.000aeb9c which goes to L2CAP_ConnectRsp — but the AVDTP signal-frame response (with sig_id byte 1, msg_type=RSP_ACK in byte 0) must be emitted somewhere else, presumably by AVDTP layer code triggered by a state transition rather than by direct call from the handler. fcn.000afd40 only writes the L2CAP CID and the accept-flag — no AVDTP signal_id byte construction.

V5 risk re-evaluation (refines the "best-effort workaround" wording from Trace #13):

1. The handler at 0xaa924 doesn't write the wire signal_id byte. It writes 2 to [GlobalAvdtpState + 1], but that's an internal state byte (the r6 base is the AVDTP module's global state struct loaded from GOT slot 0xf9c14, not the wire frame).
2. The L2CAP CONNECT_RSP path doesn't carry an AVDTP signal_id either. It just accepts/rejects the L2CAP channel.
3. Therefore the wire response sig_id is determined elsewhere, and almost certainly preserves the request's sig_id (since BlueAngel's AVDTP layer parses each request, records the sig_id internally, and pairs the response to it per V13 §8.5).
4. V5's redirect of sig 0x0c to the case-2 handler is therefore likely wire-correct: the handler builds Service-Capabilities payload (the same content valid for both GET_CAPABILITIES_RSP and GET_ALL_CAPABILITIES_RSP per V13 §8.8), and the AVDTP layer's wire-frame TX preserves sig_id=0x0c from the request.
5. Empirical risk remains in the "wire frame builder localisation" gap — without finding the actual TX code that writes byte 1 of the response, we can't prove sig_id is preserved. A peer that exercises sig 0x0c (GET_ALL_CAPABILITIES) is the only definitive test.

Net for the V5 ship (committed in e51da3f): the risk language can be downgraded one notch — from "best-effort workaround that may break signal-id pairing" to "best-effort alias whose wire-correctness depends on AVDTP layer preserving the request sig_id, which is the architectural norm for BlueAngel-style stacks but not statically verified in our binary." Patch is still safe (sig 0x0c stub at 0xab4de currently does nothing; redirect to 0xaa924 cannot regress that), still empirically untested (no peer probes with sig 0x0c on the current CT matrix), and the only path forward to definitive verification is a peer that fires sig 0x0c.

Anchors for the wire-frame-builder hunt (next session, if anyone wants to close the V5 verification gap):

• Search for str / strb instructions writing a halfword/byte where bit pattern matches (tlabel<<4)|(0<<2)|2 (= AVDTP RSP_ACK byte 0) — these are the wire byte 0 emitters.
• Check fcn.00083014 (called by fcn.0007d624): looks up channel by CID; the channel struct after offset 0x100 might contain pending-response sig_id state.
• The TX path is likely fired by AVDTP signaling state machine (fcn.000b0c30, Trace #13c) on a state transition when GAVDP returns ACK via fcn.000aeb9c — so dynamic BPs at fcn.000b0c30's exit edges + the L2CAP TX call site after fcn.0007d624's state-change branch would catch it.

Trace #16 (2026-05-10) — AVDTP signal-frame TX site localised; V5 wire-correctness upgraded to "verified by decoupling"

Goal of this trace: close the verification gap left open at the end of Trace #15 — find the actual wire-frame builder that writes byte 1 (sig_id) of the AVDTP signal response, and prove that V5's redirect of sig 0x0c into the sig 0x02 handler at 0xaa924 produces a wire-correct response (sig_id=0x0c, not sig_id=0x02).

Method. Searched for callers of L2CAP_SendData (= fcn.0007d204, identified via the "L2CAP_SendData state:%d return:%d" log string at 0xe0062). Three callers fall in the AVDTP/AVCTP region: fcn.000ae418 (AVDTP), fcn.000b1c38, and fcn.000b31ac (AVCTP-side). fcn.000ae418 is the AVDTP signal-frame TX builder.

fcn.000ae418 entry signature.

0x000ae418  push {r3,r4,r5,r6,r7,r8,sb,lr}
0x000ae41c  mov  r4, r0                ; r4 = arg1 (channel/state context)
0x000ae41e  ldrh.w r0, [r0, #0x60]     ; r0 = halfword at [r4+0x60] (CID)
0x000ae422  bl   fcn.0007ccb4          ; CID lookup

The function operates on a per-channel context r4 whose layout includes:

• r4 + 0x10 pointer to per-transaction state struct (call it txn)
• r4 + 0x1c transaction-label byte
• r4 + 0x20 packet body buffer base
• r4 + 0x5d / 0x5e / 0x5f packet header byte slots
• r4 + 0x60 L2CAP CID

Wire byte 1 (sig_id) origin. The single-packet path writes the sig_id byte from the per-transaction state struct, not from anything the dispatch handler at 0xaa924 set:

0x000ae472  ldr  r3, [r4, #0x10]      ; r3 = txn (per-channel transaction state)
0x000ae474  ldrb r1, [r3, #0xd]       ; r1 = txn->[0xd]  (msg_type / pkt_type latch)
0x000ae476  cmp  r1, 2                 ; check msg_type == RESPONSE_ACCEPT
0x000ae478  ittt ne
0x000ae47a  ldrh r3, [r3, #0xe]       ; r3 = txn->[0xe..0xf] halfword (sig_id at low byte)
0x000ae47c  add.w sb, r5, #-1
0x000ae480  strb r3, [r5, #-1]        ; *(r5-1) = low byte of txn->[0xe] → wire byte 1 (sig_id)

So byte 1 of the response frame on the wire = txn->[0xe], where txn = *(r4 + 0x10). This is the per-transaction state struct populated by the AVDTP request parser when the request is received; the sig-handler dispatch (the TBH table at 0xaa81e + sig-handlers like the one at 0xaa924) does not touch it.

Wire byte 0 (header). Built from (tlabel << 4) | pkt_type<<2 | msg_type:

0x000ae492  lsls r2, r6, 4             ; r2 = tlabel << 4
0x000ae494  ldrb r1, [r4, 0x1c]
0x000ae496  adds r0, r2, 4             ; +4 = pkt_type=01 (START), msg_type=00 (CMD)  — fragmented-cmd path
...
0x000ae510  strb.w r6, [r4, 0x5f]      ; wire byte 0

For the single-packet RSP_ACCEPT path the constant added is the response-msg-type bits (msg_type=10, pkt_type=00 → +2), not 4. Either way, byte 0 is composed from the transaction-label register r6 (sourced from per-channel context), not from a dispatch-handler-tied constant.

Frame TX call. After header + body assembled at r4+0x20..r4+0x60:

0x000ae586  ldrh.w r0, [r4, 0x60]     ; r0 = CID
0x000ae58a  add.w  r1, r4, 0x20        ; r1 = packet base
0x000ae58e  bl     fcn.0007d204        ; L2CAP_SendData(cid, packet, ...)

Net for V5 wire-correctness.

The V5 patch redirects tbh[11] (sig 0x0c GET_ALL_CAPABILITIES) to dispatch into the sig 0x02 handler at 0xaa924. The sig_id byte that appears on the wire in the response frame is read from txn->[0xe], populated by the request parser (in the L2CAP RX → state-machine path under fcn.000b0c30, not in the per-signal handler). The handler at 0xaa924 does not write to txn->[0xe]; the only byte it stores is to [r6, 1] where r6 is the AVDTP module's global state struct (loaded from .got slot 0xf9c14), and that store is a state-machine field (value 2), not a wire-frame field.

Therefore, when a peer sends GET_ALL_CAPABILITIES_REQ (sig_id = 0x0c), the request parser stores 0x0c at txn->[0xe], the dispatcher (post-V5) routes through the GET_CAPABILITIES handler at 0xaa924, the handler runs and updates state, and the response builder fcn.000ae418 reads txn->[0xe] = 0x0c and writes 0x0c into the response frame's byte-1 slot. Peer receives GET_ALL_CAPABILITIES_RSP_ACCEPT with sig_id=0x0c — wire-correct.

Risk language upgrade. §9.13 (and the V5 patch comment in patch_mtkbt.py) can move from "wire-correctness plausible but not statically proven" to "wire-correct: the response sig_id byte is sourced from per-transaction state populated at request-parse time, decoupled from the dispatch handler." The remaining unverified surface is the response payload — V13 §8.8 mandates that GET_CAPABILITIES_RSP_ACCEPT and GET_ALL_CAPABILITIES_RSP_ACCEPT carry the same Service-Capability TLVs (the latter is a strict superset, but legacy capability servers may answer either with the same Service-Capability set, which is spec-permissible since the additional 1.3 capability categories — DELAY_REPORTING etc. — are all Optional). Since the handler at 0xaa924 emits the GET_CAPABILITIES Service-Capabilities payload, that's spec-conformant for either request.

Anchor for any future GET_ALL_CAPABILITIES_REQ injection test: patch a peer or test harness to issue sig 0x0c on the AVDTP signaling channel, capture the response, verify byte1 = 0x0c and the Service-Capabilities TLV list matches what stock issues for GET_CAPABILITIES.

Trace #17 (2026-05-10) — PlayerApplicationSettings response builders disassembled

Goal: map calling conventions for the six PDU response builders + event 0x08 builder needed by Phase F4 (PApp Settings: ICS Table 7 rows 12-17 + 30). All seven builders are present in libextavrcp.so and PLT-linked from libextavrcp_jni.so, so the disassembly is purely compiler-RE — no missing-symbol gaps.

Final calling conventions (also tabulated in ARCHITECTURE.md):

PDU 0x11 — btmtk_avrcp_send_list_player_attrs_rsp (file 0x1e24, 80 B): (conn, reject, n_attrs, *attr_ids). arg1=r0=conn, arg2=r1=reject_flag, arg3=r2=count of attribute IDs, arg4=r3=pointer to byte array. Stack buffer 14 B; emits msg_id=0x20c=524. Reject path: stores 1 at sp+7 and reject byte at sp+8.

PDU 0x12 — btmtk_avrcp_send_list_player_values_rsp (file 0x1e74, 92 B): (conn, reject, attr_id, n_values, *values). r0/r1 same; r2=attr_id, r3=n_values, arg5 (sp+0x28 in callee frame) = pointer to value array. msg_id=0x20e=526.

PDU 0x13 — btmtk_avrcp_send_get_curplayer_value_rsp (file 0x1ed0, 94 B): (conn, reject, n_pairs, *attr_ids, *values). r0/r1 same; r2=n_pairs, r3=attr_id_array, arg5 (sp+0x30) = value_array. Loop writes attr_ids at sp+12+i and values at sp+16+i. Wire format on AVRCP layer is interleaved (attr,val pairs) — AVRCP_SendMessage handles the IPC→wire repacking. Stack buffer 18 B; msg_id=0x210=528.

PDU 0x14 — btmtk_avrcp_send_set_player_value_rsp (file 0x1f2e, 40 B): (conn, reject_status). Smallest builder; reject_status==0 emits an ACK, otherwise emits a reject with that status code. msg_id=0x212=530, 8 B payload.

PDU 0x15 — btmtk_avrcp_send_get_player_attr_text_rsp (file 0x1f58, 228 B): (conn, reject, idx, total, attr_id, charset, length, *str). Accumulator pattern parallel to …send_get_element_attributes_rsp from the existing T4: caller invokes once per attribute (idx=0..total-1) and the function emits AVRCP_SendMessage only when idx+1==total AND total!=0 (or on reject). Internal static buffer at vaddr 0x5ea4 (g_avrcp_playerapp_attr_rsp); per-attribute string slot is 80 B (cap 0x4f=79 B usable). Args5-8 on caller's stack at offsets 0,4,8,12. msg_id=0x214=532.

PDU 0x16 — btmtk_avrcp_send_get_player_value_text_value_rsp (file 0x203c, 252 B): (conn, reject, idx, total, attr_id, value_id, charset, length, *str). Same accumulator shape as 0x15 but with both attr_id and value_id since each value gets its own text. Internal buffer at vaddr 0x5ffe (g_avrcp_playerapp_value_rsp). Args5-9 on stack. msg_id=0x216=534.

Event 0x08 — btmtk_avrcp_send_reg_notievent_player_appsettings_changed_rsp (file 0x2720, 144 B): (conn, reject, type, n, *attr_ids, *values). type: 0=INTERIM, 1=CHANGED. n is internally capped at 4 (max attribute count per AVRCP V13 §5.2). Args5-6 on stack. event_id constant 0x08 baked at sp+13. msg_id=0x220=544 (same msg_id as other notification events; the event_id byte at sp+13 is what differentiates).

Common shape across all seven builders:

• arg1 (r0) is always the conn buffer (= r5+8 in saveRegEventSeqId frame).
• arg2 (r1) is always reject/changed_flag: 0 = success path (full payload), !=0 = reject (truncated payload, status byte placed in a builder-specific slot).
• transId is sourced from conn[17] and written into the wire frame internally — no caller responsibility.
• AVRCP_SendMessage(conn, msg_id, sp_buffer, length) closes each builder.

PLT linkage in libextavrcp_jni.so (verified by r2 -A "ii~+player"):

All seven exist as proper PLT entries. None require new dynamic-linker resolutions.

Implementation implications for F4 (next-iteration anchors):

1. Decoder dispatch. The existing trampoline chain (T1 → T2 → T_charset → T_battery → T_continuation → T6 → T8 → T9 → T4 → fall-through-to-0x65bc) reads the PDU byte at sp+382 and routes by exact match. Adding F4 means six new PDU comparisons (0x11..0x16). Cleanest insertion is a single new T-trampoline that hosts all six dispatchers internally — call it T_papp (or T10 for naming continuity). It chains in before T4's fall-through, so unknown-to-F4 PDUs flow into the existing 0x20 GetElementAttributes handler.
2. Inbound parameter parsing. AVRCP body for PDUs 0x11-0x16 starts at sp+388 (after the 6-byte AV/C BT-SIG header at sp+378-383 and 2-byte param_length at sp+384-385). PDU 0x12 needs 1-byte attr_id; PDU 0x13 needs 1-byte n + n attr_ids; PDU 0x14 needs 1-byte n + n×{attr_id, value_id}; PDU 0x15 needs 1-byte n + n attr_ids; PDU 0x16 needs 1-byte attr_id + 1-byte n + n value_ids.
3. State storage. Y1MediaBridge already has the file-based contract for track metadata (/data/data/com.y1.mediabridge/files/y1-track-info, world-readable). Mirror this with y1-papp-state containing the current Repeat (id=2) and Shuffle (id=3) values. Y1MediaBridge writes when AndroidMediaController state changes; T_papp reads when responding to 0x13. Set commands (PDU 0x14) get applied by writing a y1-papp-set request file that Y1MediaBridge picks up via FileObserver and applies to the Android session via MediaController.transportControls.setRepeatMode/setShuffleMode.
4. Event 0x08 emission. Existing T2/T8/T9 register-notification trampolines remember the registering peer's transId in BSS. Add an analogous slot for event 0x08 transId (already-allocated globals: tc_transId for event 0x02, pb_transId for event 0x01, pos_transId for event 0x05; add pas_transId). Y1MediaBridge's onStateChange triggers re-firing T_papp's CHANGED-emit path when Repeat/Shuffle move.
5. Padding budget. Current _trampolines.py uses 1652 B of LOAD #1 padding (0xac54..0xb2c8); 2368 B remain. F4's T_papp is estimated at 400-600 B (six PDU dispatchers + one event re-emit path). Comfortable fit.
6. Strict scope alignment. Per AVRCP V13 §5.2.1 Player Application Settings, supporting any one PApp attribute makes ICS C.14 fire and rows 12-17 + 30 become Mandatory. Anchoring on Repeat (attr_id=2) + Shuffle (attr_id=3) maps cleanly to AndroidMediaController's repeat/shuffle modes (Y1's KitKat-era stack supports both via setRepeatMode / setShuffleMode). These are the two universally-implemented PApp attributes on real CT/TG implementations and represent the strictest spec-conformance posture without adding device-specific equalizer/scan plumbing that doesn't exist on Y1.

Trace #18 (2026-05-10) — F4 iter2/3/4 staged plan: real Repeat/Shuffle state binding

iter1 ships hardcoded "Repeat OFF + Shuffle OFF, Set rejects with 0x06 INTERNAL_ERROR". The next iterations replace the hardcoded values with real state binding to the Y1 music app's SharedPreferencesUtils (where Repeat/Shuffle currently live). This trace captures the staged plan so the work can be sequenced cleanly without compounding unverified changes.

Music app state surfaces (from com/innioasis/y1/utils/SharedPreferencesUtils.smali).

public final getMusicIsShuffle()Z          // SharedPreferences key "musicIsShuffle"
public final setMusicIsShuffle(Z)V         // Editor.putBoolean + commit
public final getMusicRepeatMode()I         // SharedPreferences key "musicRepeatMode"
public final setMusicRepeatMode(I)V        // Editor.putInt + commit

PlayerService.smali defines the integer enum used by musicRepeatMode:

public static final REPEAT_MODE_OFF:I = 0x0
public static final REPEAT_MODE_ONE:I = 0x1
public static final REPEAT_MODE_ALL:I = 0x2

AVRCP 1.3 §5.2.4 Tbl 5.20 (Repeat) values: 0x01 OFF / 0x02 SINGLE / 0x03 ALL / 0x04 GROUP. Mapping (Y1 ↔ AVRCP): 0 ↔ 0x01, 1 ↔ 0x02, 2 ↔ 0x03 (Y1 has no GROUP). Verified 2026-05-09 via gdb-capture (/work/logs/papp-gdb.log): Bolt sends 0x01/0x02/0x03 (never 0x04) — bidirectional mapping is sound for both inbound Set and outbound GetCurrent.

AVRCP §5.2.4 Tbl 5.21 (Shuffle) values: 0x01 OFF / 0x02 ALL / 0x03 GROUP. Mapping (Y1 ↔ AVRCP): false ↔ 0x01, true ↔ 0x02. Verified 2026-05-09: Bolt sends 0x02 (never 0x03).

Cross-app context handle (already available). Y1Application$Companion.getAppContext():Context is reachable from any smali via Y1Application;->access$getAppContext$cp()Landroid/content/Context;. This eliminates the "no Context handle in static-ish methods" blocker noted in earlier deferral notes — setMusicIsShuffle / setMusicRepeatMode can sendBroadcast directly using the app-singleton context.

Iter2 (read path). Make T_papp 0x13 and T8 event 0x08 INTERIM reflect real Y1 Repeat/Shuffle state.

• B1 / B2 in patch_y1_apk.py. Inject sendBroadcast at the end of setMusicIsShuffle and setMusicRepeatMode. Action com.y1.mediabridge.PAPP_STATE_CHANGED; extras isShuffle:Z (B1) and repeatMode:I (B2). Pre-condition: .locals bumped from 4 → 5 to give us a free local register to save the original pN value across the SharedPreferences write (the existing body clobbers p1 via sget-object p1, …editor). Post-condition smali shape:

  ` .method public final setMusicIsShuffle(Z)V .locals 5 move v4, p1 ; iter2: save original boolean …existing body unchanged… ; iter2 inject — broadcast new value invoke-static {}, Lcom/innioasis/y1/Y1Application;->access$getAppContext$cp()Landroid/content/Context; move-result-object v0 if-eqz v0, :iter2_skip new-instance v1, Landroid/content/Intent; const-string v2, "com.y1.mediabridge.PAPP_STATE_CHANGED" invoke-direct {v1, v2}, Landroid/content/Intent;->(Ljava/lang/String;)V const-string v2, "isShuffle" invoke-virtual {v1, v2, v4}, Landroid/content/Intent;->putExtra(Ljava/lang/String;Z)Landroid/content/Intent; invoke-virtual {v0, v1}, Landroid/content/Context;->sendBroadcast(Landroid/content/Intent;)V :iter2_skip return-void .end method ` B2 mirrors with Z → I and key "repeatMode".

• Y1MediaBridge. Add PappStateReceiver inner class (BroadcastReceiver) registered for com.y1.mediabridge.PAPP_STATE_CHANGED. On receipt: read both extras (default to current cached values when only one is present), translate to AVRCP enum, write 2 bytes ([avrcp_repeat, avrcp_shuffle]) to /data/data/com.y1.mediabridge/files/y1-papp-state via the same atomic tmp + rename pattern as y1-track-info. prepareTrackInfoDir() creates the file with default [1, 1] (OFF, OFF) on first launch so trampolines can read it before any music-app write fires.
• T_papp 0x13 (GetCurrent). Replace the hardcoded papp_current_values ADR with: open + read 2 bytes from y1-papp-state into stack scratch; if read fails, fall back to the hardcoded [1, 1]. Same pattern T4 uses for y1-track-info. Frame growth: +8 B for the file-I/O scratch + outgoing arg ptr.
• T8 event 0x08 INTERIM. Same file-read pattern; emit n=2 + [(2, repeat_value), (3, shuffle_value)].

Iter3 (write path). Make T_papp 0x14 (Set) actually apply changes.

• T_papp 0x14 (Set). Replace the iter1 reject path with: open /data/data/com.y1.mediabridge/files/y1-papp-set, write 2 bytes [attr_id, value] from the inbound param body (sp+387 / sp+389 — first attr/value pair; multi-pair Sets fall back to first), close, ACK.
• Y1MediaBridge. Add FileObserver watching y1-papp-set for MODIFY. On fire: read the 2 bytes, dispatch by AVRCP attr_id (2 → setMusicRepeatMode mapped back from AVRCP enum; 3 → setMusicIsShuffle). Use sendBroadcast to a music-app-side BroadcastReceiver added by:
• B3 in patch_y1_apk.py (or new dynamic register in Y1Application.onCreate): a BroadcastReceiver listening for com.y1.mediabridge.PAPP_SET_REQUEST with extras attr:I + value:I. On receipt, calls back into SharedPreferencesUtils.setMusicRepeatMode / setMusicIsShuffle with the AVRCP→Y1 inverse mapping. The setters then fire B1/B2 broadcasts which Y1MediaBridge consumes — closing the loop.
• PlayerService application of the change. setMusicRepeatMode / setMusicIsShuffle only update SharedPreferences; the actual playback behavior (does the next track repeat? does the next track shuffle?) is driven by PlayerService reading those preferences at the right time. Confirming that PlayerService re-reads on every track-end transition (vs caching at startup) is open work.

Iter4 (CHANGED). Make event 0x08 fire CHANGED on real edges.

• MtkBt cardinality NOP. BTAvrcpMusicAdapter.handleKeyMessage has per-event-id cardinality checks (if-eqz v5 patterns; same shape as the existing event-0x01 + event-0x02 NOPs) that drop the CHANGED firing if the cardinality field is 0. The event 0x08 sswitch arm needs the same NOP. Locate via grep on the smali / odex disassembly for the dispatch table.
• Native jump-patch in libextavrcp_jni.so. Add a notificationPlayerAppSettingsChangedNative analogue: identify which native method MtkBt calls for event 0x08 (or whether one exists), patch its first instruction to b.w T_papp_changed. T_papp_changed reads y1-papp-state + emits reg_notievent_player_appsettings_changed_rsp with REASON_CHANGED.
• T9-style edge detect. State byte in y1-trampoline-state (currently 16 B with last_play_status / last_battery_status at bytes 9-10) gains last_repeat_value / last_shuffle_value at bytes 11-12. T_papp_changed compares vs file bytes, emits CHANGED on inequality, updates state.

Sequencing rationale. Each iter is independently shippable + verifiable:

• Iter2 changes wire shape only on Get/INTERIM (read path); Set still rejects → iter2 adds zero new failure modes.
• Iter3 adds Set + write path → can be smoke-tested by issuing a Set from a peer CT and observing the music app's Repeat/Shuffle UI flip.
• Iter4 closes the CHANGED notification gap → can be smoke-tested by changing Repeat/Shuffle from the Y1 UI and watching for an AVRCP CHANGED frame on the wire.

Each iter is one commit, one OUTPUT_MD5 bump, one Y1MediaBridge versionCode bump.

Trace #19 (2026-05-10) — F4 iter4 shipped: T9 papp edge block + Patch B4 listener; deviations from #18's staged plan

iter4 ships, but the as-built wiring deviates from the Trace #18 plan in three load-bearing places. Captured here so the next iteration can read the as-shipped reality first.

JNI symbol enumeration (the unknown #18 flagged). BluetoothAvrcpService_notificationApplicationSettingChangedNative exists at file 0x47b4 (radare2 is~Native against stock libextavrcp_jni.so). 248 B function, signature (JNIEnv*, jobject*, signed char ack_type, signed char num_attrs, signed char count, _jbyteArray* attrs, _jbyteArray* values). Tail-calls btmtk_avrcp_send_reg_notievent_player_appsettings_changed_rsp at file 0x4878 (PLT 0x345c) — same import T8 INTERIM and T9 papp CHANGED both call directly. So the dispatch path exists but is fed only from BluetoothAvrcpService.run()'s native-event listener loop, NOT from BTAvrcpMusicAdapter.handleKeyMessage (which is what T9 / sswitch_18a piggybacks would have needed for a direct hook).

MtkBt smali finding (invalidates #18's "MtkBt cardinality NOP for event 0x08" plan). BTAvrcpMusicAdapter.handleKeyMessage's inner sparse-switch (sswitch_data_21c, smali line 1787) only contains arms for 0x1 / 0x2 / 0x9 (PlayStatus / Track / NowPlaying). There is no arm for 0x8. The only invocation of notificationApplicationSettingChangedNative in the entire MtkBt smali tree is in BluetoothAvrcpService.smali::run()'s pswitch_7f, fed by the native-event listener — wrong direction for proactive Y1→CT CHANGED. So iter4 cannot add a "matching cardinality NOP for event 0x08" — there's nothing to NOP.

As-built design (replaces the cardinality NOP + new native jump-patch from #18). Piggyback on T9 entirely:

1. T9's existing entry hook at notificationPlayStatusChangedNative (file 0x3c88) and the existing MtkBt sswitch_18a cardinality NOP (msg=0x1, file 0x3c4fe in MtkBt.odex) already wake the trampoline on every Y1MediaBridge playstatechanged broadcast. No new MtkBt edits.
2. Extend T9 with a fourth edge-detection block (papp): read y1-track-info[795..796] (repeat_avrcp / shuffle_avrcp), compare against y1-trampoline-state[11..12], emit reg_notievent_player_appsettings_changed_rsp(conn, 0, REASON_CHANGED, 2, &papp_attr_ids, &file[795]) on inequality. Frame grew 824→832 B (+8 B for the outgoing-args region the existing 0x08 INTERIM call shape needs at sp[0]/sp[4]; the values pointer is the file_buf address sp+T9_OFF_FILE_REPEAT — file_buf already holds [r,s] contiguously, no scratch copy needed).
3. T8 0x08 INTERIM also reads file[795..796] now (replacing the static papp_current_values ADR with addw r0, sp, T8_OFF_FILE_REPEAT). T_papp 0x13 GetCurrent retains the static fallback because Bolt postflash showed zero PDU 0x13 calls in practice; CTs subscribe to event 0x08 and never poll GetCurrent.

Y1-side broadcaster (replaces #18's #B1/B2 setMusicIsShuffle/setMusicRepeatMode injections). Patch B4 adds a single new class com.koensayr.PappStateBroadcaster implementing OnSharedPreferenceChangeListener. Registered against the "settings" SharedPreferences in Y1Application.onCreate (alongside the B3 PappSetReceiver registration). The listener fires on any write to any key but filters to musicRepeatMode / musicIsShuffle. On match, reads both live values via SharedPreferencesUtils.INSTANCE.getMusicRepeatMode() / getMusicIsShuffle(), maps to AVRCP enum bytes (Y1 0/1/2 → AVRCP 0x01/0x02/0x03 for Repeat; Y1 false/true → AVRCP 0x01/0x02 for Shuffle — the §5.2.4 mapping verified by Trace #18's gdb-capture), and broadcasts com.y1.mediabridge.PAPP_STATE_DID_CHANGE to package com.y1.mediabridge with extras repeat_avrcp:I + shuffle_avrcp:I.

Why a listener over per-setter sendBroadcast injections (#18's plan): the listener fires uniformly for AVRCP-driven Sets (which come in via Patch B3 calling SharedPreferencesUtils.setMusicRepeatMode / setMusicIsShuffle, which write the prefs and trip the listener) and Y1-UI toggles (in-app Settings screen calls the same setters). Single source of truth; no per-setter smali edit; no .locals bumping in SharedPreferencesUtils.smali. The listener is rooted via a static sInstance field inside PappStateBroadcaster so the GC doesn't reclaim it (Android holds OnSharedPreferenceChangeListener instances by weak reference).

Y1MediaBridge as-built. New mPappStateReceiver consumes ACTION_PAPP_STATE_DID_CHANGE, updates mCurrentRepeatAvrcp / mCurrentShuffleAvrcp (volatile bytes, default 0x01 OFF), calls writeTrackInfoFile (now writes buf[795] = repeat_avrcp; buf[796] = shuffle_avrcp;), and fires com.android.music.playstatechanged so MtkBt invokes notificationPlayStatusChangedNative → T9 picks up the edge. The intent extras are clamped to AVRCP §5.2.4 spec ranges (Repeat 0x01..0x04, Shuffle 0x01..0x03); out-of-range folds to OFF.

No separate y1-papp-state file. #18 proposed a 2-byte y1-papp-state file written by Y1MediaBridge and read by T_papp 0x13 + T8 0x08 INTERIM. As-shipped uses the existing y1-track-info schema's reserved bytes 795..799 instead — saves a write syscall (track-info is already written on every broadcast) and a read syscall (file_buf is already loaded by T8/T9 above the papp blocks). The y1-track-info schema comment at MediaBridgeService.java:1502 already had 795..799 pad (PlayerApplicationSettings shuffle_flag / repeat_mode reservation) — iter4 just makes that reservation real.

Initial-state sync. Y1Application.onCreate calls PappStateBroadcaster.sendNow() once on registration so a fresh music-app start (e.g. after reboot) syncs Y1MediaBridge to actual SharedPreferences state. There's no music-app-side query handler, so if Y1MediaBridge boots after the music app, the music-app initial broadcast was missed and Y1MediaBridge defaults to OFF/OFF until the first user toggle. In practice both processes are spawned at boot; the gap is short.

Open verification work (rolled into the active queue in docs/BT-COMPLIANCE.md §1):

• Hardware verify on Bolt: Y1-UI Repeat/Shuffle toggle → CT subscriber sees CHANGED frame following the edge.
• T_papp 0x13 GetCurrent live binding deferred (zero observed calls; not on critical path).

Open questions

1. A2DP SupportedFeatures (attribute 0x0311) value — what feature bits does the served A2DP record advertise today, and what do A2DP 1.2 / 1.3 add? Confirms whether bumping A2DP 1.0 → 1.3 needs a paired feature-mask edit.
2. A2DP / AVDTP version-byte authority — confirm via experimental flash + sdptool re-capture: bump 0xeb9f2 (A2DP) from 0x00 to 0x03, capture, see if the wire moves. If yes, static byte drives advertisement (same shape as V1 / V2). If no, mtkbt has runtime version logic too and we need to find it.
3. AVCTP-multiplicity — V2 patches one of three AVCTP version sites. The other two (0xeba25 / 0xeba37) are unpatched at 0x0100 and may sit on dead code paths; verifying static-vs-runtime authority via experimental patch is the cheapest answer.
4. GAVDP — no separate SDP record advertised (UUID 0x1203 hits in the SDP region are part of the HFP / HSP records, not GAVDP). Per GAVDP 1.3 §6 versioning piggybacks AVDTP; no independent byte-patch needed.

Verification path for any triad version-byte bump: experimental flash + tools/dual-capture.sh + sdptool browse + a peer CT that exercises GET_CAPABILITIES (AVDTP sig 0x02) — the captured exchange tells us what we advertise and what the peer does with it.

§9.2 A2dpSuspended Java approach reverted, HAL byte-patch landed (2026-05-09)

Context: §9.2 of BT-COMPLIANCE.md shipped in v2.7-v2.8 driving audioManager.setParameters("A2dpSuspended=true|false") from Y1MediaBridge/MediaBridgeService.java::onStateDetected on every play-state edge. Theory: setting A2dpSuspended=true would make libaudio.a2dp.default.so::standby_l skip its a2dp_stop call, leaving the AVDTP source stream alive across pauses (per AVDTP 1.3 §8.13 / §8.15).

Empirical falsification in capture /work/logs/dual-tv-20260509-1538 (TV pause/play exercise, post-flash with §9.2 + Patch H″):

15:38:40.527 D Y1MediaBridge: State change: avrcpStatus=2 (PAUSED)
15:38:40.529 D A2dpAudioInterface: +setSuspended 1
15:38:40.546 I [A2DP] a2dp_stop. is_streaming:1            ← stream torn down INSIDE setSuspended(1)
15:38:40.546 D A2dpAudioInterface: -setSuspended 1

Every PAUSED edge produces this pattern: +setSuspended 1 is followed within 17-31ms by [A2DP] a2dp_stop. is_streaming:1, on the same thread, before -setSuspended 1 returns. The AOSP A2DP HAL implements setSuspended(true) as a synchronous tear-down. Stock semantics: A2dpSuspended is the system's way of telling A2DP "drop the stream so I can route audio elsewhere (e.g., for a phone call)" — not the protective skip we assumed.

Net effect comparison (TV pause/play exercises):

§9.2 reduced silence-induced standby events (8→3) but introduced an equal number of pause-edge-triggered teardowns (1 per PAUSED edge). Burst-on-resume + playhead-drift symptom unchanged.

Pivot: drop the Java setParameters call entirely. Add patch_libaudio_a2dp.py (AH1) which flips a single ARM cond byte (0x0a → 0xea at file offset 0x000086ab) inside A2dpAudioStreamOut::standby_l. Original conditional beq 8684 becomes unconditional b 8684, making the call to a2dp_stop@plt at vaddr 0x86b0 unreachable. Standby still completes; AVDTP stream stays alive. No Java-side coupling.

Patch H″ verification (same capture): ✓ working — 0 kernel REPEAT events on event4 (U1 holds), 0 repeatCount=N>0 lines in dumpsys-input.txt (framework synthetic-repeat filter stays inactive because there are no synthetic repeats), clean DOWN/UP pairs in getevent. The framework-synthetic-FF cascade is closed.

Trace #20 (2026-05-11) — Y1MediaBridge retirement Phase 1: parallel in-app y1-track-info writer (B5/iter1)

Phase 1 of docs/PLAN-Y1MEDIABRIDGE-RETIREMENT.md lands. Music app gains its own y1-track-info writer at /data/data/com.innioasis.y1/files/; trampolines still read Y1MediaBridge's file at /data/data/com.y1.mediabridge/files/. Two writers run in parallel so the diff between them on every state edge is the verification gate for Phase 2's trampoline-path-string flip.

Failure mode driving the pivot. Y1MediaBridge's LogcatMonitor scrapes BasePlayerActivity UI render lines (刷新一次专辑图) and BaseActivity LiveData observer lines (播放状态切换 N) to learn about state changes. Empirically (2026-05-10 1119/1409/1901/1910 captures referenced in the plan doc): the scrape only fires when the music app's UI activity is in the foreground. KEYCODE_HOME → audio keeps playing → bridge sees nothing for the duration of the backgrounded session → metadata + play-state on the wire freeze.

Plan-vs-reality deltas surfaced by Phase 0 recon (docs/RECON-MUSIC-APP-HOOKS.md, commit bee0416). Plan §4.2 assumed MediaPlayer.OnCompletion/Prepared/Error registration and MediaMetadataRetriever for tag extraction. Actual:

• Primary engine is tv.danmaku.ijk.media.player.IjkMediaPlayer (Bilibili IJK FFmpeg fork); secondary is android.media.MediaPlayer (player2). Listener interfaces differ — IJK uses IMediaPlayer$OnCompletionListener etc.; both engines have 3-listener registration sites in initPlayer() (line 875) and initPlayer2() (line 1091). The R8-generated $$ExternalSyntheticLambda{0..5} thunks call into initPlayer$lambda-{10,11,12} (IJK Completion/Prepared/Error in source order — confirmed by chasing the $r8$lambda$* accessors) and initPlayer2$lambda-{13,14,15} (MediaPlayer same). Six lambda bodies, six prepend hooks.
• Static.setPlayValue(II)V at Static.smali:334 is THE canonical play-state-edge entry. The BaseActivity.setObserve$lambda-7 log line (line 819) we currently scrape is the LiveData observer's reaction — fires after setPlayValue updates the LiveData. Hooking the observer means waiting for activity resume. Hooking setPlayValue catches every edge regardless of foreground state. setPlayValue's newValue space empirically includes 0/1/3/5 (mapped per Y1MediaBridge.LogcatMonitor's existing dictionary to STOPPED/PLAYING/PAUSED/STOPPED) plus internal Y1 transitions 2/4/6/7/8/9 which we ignore.
• Music app does no MediaMetadataRetriever — metadata lives in the Room Song entity (already populated at scan time). TrackInfoWriter reads PlayerService.getPlayingMusic() / getPlayingSong() Song getters directly, no re-extraction. No duration field on the entity though — duration comes from PlayerService.getDuration() (live from the engine).
• Single-process app — no android:process anywhere. AvrcpBridgeService (Phase 3) will be co-resident with Y1Application and PlayerService automatically. Plan §5 risk row #1 closed empirically.
• Music app does NOT emit com.android.music.metachanged / playstatechanged natively — Y1MediaBridge is the sole sender today. Phase 1 keeps Y1MediaBridge installed so those broadcasts still wake T9 via the existing MtkBt.odex cardinality NOPs; Phase 3's AvrcpBridgeService will replicate the broadcast emission inside the music app.

Architecture as-built (Phase 1). Four new classes under com.koensayr.y1.* (smali sources at src/patches/inject/com/koensayr/y1/, copied into smali_classes2/ at patcher time):

• trackinfo.TrackInfoWriter — singleton state holder + atomic file writer. Mirrors the byte schema and field semantics of MediaBridgeService.writeTrackInfoFile (1104 bytes, atomic tmp+rename, setReadable(true, false) for the bluetooth uid). audio_id at bytes 0..7 from syntheticAudioId(path) = (path.hashCode() & 0xFFFFFFFFL) | 0x100000000L — same hash Y1MediaBridge falls back to when MediaStore _ID lookup fails, so the byte should match the bridge's value when both are running against the same Song entity. State fields: mPlayStatus (B), mPositionAtStateChange (J), mStateChangeTime (J — SystemClock.elapsedRealtime() for lockstep with T6's clock_gettime(CLOCK_BOOTTIME)), mPreviousTrackNaturalEnd (Z), mPendingNaturalEnd (Z — latched between onCompletion and the next onTrackEdge), mBatteryStatus (B), mRepeatAvrcp (B, default 0x01 OFF), mShuffleAvrcp (B, default 0x01 OFF). All public mutators are declared-synchronized on INSTANCE with manual monitor-enter/monitor-exit (Dalvik doesn't auto-wrap on the access flag).
• playback.PlaybackStateBridge — stateless static dispatcher. onPlayValue(II)V maps newValue → AVRCP byte. onPrepared/onCompletion/onError fire from the listener lambdas; onCompletion latches natural-end (player engine guarantees OnCompletion fires only at EOS — no extrapolated-vs-duration heuristic needed); onPrepared consumes the latch into mPreviousTrackNaturalEnd, resets position+time, flushes; onError clears the latch.
• battery.BatteryReceiver — Intent.ACTION_BATTERY_CHANGED consumer, sticky-broadcast value processed inline at registration so cold boot has a real bucket. Same FULL_CHARGE > EXTERNAL > CRITICAL > WARNING > NORMAL bucket ordering as Y1MediaBridge.handleBatteryIntent.
• papp.PappSetFileObserver — FileObserver(/data/data/com.innioasis.y1/files/y1-papp-set, CLOSE_WRITE). Reads 2 bytes (attr_id, value), maps to Y1 enum, calls SharedPreferencesUtils.setMusicRepeatMode/setMusicIsShuffle directly. Inert in Phase 1 because trampolines still write the bridge's path; goes live in Phase 2 when the trampoline path strings flip. Pre-deployed so Phase 2 doesn't need a fresh smali edit, only an _trampolines.py constant change.

Hook injection sites (Patch B5.1..B5.4 in patch_y1_apk.py):

Smali smoke-test gotcha #1. First apktool reassembly failed with 4294967296 cannot fit into an int on const-wide/32 v0, 0x100000000L. const-wide/32 literal is 32-bit sign-extended; 2^32 needs full const-wide (64-bit). Fixed both occurrences in syntheticAudioId. Also confirmed declared-synchronized is purely an access-flag annotation in Dalvik — explicit monitor-enter/monitor-exit are required regardless.

Runtime gotcha #3 — PlayerService.getDuration() during prepareAsync nukes the new MediaPlayer (B5/iter1.3). Second on-device boot of B5 (post-iter1.2 hardening, commit 2101495) booted clean but playback stuck at 0:00 on every track requiring the android.media.MediaPlayer engine (isUseIjk(path) == false). Captured in /work/logs/logcat-20260510-2132.log. Trace:

436:D/MediaPlayerService: [3] prepareAsync                            # native MP starts async prep
437:D/DebugY1 restore: restart 使用mediaPlayer完毕                    # music app's restart returns
438:E/MediaPlayer: Attempt to call getDuration without a valid mediaplayer
439:E/MediaPlayer: error (-38, 0)                                     # async OnError
440:I/DebugY1 BaseActivity: 播放状态切换   1                          # Static.setPlayValue(1, 8)
...
484:D/DebugY1 PlayerService: MediaPlayer Crash @414547b8 -38 0        # lambda-15 fires
485:D/DebugY1 PlayerService: player onError 2
486:D/MediaPlayerService: [3] reset                                   # MP back to Idle, stuck

Root cause: the music app's restart sequence calls Static.setPlayValue(1, 8) to mark PLAYING after prepareAsync is dispatched but before OnPrepared arrives. My Static.setPlayValue hook fires synchronously → PlaybackStateBridge.onPlayValue → TrackInfoWriter.setPlayStatus → flushLocked → PlayerService.getDuration(). PlayerService.getDuration() (smali line 2922 :cond_1) delegates to player2.getDuration() for non-IJK paths. The C++ MediaPlayer::getDuration runs on the brand-new MediaPlayer instance #3 (still in Preparing state), logs Attempt to call getDuration without a valid mediaplayer, returns INVALID_OPERATION. The native MediaPlayer then transitions into Error state and posts an async OnError(-38) — which triggers stock's lambda-15 reset(), leaving the player Idle forever. playerIsPrepared never becomes true, BasePlayerActivity polls prepare: false indefinitely.

The stock app never queries getDuration between prepareAsync and OnPrepared. My flush did, on every play-state edge.

Fix: gate every PlayerService.getDuration() call inside TrackInfoWriter on PlayerService.getPlayerIsPrepared() (a pure iget-boolean, safe in any state). When not prepared, write 0 for duration — same "unknown" sentinel Y1MediaBridge uses. Two call sites in flushLocked (the per-attribute write at offset 776 + the PlayingTime ASCII string at 832) and one in computeLivePositionLocked (the duration-cap on extrapolated position). All three guarded.

Lesson for Phase 3: when AvrcpBridgeService Binder methods read playback state for inbound CT requests, treat any accessor that touches the underlying native player (getDuration, getCurrentPosition, seekTo, setVolume) as unsafe outside the prepared window. Use the same getPlayerIsPrepared gate.

Runtime gotcha #2 — MultiDex cache + system-app reflash interaction (B5/iter1.1). First on-device run threw java.lang.NoClassDefFoundError: com.koensayr.y1.trackinfo.TrackInfoWriter at Y1Application.onCreate(Y1Application.kt:137), with the dalvik verifier logging VFY: unable to resolve static field 47282 (INSTANCE) in Lcom/koensayr/y1/trackinfo/TrackInfoWriter; at class-load time and the runtime resolution failing even after MultiDex reported install done. Captured in /work/logs/logcat.log (pid 649 → first crash; pid 850 → second attempt with full trace including the MultiDex install logs). Root cause: classes2.dex extraction is cached under /data/data/com.innioasis.y1/code_cache/secondary-dexes/, which survives /system/app/com.innioasis.y1/com.innioasis.y1.apk reflashes; MultiDex 1.0.x on Dalvik 1.6 reuses the cached pre-patch classes2.dex (loading existing secondary dex files / load found 1 secondary dex files) and the new Lcom/koensayr/y1/* classes are nowhere to be found at runtime. Fix: route the four B5 classes into smali/ (primary DEX) instead of smali_classes2/ so they load with Y1Application itself — same DEX placement as B3/B4. apktool 2.9.3 / smali 3.0.3 reassembly succeeded; both classes.dex (9.2 MB, ~+25 methods) and classes2.dex (8.97 MB, unchanged) under the 64K-method cap. All four classes verified in classes.dex via unzip -p classes.dex | strings | grep koensayr/y1.

Phase 1 → Phase 2 verification gate. Both files exist on device and update in lockstep (adb shell md5sum /data/data/com.innioasis.y1/files/y1-track-info /data/data/com.y1.mediabridge/files/y1-track-info). The plan idealised this as "byte-exact within ±100 ms"; in practice mStateChangeTime (low 32 bits of SystemClock.elapsedRealtime() at the edge) will differ by the few-ms gap between when each writer fires, and audio_id may differ if Y1MediaBridge's MediaStore _ID lookup succeeds (music app side always uses the synthetic hash). The realistic gate is "all CT-visible fields (Title/Artist/Album/Genre/Duration/PlayStatus/NaturalEnd/Battery/Repeat/Shuffle/TrackNumber/TotalTracks/PlayingTime) match byte-for-byte; clock + audio_id allowed to differ within their natural skew." Plus the foreground/background test: adb shell input keyevent KEYCODE_HOME → trigger track change via Bluetooth PASSTHROUGH → music-app file updates (existing LogcatMonitor scrape would not).

Open work (handed to Phase 2). _trampolines.py flips three asciiz literals from /data/data/com.y1.mediabridge/files/ to /data/data/com.innioasis.y1/files/; re-pin libextavrcp_jni.so OUTPUT_MD5. After the flip, PappSetFileObserver becomes the live consumer of T_papp 0x14 writes (replacing Y1MediaBridge's FileObserver). Y1MediaBridge keeps writing to its own path but to a file the trampolines no longer read — dead but installed. Phase 3 then adds AvrcpBridgeService to the music app manifest and uninstalls Y1MediaBridge.

Trace #21 (2026-05-11) — Y1MediaBridge retirement Phase 2: trampoline file-path cutover

Phase 1 (Trace #20) shipped the music app's TrackInfoWriter as a parallel writer at /data/data/com.innioasis.y1/files/y1-track-info, with on-device md5sum comparison against Y1MediaBridge's path confirming all CT-visible fields match byte-for-byte except state_change_time_ms, position_ms, and (when MediaStore _ID lookup succeeds bridge-side) audio_id. Verified 2026-05-11 on Killswitch Engage "My Last Serenade (live)":

audio_id       OK   music=00000001a957a7e8  bridge=00000001a957a7e8
title          OK   music=4d79204c61737420536572656e616465...  bridge=…
artist         OK   music=4b696c6c73776974636820456e676167  bridge=…
album          OK   music=54686520456e64206f66204865617274…  bridge=…
duration       MISMATCH  music=0000c288 (49800 ms)  bridge=0000c25e (49758 ms)
play_status    OK   music=01  bridge=01
battery        OK   music=00  bridge=00
repeat         OK   music=04  bridge=04
shuffle        OK   music=01  bridge=01

The 42 ms duration delta is expected: Y1MediaBridge re-runs MediaMetadataRetriever (Xing/LAME header parse) while TrackInfoWriter.flushLocked calls MediaPlayer.getDuration() (codec-reported). For VBR MP3 those routinely disagree by tens of ms; the trampolines round to seconds for AVRCP PLAYING_TIME anyway. audio_id matched because both writers fell through to the path-hash fallback ((hash & 0xFFFFFFFFL) | 0x100000000L) — the Phase 2 blocker I flagged in Trace #20 ("MediaStore-id mismatch would force a CT track-change on every state edge") is not a problem in practice.

Path-string flip. Three asciiz literals in _trampolines.py (lines 2267 / 2270 / 2273) repointed from /data/data/com.y1.mediabridge/files/* to /data/data/com.innioasis.y1/files/*. Each path string shrinks by 2 bytes (com.y1.mediabridge = 18 chars → com.innioasis.y1 = 16 chars); all PC-relative references to the path labels resolve through Asm.label so the assembler re-computes offsets automatically. Trampoline blob grows by net 700 bytes vs. the figures in docs/PATCHES.md that were stale (pre-T_papp); current size = 2736 bytes (was nominally tracked as 2036 / 1652 in older docs), free padding after LOAD #1 = 1284 bytes.

OUTPUT_MD5 transition. Set OUTPUT_MD5 = None temporarily, re-ran patch_libextavrcp_jni.py /work/v3.0.2/system.img.extracted/lib/libextavrcp_jni.so. Pre-patch verification confirmed 9/9 sites OK against STOCK_MD5 = fd2ce74db9389980b55bccf3d8f15660. Post-patch verification 9/9 sites OK. New OUTPUT_MD5 = f021e71d12c170f2e135281d37ba8477 (was 5b7f5ae685c4c9299f36b1b3f88d564c in the v1+B5 build). Output size unchanged at 50,992 bytes — confirms the 6-byte path-string shrink fits within existing alignment slack and no LOAD #1 program-header bump is needed.

Cold-boot gap (known limitation). Y1MediaBridge auto-starts at boot via its BOOT_COMPLETED receiver; the music app's Y1Application.onCreate runs only when the music process is launched. Between reboot and first music-app launch, MtkBt's trampolines open() the music-app files and get ENOENT (no O_CREAT on read paths). Trampolines fail-soft on ENOENT (return INTERIM with sentinel/zero values). In practice the user launches music before connecting a CT, so this only affects the contrived "boot → connect CT immediately" path. Phase 3's AvrcpBridgeService (exported, bound by MtkBt) will cold-start the music process implicitly via bindService. Mitigation alternative if Phase 3 slips: add a BOOT_COMPLETED receiver to the music app that calls TrackInfoWriter.prepareFiles() to materialise the files.

Patches B3 status post-cutover. B3 (com.koensayr.PappSetReceiver) is now inert: Y1MediaBridge's FileObserver on its own y1-papp-set no longer fires (the trampolines write to the music-app path), so the bridge no longer re-broadcasts SET_REPEAT_MODE / SET_IS_SHUFFLE intents that B3 listens for. B5's PappSetFileObserver is the live consumer. B3 is kept installed as a transitional safety net; Phase 3 / 4 will remove it.

B4 wake-up loop after Phase 2. PappStateBroadcaster.sendNow calls TrackInfoWriter.setPapp(repeat, shuffle) directly (writing the music-app's y1-track-info[795..796]) and continues to fire the com.y1.mediabridge.PAPP_STATE_DID_CHANGE broadcast. Y1MediaBridge still consumes that broadcast and fires com.android.music.playstatechanged, which is what wakes T9 to emit AVRCP §5.4.2 Tbl 5.36 PLAYER_APPLICATION_SETTING_CHANGED CHANGED on the wire. The bridge's own y1-track-info write (also at byte 795..796) is a dead path. After Y1MediaBridge is retired, the music app will need to fire playstatechanged itself in setPapp — currently it relies on the bridge as a broadcast relay.

Active docs updated for Phase 2 reality. ARCHITECTURE.md "Music app state-writer lifecycle" section now describes the in-process writer chain (TrackInfoWriter + PlaybackStateBridge + BatteryReceiver + PappSetFileObserver + PappStateBroadcaster) replacing the old "Y1MediaBridge lifecycle" walk; cross-component state dependencies table re-anchored to the music app's filesDir; BT-COMPLIANCE.md ICS rows + risk table refreshed; PATCHES.md B3/B4/B5 narratives reflect Phase 2 owner; _trampolines.py and patch_libextavrcp_jni.py source comments stripped of stale "Y1MediaBridge writes" framing.

Phase 2 → Phase 3 verification gate (per docs/PLAN-Y1MEDIABRIDGE-RETIREMENT.md §6): AVRCP CT cold-connect → metadata visible within one polling cycle; T_papp 0x14 Set still round-trips into music-app SharedPreferences via PappSetFileObserver; play/pause edges still drive CHANGED notifications. Verified on hardware 2026-05-11 via a Sonos dual-capture (/work/logs/dual-sonos-20260511-0733/): 7,272 msg=544 frames (RegisterNotification responses), 227 msg=540 (GetElementAttributes responses with size=644, carrying Title/Artist/Album bytes), 18 msg=520 (PASSTHROUGH ACKs). No FATAL / NoClassDefFoundError. Sonos display tracked correctly per the user's confirmation. Gate passed; Phase 3 unblocked.

Trace #22 (2026-05-11) — Y1MediaBridge retirement Phase 3: AvrcpBridgeService Binder lands in the music app

Phase 3 retires Y1MediaBridge.apk by hosting its IBTAvrcpMusic + IMediaPlaybackService Binder inside the music app itself. Two new smali classes (com.koensayr.y1.avrcp.AvrcpBridgeService + AvrcpBinder) implement a minimum-viable Binder; apply.bash no longer installs Y1MediaBridge.apk and now removes any pre-existing copy from /system/app/.

Recon (already done in Phase 0; reused). docs/RECON-MUSIC-APP-HOOKS.md §7 has the full transaction-code table for both interfaces (38 codes on IBTAvrcpMusic, 32 on IMediaPlaybackService, 8 on IBTAvrcpMusicCallback). Y1MediaBridge's MediaBridgeService.java::onTransact ships a working reference implementation for every code; Phase 3 mirrors its dispatch shape but in smali.

Minimum-viable scope. ARCHITECTURE.md's existing note on the Binder role — "in the post-patch architecture this Java path is largely unused; the C-side trampolines deliver the real metadata + control on the AVRCP wire" — set the bar low. The Sonos log from Trace #21 confirmed it: Y1MediaBridge: notifyAvrcpCallbacks code=1 — no callbacks registered appeared 20× alongside 7,272 T9 wakeups via the broadcast path. MtkBt never actually transacted on the Java callback path; the broadcast wake path drove everything. So AvrcpBinder.onTransact implements: code 1 (registerCallback) — stash IBinder; code 2 (unregisterCallback); code 3 (regNotificationEvent) — ACK true (critical: returning false leaves MtkBt's mRegBit empty and notifyTrackChanged gets dropped pre-emit); code 5 (getCapabilities) — return [0x01, 0x02]; codes 6-13 — broadcast media keys to PlayControllerReceiver via DOWN+UP ACTION_MEDIA_BUTTON. Every other code: writeNoException + return true. Total smali: ~330 lines for AvrcpBinder + ~280 lines for AvrcpBridgeService (Service shell + callback list + media-key sender).

Descriptor skip. Same defensive pattern Y1MediaBridge used: skip strictModePolicy (int32) + descriptor (string) and dispatch purely by transact code. enforceInterface has historically aborted on ROM-variant descriptor mismatches, leaving cardinality at 0. Code path tested cleanly: apktool b's smali compile succeeds (Smaling smali_classes2 folder into classes2.dex); androguard's AXMLPrinter re-parses the manifest splice; method count delta is +38 in classes2.dex (52,935 → 52,973, well under the 64K cap; 12,563 slots free).

Method-count routing. classes.dex sits at 65,330/65,536 (99.7%, ~176 slots free) after Patch B5. AvrcpBridgeService + AvrcpBinder route to smali_classes2/com/koensayr/y1/avrcp/ — secondary DEX, where there's 12K+ method headroom. Trade-off: MultiDex 1.0.x on Dalvik 1.6 caches the extracted classes2.dex under /data/data/com.innioasis.y1/code_cache/secondary-dexes/, and that cache survives every apply.bash invocation (mtk.py w android writes the system partition only — no apply.bash flag touches userdata). Mitigation: apply.bash emits an unconditional instruction at the end of --avrcp telling the user to adb shell rm -rf /data/data/com.innioasis.y1/code_cache/secondary-dexes/ before reboot. Earlier docs (Trace #20 + the dex-budget memory) said --all would reprovision userdata as a side effect; that was wrong — corrected here. Every --avrcp install needs the manual cache-clear step until/unless we wire a music-app-side cache invalidator (an Application.onCreate shim that calls getCodeCacheDir().delete() if a sentinel class is missing).

AndroidManifest patch (the real engineering decision). apktool d --no-res leaves the manifest as binary AXML; we have no aapt2 binary on the host (/tmp/bak/prebuilt/linux/aapt2 is 32-bit x86, host is 64-bit; Rocky 10 has no aapt2 package; apktool's bundled aapt2 fails with cannot execute binary file). Three paths considered:

1. Python AXML splicer — wrote src/patches/_axml.py (~250 lines). Reads the binary AXML chunk-by-chunk, exposes start_element / end_element / attr_string / attr_bool / attr_int builders, and a write that re-emits the file with a freshly-serialized string pool. Round-trip on the unmodified manifest is byte-identical (md5 match). Strings get APPENDED to the pool past the resource-mapped prefix (first 31 slots are android.R.attr.* via ResourceMap; new strings at index 172+ have no ResourceMap entry, no conflict).
2. Install Android SDK + aapt2 — adds a permanent ~1.5 GB toolchain dep. Wrong direction since Phase 4 was meant to drop the gradle dep anyway.
3. Tiny shim APK — defeats the "retire to a single APK" intent of the plan.

Went with option 1. Manifest splice inserts (just before </application>):

<service android:name="com.koensayr.y1.avrcp.AvrcpBridgeService" android:exported="true">
  <intent-filter android:priority="100">
    <action android:name="com.android.music.MediaPlaybackService"/>
    <action android:name="com.android.music.IMediaPlaybackService"/>
  </intent-filter>
</service>

Verified the splice via androguard's AXMLPrinter.get_xml() — independent reader re-emits the exact XML we intended. New manifest is 23,516 bytes (was 22,916; +600 ≈ new chunks (340) + 3 new strings × ~85 bytes each + alignment).

Output-APK assembly bug surfaced. The patcher's final zip-rebuild loop swaps only classes.dex / classes2.dex from staging; manifest comes from the stock APK regardless. Phase 1 + 2 never patched the manifest so the bug was invisible. Fixed in the same commit: also swap AndroidManifest.xml from staging.

Wake-up trigger migration. Y1MediaBridge previously fired com.android.music.playstatechanged on:

• play/pause edge (stock music app fires it too, so duplicative — OK)
• battery bucket transition (Y1MediaBridge-only — now music-app responsibility)
• papp change via PAPP_STATE_DID_CHANGE intent bridge (Y1MediaBridge-only — now music-app responsibility)
• 1 s position tick while playing (stock music-app fires it, no change needed)

After Y1MediaBridge is removed, the music app must emit playstatechanged for battery + papp. Phase 3 changes:

• BatteryReceiver.onReceive (smali): after TrackInfoWriter.setBattery, fire Context.sendBroadcast(Intent("com.android.music.playstatechanged")) wrapped in try/catch(Throwable).
• PappStateBroadcaster.sendNow (Patch B5.4 in patch_y1_apk.py): same pattern after TrackInfoWriter.setPapp. The existing com.y1.mediabridge.PAPP_STATE_DID_CHANGE broadcast is retained as a no-op for the transition window — goes to no listener once Y1MediaBridge is uninstalled.

apply.bash changes.

• Dropped the assembleDebug prerequisite and the Y1MediaBridge.apk install step.
• Added defensive removal of /system/app/Y1MediaBridge.apk / Y1MediaBridge.odex / Y1MediaBridge/ at mount time (covers users upgrading from a previous --avrcp build).
• Added a post-flash usage note pointing at the code_cache invalidation adb shell command and the pm uninstall com.y1.mediabridge defensive cleanup (covers any prior non-system-app installs).

Patcher smoke test passed. Full --clean-staging run:

• All B1..B5 patches apply as before.
• B6.1 copies AvrcpBridgeService.smali + AvrcpBinder.smali into smali_classes2/com/koensayr/y1/avrcp/.
• B6.2 splices the manifest via _axml.py.
• apktool b smaling phase: clean, no errors.
• DEX method counts: classes.dex 65,330 (unchanged), classes2.dex 52,973 (+38 vs Phase 2 baseline).
• Output APK contains the spliced manifest (verified via androguard) and both new smali classes.

Phase 3 → 4 verification gate (per plan §6): pm list packages | grep mediabridge empty post-flash; ls /system/app/Y1MediaBridge* returns "No such file or directory"; MtkBt's adapter logs MMI_AVRCP: PlayService onServiceConnected className:com.koensayr.y1.avrcp.AvrcpBridgeService (not the old com.y1.mediabridge); all three CT scenarios (Bolt/Kia/TV — Sonos deprecated) repeat the Phase 2→3 gate. To be verified on hardware after reflash.

Known unknowns to watch on first flash.

• Cold-boot Binder bind: MtkBt's bindService should cold-start the music app's process via Android's standard service-binding flow, which means Y1Application.onCreate runs (registering TrackInfoWriter etc.) before MtkBt's onServiceConnected callback fires. If this races (e.g. onServiceConnected arrives before Y1Application.onCreate completes), the AvrcpBridgeService.onCreate order may be off. The fix would be to make AvrcpBridgeService.onCreate defensively trigger TrackInfoWriter.init itself, but Android's lifecycle guarantees Application.onCreate runs before any component's onCreate, so this race shouldn't happen in practice. Monitor for it.
• PackageManager resolution priority: the intent-filter ships at android:priority="100". Y1MediaBridge's intent-filter has no priority (default 0). PMS should resolve to the music app's filter on first install. If both APKs are present (transition window), the music app wins. After Y1MediaBridge is removed, only the music app has a matching filter.
• code_cache staleness: MultiDex 1.0.x reuses any cached classes2.dex it finds at /data/data/com.innioasis.y1/code_cache/secondary-dexes/, regardless of whether the underlying APK changed (observed in Trace #20). apply.bash never touches /data, so the cache persists across reflashes — --all, --avrcp, and any other combination of flags. The mandatory post-flash adb-shell step is the cache-clear; no flag bypasses it.

Trace #23 (2026-05-11) — Phase 3 v1 stand-down: AndroidManifest.xml splice rejected by JarVerifier

Phase 3 v1 (commit 032f655) shipped an AndroidManifest.xml splice via the new src/patches/_axml.py editor, adding a <service> declaration for com.koensayr.y1.avrcp.AvrcpBridgeService with a priority-100 intent-filter for com.android.music.MediaPlaybackService. The intent: MtkBt's bindService would resolve to the music app instead of Y1MediaBridge, retiring Y1MediaBridge.apk entirely.

User flashed Phase 3 v1 via mtkclient. Boot hung at the boot animation indefinitely. New logcat capture (/work/logs/logcat-20260511-0927.log) shows PackageManager rejecting the patched music APK during /system/app/ scan:

W/PackageParser(523): java.lang.SecurityException:
    META-INF/MANIFEST.MF has invalid digest for AndroidManifest.xml
    in /system/app/com.innioasis.y1_3.0.2.apk
E/PackageParser(523): Package com.innioasis.y1 has no certificates
    at entry AndroidManifest.xml; ignoring!
W/PackageManager(523): Failed verifying certificates for package:com.innioasis.y1
D/PackageManager(523): scan package: /system/app/com.innioasis.y1_3.0.2.apk,
    elapsed time = 1831ms

PackageManager dropped com.innioasis.y1 entirely. With no music app installed, the system's launcher (which lives in com.innioasis.y1.activity.MainActivity) couldn't start, BootCompleted never fired, the boot animation looped forever.

Root cause. META-INF/MANIFEST.MF records a SHA1-Digest for each file in the APK. JarVerifier, called via JarFile.getCertificates(AndroidManifest.xml) in PackageParser.collectCertificates, reads AndroidManifest.xml and SHA1s the bytes; comparison against MANIFEST.MF's recorded digest fails on our modified manifest → throws SecurityException → getCertificates() returns null → PackageParser reports "no certificates" → package dropped.

Phase 1 + 2 worked because JarVerifier only digest-checks AndroidManifest.xml during scan. It does NOT check classes.dex / classes2.dex / resources.arsc at parse time. Empirically: we modified classes.dex (Patch B5) without issue. The moment we modified AndroidManifest.xml, JarVerifier fired.

Why we can't re-sign. Updating the SHA1-Digest in MANIFEST.MF would invalidate CERT.SF's per-section SHA1 (which signs the MANIFEST.MF section bytes). Updating CERT.SF invalidates CERT.RSA's signature over CERT.SF. Re-signing CERT.RSA requires the OEM platform private key, because com.innioasis.y1 declares android:sharedUserId="android.uid.system". Without that key the package would either be rejected entirely (unsigned check) or rejected for not matching the platform-cert prerequisite of android.uid.system.

Why Y1MediaBridge.apk works. Different package (com.y1.mediabridge), self-signed test cert, no sharedUserId constraint. /system/app/ doesn't require any specific signing key for arbitrary packages — only sharedUserId-claiming packages need a matching cert.

Phase 3 v1 stand-down. Reverted in commit <next>:

• patch_y1_apk.py: dropped Patch B6.2 (manifest splice). The B6.1 smali drop (AvrcpBridgeService.smali / AvrcpBinder.smali into smali_classes2/) is retained as groundwork for Phase 3 v2 — the classes exist but are not declared anywhere, so nothing instantiates them at runtime.
• apply.bash: restored the Y1MediaBridge.apk install step + the gradle-build prerequisite + the post-flash adb-shell note (dropped). Defensive removal of pre-existing Y1MediaBridge.apk removed.
• patch_y1_apk.py zip-rebuild: no longer swaps AndroidManifest.xml (it stays bit-exact stock).
• Active docs (ARCHITECTURE.md, PATCHES.md, README.md, CHANGELOG.md) re-anchored to "Y1MediaBridge.apk stays as Binder host; music app does file writes + state production."

Phase 3 net result. Same on-the-wire behavior as Phase 2 (verified working on Sonos in Trace #21):

• Music app's TrackInfoWriter is the canonical writer for y1-track-info / y1-trampoline-state / y1-papp-set under /data/data/com.innioasis.y1/files/.
• Trampolines in libextavrcp_jni.so read from the music app's path (Phase 2's path-string flip).
• Y1MediaBridge.apk hosts the Binder declaration MtkBt binds to — its file-write side runs but writes a path nothing reads.
• AvrcpBinder smali classes ship in classes2.dex as groundwork; not load-bearing.
• BatteryReceiver and PappStateBroadcaster fire com.android.music.playstatechanged for non-play-edge wakeups — useful regardless of who hosts the Binder, since these previously relied on Y1MediaBridge as a broadcast relay.

Phase 3 v2 design space (not implemented in this stand-down):

• Shrink Y1MediaBridge to a thin Binder forwarder. Keep its manifest-declared service, replace the bulk of MediaBridgeService.java with: onBind does bindService(new Intent().setComponent(new ComponentName("com.innioasis.y1", "com.innioasis.y1.service.PlayerService"))) and returns the bound IBinder. Music app's PlayerService.onBind is smali-extended to return AvrcpBinder when called with a specific intent marker. This achieves "Y1MediaBridge is trivial" without touching the music APK manifest. Two APKs but the bridge becomes ~50 lines.
• Brand-new tiny stub APK. Build a fresh Y1AvrcpStub.apk (own package, own self-signed cert, no platform key needed) whose only job is the intent-filter Service declaration. Replaces Y1MediaBridge.apk; ~5 KB. Build pipeline: minimal source + signapk.jar (no gradle). Same architectural outcome.
• Patch MtkBt.odex to bindService via component name. Change BTAvrcpMusicAdapter.startToBindPlayService smali to use Intent().setClassName("com.innioasis.y1", "com.innioasis.y1.service.PlayerService") instead of action-only Intent. Component-based bindService doesn't require an intent-filter, so the stock manifest's existing PlayerService declaration would resolve. Smali-extend PlayerService.onBind to return AvrcpBinder. Truly retires Y1MediaBridge with zero new APKs. Most invasive: requires inserting smali instructions into MtkBt.odex's method body (shifts code offsets), which the current patch_mtkbt_odex.py infrastructure doesn't support — would need a smali-reassembly path.

All three Phase 3 v2 paths preserve the constraint discovered in Trace #23: don't modify com.innioasis.y1's AndroidManifest.xml.

Trace #24 (2026-05-11) — Phase 3 v2: shrink Y1MediaBridge to a minimal Binder host

Phase 3 v1 (Trace #23) established that we can't retire Y1MediaBridge.apk entirely without either (a) the OEM platform key (impossible) or (b) substantial MtkBt.odex smali surgery (deferred). What we CAN do — and what the user asked for as the optimal forward path — is keep all behavioral logic in the music app's process and shrink Y1MediaBridge to nothing but a Binder declaration. The "visibility issues" that drove the original Y1MediaBridge design (logcat scraping, cross-process state observation, foreground/background gaps) are all solved by Phase 1+2's in-music-app components; Y1MediaBridge had been duplicating that work to a dead path since Phase 2 shipped.

What got deleted from src/Y1MediaBridge/app/src/main/java/com/y1/mediabridge/MediaBridgeService.java

Old file: 2152 lines. New file: 130 lines. Deletions:

• LogcatMonitor thread + processLogLine + onStateDetected + onTrackDetected + every state-tracking field (mPlayStatus, mIsPlaying, mCurrentTitle, mCurrentArtist, mCurrentAlbum, mCurrentDuration, mPositionAtStateChange, mStateChangeTime, mPreviousTrackNaturalEnd, mCurrentRepeatAvrcp, mCurrentShuffleAvrcp, …). The music app's PlaybackStateBridge observes the player engine in-process — no logcat race, no foreground/background gap.
• The 1104-byte y1-track-info schema + writeTrackInfoFile + putBE64 / putBE32 / putUtf8Padded helpers + prepareTrackInfoDir. TrackInfoWriter in the music app is the canonical writer (Phase 1+2).
• setupRemoteControlClient + mAudioManager + registerMediaButtonEventReceiver. The music app's manifest-declared PlayControllerReceiver (priority=MAX_INT for ACTION_MEDIA_BUTTON) wins ordered-broadcast dispatch directly; AudioService's RCC fallback to ordered broadcast is the active path.
• registerBatteryReceiver + handleBatteryIntent + bucket-mapping helpers. Music app's BatteryReceiver does this and fires playstatechanged itself.
• registerPappStateReceiver + handlePappStateIntent + mPappStateReceiver. Music app's PappStateBroadcaster calls TrackInfoWriter.setPapp directly and fires playstatechanged itself.
• setupPappSetObserver + the bridge's FileObserver(y1-papp-set). Music app's PappSetFileObserver watches the path the trampolines actually write to.
• mPosTickRunnable + the 1 Hz position-tick Handler.postDelayed loop. Music app's PlayerService already emits playstatechanged on its own tick.
• notifyAvrcpCallbacks + notifyPlaybackStatus + notifyTrackChanged + the mAvrcpCallbacks CopyOnWriteArrayList. Per Sonos capture in Trace #21, MtkBt never registered a callback (the binder transact 1 never landed); the broadcast wake path drove every T5 / T9 fire. Dead code.
• mPlayService + mPlayConnection + every IMediaPlaybackService.Stub.asInterface consumer. The bridge didn't need to bind to anything.
• computePosition + safeString + sendMediaKey + every other helper. All deleted.

What stays in MediaBridgeService.java (130 lines)

• Empty onCreate.
• onBind returns a private AvrcpBinder instance.
• onUnbind returns true so the framework's service record persists across MtkBt re-binds.
• AvrcpBinder (~30 LOC inner class): onTransact skips strictModePolicy + descriptor string (same defensive pattern Y1MediaBridge used to dodge ROM-variant enforceInterface failures), dispatches by code. Code 5 (getCapabilities) returns [0x01 PLAYBACK_STATUS_CHANGED, 0x02 TRACK_CHANGED]. Every other code: writeNoException + return true.

PlaySongReceiver.java simplification

• Deleted: ACTION_MEDIA_BUTTON forwarding (music app's PlayControllerReceiver handles directly via ordered broadcast); MY_PLAY_SONG handling (was wakeup for the deleted LogcatMonitor); ABOUT_SHUT_DOWN handling (was for the deleted shutdown coordination).
• Kept: BOOT_COMPLETED → startService(MediaBridgeService) so the service is alive when MtkBt's first bindService fires (bindService would cold-start it anyway, but this makes the first bind cheaper).

Old PlaySongReceiver.java: 106 lines. New: 28 lines.

AndroidManifest.xml cleanup

• Dropped permissions: READ_LOGS (logcat monitor gone), MEDIA_CONTENT_CONTROL (no more MediaController APIs), MODIFY_AUDIO_SETTINGS (no more RCC / AudioManager), BLUETOOTH (we don't talk BT directly — MtkBt does), READ_EXTERNAL_STORAGE + WRITE_MEDIA_STORAGE (no file IO outside our own data dir), WAKE_LOCK (no background work).
• Kept: RECEIVE_BOOT_COMPLETED.
• Dropped <application android:persistent="true">: with no background work happening, there's no reason to keep the process resident. MtkBt's bindService will cold-start it when needed; the framework keeps the binder bound while there's a client.
• Dropped <receiver> intent-filters: removed MY_PLAY_SONG, ABOUT_SHUT_DOWN, MEDIA_BUTTON. Only BOOT_COMPLETED left.

Old manifest: 74 lines. New: 43 lines.

app/build.gradle lint config

Removed suppressions for warnings that no longer apply: ProtectedPermissions (no MEDIA_CONTENT_CONTROL), SetWorldReadable (no setReadable(true, false)). Kept: ExpiredTargetSdkVersion, ExportedService, MissingApplicationIcon.

Net result

Y1MediaBridge/ source goes from 2332 lines to 201 lines across three files. The compiled APK should be ~5–10 KB (was ~80 KB pre-shrink). Build pipeline unchanged: cd src/Y1MediaBridge && ./gradlew assembleDebug → app/build/outputs/apk/debug/app-debug.apk → apply.bash --avrcp copies to /system/app/Y1MediaBridge.apk.

The wire-level behavior is identical to Phase 1+2 (the bridge wasn't load-bearing for AVRCP events post-Phase-2 anyway — it just had a lot of redundant code running). The user-facing improvement is that the bridge is now trivially auditable: ~30 lines of actual logic.

Visibility-issue audit (the user's framing question)

All visibility-critical logic lives in the music app's process. Y1MediaBridge is purely a "JarVerifier bypass" — a self-signed manifest carrier for the intent-filter MtkBt expects.

Stretch goals (still future work)

• Drop the gradle dep: shrink-source is small enough to build with just javac + d8 + a minimal aapt2 substitute (or commit a prebuilt APK). Not addressed here because the user's flash machine already has gradle set up.
• Truly retire Y1MediaBridge.apk: requires MtkBt.odex smali surgery to component-bind into com.innioasis.y1/.service.PlayerService directly (option (c) from Trace #23). patch_mtkbt_odex.py would need a smali-reassembly path; currently it only supports same-size byte substitutions.

Trace #25 (2026-05-11) — Phase 1+2 broadcast-wake regression: PlaybackStateBridge now fires metachanged + playstatechanged

Symptom

Multi-CT capture session 2026-05-11 afternoon (dual-bolt-20260511-1339, dual-kia-20260511-1336) surfaced three user-visible regressions vs the pre-Phase-2 Y1MediaBridge.apk-driven behavior:

• Bolt: zero metadata rendered. Only 1 × msg=540 (GetElementAttributes response) in 4 min, vs Sonos's 190 × in 3 min during Phase 3 v3 verification. Bolt's CT subscribes to EVENT_TRACK_CHANGED and waits for CHANGED notifications before issuing GetElementAttributes — without CHANGED firing on track edges, the CT never queries.
• Kia: time-playhead lags real device playhead by ~seconds; timestamps appear only after a pause. Kia polls GetPlayStatus (75 × in 3 min) so T6's clock_gettime(BOOTTIME) extrapolation returns live position correctly, but the rendering side appears to anchor on EVENT_PLAYBACK_POS_CHANGED CHANGED notifications which were only firing every 10 s (BatteryReceiver tick), not the documented 1 s cadence.
• Bolt: Repeat toggle from the CT updates SharedPreferences but the music-app UI doesn't refresh until the user backs out and returns; shuffle state appears stuck "on" on the CT regardless of Y1 state.

Root cause

The Y1 music app's PlayerService does NOT fire the standard com.android.music.metachanged / playstatechanged broadcasts at play-state or track edges. It uses its own internal android.intent.action.MY_PLAY_SONG instead. Pre-Phase-2 Y1MediaBridge.apk had a logcat-scraping LogcatMonitor + a 1 s Handler loop that synthesised these broadcasts whenever it observed state changes. The Phase 3 v2 shrink removed both.

Verified by grep: inject/com/koensayr/y1/playback/PlaybackStateBridge.smali had no sendBroadcast call before this fix. Only BatteryReceiver.smali and PappStateBroadcaster.smali were firing playstatechanged, and nothing was firing metachanged.

MtkBt.odex's cardinality-NOP-patched BTAvrcpMusicAdapter.handleKeyMessage (patch_mtkbt_odex.py sswitch_1a3/sswitch_18a) is what wakes notificationTrackChangedNative / notificationPlayStatusChangedNative (and thus T5 / T9). Without the broadcasts being emitted, the wake never fires.

Fix

Added two helper methods to TrackInfoWriter:

• wakeTrackChanged()V — fires com.android.music.metachanged via the stored Application Context.
• wakePlayStateChanged()V — fires com.android.music.playstatechanged via the same.

Modified PlaybackStateBridge:

• onPlayValue — after setPlayStatus(B) flushes the new state byte synchronously, calls wakePlayStateChanged(). Drives T9 → PLAYBACK_STATUS / PLAYBACK_POS CHANGED on real state edges (play→pause, pause→play, etc.).
• onPrepared — after onTrackEdge flushes the new track to disk, calls wakeTrackChanged() + wakePlayStateChanged(). The metachanged wake drives T5 → TRACK_CHANGED / REACHED_END (gated) / REACHED_START. The playstatechanged wake drives T9 → PLAYBACK_POS CHANGED for the position reset to 0.

onCompletion / onError unchanged — the next onPrepared will fire the broadcasts.

Method-count budget

classes.dex post-Patch-B5 was 65330/65536. Two new methods (wakeTrackChanged + wakePlayStateChanged on TrackInfoWriter) take it to 65332. Three new method-ref uses inside PlaybackStateBridge reference these same defined methods, so no additional method refs. ~204 slots remain (still under cap; cap-check passes via apktool reassembly succeeding).

Verification (pending hardware)

Patcher smoke-test: output/com.innioasis.y1_3.0.2-patched.apk reassembles cleanly. META-INF + AndroidManifest.xml byte-identical to stock (md5 match) — JarVerifier won't reject. New smali md5s:

• TrackInfoWriter.smali → 35496cf01171fa9c5293813a45553cc0 (was 1f6a3f44dd4ac4f3edf7c08caf76eba9 pre-fix)
• PlaybackStateBridge.smali → 69d50e5835b23cbf6e546298a7130f06 (was 0d8e4ed14b4dbe5683e8716b30dba76b pre-fix)

Expected behavior on hardware:

• Bolt: TRACK_CHANGED CHANGED should fire on every onPrepared; Bolt CT should query GetElementAttributes → metadata renders.
• Kia: PLAYBACK_STATUS / POS CHANGED should fire on every play / pause / track edge, not just the 10 s battery tick. Playhead lag should reduce (full 1 s position cadence is a separate follow-up — that requires a Handler.postDelayed tick loop while playing; not in this fix).

Out of scope for this fix

• 1 s position-tick loop (Kia's residual playhead drift between actual edges). Separate change to PlaybackStateBridge — a Handler scheduled from onPlayValue(PLAYING) and cancelled at STOPPED/PAUSED, calling wakePlayStateChanged on tick.
• Shuffle "always on" — likely initial-state issue: y1-track-info[795..796] is zero-filled at creation and 0x00 is not a valid AVRCP §5.2.4 Tbl 5.20 / 5.21 value. Need to initialize TrackInfoWriter defaults to 0x01 OFF / 0x01 OFF before any read. Separate change.
• Music-app Settings UI refresh on CT-driven Repeat/Shuffle change. Music-app side observer, not a wire-level issue.

Trace #26 (2026-05-11) — Multi-CT verification of Trace #25 + 1 s position tick + cold-boot file-flush

What the multi-CT capture showed (post-Trace #25)

Captures: dual-bolt-20260511-1422, dual-kia-20260511-1417, dual-tv-20260511-1532. Hardware confirmation that the Trace #25 broadcast-wake fix landed:

The Trace #25 wake fix unblocked metadata flow on all CTs that proactively poll GetElementAttributes (Kia, TV, Sonos). Bolt still has no UI metadata despite receiving the full response payload — that's a CT-side rendering issue, not a wire-shape issue.

Fix shipped in this trace

Two compounding follow-ups for the Kia playhead lag + the shuffle initial-state issue:

1. 1 s position-tick loop. New class com.koensayr.y1.playback.PositionTicker (Runnable + lazy main-thread Handler):

• PositionTicker.start() — Handler.removeCallbacks(INSTANCE) + postDelayed(INSTANCE, 1000). Idempotent.
• PositionTicker.stop() — Handler.removeCallbacks(INSTANCE).
• PositionTicker.run() — calls TrackInfoWriter.wakePlayStateChanged() then Handler.postDelayed(this, 1000).

PlaybackStateBridge.onPlayValue now calls PositionTicker.start() on the PLAYING edge (mapped state byte == 0x01) and PositionTicker.stop() on STOPPED / PAUSED. The wake fires com.android.music.playstatechanged → T9 → AVRCP 1.3 §5.4.2 Tbl 5.33 PLAYBACK_POS_CHANGED CHANGED with clock_gettime(CLOCK_BOOTTIME)-extrapolated position.

Expected effect on hardware:

• Kia: playhead appears immediately on first PLAY edge (T9 fires CHANGED within 1 s of Static.setPlayValue(1, _)) and stays current within ~1 s of real device playhead.
• TV / Sonos: extra wakes are no-ops for CTs that don't subscribe to event 0x05; small overhead (~one broadcast/sec while playing).
• Bolt: unchanged at the wire metadata layer; downstream of the rendering investigation.

2. Cold-boot y1-track-info flush. TrackInfoWriter.init(Context) now calls flushLocked() immediately after prepareFilesLocked(). The file lands on disk with the in-memory defaults (mRepeatAvrcp=0x01 OFF, mShuffleAvrcp=0x01 OFF — valid AVRCP §5.2.4 Tbl 5.20 / 5.21 values) before any CT can read it.

Pre-fix sequence:

1. Y1Application.onCreate → TrackInfoWriter.init → prepareFilesLocked creates y1-trampoline-state + y1-papp-set, but NOT y1-track-info.
2. CT subscribes to PApp CHANGED before B4's PappStateBroadcaster.sendNow() fires → T8 INTERIM reads y1-track-info[795..796], file doesn't exist, trampoline buffer stays zero-filled, MtkBt sends [0, 0] → invalid AVRCP enum.
3. CT latches onto invalid initial state; some CTs (observed: Bolt) refuse to follow subsequent CHANGED events from that point.

Post-fix: file always exists with [0x01, 0x01] at boot.

Method-count budget

classes.dex now 65337/65536 method refs (199 slots free). +7 over the pre-Trace-#25 baseline of 65330. Inside 64K cap.

Out of scope

• Bolt no UI metadata. Wire-level metadata response is correct (full 7 attributes, valid UTF-8, valid SongPosition). Investigation needs btlog.bin parse of the AVRCP frames Bolt sends back, to figure out what specific event/PDU Bolt is waiting for before rendering. Possibilities: missing AVRCP 1.4 ABSOLUTE_VOLUME response, missing PLAYBACK_STATUS_CHANGED INTERIM with status=PLAYING, AVCTP fragmentation parsing on the CT side.
• Bolt PAUSE not actually pausing. PASSTHROUGH 0x46 receipt confirmed at the MMI_AVRCP layer; the downstream kernel input → AVRCP.kl → KeyEvent → BaseActivity (Patch H) → PlayControllerReceiver (Patch E) path needs to be traced. Bolt's icon toggling without actual pause action suggests a dispatch hole somewhere in the foreground-activity propagation path.
• Music-app Settings UI refresh on CT-driven Repeat/Shuffle. Music-app side observer, not a wire-level issue. Fix needs SharedPreferences listener in the Settings activity or an explicit refresh Intent from PappSetFileObserver.

Trace #27 (2026-05-13) — AVRCP §6.7.1 per-subscription gate completes the 1.3 pipeline; Bolt's metadata pane remains 1.4-CoverArt-blocked

Background

Trace #26's hardware verification showed Kia's playhead "appeared, played for 2 seconds, then froze." The two-second window is the smoking gun: the wire was emitting PLAYBACK_POS_CHANGED CHANGED continuously at 1 s cadence via PositionTicker, but Kia stopped updating its display after the second frame. Bolt similarly showed its play/pause icon flipping correctly on the first state-edge, then sticking on "Play" forever — and its Shuffle button enabling shuffle on Y1 but never registering as enabled in Bolt's own UI.

Both symptoms point at the same spec gap: AVRCP 1.3 §6.7.1 says "Once a Controller has registered to receive a particular EventID, the Target shall notify the CT of the change to the registered EventID only once." After CHANGED, the subscription is consumed; the CT must re-register to receive another. We were emitting CHANGED unconditionally — on every PositionTicker tick (for event 0x05) and on every actual state edge (for events 0x01/0x02/0x06/0x08).

Cadence comparison from dual-kia-20260513-1144 vs the older Sonos working capture (dual-sonos-20260511-1042):

Sonos's aggressive re-registration matches the strict §6.7.1 contract — it gets a steady stream of valid CHANGEDs. Kia subscribes once and trusts the TG to keep sending. Our excess CHANGEDs after the first were silently rejected by Kia.

Fix — full §6.7.1 compliance via per-subscription gates

y1-trampoline-state grew from 16 B → 20 B. Bytes 13..19 each hold one subscription byte:

INTERIM emit sites write 0x01 to their byte via _emit_subscription_write helper (1-byte strb_w + open + lseek + write + close). CHANGED emit sites read the byte; if 0, skip emit; if 1, emit + clear. Edge-detection writes (state[9..12]) remain unconditional so we don't loop "edge detected, can't emit" forever while un-subscribed.

Schema migration: existing 16-B files on already-flashed devices grow naturally — T2/T8's lseek(N >= 16) + write(1) extends the file. Until then, new gate-bytes read as 0 = "not subscribed" via T5/T9's memset-then-read pattern. No manual remediation needed.

Stack-frame growth: T5_FRAME 816 → 820, T9_FRAME 832 → 836. T5_OFF_FILE 16 → 20, T9_OFF_FILE 24 → 28 (timespec offset shifts accordingly). T4 state write switched from O_WRONLY|O_TRUNC to O_WRONLY so it doesn't clobber bytes 16..19 that T2/T8 may have written. Some short-form branches in T5 needed promotion to wide-form (blt_w / beq_w) — extended body exceeded the 254-B short range.

OUTPUT_MD5 of libextavrcp_jni.so is now c017b6ab5d66ccbd851c9399e0642262.

Other fixes shipped same session

Hardware results (2026-05-13 captures)

Kia EV6 (dual-kia-20260513-1351): play/pause toggles work, playhead updates continuously, Repeat/Shuffle UI flips in real-time on the Y1 Now Playing screen, metadata pane renders. All previously-reported Kia issues resolved.

Bolt EV (dual-bolt-20260513-1355):

• Audio actually pauses on Pause button press (was broken pre-44d376c). ✓
• Forward / Previous PASSTHROUGH actions work. ✓
• Metadata pane stays empty. Root cause confirmed: Bolt's GetElementAttributes request (wire size:45) asks for 8 attributes including attr 8 (Default Cover Art handle, AVRCP 1.6 §5.14.1; attribute id assigned in §26 Table 26.1 per ESR09 E6073). We return 7. Bolt gates pane render on receiving a non-empty CoverArt entry. Note: Default Cover Art is an AVRCP 1.6 feature (Dec 2015), NOT 1.4. AVRCP 1.4 added browsing + AbsoluteVolume; 1.5 added AddressedPlayer / AvailablePlayers; 1.6 added Default Cover Art via attribute 8.
• Play/Pause icon stuck after first toggle. Root cause: Bolt subscribes for event 0x01 once at connect and never re-registers. Our gate emits exactly one CHANGED per registration; Bolt only ever sees one. UI mirror frozen at first-CHANGED state.
• Shuffle stuck on. Same root cause — Bolt subscribes for event 0x08 once.

Bolt's failure to re-register after CHANGED is a CT-side spec violation we cannot work around without violating §6.7.1 on the TG side (which would re-break Kia). The empty metadata pane is the actionable symptom — implementing AVRCP 1.6 Default Cover Art unblocks it.

Scope change: AVRCP 1.6 Default Cover Art newly in-scope

User directive 2026-05-13 after seeing the §6.7.1 fixes work end-to-end on Kia: "I do not accept the Bolt's behavior as-is. I think the cover art thing might be worth a look."

Project policy amended: feedback_avrcp13_only_scope.md now lists two carve-outs:

1. MtkBt.odex F1 BlueAngel internal-flag spoof (existing).
2. AVRCP 1.6 Default Cover Art — new. Specifically: GetElementAttributes attribute id 8 (AVRCP 1.6 §5.14.1; ID assigned in §26 Table 26.1 per ESR09 E6073), the AVRCP Cover Art OBEX channel (§5.14.2.1 Target Header UUID 7163DD54-4A7E-11E2-B47C-0050C2490048) on a dynamically-assigned L2CAP PSM advertised via the AVRCP TG SDP record's Additional Protocol Descriptor List (Table 8.2), and the BIP Image Pull functions GetImageProperties / GetImage / GetLinkedThumbnail (§5.14.2.2). The generic BIP Imaging Responder SDP record (0x111B) is not used — §13 forbids publishing it when BIP is used solely for Cover Art.

Other 1.4+ / 1.5+ / 1.6+ features (SetAbsoluteVolume, browse channel for player switching, SetAddressedPlayer, NOW_PLAYING_CONTENT_CHANGED, etc.) remain out of scope.

What needs investigation before implementing Default Cover Art

1. AVRCP TG SDP record changes — Table 8.2 specifies: AVRCP profile version 0x0106 (currently 0x0103); SupportedFeatures (attr 0x0311) bit 8 = Supports Cover Art (currently 0x0001, bit 8 unset); Additional Protocol Descriptor List with a Cover Art L2CAP PSM + OBEX entry. Need to extend patch_mtkbt.py V-family to inject these.
2. Where does the music app store/access cover art for local display? Likely MediaMetadataRetriever.getEmbeddedPicture() or similar.
3. Wire format for attribute 8: per AVRCP 1.6 §5.14.1 + §29.23 example MSC, the value is a BIP Image Handle (BIP §4.4.4 format; the example shows a 7-character ASCII identifier such as "1000004").
4. AVRCP Cover Art OBEX responder implementation — must listen on the dynamically-assigned PSM, accept OBEX connections with Target Header UUID 7163DD54-4A7E-11E2-B47C-0050C2490048 (§5.14.2.1), and serve GetImageProperties / GetImage / GetLinkedThumbnail. mtkbt ships a generic BIP responder in libextbip.so that could potentially be reused; whether it matches the Cover-Art-specific Target Header UUID needs verification.
5. Imaging Thumbnail format per §5.14.2.2.1: 200×200 pixels, JPEG baseline-compliant, sRGB default colour space, YCC422 sampling, one marker segment per DHT/DQT, typical Huffman table, DCF thumbnail file format. (Spec specifies pixel size + encoding; no byte-size limit.)

Implementation plan sketch in memory project_y1_cover_art_direction.md.

Trace #28 (2026-05-13) — AVRCP 1.6 Default Cover Art recon + T4 attr 8 emit landed

Investigation answers

Q1 (mtkbt BIP server) — answered YES, partial. Native side fully present, Java side stripped:

• /work/v3.0.2/system.img.extracted/system/lib/libextbip.so (63 108 B) — full BIP responder + initiator state machine. Source path baked in: mediatek/protect/external/bluetooth/blueangel/btadp_ext/profiles/bip/. Exports bip_responder_enable / disable / disconnect / authorize_response / getcapability_response / access_response / auth_response / obj_rename plus btmtk_bipr_* helpers covering get capabilities / images list / image properties / image / linked thumbnail / put image / put thumbnail / continue / abort / connect.
• /work/v3.0.2/system.img.extracted/system/lib/libextbip_jni.so (21 900 B) — JNI bridge. JNI_OnLoad calls FindClass com/mediatek/bluetooth/bip/BluetoothBipServer and RegisterNatives for 21 methods (full signature table at memory architecture_y1_bip_jni_shape.md). classInitNative caches one field (mNativeData:I) + one method (onCallback:(III[Ljava/lang/String;)V). Value-class field IDs are looked up lazily inside the methods that use them; partial shapes recovered (e.g. ImageFormat: Encoding / Width / Height / Width2 / Height2 / Size / Transform; ImageDescriptor: DirName / FileName / Version / ThumbnailFullPath / ObjectSize; AuthInfo: bAuth / UserId / Passwd).
• /work/v3.0.2/system.img.extracted/system/framework/javax.obex.jar — OBEX Java APIs available.
• No Dalvik classes under com/mediatek/bluetooth/bip/* anywhere in the system image. Scanned every .dex + .odex + APK classes.dex. MtkBt.odex references com.mediatek.bluetooth.bip.BipService only as a string passed to startService(...) — that service doesn't exist on this build, so the start silently no-ops.

The OEM stripped the Java BIP service layer (likely to slim the firmware — Y1 has no native UI for OPP/FTP image push). Native libs ship as-built; nothing currently calls into them.

Q2 (SDP record) — recon initially focused on the wrong artifact. Complete generic BIP Imaging Responder SDP record is baked into mtkbt at file offset 0xf9df0 (record body, 10 attribute entries of 12 B each) + value blobs at .rodata 0xebc97..0xebd40 — ServiceClassIDList (0x111B), ProtocolDescriptorList (L2CAP / RFCOMM / OBEX), BrowseGroupList (PublicBrowseRoot), LanguageBaseAttributeIDList, BluetoothProfileDescriptorList (0x111A v1.0), ServiceName ("Imaging"), SupportedCapabilities, SupportedFeatures, SupportedFunctions, TotalImagingDataCapacity (0x50000000 ≈ 1.34 GB). Live sdptool browse (capture logs/y1-sdptool-20260513-1437.log) confirms it is not advertised: server returns 5 records (A2DP / AVRCP TG / PBAP PSE / NAP / OBEX Object Push); record handle slots 0x10001 and 0x10006 are absent.

Reading the spec afterward reveals this record is the wrong target anyway. AVRCP 1.6 §13 explicitly forbids publishing the generic BIP SDP record when BIP is used solely for AVRCP Cover Art:

"When BIP functionality is used solely for AVRCP Cover Art the BIP SDP record described in [BIP] shall not be published. The Cover Art feature never affects the format or values of the BIP SDP record described in [BIP]. L2CAP channels implementing BIP functionality for AVRCP Cover Art shall be distinct from L2CAP channels implementing BIP functionality in conformance to [BIP]." — AVRCP 1.6 §13

The correct AVRCP-Cover-Art SDP signaling lives in the AVRCP TG service record (§8 Table 8.2):

• AVRCP profile version 0x0106 (currently Y1 advertises 0x0103).
• SupportedFeatures (attr 0x0311) bit 8 = Supports Cover Art (currently Y1 advertises 0x0001, bit 8 unset).
• Additional Protocol Descriptor List with an entry for L2CAP, PSM=<dynamically assigned Cover Art PSM>, OBEX.

And the OBEX channel uses Target Header UUID 7163DD54-4A7E-11E2-B47C-0050C2490048 (§5.14.2.1) on an L2CAP PSM distinct from any generic BIP channel — the generic libextbip.so BIP responder accepts the BIP target header (E33D9545-8374-4AD7-9EC5-C16BE31EDE8E), not the Cover Art one, so even if we could activate it, it would not match the AVRCP Cover Art client's connect.

Net effect: the whole "mtkbt has a baked-in BIP record, just call biprEnableNative to advertise it" framing in earlier sections of this trace is misdirected. The 0x111B record is the wrong record. The actual SDP changes belong in patch_mtkbt.py against the AVRCP TG record (already mutated by V1/V6/V7/S1) — specifically: bump the AVRCP-profile-version bytes, flip the SupportedFeatures attribute, append the Additional Protocol Descriptor List entry.

Q3 (music-app cover art source) — not yet investigated; deferred to the image-wiring chunk.

Q4 (wire format for attr 8) — confirmed AVRCP 1.6 §5.14.1 + §29.23 example MSC. The value is a BIP Image Handle (BIP §4.4.4 format). The §29.23 MSC shows AttributeValueLength=7; AttributeValue='1000004' — a 7-character ASCII identifier. (Earlier notes claimed "hex" — spec doesn't constrain the encoding to hex; BIP defines the format.)

Q5 (image constraints) — AVRCP 1.6 §5.14.2.2.1 Imaging Thumbnail: 200×200 pixels, JPEG baseline-compliant, sRGB default colour space, YCC422 sampling, one marker segment per DHT/DQT, typical Huffman table, DCF thumbnail file format. (Spec specifies pixel size + encoding; no byte-size limit. Earlier notes citing a 200 KB cap were fabricated.)

T4 attr 8 emit shipped (_trampolines.py)

T4 attr_table grew from 7 entries to 8 with ("cover_handle", 0x08, T4_OFF_FILE_COVER_HANDLE). y1-track-info schema grew 1104 → 1112 B (new tail [1104..1110] for the 7-character ASCII BIP Image Handle + NUL terminator at 1111). T4's add_sp_imm calls in the attr-emit loop gained a per-offset fallback to the wider addw rd, sp, #imm12 encoding so the new cover_handle slot at SP+1136 emits cleanly — add_sp_imm only reaches 1020 via its imm8<<2.

Until the AVRCP Cover Art OBEX responder lands and TrackInfoWriter starts writing per-track handles into y1-track-info[1104..1110], T4 emits attr 8 with an empty value (file is 1104 B on disk; T4's read(fd, buf, 1112) short-returns at 1104, the new tail bytes stay memset-zeroed; strlen of zeroed bytes returns 0). Per AVRCP §5.3.4 a 0-length attribute is the canonical "not available" signal — spec-compliant graceful degradation. The wire frame now contains the expected 8th attribute slot; strict-CT metadata-pane render still gates on a non-empty handle, so panes remain empty today but the protocol surface is in place.

OUTPUT_MD5 of libextavrcp_jni.so is now 4da9283b85954648521efd0d11524192. File size unchanged at 50 992 B (T4 grew ~32 B from the new attr iteration + 4 widened add_sp_imm → addw encodings; still fits inside the LOAD #1 padding code-cave).

What remains for the metadata pane to render

Per AVRCP 1.6 §5.14 + §8 + §13 + §29.23 the actual blockers are:

1. AVRCP TG SDP-record patches (patch_mtkbt.py V-family extensions). Three changes to the served AVRCP TG record (handle 0x10003 in current capture):
   • AVRCP profile version bytes: 0x0103 → 0x0106 (Table 8.2 requires 1.6 advertisement for Cover Art support).
   • SupportedFeatures attribute (0x0311): set bit 8 (Supports Cover Art). Currently 0x0001 → must include 0x0100.
   • Additional Protocol Descriptor List: add an entry L2CAP (PSM=<dynamic Cover Art PSM>), OBEX.
2. AVRCP Cover Art OBEX responder listening on the dynamic PSM and accepting OBEX connections whose Target Header carries the 7163DD54-4A7E-11E2-B47C-0050C2490048 UUID (§5.14.2.1). Must serve GetImageProperties / GetImage / GetLinkedThumbnail. mtkbt's stock libextbip.so BIP responder accepts the generic BIP target UUID (E33D9545-8374-4AD7-9EC5-C16BE31EDE8E), so it likely will not match the Cover Art target out of the box — needs verification, and if the mismatch is confirmed we either patch the target-UUID check or write a small OBEX responder of our own (javax.obex on the Y1's classpath would make this tractable).
3. Music-app image source: MediaMetadataRetriever.getEmbeddedPicture() (or equivalent) to extract album art, JPEG-200 re-encode to the Imaging Thumbnail constraints (§5.14.2.2.1), and write to a known file path the responder reads.
4. TrackInfoWriter schema bump: grow on-disk write from 1104 B to 1112 B, populate [1104..1110] with a 7-character BIP Image Handle per track (e.g. a 7-char encoding of audio_id low bits). Independent of (1)-(3) but only useful once those land.

Trace #29 (2026-05-13) — Cover Art dropped; real blocker was a §5.3.4 spec deviation in libextavrcp.so

What we set out to verify (Phase 2 of the "what's blocking Bolt's pane" investigation)

After flashing T4 attr 8 emit (commit 3f99028) we inspected post-flash Bolt + Kia captures (dual-bolt-20260513-1514, dual-kia-20260513-1515):

EXTADP_AVRCP log on every GetElementAttributes response:

AVRCP send_get_element_attributes_rsp raw i:7 total:8 attid:8 strlen:0
AVRCP send_get_element_attributes ignore empty attrib attri_id:8 strlen:0

T4 was correctly emitting all 8 attribute slots, but the stock libextavrcp.so response builder was hitting an "ignore empty attrib" branch and dropping every zero-length attribute from the wire frame. This is a deviation from AVRCP 1.3 §5.3.4 which requires "for attributes not supported by the TG, this field shall be sent with 0 length data."

The drop is uniform (not attr-8-specific): in the no-music capture, attrs 1/2/3/5/6/7 also have strlen:0 and are also dropped. Only attr 4 (TrackNumber "1") survives. The g_offset tracer in EXTADP_AVRCP confirms: g_offset only advances for non-empty attrs.

What does Bolt actually request?

Parsed raw btlog binary for inbound GetElementAttributes commands (signature 00 19 58 20 00 = SIG CompanyID + PDU 0x20 + PT 0):

Two request patterns observed from both Bolt-class AND Kia-class CTs:

Both CTs use both patterns. The "Bolt requests 8 attributes" claim in prior traces was based on the EXTADP_AVRCP total:8 log, which is what Y1 unilaterally emits — not what either CT asked for. Both CTs ask for the same attribute set.

So why does Kia render but Bolt not?

Both receive the same wire frame (whatever non-empty attrs Y1 happens to have). Kia is lenient: picks out what it recognizes from the response. Bolt is strict: the §5.3.4 spec says the TG sends exactly the requested attributes in the requested order, including zero-length entries for unsupported ones, and Bolt's parser gates on receiving that exact shape. When Bolt requested Pattern A [1,2,3,6,8,7] it expected to see all six slots back, even if some came with length 0. Y1 was returning [1,2,3,?,?,4,5,6,7] — extras (4, 5) it didn't ask for, missing (8) it did.

Charset ruled out (other ruled-out hypotheses for record)

• Fragmentation: libextavrcp.so allocates a 644-byte response buffer regardless of content; g_offset tracking shows real payload is ~58 bytes. No AVRCP-level Packet Type fragmentation; whole frame goes out as a single Packet Type=00 (Complete) AVRCP frame inside one L2CAP packet of size 672 (well under the 672-byte default L2CAP MTU). Both CTs receive identically shaped frames.
• Charset: parsed Bolt's InformDisplayableCharacterSet PDU 0x17 from raw btlog (signature 00 19 58 17). Bolt advertised Count=1, CharsetID[0]=0x006A (UTF-8 only). Y1 emits charset=0x006A in every attribute. Match — not the problem.
• LanguageBaseAttributeIDList in SDP record: AVRCP TG SDP record doesn't carry attribute 0x0006 (PBAP's does). Not authoritative for charset selection — PDU 0x17 already settled the question — but worth noting as a stylistic gap.

Fix: patch_libextavrcp.py E1

Single 2-byte CBZ→NOP at file offset 0x00002266 inside btmtk_avrcp_send_get_element_attributes_rsp. Disables the (attr_id == 0) OR (strlen == 0) gate so attributes always emit, including zero-length ones. AVRCP §5.3.4 compliance restored. Stock MD5 6442b137d3074e5ac9a654de83a4941a → Output MD5 1347e1b337879840ad2f66597836b05f. New patcher wired into apply.bash --avrcp.

Scope decision

User directive 2026-05-13 after spec analysis: "I really don't need to implement DCA as it's outside of the 1.3 spec. I really just want to ensure that all endpoints work as expected."

The AVRCP 1.6 Cover Art carve-out is rolled back — no BIP responder, no OBEX channel, no SDP record changes per §8 Table 8.2, no MediaMetadataRetriever image source. Attr 0x08 emits as a §5.3.4-compliant zero-length entry forever. feedback_avrcp13_only_scope.md updated: AVRCP 1.6 §5.14.1 + §26 Table 26.1 / ESR09 E6073 may still be cited when explaining what attr 0x08 is, but no implementation work is in scope.

Remaining strict-CT issues (CT-side, not fixable on TG)

• Strict-CT pause-icon stuck after first toggle: CT doesn't re-register after our CHANGED, §6.7.1 prevents subsequent CHANGED without re-registration. CT-side §6.7.1 violation.
• Strict-CT Shuffle stuck on: same root cause.

Trace #30 (2026-05-13) — Phase 1 request-shape compliance; drop all AVRCP 1.6 framing

Diagnosis from post-E1 captures

Bolt's metadata pane still empty after patch_libextavrcp.py E1 landed. The post-flash capture (dual-bolt-20260513-1556) shows:

• EXTADP_AVRCP send_get_element_attributes strlen:0 offset:57 g_offset:58 — attr 8 zero-length entry now reaches the wire (E1 working as designed).
• But the inbound parser shows Bolt's actual request was NumAttr=7, AttrIDs=[0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7] (canonical 1.3 set, no attr 0x08), and Y1 was sending a frame with 8 attributes (1..7 plus 0x08 zero-length).

So Y1's response violates AVRCP 1.3 §6.6.1 Table 6.26:

"If NumAttributes is set to zero, all attribute information shall be returned, else attribute information for the specified attribute IDs shall be returned by the TG."

We were emitting more (and in a different order) than Bolt asked for. Lenient CTs tolerate the extras; strict-CT parsers reject the entire frame.

Phase 1 implementation

T4 in _trampolines.py rewritten to:

1. Read NumAttributes (1 byte at caller's sp+394, post-SUB-SP at sp+1530).
2. If N == 0: fall back to the compile-time-unrolled "emit all 7" loop (per §6.6.1 zero means all).
3. Otherwise: loop i = 0..N-1, read each AttributeID[i] (4 byte BE u32 at caller's sp+395+4i), byte-reverse, dispatch:
   • attr_id ∈ {0x01..0x07}: look up y1-track-info offset via the inline t4_attr_offset_table data block + emit with strlen value.
   • Else (attr_id == 0 or > 7): emit with AttributeValueLength=0 per §5.3.4.

The lookup table is appended at the trampoline blob's tail (8 u32 words = 32 B). Register conventions: r5=JNI base, r6=i, r7=N, r9=saved attr_id across calls, r10=saved str_offset across calls, r0..r4 scratch.

New asm primitives added in _thumb2asm.py: ldr_w (32-bit imm word load, T3), add_reg (ADD register T2, supports any reg incl. SP), lsls_imm5 (LSL imm T1), and bhi/bls/bcs/bcc/bhs/blo + bhi_w/bhs_w branch helpers.

Schema rollback

y1-track-info returns to 1104 B (was bumped to 1112 in the previous trace to make room for the cover-art handle slot at [1104..1110]). The slot is gone; Y1 emits attr 0x08 (and any other unsupported ID) with AttributeValueLength=0 regardless of whether y1-track-info carries any handle data.

OUTPUT_MD5 of libextavrcp_jni.so is now 3454ffe3c28f609d07852435433cf3a8. File size unchanged at 50,992 B — Phase 1 + the new data table still fit within the LOAD #1 padding extension.

AVRCP 1.6 framing stripped

All AVRCP 1.6 implementation references removed from active docs (docs/PATCHES.md, docs/BT-COMPLIANCE.md, docs/ARCHITECTURE.md, CHANGELOG.md, src/patches/_trampolines.py, src/patches/patch_libextavrcp.py). The §5.14.1 / §26 Table 26.1 / ESR09 E6073 citations were originally kept under a "narrow citation exception" — they're now gone entirely because attr 0x08 no longer requires special-case explanation: it's just "any attribute outside 0x01-0x07, handled by the general unsupported-attribute path".

Memory feedback_avrcp13_only_scope.md tightened: no more narrow citation exception. AVRCP 1.6 is not referenced anywhere in active docs/source. The four memory files about Cover Art / BIP / SDP infrastructure stay marked HISTORICAL for future-reference value but are no longer load-bearing.

Open: Bolt pane render still uncertain

Whether Phase 1 unblocks Bolt's pane is unverified on hardware — we shipped 0 in-spec [1..7] responses pre-Phase-1 and Bolt's pane was still empty. Possibilities:

1. Pre-Phase-1 Bolt was rejecting [1..7] + extra(0x08) shape; Phase 1 emits exactly [1..7] matching the request — pane may now render.
2. Bolt's pane has additional requirements we haven't identified (e.g., specific event subscriptions before pane query). Already noted: Bolt only subscribes to event 0x01 PLAYBACK_STATUS_CHANGED, not TRACK_CHANGED — significantly narrower than Kia's 6-event subscription set.

If Phase 1 doesn't unblock the pane, the remaining diagnosis path is on the CT-state side (forget+repair, force-open the metadata pane at a specific point, etc.) rather than further TG-side changes — we've now exhausted the §5.3.4 / §6.6.1 spec deviations on Y1's end.

Trace #31 (2026-05-13) — Phase 1 verified on wire; AVRCP 1.3 Y1-side exhausted for Bolt-class pane

Phase 1 confirmed working

dual-bolt-20260513-1703 (post-Phase-1 flash):

AVRCP send_get_element_attributes_rsp raw i:0 total:7 attid:1 strlen:13
AVRCP send_get_element_attributes strlen:13 offset:0 g_offset:14
AVRCP send_get_element_attributes_rsp raw i:1 total:7 attid:2 strlen:9
... (attid 3 strlen:18, attid 4 strlen:4, attid 5 strlen:4, attid 6 strlen:13, attid 7 strlen:6)
msg=540, ptr=0x52385638, size=644

total:7 confirms T4 now emits exactly the seven attributes Bolt requested ([0x1,0x2,0x3,0x4,0x5,0x6,0x7] Pattern B), in the requested order, with real-value lengths. No spurious attr 8. No "ignore empty attrib" lines. Spec-compliant per AVRCP 1.3 §6.6.1 Table 6.26.

Response timing on this capture: 1 ms (matches dual-bolt-20260513-1556 timing audit — well under T_MTP 1000 ms).

Bolt's metadata pane: still empty

Despite the wire response now exactly matching the request shape, the Bolt-class CT's metadata pane still doesn't render. This is the end of what's reachable from the AVRCP 1.3 TG side.

Exhaustion checklist — AVRCP 1.3 Y1-side spec compliance

Bolt's residual symptoms — all CT-side / out-of-1.3-scope

• Metadata pane empty: forum evidence + community knowledge points at Bolt-class CTs gating pane render on AVRCP 1.4+ SDP advertisement (profile version 0x0104+, SupportedFeatures GroupNavigation bit, AdditionalProtocolDescriptorList Browse PSM). Out of the AVRCP 1.3-only project policy; will be tackled on a separate feature branch.
• Play/Pause icon stuck after first toggle: Bolt doesn't re-register after CHANGED. §6.7.1 prevents subsequent CHANGED without re-registration. CT-side spec violation, not fixable on the TG side without re-violating §6.7.1 (which would re-break Kia and other spec-compliant CTs).
• Shuffle stuck on: same root cause as Play/Pause icon — Bolt doesn't re-register after the §6.7.1-compliant CHANGED.

Conclusion (superseded by Trace #32)

Trace #31 concluded that Bolt's empty pane was blocked by CT-side reliance on 1.4+ SDP advertisement. Trace #32 refuted that hypothesis: Pixel-as-TG advertises strict AVRCP 1.3 in SDP (profile descriptor 0x0103, SupportedFeatures 0x0001) and Bolt's pane renders against it. The discriminator was the GetCapabilities event list — Pixel advertises four 1.4 event IDs (0x09-0x0c) from a 1.3-declared TG; Y1 (post-Trace-#31) did not.

Trace #32 (2026-05-14) — Pixel HCI snoop reveals GetCapabilities event-list discriminator; Y1 mirrors

After CoD masquerade attempts (Information bit, full Phone-Smartphone) both failed to unblock the metadata pane, the user provided a Pixel-4 adb bugreport containing btsnoop_hci.log of a working Pixel↔Bolt connection. Parsed via tshark.

Wire-level Pixel-vs-Y1 deltas at metadata-pane time

The only Pixel↔Y1 wire delta that maps cleanly to "what Pixel does that Y1 doesn't" is the GetCapabilities event-list mismatch + the 0x09-0x0c INTERIM acks. Pixel's response builders for these four events exist in libextavrcp.so (verified via objdump — btmtk_avrcp_send_reg_notievent_now_playing_content_changed_rsp @ 0x26c0 etc); the PLT stubs are already linked into libextavrcp_jni.so (verified via readelf --dyn-syms — symbols 10/12/14/16 at PLT 0x330c / 0x3318 / 0x3324 / 0x3330) though stock JNI never invokes them.

Implementation

Two surgical patches in patch_libextavrcp_jni.py:

1. T1 advertised-event bytes at file 0x7328..0x732f: 01 02 03 04 05 06 07 08 → 01 02 05 08 09 0a 0b 0c. Same 8-event count (which matches the existing movs r2, #8 in T1).
2. T8 dispatcher: 4 new arms for events 0x09 / 0x0a / 0x0b / 0x0c, each calling the existing PLT stub with r1=0 (success), r2=REASON_INTERIM (0x0f), and event-specific payload (zero for 0x09 / 0x0a; PlayerID=0, UidCtr=0 for 0x0b via r3=0, sp[0]=0; UidCtr=0 for 0x0c via r3=0). No subscription gate is armed for any of the four — no CHANGED ever fires (Y1 has one player, no Now Playing folder, no UID database). New blob size 3852 B (within the 4020-B LOAD #1 padding budget). New OUTPUT_MD5 = c16a6b7892be2098ac07bef1989c937e.

Cost: lost 1.3 event coverage

Dropping events 0x03 / 0x04 / 0x06 / 0x07 from the advertised set to make room for 1.4-event IDs at the spec-mandated 8-element cap means:

• 0x03 TRACK_REACHED_END: T5's natural-end emit path is no longer subscribed-to by any CT (event 0x02 TRACK_CHANGED still works; the dedicated end-of-track signal is gone)
• 0x04 TRACK_REACHED_START: same — collapsed into 0x02
• 0x06 BATT_STATUS_CHANGED: battery-status indicator on CTs that read it is no longer driven (the music app's BatteryReceiver still writes y1-track-info[794] but no CT subscribes)
• 0x07 SYSTEM_STATUS_CHANGED: always-INTERIM-only anyway, no behavioural change

T8 / T5 / T9 handlers for these four events are retained in the trampoline (a permissive CT subscribing to them despite no advertisement still gets handled correctly), but no observed CT does that.

Open: result not yet on the wire

Bolt-Y1 reflash test pending the user's flash cycle. If it works, this trace closes the metadata-pane investigation that's run from Trace #1 (2026-05-02). If it doesn't, the remaining candidates are: (a) some SDP-record-content discriminator (the BrowseGroupList / ServiceName presence delta, or Pixel's not-yet-RE'd 0x0102 ProviderName), or (b) the Bolt-side BR/EDR device-name regex or EIR discriminator.

Trace #33 (2026-05-14) — Bolt's 3-second InformDisplayableCharacterSet stall; T_charset switched to reject

Wire-level finding from dual-bolt-20260513-2150 (post-Trace-#32 flash)

After the Trace #32 flash (advertise + INTERIM-ack 0x09-0x0c), Bolt's metadata pane still didn't render. New dual-bolt-* capture shows the same wall-clock symptom as every prior Bolt capture, but a tighter inspection of the first few seconds reveals the real discriminator:

21:48:01.299  CMD_FRAME_IND size:9  (GetCapabilities request)
21:48:01.299  AVRCP_SendMessage len=30  (GetCapabilities response — 8 events)
21:48:01.360  CMD_FRAME_IND size:11 (InformDisplayableCharacterSet)
21:48:01.360  AVRCP_SendMessage len=8  (T_charset ACK)
21:48:04.367  CMD_FRAME_IND size:13 (FIRST RegisterNotification) ← +3.007 s

Compare to pixel4-bugreport/.../btsnoop_hci.log (Pixel-as-TG, Bolt-as-CT, same Bolt):

98.773  GetCapabilities request
98.773  GetCapabilities response — 8 events
98.785  InformDisplayableCharacterSet
98.786  Rejected - Status: Invalid Command
98.792  FIRST RegisterNotification (PlaybackStatusChanged) ← +0.006 s
98.803  RegisterNotification (TrackChanged)
98.809  GetElementAttributes
98.815  RegisterNotification (PlaybackPosChanged)
98.821  RegisterNotification (NowPlayingContentChanged)
98.836  RegisterNotification (AvailablePlayersChanged)
98.852  RegisterNotification (AddressedPlayerChanged)
98.861  RegisterNotification (UIDsChanged)
98.868  ListPlayerApplicationSettingAttributes

The single Y1 → Pixel delta in that window: Y1 ACKs 0x17 via inform_charsetset_rsp (success); Pixel rejects 0x17 with AV/C ctype NOT_IMPLEMENTED. Bolt evidently waits ~3 s for a follow-up notification after the ACK, then falls back to a 3-second polling cadence for RegisterNotification — which is what every prior dual-bolt-* capture (going back to Trace #21) actually shows, but it never read as a "stall" before because the wall-clock-equivalent symptom (empty metadata pane) was consistent with several other hypotheses.

Fix

T_charset rewritten 14 B → 12 B: drop the blx PLT_inform_charsetset_rsp ACK, restore lr canary + r0=conn, tail-jump to UNKNOW_INDICATION (0x65bc). Same calling convention as T_continuation. Net wire: 0x17 now produces an AV/C NOT_IMPLEMENTED reject (msg=520) instead of an ACK (msg=536), matching Pixel-as-TG byte-for-byte at the AV/C ctype level.

Spec-permissible per AVRCP 1.3 §5.2.7 (InformDisplayableCharacterSet is Optional, both as a feature and as a response shape). The TG's outbound charset is decoupled from the CT's advertised set; we continue to emit UTF-8 for metadata regardless. ICS Table 7 row 18 status unchanged (O); the reject is a valid response for an unsupported Optional PDU.

OUTPUT_MD5: c16a6b78... → e2d44674f6f04f2b2d18ff3f633c5dfc.

Pre-flash prediction

If the InformDisplayableCharacterSet → ACK was indeed the 3-second stall, the next dual-bolt-* capture should show:

• CMD_FRAME_IND size:13 (first RegisterNotification) within ~10 ms of the 0x17 frame, not +3 s
• A burst of 5-8 RegisterNotification commands in the first ~100 ms after 0x17 (one per advertised event Bolt cares about), matching Pixel-Bolt's pattern
• GetElementAttributes (size 45) follows the first RegisterNotification by ~10 ms

If the burst pattern matches Pixel's and the metadata pane still doesn't render, the discriminator is elsewhere (SDP record content, EIR/inquiry response, BR/EDR name regex). If the burst happens but the pane does render, this closes the investigation.

Trace #34 (2026-05-14) — mtkbt msg=544 wire ctype is hardcoded 0x0D CHANGED; M1 fix

Direct discriminator finally found at the wire layer

Post-Trace-#33 captures (dual-bolt-20260513-2207) parsed at HCI ACL level. AV/C ctype byte counted from all outbound AVRCP frames:

Every Y1-as-TG response to RegisterNotification has gone out as CHANGED on the wire, never INTERIM, for the entire v2.0 / v2.1 trampoline-chain era. The Pixel capture of the identical Bolt CT shows ctype 0x0F INTERIM for the first response per subscription, 0x0D CHANGED on subsequent edges — the spec-correct AVRCP 1.3 §6.7.1 pattern. Bolt drops CHANGED-without-INTERIM and falls back to ~3 s polling, which never delivers the metadata pane render.

Why no earlier trace caught this

Every prior btlog inspection (Trace #18, #21, #28-31) parsed mtkbt's IPC byte stream (msg=520, msg=540, msg=544) and verified the IPC frame shape; none decoded the actual HCI ACL bytes mtkbt put on the wire. The IPC layer's reasonCode byte at IPC frame[8] is exactly what the trampoline passes (0x0F INTERIM for first response per subscription, 0x0D CHANGED for proactive edges). The bug is between mtkbt's IPC reception and HCI emission.

Root cause in mtkbt

mtkbt's outbound AVRCP wire encoder at file 0x37cca:

37cb8: ldrb.w r1, [r5, #548]   ; per-conn state byte
37cbc: and.w  r2, r1, #34       ; mask 0x22 = bits 1, 5
37cc0: cmp    r2, #2            ; bit 1 set, bit 5 clear ?
37cc2: bne.n  37cd8
37cc4: movs   r0, #1
37cc6: movs   r2, #0
37cc8: strb   r0, [r4, #25]
37cca: movs   r3, #13           ; <-- 0x0D CHANGED, HARDCODED
37cce: strb   r2, [r4, #24]
37cd0: strb.w r3, [r0, #12]!    ; r4+12 := 0x0D  (wire AV/C ctype byte)

The msg=544 dispatch path reaches this branch unconditionally for every RegisterNotification response (the state byte r5[548] & 0x22 == 2 matches). The reasonCode byte the trampoline shipped in IPC frame[8] is never consulted. In stock JNI flow this hardcoded CHANGED was correct: msg=544 was only ever invoked by _Z45BluetoothAvrcpService_registerNotificationCnfNative... after the music app reported a value change. The initial INTERIM came from mtkbt's native dispatcher through a different function at file 0x42abe, which conditionally writes ctype 0x0F when its dispatch byte r5[1]==3. The v2.0.0 trampoline bypasses the native dispatcher (because cardinality:0 was unresolvable) and routes both INTERIM and CHANGED through msg=544 → CHANGED-only on the wire.

Fix (M1)

One-byte flip at mtkbt file 0x37cca: 0d 23 → 0f 23 (movs r3, #13 → movs r3, #15). Net wire: msg=544 emits ctype 0x0F INTERIM. The trampoline's reasonCode argument is now ignored either way; both first-response and edge-CHANGED emit INTERIM. AVRCP 1.3 §6.7.1 allows the CT to treat repeated INTERIM responses as fresh subscription confirmations, so CTs that previously relied on the CHANGED edge see their state via the INTERIM payload instead.

OUTPUT_MD5 for mtkbt.patched: 5d650885... → 2f4e811632dc61564d527d41cf1da32c.

Open: validate against Kia

The trampoline-chain output reaching every CT in the test matrix has been CHANGED-only since v2.0.0. CTs that worked (Kia, etc.) tolerated CHANGED-without-INTERIM. With M1 they get INTERIM-on-edge instead of CHANGED-on-edge — also a §6.7.1-permissible response shape, but a behaviour-shift. Need a fresh dual-kia-* capture post-M1 flash to confirm no regression in PLAY / PAUSE / metadata refresh.

If Kia regresses on M1: option C from the deep-analysis discussion remains — patch mtkbt to read the IPC frame[8] reasonCode byte at 0x37cca and use it as the wire ctype, preserving the INTERIM/CHANGED distinction the trampoline already passes. Requires identifying which register or memory location holds the reasonCode byte at that point in the function (open RE work).

Trace #35 (2026-05-14) — M1 alone didn't reach the wire; fn 0x379e0 has 3 CHANGED branches

Post-M1 flash dual-bolt-20260514-0852 and dual-kia-20260514-0837 parsed at HCI ACL level. Wire AV/C ctype byte still 0x0D (CHANGED) across every RegNotif response; zero 0x0F INTERIM frames on the wire. M1 had no observable effect.

Why

The mtkbt outbound AVRCP response builder lives in fn 0x379e0 and dispatches inbound responses through a multi-branch ladder (a tbb [pc, r3] jump table at 0x37c3e plus several cmp / bne chains). The function writes the AV/C ctype byte to [r4, #12] from three different sites, each in a different dispatch branch:

Initial M1 scan used a too-narrow byte pattern (only matched r3 = #13 followed by strb.w r3, ...). The two r2 = #13 sites were missed. M1 patched only 0x37cca; the actual inbound dispatch for msg=544 routes through 0x37d3c or 0x37dfc, which kept emitting CHANGED.

The function 0x379e0 also writes ctype values 2, 3, 4, 5, 7 in other branches but never 0x0F (INTERIM). The stock INTERIM-emit path lives in a separate function 0xa655c (movs r1, #15; strb r1, [r4, #12] at 0xa65e2), reachable only when mtkbt's native dispatcher handles the inbound RegisterNotification itself — exactly the path the v2.0 trampoline bypasses.

Fix (M1+M1b+M1c)

Three 1-byte flips at all three CHANGED-writing sites in fn 0x379e0:

All inbound-dispatch branches now emit ctype 0x0F INTERIM. OUTPUT_MD5 for mtkbt.patched: 2f4e8116... → 7a9365e280172548429974935cfb4a29.

Open: Kia track-end position unreliability

The dual-kia-20260514-0837 capture (which was against the M1-only build that didn't reach the wire) showed Kia subscribing in the spec-correct rapid burst pattern (8 RegNotifs in < 300 ms, matching Pixel's pattern), but the user reports "track end position doesn't reliably update." Since M1 didn't change the wire bytes, this regression — if real — must be from something else in the recently flashed stack (Trace #33's T_charset → reject is the most likely candidate, since size=214 reject is visible in the Kia log's charset response). Will re-evaluate after the M1+M1b+M1c flash.

Trace #36 (2026-05-14) — Pixel-mirror emit semantics in T5 / T9

Premise

After M1+M1b+M1c flipped mtkbt's wire ctype to INTERIM on every RegNotif response, the question was whether to keep the §6.7.1-strict "single-shot CHANGED per re-registration" semantics in T5 / T9 or to mirror Pixel's "fire whenever the value changes, don't gate-clear" pattern. Two observations drove the decision:

1. The user reported Kia's track-end position not reliably updating. The root cause: T9's sub_pos gate clears after the first CHANGED, so subsequent 1Hz position ticks and track-edge transitions never emit unless the CT re-registers between every event. Kia (and most CTs) don't re-register reliably between value changes — they rely on either (a) Pixel-style continuous emits or (b) GetPlayStatus polling.
2. Pixel-as-TG's btsnoop trace shows it preempting §6.7.1: emits CHANGED unsolicited on every value change, doesn't wait for re-registration. Bolt accepts this, re-registers within ~20 ms of each CHANGED. The §6.7.1-strict reading is more rigid than the actual ecosystem expects.

Implementation (_trampolines.py)

State byte semantics shifted from single-shot to session-long. T2 / T8 INTERIM still arm the gate bytes (state[13..20]); T5 / T9 read but no longer clear after CHANGED emit. Once a CT subscribes in a session, every subsequent value change emits.

Specific changes:

• Removed 7 _emit_subscription_write(a, 0, …) clear-on-emit calls from T5 (3) and T9 (4).
• Added state[20] = sub_now_playing_content (event 0x09). T8 0x09 INTERIM arms it. T5 / T9 gate on it for the new NowPlayingContent emits.
• T5: added reg_notievent_now_playing_content_rsp + reg_notievent_pos_changed_rsp calls on every track-edge fire. Order matches Pixel's wire ordering (NowPlayingContent → PlaybackPos → TrackChanged → TrackReachedEnd → TrackReachedStart, with 0x03 / 0x04 gated on their respective sub_* bits which are typically 0 since events 0x03 / 0x04 aren't advertised).
• T9: added reg_notievent_now_playing_content_rsp call on play-status edge (paired with the existing PlaybackStatus CHANGED emit).
• T5_FRAME 820 → 824 (4-B align for 24-byte state buf); T9_FRAME 836 → 840 (same).
• State buf read size 20 → 21 in both T5 and T9.

On-disk state file grows from 20 → 21 bytes on first T8 0x09 INTERIM arm (lseek + write past EOF zero-extends; older 16-B / 20-B files degrade gracefully — short reads zero-fill the in-memory buffer).

Pixel-mirror coverage table

What we now emit, compared with the Pixel ↔ Bolt btsnoop trace:

Spec deviation

Strict §6.7.1: TG SHALL only send CHANGED in response to an outstanding INTERIM-acked registration; the registration is consumed by the CHANGED. We treat the registration as session-long instead — same deviation Pixel-as-TG ships and Bolt empirically tolerates. CTs that depend strictly on §6.7.1 would see "duplicate" CHANGEDs without re-registration between them; in the test matrix, all observed CTs accept this and update their UI on every frame.

Wire output

OUTPUT_MD5 for libextavrcp_jni.so.patched: e2d4467… → 75270ee12a36bbf553ff504746d218fd.

Blob size 3852 → 3568 B (gate-clear removals freed more bytes than the new emits added; 452 B free in the LOAD #1 padding budget).

Open

If a future CT in the test matrix rejects unsolicited CHANGED following the first INTERIM, the fallback is to clear state[13..20] on the connect_ind edge to scope subscription state to a single CT session. There's no clean trampoline hook for "new CT connected" today — would need to add an entry in mtkbt's IPC dispatch or rely on the music app to clear state files on disconnect.

Trace #37 (2026-05-14) — End-to-end mtkbt msg=544 ctype trace; M1/M1b/M1c/M1d confirmed dead; live site is 0x12244

Premise

User report after the M1+M1b+M1c flash: Bolt's metadata pane still empty; wire AV/C ctype byte 0 still 0x0D (CHANGED). User-verified deployment MD5 7a9365e280172548429974935cfb4a29 matches the patcher output — the three sites in fn 0x379e0 ARE in dead code for the msg=544 RegNotif response path. M1d (0x39714, fn 0x396d0) was a speculative second guess. User directive: "Continue tracing to completion. No more interim iterative stuff."

Method

Full radare2 walk of the AV/C wire frame builder chain in mtkbt, starting from the wire-byte write and walking up through every layer until reaching a code site whose byte-level diff matches the wire symptom (ctype = 0x0D for RegNotif responses).

End-to-end chain (verified by axt xrefs at every hop)

JNI IPC socket "bt.ext.adp.avrcp" msg_id=544 (0x220)
  → fcn.0006adec (IPC poll loop, mentioned in earlier traces)
  → fcn.00067768 (IPC dispatch by msg_id)
      [0x67776] str r3, [r0, 8]              ; msg[8] = msg+0x1c (ctxt ptr)
      [0x679da-0x679e4] if 500 <= msg_id <= 612: bl fcn.000518ac
  → fcn.000518ac (msg_id - 500 jump table, 113 cases, tbh)
      [0x518b0] ldr r4, [r0, 8]              ; r4 = ctxt (= msg+0x1c)
      msg=544 → index 44 (=544-500)
      table @ 0x518c2 + 44*2 = 0x5191a contains 0xf0
      target = 0x518c2 + 2*0xf0 = 0x51aa2
      [0x51aa2] mov r0, r4 ; bl fcn.00012478
  → fcn.00012478 (per-event RegNotif response dispatcher)
      [0x12490] ldrb r0, [r4, 5]
      [0x12492] ldrb r3, [r4, 6]              ; gate; must be 0
      [0x124a0] ldrb r3, [r4, 9]              ; r3 = ctxt[9] = event_id
      tbb on event_id-1 → per-event handler (fcn.000122cc/e4/24/54/90/270/...)
  → fcn.00012270 (one of 9 per-event response builders;
                  others 000122cc/e4/24/54/90 mirror this shape)
      bl fcn.000121d8 with r0 = unchanged arg1 (the ctxt at msg+0x1c)
  → fcn.000121d8 (RegNotif response packetFrame builder dispatch)
      [0x1222e] ldrb r1, [r4, 8]              ; r1 = ctxt[8]
      [0x12230] cmp  r1, 1
      [0x12232] bne  0x12240                  ; ctxt[8] != 1 → CHANGED branch
      ; INTERIM branch:
      [0x12238] movs r1, 0xF                  ; r1 = 0x0F (INTERIM ctype)
      ; CHANGED branch:
      [0x12244] movs r1, 0xD                  ; r1 = 0x0D (CHANGED ctype)
      [0x1224a] movs r2, 0x31                 ; r2 = PDU 0x31 (RegisterNotification)
      [0x1224e] bl fcn.00011894               ; build single-packet response
  → fcn.00011894 (single-packet response builder)
      [0x1191e] mov r6, r1 = arg2 = ctype
      [0x11922] strb r6, [r4, 0xb]            ; packetFrame[0xb] = ctype
  → fcn.0000f0bc (queues packetFrame onto conn[0x310], calls wire builder)
      [0xf11c] str.w r6, [r4, 0x310]          ; conn[0x310] = packetFrame
      [0xf198] bl fcn.0000ef08
  → fcn.0000ef08 (AV/C wire frame builder)
      [0xef5e] ldrb r2, [r5, 0xb]             ; r2 = packetFrame[0xb] = ctype
      [0xef68] strb r2, [r4, 0]               ; wire buf[0] = ctype
  → wire L2CAP/AVCTP frame → air → CT

The verified write site

File offset 0x12244, bytes 0d 21 (movs r1, 0xd). Paired INTERIM site at 0x12238 (0f 21 = movs r1, 0xf). Both branches converge at 0x1224a (movs r2, 0x31, PDU=RegisterNotification) and feed fcn.00011894 which stores r1 into packetFrame[0xb]. The packetFrame's byte 0xb is read by fcn.0000ef08 and written to wire buf[0].

The discriminator is ctxt[8] == 1:

• ctxt[8] == 1 → INTERIM (0x0F)
• ctxt[8] != 1 → CHANGED (0x0D)

Since the wire shows 0x0D, the JNI's msg=544 payload at offset 0x1c + 8 = 0x24 is reaching mtkbt with a value other than 1.

Why M1/M1b/M1c/M1d are dead

Functions fcn.0x379e0 (M1/M1b/M1c) and fcn.0x396d0 (M1d) are different code paths — likely AVCTP/L2CAP frame fragmentation or error-reply builders. They write 0x0D to [r4, #12] (offset 12, not 11) of their respective work structs. Even though the offset-12 write would land at packetFrame[0xc] (a different field, possibly packet-type), the wire-side ctype byte read by fcn.0000ef08 is at offset 0xb. M1/M1b/M1c/M1d never touch offset 0xb, never affect the msg=544 RegNotif response chain identified above.

Helper-side analysis (libextavrcp.so)

Following the chain into the JNI library that actually marshals the IPC payload: each btmtk_avrcp_send_reg_notievent_*_rsp helper (e.g. pos_changed_rsp at file 0x2588, track_changed_rsp at 0x2458) has the same shape — memset(sp+4, 0, 0x28) then writes specific bytes:

AVRCP_SendMessage then prepends a 28-byte header and ships the bytes via BT_SendMessage with msg_id = 0x220 = 544. Mtkbt's fcn.00067768 parses the IPC frame: the 40-byte payload starts at msg+0x1c (matches the JNI's sp+4 content exactly because AVRCP_SendMessage copies sp+4 → sp+0x1c of the full IPC frame).

Therefore:

• mtkbt's ctxt[7] = JNI payload byte 7 = reasonCode (0x0F or 0x0D).
• mtkbt's ctxt[8] = JNI payload byte 8 = always 0 (memset; no helper writes here).
• mtkbt's ctxt[9] = JNI payload byte 9 = event_id (matches fcn.00012478's tbb dispatch).

Stock mtkbt's discriminator at fcn.0x121d8 reads ctxt[8] and compares with 1. Off-by-one. Always misses. Always lands on the CHANGED branch. Wire always emits 0x0D regardless of the JNI's intent.

The fix (M1a / M1b)

Two-site, two-byte mtkbt patch:

After M1a + M1b, mtkbt's dispatch correctly routes the JNI's reasonCode:

• ctxt[7] == 0x0F → INTERIM branch → wire ctype 0x0F (T2 / T8 first-response arms in _trampolines.py).
• ctxt[7] != 0x0F (i.e., 0x0D from T5 / T9 edge emits) → CHANGED branch → wire ctype 0x0D.

Spec-compliant per AVRCP 1.3 §6.7.1 and matches the Pixel-as-TG btsnoop pattern: INTERIM on the first response per registration, CHANGED on subsequent value updates without waiting for re-registration. The Pixel-mirror gate semantics in _trampolines.py (T2 / T8 arm state[N]; T5 / T9 read but don't clear) drives the JNI's INTERIM-vs-CHANGED choice; M1a / M1b just routes that intent through to the wire.

Patcher state

• Stock mtkbt MD5 3af1d4ad8f955038186696950430ffda.
• Output mtkbt MD5 with M1a + M1b applied: c6ffea0082aae923ec9e7bc64293f848.
• The old M1 / M1b / M1c (sites in fn.0x379e0) and M1d (site in fn.0x396d0) have been removed from patch_mtkbt.py — they wrote to offset 0xc of unrelated work structs, never touched the msg=544 RegNotif response chain.

Verification plan

After flash:

1. mtkbt MD5 on device: c6ffea0082aae923ec9e7bc64293f848.
2. Capture dual-bolt and dual-kia btsnoop. Inspect wire AV/C ctype byte 0 on RegNotif responses. Expect 0x0F INTERIM on the first response per registration, 0x0D CHANGED on T5 / T9 edge emits.
3. Bolt: metadata pane render is the proof. Kia: continued operation, no regression on PlayStatus / position reporting.

If Bolt still doesn't render and wire ctype sequence is correct (0x0F first per event, 0x0D on subsequent edges): the issue is downstream of ctype — TRACK_CHANGED Identifier payload, GetElementAttributes attr-list shape, or PASSTHROUGH command handling. The §6.7.1 / wire-ctype chain is then fully accounted for.

Trace #38 (2026-05-14) — M1a/M1b deployed-and-verified (MD5 c6ffea00) but post-flash behaviour unchanged; M2 diagnostic patch

What happened

Post-M1a/M1b flash: device-side md5 /system/bin/mtkbt returned c6ffea0082aae923ec9e7bc64293f848 (matches patcher output). User reports Bolt's metadata pane still empty. New capture dual-bolt-20260514-1555 synced.

Forensics on the post-patch capture

Static analysis of btlog.bin from both pre-M1a/M1b (dual-bolt-20260514-1020) and post-M1a/M1b (dual-bolt-20260514-1555) captures:

• mtkbt MD5 deployed: verified by user, matches c6ffea00....
• Bytes at M1a/M1b sites in the deployed binary: e1 79 0f 29 (post-patch values) — confirmed by patcher reproduction from the same stock + matching MD5.
• btlog.bin does NOT contain raw wire bytes. Despite the file size and apparent presence of AV/C-shaped byte patterns (00 0d 00 ... 00 19 58 31 00 00 05 01), those patterns are mtkbt's internal log frame formatting (some kind of packed struct dump). Two pieces of evidence:
  1. The byte patterns are byte-for-byte identical pre- and post-patch. If they were wire bytes, M1a/M1b's effect on RegNotif responses would shift at least some ctype values from 0x0D to 0x0F.
  2. The AVRCP profile_id 0x110E (which every AVCTP-layer frame on AVRCP carries in big-endian wire order) appears only 1-3 times across the entire 2.8 MB btlog — far below the hundreds we'd expect if wire frames were logged.
• [BT]PutByte: len=N log lines in btlog.bin truncate at ~4 bytes of payload data after the length string — well before reaching the AV/C ctype byte (offset ~12-15 from L2CAP frame start, depending on AVCTP / ACL framing).
• [AVC] L2CAP_SendData channelId:68 packet.headerLen:6 packet.dataLen:N log lines exist (~80 in 1020, ~80 in 1555) — Y1 is actively sending L2CAP traffic to Bolt — but mtkbt's log format strings for these lines don't include the AV/C ctype byte. Bytes are gone by the time the log line is emitted.
• No [AVCTP] cmdFrame->ctype:%d ... log lines in either capture. That log line lives in fcn.0006d048 (cmdFrame RECV parser), only fires for AV/C frames mtkbt processes natively (not the trampoline-shortcircuited path the v2.0 design uses).

What the logs cannot tell us

Whether the wire ctype byte for the post-M1a/M1b RegNotif responses is 0x0F (M1a/M1b working) or 0x0D (M1a/M1b on a dead path). The captures don't contain wire-byte evidence.

M2 diagnostic — force-INTERIM at the wire-write site

File offset 0xef5e in fcn.0000ef08 (the AV/C wire frame builder) loads the ctype byte from packetFrame[0xb] into r2, which strb r2, [r4, 0] at 0xef68 writes to wire buf[0]. M2 replaces the load with movs r2, 0xF — every outbound AV/C frame fcn.0000ef08 builds gets wire ctype 0x0F INTERIM, regardless of what the upstream builder put in packetFrame[0xb].

Gated behind KOENSAYR_DEBUG=1 (the existing apply.bash --debug flag). Release builds don't include M2; the patcher's DEBUG_PATCHES list is only appended to PATCHES when the env var is set. Stock MD5 → M1a/M1b only output c6ffea00...; stock MD5 → M1a/M1b + M2 debug output 4321c84147b5a0a43ab028b9f6ceff1b.

Diagnostic decision tree

Build with ./apply.bash --avrcp --debug, flash, pair with Bolt, observe metadata pane:

1. Pane renders → fcn.0000ef08 IS the active wire emitter for RegNotif responses. M1a/M1b's logic is correct; some upstream divergence prevents it from biting. Pivot: find why ctxt[7] isn't carrying the JNI's reasonCode through, OR what other path supplies a different ctype value to packetFrame[0xb] before fcn.0000ef08 reads it. Roll M2 out.
2. Pane still empty → ctype is not the (sole) blocker. Wire ctype is reaching Bolt with whatever the rest of the stack produces but Bolt's pane gates on a downstream field. Investigation pivots completely — TRACK_CHANGED Identifier payload shape, GetElementAttributes attr-list ordering, PASSTHROUGH command handling, paramLen encoding. Roll M2 out.

Either branch is a productive next move, and either branch closes the "ctype on the wire" question for good.

Side effects of M2 while it's flashed

Every outbound AV/C frame fcn.0000ef08 builds emits wire ctype 0x0F INTERIM regardless of spec-mandated value:

• RegNotif responses: 0x0F INTERIM for first response and for value-change updates (the v2.0 / Pixel-mirror design already emits unsolicited CHANGEDs without re-registration, so the data flow continues).
• ACCEPTED responses (PASSTHROUGH command acks, GetCapabilities, GetElementAttributes, GetPlayStatus): ctype 0x09 → 0x0F.
• NOT_IMPLEMENTED responses (T_charset's PDU 0x17 reject): ctype 0x0C → 0x0F.
• REJECTED responses (per-CT NOT_AVAILABLE etc.): ctype 0x0A → 0x0F.

Some strict CTs may reject non-RegNotif responses with INTERIM ctype. This is acceptable for the one-flash diagnostic capture. M2 is removed after the diagnostic question is answered.

Trace #39 (2026-05-14) — M2 diagnostic outcome: chain confirmed, M1a was wrong, M1b is the correct fix

M2 outcome

Post-M2 flash (debug build, mtkbt MD5 4321c84147b5a0a43ab028b9f6ceff1b, force wire ctype = 0x0F at fcn.0000ef08 0xef5e):

• Metadata pane RENDERED on Bolt. Artist / Track / Album visible (Zebrahead track verified by the user).
• All Bolt-side PASSTHROUGH buttons broke. PASSTHROUGH responses (PLAY / PAUSE / NEXT / PREVIOUS command acks) normally carry ctype 0x09 ACCEPTED. M2 forces them to 0x0F INTERIM, which Bolt interprets as "command pending" rather than "command accepted" — UI feedback never confirms.
• Metadata did not update on track skip from the Y1. T5 / T9 CHANGED-on-edge emits normally carry ctype 0x0D CHANGED. M2 forces them to 0x0F INTERIM, so Bolt sees the same registration's "initial state" message repeatedly instead of a value-change notification — no refresh trigger fires.

Both side-effect symptoms are precisely what the spec predicts for ctype overload, confirming that:

1. fcn.0000ef08 IS the active wire-emit path for every outbound AVRCP frame, not just RegNotif responses. The chain IPC msg=544 → fcn.00067768 → fcn.000518ac → fcn.00012478 → per-event handler → fcn.000121d8 → fcn.00011894 → fcn.0000f0bc → fcn.0000ef08 is correct.
2. Wire ctype IS the blocker for Bolt's metadata pane render. Once 0x0F appeared on the wire, the pane filled in.
3. Y1's RegNotif response data payload is correct as soon as the ctype byte is. Artist / Track / Album bytes flow through GetElementAttributes and the metadata structures are well-formed; Bolt parses them happily.

What M1a got wrong

M1a (commit aae16de) retargeted the discriminator load from [r4, 8] to [r4, 7]. The premise was that the JNI helper's strb.w r7, [var_bh] stored the reasonCode at the local-buffer offset that radare2 labelled var_bh = "variable at sp+0xb". That label is misleading. The actual instruction bytes 8d f8 0c 70 decode to strb.w r7, [sp, #0xc] — sp+12, not sp+11. Combined with the helper's add r0, sp, 4; memset(r0, 0, 0x28) (40-byte buffer starts at sp+4), sp+12 maps to payload byte 8, not byte 7.

That puts the JNI's reasonCode at payload[8] = ctxt[8] (in mtkbt's view, after the ldr r3, [r0+8] → ctxt = msg+0x1c plumbing). Stock mtkbt's ldrb r1, [r4, 8] was reading the correct byte. The only bug was the comparison constant.

After M1a + M1b: dispatch reads ctxt[7] (always 0 from memset) and compares to 0x0F. Always fails. Dispatch always lands on CHANGED branch. Wire = 0x0D. Bolt's pane stays empty.

After M1b alone (revert M1a): dispatch reads ctxt[8] (= JNI reasonCode = 0x0F for T2/T8 INTERIM, 0x0D for T5/T9 CHANGED) and compares to 0x0F. Matches for INTERIM emits → wire 0x0F. Mismatches for CHANGED emits → wire 0x0D. Spec-compliant per AVRCP 1.3 §6.7.1 and matches the Pixel-as-TG behaviour.

Verified helper offset (libextavrcp.so)

For btmtk_avrcp_send_reg_notievent_pos_changed_rsp at file 0x2588:

The radare2 var labels var_9h, var_bh, var_dh, var_28h index decimal offset, hex-suffixed (so var_bh = sp + 0xb = sp + 11), but the encoded imm12 for the var_bh write is 0xc. The label and instruction disagree by one; trust the bytes.

Final patch state

Rolled back:

• M1a (was 0x1222e: 21 7a → e1 79, retargeting load to byte 7). Wrong byte.
• M2 (debug-only 0xef5e: ea 7a → 0f 22, force-wire 0x0F). Diagnostic served its purpose; no longer needed.
• Pre-existing M1 / M1b / M1c / M1d in fn.0x379e0 / fn.0x396d0 (removed in commit aae16de). Were dead code.

Stock MD5 → M1-only output: 926b8e808693a4c44028ee257b33e898.

Trace #40 (2026-05-16) — Kia button-stuck root cause: AF_UNIX SOCK_DGRAM datagram drop in mtkbt IPC

Premise

Post-2.1.0 Kia regression: play/pause button on Kia stays stuck on its initial state across multiple play/pause cycles. Combined logs from dual-kia-20260515-1841 showed T9emit pstat firing 30 times (15× PLAYING / 15× PAUSED, clean alternation) — Y1 detects every edge correctly. Yet Kia's UI doesn't refresh.

T9 → wire delivery rate is ~14%

Added T8reg ev=%02x debug log (commit 446baa8) at the head of _emit_t8 to count incoming RegisterNotification PDUs from Kia.

dual-kia-20260515-1933 capture (5-min Kia session):

After fixing tools/btlog-hci-extract.py (commits 1de1d5f + 2bc680c) to handle the new firmware's record header layout, wire-side decode of the same capture:

So out of 28 trampoline T9emit pstat attempts, only 4 PLAYBACK_STATUS_CHANGED CHANGED frames reached the wire. Kia subscribes to event 0x01 only twice in the entire 5-minute session — explaining why most CT-side updates never happen — but more importantly, 86% of our trampoline-side emits for event 0x01 are silently dropped between T9 and the wire.

First false hypothesis: AVRCP TG one-shot transaction recycle (REFUTED)

Initial reading of BT_SendMessage at libextavrcp.so:0x1840 found a cbz r6, 0x18bc guard at offset 0x1870 that drops the frame silently when conn[8] (the field at offset 8 of the conn struct passed in) is zero. Hypothesised the AVCTP TG state machine was recycling the per-transaction conn struct after each CHANGED, so subsequent T9 emits would hit a cleared conn[8] and drop.

Added T9connfd=%08x log (commit eeeb49c) at the top of T9's play_status emit path to capture r4[8] = conn[8] directly.

In parallel, RE'd enableNative at libextavrcp_jni.so:0x48d4:

0x48fa: bl 0x36c0                  → r5 = struct ptr (the SAME 0x36c0 T9 uses)
0x491a: blx socket_local_server    → r0 = local server FD  
0x4920: str r0, [r5, 0x14]         → struct[0x14] = server FD
0x494a: blx socket(AF_UNIX, SOCK_DGRAM, 0)
0x4952: str r0, [r5, 0x10]         → struct[0x10] = AF_UNIX SOCK_DGRAM FD

And initializeNativeObjectNative at 0x3fd4: calloc(1, 28) → 28-byte struct → stored as a Java long field via vtable-resolved SetLongField (vtable offset 0x1b4).

So 0x36c0 returns a persistent 28-byte struct that initializeNativeObjectNative allocates once (at service construction) and enableNative populates. conn = struct + 8, conn[8] = struct[0x10] = AF_UNIX socket FD. The FD is session-long — opened once when the AVRCP service enables, valid until disable.

Therefore conn[8] is non-zero throughout the BT pairing session. BT_SendMessage's cbz r6 guard never trips for normal operation. The drop can't be there. Hypothesis refuted before the connfd capture even came back (although the log will still confirm it empirically).

Real hypothesis: send() → mtkbt IPC kernel-level datagram drop

The conn struct's FD is AF_UNIX SOCK_DGRAM (socket(1, 2, 0) — domain=1=AF_UNIX, type=2=SOCK_DGRAM). Datagram sockets are unreliable: if the receive side's queue is full, the kernel drops the packet silently. send() returns -1 with EAGAIN or ENOBUFS depending on socket flags.

mtkbt is the recv side. It's concurrently processing:

• A2DP audio streaming (~50ms-cadence ACL frames at ~736 B each, saturating the BT chip UART)
• Inbound AVCTP control frames (PASSTHROUGH, GetPlayStatus polls, GetElementAttributes, RegisterNotification)
• Outbound AVRCP responses

When T9 fires 28 times in a 5-minute window — many bursts triggered by playstatechanged broadcasts that happen 1-3 in rapid succession on each play/pause toggle — the mtkbt recv queue saturates and 24 of those 28 frames get dropped at the kernel layer. send() returns -1, BT_SendMessage returns -1, AVRCP_SendMessage logs "ignore index:%d total:%d" and returns 1, T9 has no idea anything went wrong.

The wire-side counts confirm this delivery profile:

• 4 successful event 0x01 CHANGED sends — matches roughly "first CHANGED of each subscription burst plus a couple that snuck through".
• 17 successful event 0x05 POS_CHANGED sends — pos_changed fires at our 1 Hz cadence, much less bursty than pstat, so most go through.
• 7 successful REACHED_END/START — same low cadence, mostly go through.

The drop pattern is rate-limit-driven, not subscription-driven.

Where the FD lives

r7[0x19] write at 0x3cf2 is strb.w ip, [r7, 0x19] where ip was loaded from [lr+1] after lr = pc + <const> resolves to a string. So the transId stored is a constant byte from .rodata, not the per-CT inbound transId. This means stock notificationPlayStatusChangedNative always emits with the same fixed transId — a separate spec-compliance concern from the drop question, but worth noting.

Diagnostic plan (next capture)

T9connfd=%08x log will show — definitively — whether conn[8] is zero on dropped attempts. Three outcomes:

Spec-compliance angle (per feedback_avrcp13_only_scope)

AVRCP 1.3 §6.7.1 is explicit: CT MUST re-RegisterNotification after each CHANGED. Kia subscribes once at session start, once mid-session, and that's it. CT-side spec violation. But Y1's TG is also generating ~28 CHANGED frames per 5-minute session for event 0x01 — way more than the 2 the CT subscribed for. With the AVRCP 1.3 one-shot model, the spec-correct TG would emit CHANGED only 2 times (one per subscription). Our session-long gate semantics (state[14]=1, never cleared) emit on every edge — which would be fine if the AVCTP layer had the buffer space, but the AF_UNIX SOCK_DGRAM IPC saturates first.

A spec-compliant fix path: implement strict §6.7.1 one-shot in T9 (clear state[14] after each CHANGED emit, re-arm only on next T8 INTERIM). That brings our wire emit count down from 28 to 2 per Kia session — eliminating the IPC overflow and matching what Kia actually expects. The trade-off: the 26 dropped emits we currently make were "best-effort" attempts to compensate for non-compliant CTs; switching to strict one-shot would relinquish that compensation. But empirically the 26 attempts don't reach the wire anyway, so we lose nothing concrete by becoming spec-compliant.

Per-event transId database

At libextavrcp_jni.so:0x71f0, getSavedRegEventSeqId(eventId):

cmp r0, 0xf
bhi return_zero
ldr r3, [pc + 0x60bb]    → r3 = &g_avrcp_req_event_database
add r3, pc
ldrb r0, [r3, r0]         → r0 = g_avrcp_req_event_database[eventId]
bx lr

g_avrcp_req_event_database is a 16-byte global table (one byte per event_id, indices 0..15) at VA 0xd2b5 in .bss. Sister function saveRegEventSeqId(eventId, seqId) at 0x5ee4 writes to it from the inbound RX path when CT sends a RegisterNotification.

The stock notificationPlayStatusChangedNative (at 0x3cdc) reads this DB to populate conn[0x11] (= AVCTP transaction label) before calling the response builder:

ldr.w lr, [pc + ...]       ; lr = const offset, resolves to 0xd2b5 = g_avrcp_req_event_database
add lr, pc
ldrb.w ip, [lr, 1]         ; ip = g_avrcp_req_event_database[1] (event 0x01 = PLAYBACK_STATUS)
strb.w ip, [r7, 0x19]      ; r7[0x19] = conn[0x11] = transId

Our T9 trampoline (entered via b.w T9 at 0x3c88, the first instruction of notificationPlayStatusChangedNative) bypasses this stock prolog — we don't write conn[0x11] either. So T9 emits CHANGED with whatever transId the conn struct already held from the last stock-prolog or inbound-RX path execution. In practice that's still correct (= the CT's last subscription transId), but it's an implicit dependency that should be made explicit if T9 is ever entered before any inbound RX path has run.

Struct layout (28-byte conn struct from calloc(1, 28))

BT_SendMessage reads only conn[8] (FD) from the conn struct. btmtk_avrcp_send_*_rsp builders read conn[0x11] (transId) for the AVCTP byte. Everything else is local-buffer scratch.

Strict-gate revert history

The "session-long subscription gate" semantics that produce 28 T9 emit attempts per 14 play/pause cycles weren't always in place. Project history:

So the strict-gate flip-flop was tried-and-reverted within hours on 2026-05-15. The current state is session-long, justified empirically by some CTs not re-registering. But Trace #40's finding — that 24/28 emits drop at the IPC layer anyway — means session-long's "compensate for non-compliant CTs" doesn't actually compensate. Strict §6.7.1 (re-introducing 6503c87) would emit at most 2 CHANGED per Kia's 2 subscriptions for event 0x01, and all 2 would survive the IPC layer (low burst rate, no buffer overflow).

Why session-long isn't actually compensating

The intuition behind session-long: "if a CT doesn't re-register but expects more updates (1.4-style sticky semantics), keep firing CHANGED." Empirically:

• Kia subs 2× for event 0x01, gets 4 CHANGED on the wire (≈ 2× INTERIM-bonus per sub). Button updates ~2 times across the session.
• Strict-gate would emit exactly 2 CHANGED on the wire (one per sub). Button still updates 2 times.

Either mode results in the same Kia UI behaviour, because Kia's button updates are bounded by Kia's subscription count, not our CHANGED count — Kia treats unsolicited CHANGEDs (without a matching pending NOTIFY) as protocol noise.

The 14% delivery rate IS the IPC-saturation symptom; it's not a separate failure — the session-long firing rate is what fills the IPC queue. Strict-gate would emit at the natural CT-driven rate, which is well within IPC throughput.

Spec-compliance fix

Re-introduce the strict §6.7.1 gate-clear:

• T9 PLAYBACK_STATUS_CHANGED CHANGED: clear state[14] after emit.
• T9 PLAYER_APPLICATION_SETTINGS_CHANGED CHANGED: clear state[15] after emit.
• T9 PLAYBACK_POS_CHANGED CHANGED: clear state[13] after emit.
• T9 NowPlayingContent CHANGED: clear state[20] after emit.
• T5 TRACK_CHANGED CHANGED: clear state[16] after emit.

Existing implementation in 6503c87 can be cherry-picked; the _emit_subscription_write helper already supports the fd_reg parameter for callee-saved register choice.

Trade-off: with strict gate, a CT that really does treat sub as sticky (doesn't re-register) would receive only the first CHANGED. We'd lose that CT's compensation. But the CT test matrix doesn't include any such CT (Kia, Bolt, Sonos, Pixel-mirror all spec-compliantly re-register). And empirically the IPC drop kills the sticky-CT compensation anyway.

What the upcoming T9connfd capture confirms

Three possible outcomes; this RE narrows it to one.

Outcome 1 is the predicted result. The companion T9rsprc=%u log (commit baaf496) captures the response builder's return value: 0 = wire frame sent, 1 = send() returned -1 (silent drop). Together they pin the drop site to the kernel-level datagram queue.

dual-kia-20260515-2215 capture (commit f8fe647) — empirical results

The full debug-log + btlog capture brought back definitive data that overturns the AF_UNIX SOCK_DGRAM IPC-drop hypothesis:

Interpretations confirmed:

1. conn[8] is session-long FD=47. Confirms enableNative RE: AF_UNIX SOCK_DGRAM FD opened once at AVRCP service enable, persistent. The cbz r6, 0x18bc guard in BT_SendMessage never trips.
2. AVRCP_SendMessage always returns 0 (success). send() on the AF_UNIX SOCK_DGRAM socket succeeds for all 44 emit attempts. The kernel queues every datagram into mtkbt's recv socket buffer.

Hypothesis overturned: the drop is NOT at the kernel datagram queue. mtkbt receives every datagram. mtkbt itself drops 36 of 44 frames before forwarding to the BT chip.

Real drop site: mtkbt-side AVRCP TG state machine

mtkbt's IPC handler reads our AVRCP response datagram, runs it through the chain documented in Trace #34:

IPC msg=544 → fcn.00067768 → fcn.000518ac → fcn.00012478 → per-event handler
   → fcn.000121d8 → fcn.00011894 → fcn.0000f0bc → fcn.0000ef08 (UART wire write)

Somewhere in that chain (most likely fcn.000121d8 or fcn.00011894 — the ones nearest the wire-write) mtkbt checks per-event AVRCP TG state ("is there a pending RegNotif sub for event X?") and silently drops the frame if no match. This is mtkbt enforcing AVRCP §6.7.1 strict semantics on its side, regardless of what our trampolines send.

Fix architecture (corrected)

The strict-gate cherry-pick (6503c87) would not change wire-side behaviour — mtkbt is the gate, not our trampolines. Reducing our emit rate to spec-compliant levels is still good hygiene (less pointless IPC traffic), but it doesn't unstick Kia's button.

The real fix paths are:

1. Patch mtkbt to NOP its drop-gate. Same shape as the M1 patch — find the byte sequence in fcn.000121d8 or fcn.00011894 that gates wire emission on TG-side pending sub state, and either NOP the check or rewrite the cmp constant. Precedent exists; this is the same RE territory as Trace #34/35/36.
2. Synthetic re-arm via IPC. Before each T9 CHANGED emit, send an additional IPC message that emulates "CT just sent RegisterNotification(event=X, transId=Y)" so mtkbt allocates a fresh pending response slot. mtkbt's chain accepts our subsequent CHANGED, forwards to wire. Requires understanding the IPC msg-id for inbound RegNotif from CT direction (different from our outbound msg=544).

(1) is the cleaner fix once the byte-level gate is located.

Why the IPC-drop hypothesis was wrong

The model I derived from RE'ing BT_SendMessage was correct as far as the libextavrcp.so layer goes — cbz r6, 0x18bc does drop frames if conn[8]==0, and send() failures do propagate through AVRCP_SendMessage's cmp r0, 0; bge return; movs r0, 1. Both observations are accurate.

But neither matches the empirical data. The capture shows neither cbz r6 trip (FD always non-zero) nor send() failure (rsprc always 0). The drop is downstream of send(), in mtkbt — a layer the libextavrcp.so RE doesn't see.

The T9connfd= and T9rsprc= instrumentation was load-bearing here: without it, I would have committed to the wrong fix layer based on plausible-but-wrong RE.

Additional context: 18% delivery is system-wide, not pstat-specific

Same dual-kia-20260515-2215 capture across all events:

The pattern isn't strict §6.7.1 one-shot (would predict 2 wire CHANGED for event 0x01 = matching 2 subs; we see 8). It's not TL contention (all wire frames carry TL=0; AVCTP allows queueing). It's not IPC overflow (T9rsprc=0 always). It's not cbz guard (T9connfd=0x2f always non-zero).

The empirical signature is rate-limit-shaped — roughly the same ~10-20% delivery across event types, regardless of how many subs the CT issued or how many emits we attempted. Most likely candidates for the actual gate:

1. mtkbt has an internal per-event rate limit (e.g., max 1 wire frame per N ms per event_id) to prevent flooding the BT chip's AVCTP outbound queue. Our session-long T9 emits at the music-app's broadcast rate (multiple per play/pause cycle), exceeding the limit.
2. mtkbt has an AVCTP transaction-state queue (limited entries) and drops frames when the queue is full. Our trampolines emit too fast for the queue to drain.
3. mtkbt's mPlayStatus / mTrackInfo dedup at the per-event handler — checks "is the value being emitted different from the last one I sent on the wire?" and drops if not. (Less likely given pos varies continuously.)

Either way, the drop is inside mtkbt's TG state machine, downstream of send() / IPC recv. Finding the exact byte-level gate requires RE'ing mtkbt's per-event handlers (fcn.0x122cc for event 0x01, fcn.0x12354 for event 0x05, etc.) and the wire-write chain (fcn.0xf0bc → fcn.0xef08).

Open RE next steps

• Find the byte sequence in mtkbt's chain that gates wire emission. Candidate sites:
  • fcn.0x12478 per-event dispatch entry
  • fcn.0x121d8 ctype dispatch (the M1 patch site)
  • fcn.0x11894 middle-layer (calls fcn.0xf0bc)
  • fcn.0xf0bc writes to [r4, 0x310] (look like queue-manager) and checks [r4, 0x528] — possible drop check
  • fcn.0xef08 wire-write last layer
• Empirical verification: if mtkbt has a debug build / tracing that we can enable, we could see the drop directly.
• Alternative: instrument our trampolines to send ZERO emits for a period and observe whether mtkbt stops sending wire CHANGEDs immediately or has a queued-up backlog. Tells us if the gate is at IPC-queue level or per-frame.

Strategic update

The strict-gate cherry-pick (6503c87) is not the fix for this regression — mtkbt drops at its own layer regardless of our emit rate. But strict-gate is still good hygiene: emitting ~28 attempts when mtkbt only forwards 4 wastes IPC bandwidth and slows the response builder under play/pause bursts. Worth applying eventually for spec correctness, but it doesn't unstick Kia's button.

The unstick fix has to be at the mtkbt layer — same precedent as the M1 patch family.

Drop site located: two-gate chain inside mtkbt's chip-write path

After mapping the full chain fcn.0xf0bc → fcn.0xed50 → fcn.0x6d048 → fcn.0x6df20 → fcn.0xae5e4 → fcn.0xae418, the actual drop sites are two consecutive gates that both report "success" upward while silently bypassing the wire-write build:

Gate 1 — fcn.0x6d048 at file offset 0x6d06e:

0x6d05c: cmp r4, 0
0x6d05e: beq 0x6d0dc          ; return 0x12 if r4 == 0 (no ctx)
0x6d060: ldr r0, [pc + ...]   ; r0 = &g_active_conn_list
0x6d062: mov r1, r4            ; r1 = conn
0x6d066: ldr r0, [r0]
0x6d068: bl 0x6ccdc            ; r0 = list_contains(list_head, conn)
0x6d06c: cmp r0, 0
0x6d06e: beq 0x6d0e0           ; *** drop if conn not in list, returns 0xd ***
0x6d070..0x6d0d0: build wire frame at conn[0xc8..0xd4]
0x6d0d2: mov r0, r4
0x6d0d8: b.w 0x6df20            ; tail-call to gate 2

fcn.0x6ccdc is a doubly-linked-list contains primitive. Returns 1 if r1 (conn pointer) is in the linked-list anchored at r0. The list is *(0xf99XX) (mtkbt's "active outbound chip-write channels"); items get added via fcn.0x6cd18 and presumably removed when a chip-write completes (or when the L2CAP channel state transitions).

Gate 2 — fcn.0x6df20 at file offset 0x6df3a:

0x6df20: push {r4, lr}
0x6df28: mov r4, r0
0x6df2a: ldrb r3, [r0, 0xf2]    ; r3 = ctx[0xf2] = "chip-write busy" flag
0x6df36: ldrb r3, [r4, 0xf2]    ; r3 = ctx[0xf2] (re-read after log)
0x6df3a: cbnz r3, 0x6df52        ; *** drop if busy flag set, returns 0xb ***
0x6df3c..: set ctx[0xf2] = 1 (mark busy), tail-call to fcn.0xae5e4 (chip send)

ctx[0xf2] is set to 1 at 0x6df42 (just before the actual chip-send tail-call) and cleared to 0 at 0x6da10 (inside the send-completion handler at fcn.0x6d9b8). Between set and clear, any new emit attempt sees the flag and drops.

Why fcn.0xf0bc's queue doesn't catch this

fcn.0xf0bc's "queue path" at 0xf210 triggers on ctx[0x310] != 0 OR ctx[0x528] != 0. Neither corresponds to ctx[0xf2]:

Short packets (PSTAT, REACHED_END/START — anything with single-AVCTP-fragment payload) take fcn.0xf0bc's fast path (since ctx[0x310] is briefly set/cleared per-call and ctx[0x528] never sets for non-fragmented frames). The fast path calls fcn.0xed50 → fcn.0x6d048 → fcn.0x6df20. Gate 2 then drops if ctx[0xf2] is set — which it is, whenever the chip-write of the previous packet hasn't completed.

The empirical pattern matches: ~10-20% delivery = ratio of time the chip-write completes before the next emit arrives, vs time the busy flag is set. Concurrent A2DP saturates the chip-write queue, so ctx[0xf2] stays set most of the time.

Why the EXISTING M1 patch doesn't help

M1 (0x12230: cmp r1, 1 → cmp r1, 0x0F) is upstream of these gates — it fires at fcn.0x121d8 which dispatches INTERIM vs CHANGED ctype before reaching fcn.0x11894 → fcn.0xf0bc. M1 ensures correct ctype on the wire when the frame reaches the wire, but doesn't change the drop characteristics.

Two candidate patches

P-MTK-1 — NOP gate 1:

Removes the list-contains check. Wire frame is built and tail-call to gate 2 always happens. Doesn't fix the actual problem (gate 2 still drops), but eliminates the first early-exit.

P-MTK-2 — NOP gate 2:

Removes the busy-flag check. Chip-send is always called, even if previous send hasn't completed. HIGH RISK — could:

• Corrupt mtkbt's per-channel chip-write state
• Cause overlapping UART writes (depending on what fcn.0xae5e4 / fcn.0xae418 actually do)
• Hang mtkbt if the chip-side queue overflows

P-MTK-3 (preferred) — Replace gate 2 with a queue insert:

Rather than NOP, redirect the drop to fcn.0x6cd18 (list-add to a pending queue). Inserts our packet into a per-conn pending list when chip is busy; queue gets drained by the completion handler when it clears ctx[0xf2].

The fcn.0xf0bc queue path (0xf210) is exactly this shape, but at a higher layer. The proper fix moves the queueing down so it covers short-packet emits too. This would be a multi-instruction patch, larger than M1.

Cross-reference for fix design

Strategic recommendation

P-MTK-2 (NOP gate 2) is empirically the simplest test of whether bypassing the busy flag fixes the drops. Risk is real but bounded — worst case mtkbt becomes unstable for ~10 seconds until next reboot, which is acceptable for a diagnostic patch.

P-MTK-3 (proper queueing) is the production fix but requires:

1. Identifying the queue node structure expected by fcn.0x6cd18
2. Inserting allocator + queue-add code at gate 2
3. Verifying the completion handler drains correctly

Order of work:

1. Apply P-MTK-2 as --debug-only diagnostic patch.
2. Capture: if PSTAT delivery jumps to ~100%, gate 2 is the right target.
3. Design P-MTK-3 if (2) confirms.

Correction: P-MTK-2 (NOP gate 2) is unsafe — would corrupt state

Closer look at fcn.0xae5e4's prolog shows it writes the packet pointer to ctx[0x10] (relative to its own arg0, which is ctx_orig + 0x14 per fcn.0x6df20:0x6df46):

0xae5e8: mov r4, r0           ; r4 = ctx_orig + 0x14
0xae5ea: ldrh r0, [r0, 0x60]  ; r0 = ctx[0x60] (MTU)
0xae5ee: mov r5, r1           ; r5 = packet
...
0xae60a: str r5, [r4, 0x10]   ; ctx_orig[0x24] = packet

If we NOP gate 2 and two fcn.0xae5e4 calls happen concurrently with the same ctx_orig, both write to ctx_orig[0x24]. The second overwrites the first → first packet is silently lost AND the in-flight chip-write may be confused mid-transaction. This isn't a fix — it just moves the drop one layer deeper while corrupting state.

So the candidates collapse to:

The Y1-side options are simpler and don't risk mtkbt instability. Trade-offs:

• P-Y1-rate-limit: limits emit rate to match mtkbt's chip-write capacity. Requires clock_gettime in the trampoline (precedent: T6 / T9 already use it for live-position math). Set rate to ~1 emit per 100-200ms — enough to clear chip-write busy between attempts but fast enough to feel responsive.
• P-Y1-strict-gate: cherry-pick 6503c87. Emits one CHANGED per CT subscription, full stop. For a CT that re-registers at 1 Hz (Bolt, Sonos): 1 CHANGED per second. For Kia (re-registers ~2× per 5 min): 2 CHANGEDs per 5 min. Spec-correct but Kia gets very few updates.

A hybrid is possible: re-introduce strict-gate BUT also rate-limit. For non-re-registering CTs, fire emits at 1/sec for the first ~5 seconds after a transition (giving the CT time to notice and re-subscribe), then quiesce.

This is now a design decision rather than a discovery question. The RE has located the drop definitively; the fix shape depends on which CTs we want to optimize for and what protocol-deviation cost we'll accept.

Open: P-MTK-3 implementation sketch

If the user prefers a mtkbt-side fix:

1. Replace cbnz r3, 0x6df52 (gate 2) with bne <queue_insert_thunk>. The thunk:
   • Loads the per-conn pending queue head from ctx[0xb0] (offset TBD by RE)
   • Calls fcn.0x6cd48 to add the packet
   • Returns 0xb (same as drop) so caller's bookkeeping works
2. Patch fcn.0x6d9b8 (the send-completion handler that clears ctx[0xf2]) to drain the per-conn queue when ctx[0xf2] clears.
3. Allocate the per-conn queue head in stock data — likely possible via mtkbt's existing list-init infrastructure.

This is ~50-80 bytes of injected code, similar in scope to extended_T2. Likely fits in mtkbt's padding regions but needs verification.

Trace #40 implementation (2026-05-16)

Both candidate fixes from the strategic analysis landed in two commits:

Commit 00f4817 — mtkbt M2 / M3 (P-MTK-3 simplified):

Net effect: every T9/T5 CHANGED emit reaches the wire. 100% delivery instead of the ~18% baseline. Stock 3af1d4ad8f955038186696950430ffda → Output 2b0bffeb6d29ff2ba75cf811688ec0ef.

Rationale for the M3 NOP-the-SET (not NOP-the-CHECK): two concurrent emits inside fcn.0xae5e4 would race on ctx_orig[0x24]. But mtkbt's IPC dispatcher is single-threaded, and the downstream chain fcn.0xae5e4 → fcn.0xae418 → fcn.0x50918 → mtk_bt_write is a synchronous blocking UART write. So no concurrent emits actually materialise; the flag was a safety check for a race that can't happen under mtkbt's threading model.

Commit 7acd7bd — T5+T9 §6.7.1 strict gate clearing (P-Y1-strict-gate):

Re-applied the strict-gate clears from commit 6503c87 (which was bare-reverted in b1c15a9 on the original day). Trace #40 made it clear that the revert was misdirected — Kia's stuck button wasn't caused by strict-gate's lower emit rate, it was caused by mtkbt silently dropping ~80% of CHANGED emits regardless of emit rate.

With M2/M3 fixing the drops, strict-gate becomes a pure spec-compliance win: emits exactly one CHANGED per CT-re-register, no spam, no IPC saturation. Wire-side cadence becomes min(TG_tick_rate, CT_re-register_rate).

T5's POS_CHANGED on track edge intentionally doesn't clear (T9's PositionTicker owns the re-register loop). T5's NowPlayingContent and TRACK_REACHED_END/START also don't clear (the gates are rarely armed by CT test matrix; extra clears would be ~56 B of dead code each).

Release blob: 3552 → 3784 B. Stock libextavrcp_jni.so fd2ce74db9389980b55bccf3d8f15660 → Output d803f42c973bf9539f4d03ccb658cab3.

Combined behaviour (M2 + M3 + strict-gate)

For each CT in the test matrix:

For Kia, post-fix wire count is LOWER (2 vs 8) but every CHANGED is guaranteed delivery and spec-correct. If Kia's button responsiveness depends on the CHANGED count rather than the re-register matching, this would be a regression. If Kia's button responsiveness depends on spec-correct one-shot semantics (i.e., it ignores unsolicited CHANGEDs anyway), the post-fix behaviour is equivalent.

If Kia turns out to need MORE CHANGEDs than its own re-register rate provides, the next iteration would be P-Y1-rate-limit — emit at ~1/sec for ~5 seconds after a state edge, then quiesce. Falls between strict-gate and the pre-revert "session-long forever" behaviour.

Closing this trace pending empirical validation of Kia post-flash. The discovery question (where does the drop happen?) is answered; the fix question (which combination is best?) requires CT-side observation.

Trace #40 closure (2026-05-16) — car-test validated

dual-bolt-20260516-0810 (subscription-driven CT) + dual-kia-20260516-0808 (polling-driven CT) + driver-seat verification:

The Kia path that works is pure polling (T6 GetPlayStatus + GetElementAttributes), independent of every notification-side patch landed in this trace. Strict-gate is irrelevant for Kia because Kia never subscribes. M2/M3 are irrelevant for Kia because Kia's polled responses don't go through the outbound-frame builder gates (those gate only TG-initiated CHANGED frames, not synchronous responses to CT requests).

The 18% delivery rate observed throughout Trace #40 is most likely a btlog sampling artifact, not a real drop. Empirical proof in dual-sonos-20260516-0758: Sonos re-registered ev=05 73 times, which per §6.7.1 means Sonos received 73 CHANGED frames. btlog visible: 9. → btlog captured ~12% of wire traffic. The "drop" measured by expected_emit_count / wire_frame_count is the inverse of btlog's sampling rate, not the wire delivery rate.

Implications for the M2/M3 patches: most likely no-ops. The chip-readiness list-check (gate 1) and chip-busy flag (gate 2) in mtkbt's outbound-frame chain were rejecting frames that btlog wasn't capturing anyway; the actual wire delivery was already ~100% via paths btlog under-samples. M2/M3 don't regress anything (the chain is sync, single-threaded — no race) but they remove safety margins that weren't measurably failing. Keeping them in the release: they're verified harmless, they're documented in PATCHES.md, the docs are honest about the sampling-artifact theory, and reverting would require another patcher MD5 update.

Implications for strict-gate: validated correct for subscription-driven CTs (Bolt, Sonos, Pixel-mirror), irrelevant for polling-driven CTs (Kia in observed sessions). The "Kia gets only 2 CHANGED" concern was based on a metric (wire-visible CHANGED count) that's a btlog-sampling artifact; Kia's actual UI behaviour in this session was driven by polling, not by the CHANGED count.

Trace #40 closed: the Kia stuck-button regression resolved by the combined work even though the exact causal mechanism remains under-determined (likely a mix of TrackInfoWriter fast-path improvements + strict-gate hygiene + the position-fix work). Future Kia-specific debugging should focus on T6 freshness (file[792] / file[780-787] / file[776-779]) since that's the wire path Kia actually uses.

Trace #41 (2026-05-16) — Subscription-class CT metadata-pane regression: twin outbound-frame builder Path B is unpatched; M4 fix

Symptom. A subscription-class CT (Chevrolet Bolt EV — see dual-bolt-20260516-1453 for the load-bearing capture) displayed metadata for only 3 of 32 tracks played across a ~2.5 min driver-seat session. Y1 music app behaved correctly (track changes, play/pause, all logged). The 3 displayed tracks were not adjacent in playback order, not at session boundaries, and the metadata-success/failure cadence didn't correlate with screen wake events (user explicitly verified by waking the screen mid-session on failed tracks). PASSTHROUGH worked on every press. Title / Artist / Album / Genre / track-number / duration all appeared when they appeared.

Hypotheses ruled out.

• Screen-off / Y1Bridge cascade. Refuted by user waking the Y1 screen on a non-displaying track and seeing no metadata update.
• AVRCP 1.3 attribute corruption. The 3 displayed tracks contained varied attribute lengths, characters, and zero-pad alignment; nothing distinguished them structurally from non-displayed tracks.
• Path-A (M2/M3) regression. msg=540 GetElementAttributes IPC emits → wire TX frames mapped 3:3 — every msg=540 reached the wire. The 3 displayed tracks were each emitted via msg=540 opportunistically (not via subscription).
• MtkBt.odex cardinality gates. Already NOP'd; MMI_AVRCP logged 1,542 ACTION_REG_NOTIFY ... cardinality:0 lines confirming the JNI was firing the natives but the Java callback table was empty (downstream of the root cause, not the root cause itself).
• Stale btlog sampling artifact (Trace #40 closure pattern). Refuted by direct correlation between IPC emit count and MMI_AVRCP cardinality:0 log volume — the missing wire frames are real, not a sampling artifact, because subscription confirmation never happens.

Wire-level evidence. In the same dual-bolt-20260516-1453 capture:

Static dispatch trace. fcn.0xf0bc (outbound AVRCP frame dispatcher) splits at ldrb r3, [r6, #9]; cbz r3, 0xf186:

• r3 != 0 (byte[9] != 0) → Path A: fcn.0xed50 → fcn.0x6d048 → fcn.0x6df20 → fcn.0xae5e4 L2CAP_SendData. This is the fragmented multi-frame send path; M2 NOPs fcn.0x6d048's list-contains drop gate at 0x6d06e, M3 NOPs the chip-busy SET in fcn.0x6df20 at 0x6df42. Carries msg=540-class responses.
• r3 == 0 (byte[9] == 0) → Path B: fcn.0xef08 → fcn.0x6d0f0 → b.w 0xae5e4 L2CAP_SendData (tail-call direct, no fcn.0x6df20 intermediate). This is the short single-PDU send path. Carries msg=544-class responses. Unpatched before this trace.

Empirical confirmation that the JNI marshaller writes byte[9]=0 for msg=544 and non-zero for msg=540: log analysis of the dual-bolt-20260516-1453 capture shows perfect path separation by IPC msg field — every msg=544 IPC emission is followed by a Path-B selection in mtkbt, every msg=540 IPC emission is followed by a Path-A selection.

Structural identity of the two builders. fcn.0x6d0f0 is byte-for-byte structurally identical to M2's fcn.0x6d048:

Fix — M4. NOP beq 0x6d19c at 0x6d116 (2 bytes, 41 d0 → 00 bf). After M4, fcn.0x6d0f0 unconditionally builds the wire frame and tail-calls b.w 0xae5e4. No M3-analogue is needed on Path B because fcn.0x6d0f0 skips fcn.0x6df20 entirely (the chip-busy SET only exists in fcn.0x6df20).

Safety. Same reasoning as M2 — the list-contains state was a chip-readiness heuristic, not a correctness check. mtkbt's IPC dispatcher is single-threaded, fcn.0xae5e4's downstream chain (fcn.0xae418 → fcn.0x50918 → mtk_bt_write) is synchronous blocking UART write, no concurrent emits race on per-channel state.

Why subscription-class CTs disengage. AVCTP V13 §3.3.5 specifies a 3 s response timeout per outstanding transaction. A subscription-class CT (e.g. Bolt) sends RegisterNotification COMMANDs for ev=01 PLAYBACK_STATUS_CHANGED, ev=05 PLAYBACK_POS_CHANGED, ev=08 PLAY_TRACK_REACHED_END, ev=0A NOW_PLAYING_CONTENT_CHANGED on initial AVRCP TG engagement. Without INTERIM responses landing within the 3 s window, the CT retries each subscription. After several retries (CT-implementation-specific, observed 7-14 in the Bolt capture) the CT disengages AVRCP TG and gives up on subscription-based updates entirely. From that point on, only opportunistic msg=540 GetElementAttributes responses driven by track changes reach the CT — explaining the "3 of 32 tracks displayed" pattern (whichever 3 tracks triggered a msg=540 emit in the narrow window before the CT disengaged).

Why polling-class CTs were unaffected pre-M4. A polling-class CT (e.g. Kia) does not depend on RegNotif subscriptions at all — it polls GetPlayStatus + GetElementAttributes (both msg=540-class) at its own cadence. Path A was patched; Path B drops were invisible to polling CTs. This is why Trace #40 closure observed Kia working fine on the same firmware that left Bolt broken — they exercise different builders.

Why this wasn't caught in Trace #40. Trace #40 derived M2/M3 from observed wire-side drops on msg=540 Path A under a different CT class. The msg=544 Path B path was never explicitly profiled in #40 because the captures used for #40 were polling-class CTs (Kia) and a subscription-class CT (Sonos) on a build where msg=544 delivery was confounded by the cardinality-0 gate (which was a separate bug fixed elsewhere). With msg=544 actually reaching the IPC layer in current builds, the Path B drop became observable.

Confidence. High on byte-level mechanism (the fcn.0xf0bc dispatch + the structural identity of the two builders is direct static analysis, independent of any wire-side measurement). High on Bolt as primary affected CT (load-bearing capture). Medium on whether other subscription-class issues (notably the Sonos Album metadata regression observed in dual-sonos-postflash) are also resolved by M4 — Sonos's msg=544 delivery rate is higher in the current captures (~25-37% vs Bolt's ~6%), so Sonos may have a separate root cause. Recommend treating Sonos Album as a follow-up after M4 hardware validation.

Status: Patch staged in src/patches/patch_mtkbt.py. New OUTPUT_MD5 = a10ca9636417a0ed71495dfa11b5eff0. Pending hardware validation on a subscription-class CT.

Trace #42 (2026-05-16) — Static audit for additional silent-drop gates in mtkbt outbound paths

Goal. After M4 landed (Trace #41), do a static-only sweep of every outbound-frame builder, dispatcher, and L2CAP send wrapper in mtkbt to find any other gates with the M2/M3/M4 signature: a conditional that returns an error code, doesn't log surface-visibly, and the caller treats the return as drop-and-forget rather than retry-or-error. Stock binary mtkbt MD5 3af1d4ad8f955038186696950430ffda (extracted via debugfs from /work/koensayr/staging/v3.0.7_sysimg/system-raw.img).

Method. Disassemble (radare2) every function in the outbound chain: dispatchers (fcn.0xf0bc, fcn.0xf290), high-level emitters (fcn.0x1165c, fcn.0x11778, fcn.0x11894, fcn.0x119fc), frame builders (fcn.0xed50, fcn.0xef08), frame finalizers (fcn.0x6d048, fcn.0x6d0f0, fcn.0x6d1a8), AVCTP/L2CAP wrappers (fcn.0x6df20, fcn.0xae5e4, fcn.0xae418, fcn.0xae6ac), and RX-side dispatchers (fcn.0x6cee4, fcn.0x6cf30, fcn.0x6cf8c). Byte-search for the M-series gate signatures: the bl fcn.0x6ccdc + cmp r0, 0 + beq <drop> list-contains pattern, movs r0, 0xd; pop drop epilogues, and strb.w r0, [r4, 0xf2] chip-busy SET.

Three-tier dispatcher discovered. mtkbt's outbound side has TWO dispatchers (not one), selected by msg[8]:

fcn.0x119fc has 11 caller sites (per-PDU success-path emitters) and fcn.0x11778 is the project-wide error-response emitter — both route through Path C.

New gate inventory. Across the audited functions, every conditional-drop site that fits the M-series pattern:

Structural-identity verification of Tier-1 Path C gate. Bytes immediately preceding the beq <drop>:

Identical instruction sequence; only the branch displacement to each function's local drop epilogue differs. The Tier-1 Path C beq 0x6d242 is the literal byte-for-byte twin of M2 and M4 list-contains drops.

Hypothetical patches (would-be M5 / M6, not staged). Documented for future AVRCP 1.4+ Browsing channel work:

• (M5). NOP beq 0x6d242 at 0x6d1ce (38 d0 → 00 bf). Structurally identical to M2 / M4. Would matter only if Y1 ever emits browse-channel responses.
• (M6). NOP strb.w r3, [r4, 0xf2] at 0x6d1ec (4 bytes, 84 f8 f2 30 → 00 bf 00 bf). Structurally identical to M3 SET. Required as a pair with (M5) if it lands. Note: the chan-struct used here (chan+0x10c) is distinct from Path A/B's chan-struct, so chan[0xf2] in the browse context is a separate flag from M3's primary-channel chip-busy.
• M7 retracted. 0xf2c4 bne 0xf384 is a queue path, not a drop. The branch target inserts the packet onto txBrowsePacketList and returns r5=2 success.

Tier-1 reclassified to defensive after browse-channel discovery. Initial classification of M5 / M6 / M7 as Tier-1 was premature. Walking the chan[0x558] gate branch target (0xf384) and the surrounding context reveals that fcn.0xf290 exclusively handles the AVRCP Browsing channel (1.4+):