Post

Replies

Boosts

Views

Activity

AirPods Pro service visible in PacketLogger but absent from CoreBluetooth discovery
I’m investigating whether a consumer iPhone app can control AirPods Pro environmental listening settings using public APIs, while keeping all live audio processing inside the earbuds. On a real iPhone running iOS 26.6.1, with AirPods reporting model A3064 and firmware 8B41 in Settings: CoreBluetooth connects and successfully reads the manufacturer, model and firmware characteristics. Explicit discovery of service 7798082B-B7B7-45A6-9933-563492EFE04E returns no matching service. Unfiltered discovery completes without errors but also excludes that service. A system PacketLogger capture contains metadata mapping that service to handles 0x12–0x2B, and characteristic D5621CC1-F7AB-45DB-9403-9EAF744D5390 to value handle 0x18. System ATT reads of that handle receive responses. Our app performs no setting writes. We understand that system trace metadata does not establish third-party access. Is this service intentionally unavailable to third-party CoreBluetooth clients? Alternatively, is there a documented public connection, authorization or entitlement requirement that could explain its absence? If this service is unavailable, is there any supported API for controlling AirPods environmental amplification or frequency balance? A minimal Swift project and diagnostic report are available.
1
0
281
1d
AirPods Pro service visible in PacketLogger but absent from CoreBluetooth discovery
I’m investigating whether a consumer iPhone app can control AirPods Pro environmental listening settings using public APIs, while keeping all live audio processing inside the earbuds. On a real iPhone running iOS 26.6.1, with AirPods reporting model A3064 and firmware 8B41 in Settings: CoreBluetooth connects and successfully reads the manufacturer, model and firmware characteristics. Explicit discovery of service 7798082B-B7B7-45A6-9933-563492EFE04E returns no matching service. Unfiltered discovery completes without errors but also excludes that service. A system PacketLogger capture contains metadata mapping that service to handles 0x12–0x2B, and characteristic D5621CC1-F7AB-45DB-9403-9EAF744D5390 to value handle 0x18. System ATT reads of that handle receive responses. Our app performs no setting writes. We understand that system trace metadata does not establish third-party access. Is this service intentionally unavailable to third-party CoreBluetooth clients? Alternatively, is there a documented public connection, authorization or entitlement requirement that could explain its absence? If this service is unavailable, is there any supported API for controlling AirPods environmental amplification or frequency balance? A minimal Swift project and diagnostic report are available.
Replies
1
Boosts
0
Views
281
Activity
1d