I'm trying to implement a Bluetooth battery monitoring tool on Linux but there is absolutely no information regarding which protocols are used by manufacturers to send the battery level of a device to a host (I'm particularly interested at Android since it appears to be able to handle "left" and "right" batteries).
I managed to get a grasp on BLE GATT characteristics which define a "Battery Service/Level" that can be read using dbus. I correctly managed to do that, but it appears that no bluetooth headset uses GATT characteristics to send battery information.
I found a post which mentions a lot of plausible protocols, yet it's from 6 years ago and I would like to know if someone actually knows if there's an official and documented way to send battery information data to a device.
P.S. another reason I'm mentioning Android is because if a protocol is supported on Android, then it's probably something that every manufacturer implements.
Bluetooth audio devices generally implement HFP (Hands-Free Profile), which among other things provides battery information. This is unrelated to GATT and BLE. It's a "classic" (BR/EDR) profile. Headsets are fundamentally "classic" devices. They are not "low-energy" devices, even though many audio devices today also implement BLE control protocols (often custom). (*)
Some devices do support the GATT Battery Service, but it would be a device-by-device thing. More commonly, if audio devices advertise their battery over BLE, it will be part of a custom protocol in order to work with their own app, rather than using a standard service. (This is how most of the earbuds I've worked on behave.)
On Linux, I believe you'll use oFono for this.
On Android, you can access the AG role of HFP using BluetoothHeadset. For an introduction, see How to use bluetooth HFP profile in android programmatically? (I know you probably won't need this, but future searchers may be solving similar problems on Android.)
There is no equivalent on iOS. You cannot access HFP or most other classic profiles on iOS at all. The OS implements them (so your Linux tool would be able to interoperate), but does not provide any public APIs on iOS.
(*) There is a new technology called LE-Audio, but, like so many things in Bluetooth, it is yet another completely separate thing. I suspect that CAP devices, which LE-Audio relies on, will also generally provide the LE Battery Service, but I haven't worked with any of them to know.