> If you don't like the Apple device, use something else. It's not like a messaging platform where you'd need compatibility with other peoples' phones.
I own and use lots of devices, for both work and personal tasks, including Apple and non-Apple devices. I own a pair of AirPods. I'd like them to work well across all the platforms that I use. There is nothing technically preventing Apple from achieving this, aside from Apple's arguably illegal tying behavior.
> If you'd bothered to dig into the spec, v1.0 basically says do what you want. v1.1 defines a proper namespace and well known descriptions for multiple batteries. Apple did well to avoid the interoperability minefield.
I have read the spec; please don't accuse me of not reading it. Have you written Bluetooth device firmware before? In case you haven't, at a high level:
* The BT device exposes a "profile," which defines one or more "services", which are essentially different types of data that can be read from or written to the device.
* Multiple instances of the same type of service (the Battery Service in this case) can be exposed in the profile. I don't know if this ability was always present in the spec or was added after the fact, but it was, at minimum, present in 2011 when the BAS 1.0 spec was released.
* So, if your device has more than one battery, its profile will have an instance of the Battery Service defined for each one.
I will grant that the 1.1 spec document is a lot clearer and provides lots of diagrammed examples, but the only net new functionality in 1.1 are a set of new battery-related fields (these are called out near the beginning).
When a device has more than one instance of the Battery service, each Battery
Level characteristic shall include a Characteristic Presentation Format
descriptor that has a namespace/description value that is unique for that
instance of the Battery service.
1.1 says:
When a device has more than one instance of the Battery Service, each Battery
Level characteristic shall include a Characteristic Presentation Format descriptor
(Volume 3, Part G, Section 3.3.3.5 in [1]) that has the Name Space field set to
”Bluetooth SIG” and the Description field set to a valid value from the GATT
Namespace Descriptors [4] and that is unique among all instances of the Battery
Service exposed by the GATT Server.
1.0 was a mess and your anger over a poorly defined and relatively minor feature seems quite misplaced. Bluetooth interoperability has historically been a mess (still is from my experience). But go ahead be big mad that Airpods only play audio from third party devices and don't provide battery status in a way that adheres to a recent revision of the standard. Meanwhile I'm sure Sony would never use a proprietary format ever…
I had posted a reply addressing your points, but I don't think this discussion is productive and you don't seem to want to engage honestly with what I'm saying and stay on topic. So I'll just say have a good day.
> If you don't like the Apple device, use something else. It's not like a messaging platform where you'd need compatibility with other peoples' phones.
I own and use lots of devices, for both work and personal tasks, including Apple and non-Apple devices. I own a pair of AirPods. I'd like them to work well across all the platforms that I use. There is nothing technically preventing Apple from achieving this, aside from Apple's arguably illegal tying behavior.
> If you'd bothered to dig into the spec, v1.0 basically says do what you want. v1.1 defines a proper namespace and well known descriptions for multiple batteries. Apple did well to avoid the interoperability minefield.
I have read the spec; please don't accuse me of not reading it. Have you written Bluetooth device firmware before? In case you haven't, at a high level:
* The BT device exposes a "profile," which defines one or more "services", which are essentially different types of data that can be read from or written to the device.
* Multiple instances of the same type of service (the Battery Service in this case) can be exposed in the profile. I don't know if this ability was always present in the spec or was added after the fact, but it was, at minimum, present in 2011 when the BAS 1.0 spec was released.
* So, if your device has more than one battery, its profile will have an instance of the Battery Service defined for each one.
I will grant that the 1.1 spec document is a lot clearer and provides lots of diagrammed examples, but the only net new functionality in 1.1 are a set of new battery-related fields (these are called out near the beginning).
1.0 absolutely does not say "do what you want."