I realized that google publish a Head Tracker HID Protocol in Android 13 for supporting spatial audio.
And I'm now pay some efforts on this protocol.
The one question from my side is that which kind of Head Tracker HID supported in Android 13, BT HID or BLE HID Over GATT Profile (HOGP), or USB HID?
If Android 13 supports Head Tracker HID Protocol in BLE HOGP, Who knows the ATT CHARACTERISTICS UUID of head tracker in report and head tracker out report?
Thanks a lot.
I tried to implement the Head Tracker HID Protocol in BLE, but can't find the ATT CHAR UUID so that Android 13 not subscribe the HID service.
Related
I'm developing a system that identify nearby mobile devices using ESP32 for sniffing bluetooth packets.
Multiple articles indicate that it is possible to track Android phones using bluetooth, even if it is disabled:
https://qz.com/1169760/phone-data/
https://www.vozpopuli.com/memesis/balizas-google-bluetooth-ubicacion-Privacidad_0_1107489510.html
I have looked for more information on how to do it but I have not found anything.
Is only Google able to do that or anyone can do it?
Thanks.
No.
If these devices are not transmitting bluetooth packets, then it is not possible for nearby devices to listen to that traffic and identify them. What Google is doing is to require phones running Android to passively monitor for bluetooth traffic and relay this back to their servers. Phones with Google Maps installed passively relay location in the same way so that traffic maps are ~accurate in realtime.
In other words, disabling bluetooth prevents pairing and sending bluetooth traffic, but not receiving it.
If you're asking about programmatically disabling bluetooth with this caveat, take a look at this Stack Overflow question
I wonder if anyone else is seeing this. We have successfully used the RN4020 MLDP protocol (similar intent to SPP on Classic Bluetooth) with both iOS and a Bluetooth-LE USB module (BLED112) on Windows. Basically serial bytes coming in to the RN4020 module are sent via a characteristic, resulting in a notification on the connected device (iPhone, PC). Bytes written to the characteristic on the connected device come out of the RN4020 serial port.
But using similar API calls on Android (using C#/Xamarin low-level APIs), I occaisionally see the data I send appear as a notification. About 1 time in 5. The data sent does go to the module and then to the equipment it is attached to. I think I saw evidence that there was some sensitivity to timing.
Has anyone seen similar behavior? I do not see this on iOS or the BluetoothLED dongle (BLED112). I believe too that the Windows UWP version I started did not show this behavior.
Thanks to anyone who can help me understand this -- currently I have a hack in to discard received data that exactly matches what was sent out recently. But I would hate to release like this.
I want to exchange some data between two android devices using Bluetooth LE (and yes, I know that I'm not intendet exchanging data with BLE, but thats not the point here).
So I started researching on that topic and found out that the device used as peripheral needs android 5, while the core device will need android 4.3.
The first step would be starting a BluetoothGattServer on the peripheral, then advertise it and finally start scanning for it with the core device.
I understand that advertising was added in android 5 but BluetoothGattServer exists since android 4.3.
So if I would just create the BluetoothDevice object to which the core should connect from a address string (which I got), there is no need for advertising the peripheral.
If advertising isn't necessary I could just stick to android 4.3 without the need of a 5.0 device.
But somehow I got a strange feeling about this, like I'm getting something wrong? Any suggestions?
Advertising is necessary for peripheral since if it was no advertising, the central can not find the device(OK I assume you have the peripheral MAC address) but if central could not receive the advertising will not send out the connect request, hence the connection would not be set up.
I understand that advertising was added in android 5 but
BluetoothGattServer exists since android 4.3
I assume you mean that 4.3 can support BLE and advertising/BluetoothGattServer exists on android 5 right?
If you just transfer few bytes, why don't you use SPP or OPP.
We are working on a project of developing the soft and hardware for a bluetooth LE device.
We implemented GATT services and we are able to connect to the device.
Now the next step: Implement security.
We know that there are tree methods of security:
Just Works
Passkey Entry
Out Of Band
Since our device doesn't have a display (no_input, no_output), we are doomed to use Just Works since OOB is not supported by Android and iOS yet.
So this means we have this bluetooth device with all it's services just hanging there in the open to connect by anybody.
Is this really true in BLE?
We were thinking about implementing our own security just by connecting, writing a key to a keyservice and when that key is correct, the services open themselves for writing/reading. But what would that do with certification?
So you guys are our last resort since we are still hoping we are wrong in this one. Is there anybody who can acknowledge this fact? Or are we missing a big piece of the puzzle?
You can implement Just Works, Passkey Entry and Out Of Band (NFC) on your BLE Device.
Passkey can be written on a label on the product or be hardcoded to 0000 or 1234 or whatever you choose. This works on iOS and Android if you implement correct Bluetooth Security configuration on your BLE Device. What chipset are you using?
Out of Band works fine on Android and Windows Phone with NFC. Maybe Apple iPhone 6 and 6+ will get proper NFC functionality in a more mature iOS version later. On iOS 8.1 it is still just for Apple Pay, not for industri standard NFC functionality.
First step is to set the GATT flags so your Service or Characteristic requires security.
Second step is to implement the bluetooth Security manager messages.
There are official white papers on this on BT Special Interest Group:
https://developer.bluetooth.org/DevelopmentResources/Pages/White-Papers.aspx
I am working on a project that uses the Bluetooth HID profile. I understand that the BlueZ stack in android has the HID support but its not extended to app layer by Android Framework.
My main concern is to understand the driver level flow for a Bluetooth HID device.
I would like to add a new HID device driver that can handle the key events from bluetooth HID device and pass it on to the Input subsystem.
Any help would be appriciated!!
thanks
To understand the "level flow" you should start reading the specs, available on bluetooth.com and here: http://www.dawidurbanski.pl/public/download/projekty/bluepad/HID_SPEC_V10.pdf
You can also have a look at Teksoft Blueinput, as this application is a Bluetooth HID implementation. It currently supports keyboards and mouses, but has it's own Report Descriptor parser, so other devices could be easily added.