Turbo Strikes Again - Tracking Bluetooth Device Battery

UPDATE: Read Part 1 and Part 3!

After updating to Android 11 months back I figured I'd dive in and see what changed. I decided to revisit the Turbo battery research I did at the end of 2020. Nothing has changed from what I could see for the turbo.db itself but in the same folder we get something new. We will be taking a look at some bluetooth items found in the file at the following path:

data\data\com.google.android.apps.turbo\databases\bluetooth.db

Similar to the turbo.db, we don't have too many tables to sift through for evidence but some useful stuff nonetheless can be parsed from the "battery_event" and "device_address" tables.

Figure 1: bluetooth.db table structure in DB Browser for SQLite

Breaking down the "battery_event" table we get the following fields:
  • timestamp_millis - timestamp in milliseconds since Unix Epoch
  • device_idx - device index number, more on this later
  • battery_id - TBD, was empty for all my test evidence
  • battery_level - battery level percentage of the connected bluetooth device at that specific time
  • time_zone - the timezone of the phone when the event occurred
  • volume_level - volume level percentage of the bluetooth device at that specific time
Now onto "device_address":
  • device_idx - device index number, each unique bluetooth device gets one, incrementally from what I can tell, ties back to the field of the same name from the "battery_event" table
  • bd_addr - the MAC address of the connected bluetooth device
  • untethered_device - TBD, my assumption is 0 is no and 1 is yes, but haven't gotten any devices to be listed as untethered
  • device_identifier - universally unique device ID, 32 hex characters in length
Combining both tables we can get a better picture of when a bluetooth device was connected to the phone and some level of usage with the battery status of the bluetooth device and volume levels. Be aware that not all bluetooth devices allow for tracking battery level. From my testing it seems to have been implemented in devices that support BT v4.2 and above.

Figure 2: ALEAPP sample report

As we can see from the sample ALEAPP report I created, we see some battery levels of -1. I'm still looking into this but my thought is it may be related to a disconnection event. Another thing I had noticed is event entries are only created when the bluetooth device battery level changes (in increments of 10 at that).

Once again, Turbo in general looks to be exclusive to the Google Pixel line of phones so you most likely won't see any of this populated on other Android devices manufactured by the likes Samsung or OnePlus. I will update once I come across more answers. For now, update your ALEAPP instance!