android: Fix rename packet using wrong opcode (0x1E → 0x1A)#511
Merged
kavishdevar merged 1 commit intokavishdevar:mainfrom Apr 15, 2026
Merged
android: Fix rename packet using wrong opcode (0x1E → 0x1A)#511kavishdevar merged 1 commit intokavishdevar:mainfrom
kavishdevar merged 1 commit intokavishdevar:mainfrom
Conversation
createRenamePacket was building a 0x1E variant with a trailing NUL. On-device testing (AirPods Pro 2 USB-C, firmware 81.2675000075000000.6082) shows the device silently ignores that format — no 0x001D echo, no persistence across reconnect. Switched to the format documented in AAP Definitions.md and already used by linux/airpods_packets.h: '04 00 04 00 1A 00 01 [size] 00 [name]'. With this format the device accepts the rename, echoes the new name in its next 0x001D INFORMATION message, and the name persists across disconnect/reconnect cycles. Related to kavishdevar#411: the Pro 3 symptom reported there (rename doesn't show on other devices) is consistent with the Android 0x1E variant being dropped by firmware. This fix addresses that root cause. Note: Android/Windows displays still depend on each device's own Bluetooth name cache, which is a separate layer from AAP.
d4rken
force-pushed
the
fix/android-rename-opcode
branch
from
55b2cef to
6d76e11
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
createRenamePacketwas using opcode0x1Ewith a trailing NUL. Modern AirPods silently drop this format: the command goes out, the device never echoes0x001D, and the name doesn't persist across reconnect.Switched to the format already documented in
AAP Definitions.mdand used bylinux/airpods_packets.h:Verified
On AirPods Pro 2 USB-C (firmware
81.2675000075000000.6082, Pixel 8, Android 15), via my own app (d4rken-org/capod):Sent SetDeviceName (36 bytes)→ no0x001Decho, name reverts on reconnect.Device info: CAPodTest (A3048)— the device echoes the new name.Related to #411
Reporter's Pro 3 symptom ("rename doesn't show on my other phone") is consistent with the 0x1E packet being discarded — LibrePods' own UI showed the rename because
AirPodsService.setName()writes to SharedPreferences, but nothing actually committed to the device. I'd leave #411 open: even with this fix, the "globally" part depends on other devices' own Bluetooth name caching and Android's per-phone alias (which needsBluetoothDevice.setAlias(), itself CDM-gated on Android 12+), so there may still be something worth tracking there.Caveats
Tested only on Pro 2 USB-C. Worth confirming on Pro 1 / Pro 3 / AP4 ANC / Max before landing. Same fix is shipping in d4rken-org/capod#490.