2
votes

I am trying to simulate an iBeacon using BluetoothLeAdvertiser. I have managed to scan and find iBeacons without any difficulty but when creating an iBeacon myself the advertising data sent out seems wrong.

The beacons I have found have the following format: Byte 0 value: 0x02 Data length – 2 bytes Byte 1 value: 0x01 Data type – flags Byte 2 value: 0x06 LE and BR/EDR flag Byte 3 value: 0x1a Data length – 26 bytes Byte 4 value: 0xff Data type - manufacturer specific data Byte 5 value: 0x4c Manufacturer data Byte 6 value: 0x00 Manufacturer data .. etc

I tried to construct similar advertising data to simulate an iBeacon using AdvertiseData.Builder.addManufacturerData by constructing an array and copying the values above. However, when I send the advertisement data extra bytes having been added at the beginning: 0x1a 0xff 0x4c 0x00

I have notice the number of extra bytes and their values changing depending on how I set the Advertising settingsData. For example, AdvertiseData.Builder.setConnectable(true); adds another 3 bytes at the beginning of my Advertising data (As detected in BluetoothAdapter.LeScanCallback).

Is there a way to have absolute control over what the Advertiser sends out as data? I have checked https://github.com/AltBeacon/android-beacon-library/blob/master/src/main/java/org/altbeacon/beacon/BeaconTransmitter.java, but that is doing more or less what I'm doing as far as I can tell. Using Bluetooth 5 on Android 9.0

1

1 Answers

1
votes

Android BLE Advertising APIs do not give you full control over the transmitted packet. A "manufacturer advertisement" frame starts with a length byte, then 0xff to indicate it is a manufacturer type, followed by the two byte manufacturer code.

So when you see 0x1a 0xff 0x4c 0x00, you only have partial control over those bytes. The 0xff is fixed based on the advertisement type you are sending. 0x1a is the length of your packet (which you can partially control based on how many bytes you put into the advertisement) and 0x4c 0x00 you can control by setting the manufacturer code.

The remaining bytes are your payload, and you have full control of them up to the limited packet size. Any proceeding bytes before the length (0x1a in your case) are flags headers, and Android gives you no control over those.