3

We are developping a custom bluetooth low energy peripheral and we need to define our custom service. Based on this link: https://www.bluetooth.org/en-us/specification/assigned-numbers/service-discovery

All short UUID (16 bits) are reserved pending future revisions of the BT services specs. And it seems that current version of Android (4.4) doesn't support the 128 bits UUID.

So basically i can't use a 16 bits UUID for defining my service, but i can't filter my services with Android for a 128 bits UUID. Anyone got an idea on the best way to implement it ? Thanks

M to the K
  • 1,576
  • 3
  • 17
  • 27

3 Answers3

1

I'm still not sure if it's ok to use custom 16 bits UUIDS so we manage to do something else based on this SO question. startLeScan with 128 bit UUIDs doesn't work on native Android BLE implementation

We scan all the devices and search for our service in the byte[] scanRecord returned by the LeScanCallback.

Community
  • 1
  • 1
M to the K
  • 1,576
  • 3
  • 17
  • 27
  • This will always be safe and future proof. And Android seems to be supporting longer UUID's in their new scanning API (level 21). Apple recommends a [tool](http://developer.android.com/reference/android/bluetooth/le/ScanFilter.Builder.html#setServiceUuid(android.os.ParcelUuid, android.os.ParcelUuid)) for just generating a random UUID to use. So it seems this is the right way. – Vegar Westerlund Oct 25 '14 at 08:40
0

Apparently not all 16 bit UUIDs are reserved. The mentioned UUIDs and UUIDs in range 0x000E – 0x01FF are reserved. I have used the UUIDs FFF0 - FFFA for my custom profile and it is still working fine.

Take a look at simpleGATTProfile in TI's simple peripheral example.

  • From what i understand it seems that the range 0x00E - OxO1FF is reserved only for the attributes. (From the doc: The following attribute IDs have the same meaning for all services. These attribute IDs shall be in the 0x0000 to 0x01FF range.). So im not sure that everything above could be used... In the TI exemple they used the id 0xFFF0 for their service, but from the bluetooth perspective is this ok ? The collision risk with other services is pretty high no ? – M to the K Jan 30 '14 at 08:27
  • 1
    Assigning custom 'internal' UUID ranges from 0xffff is not recommended. The Standards Development Organization (SDO) [describes](https://www.bluetooth.org/en-us/specification/assigned-numbers/sdo-16-bit-uuids) how companies can apply for a 16-bit UUID and the only one approved so far is one for A4WP. It has 0xFFFE, so it seems likely that the they started from there and just decrements the counter. – Vegar Westerlund Oct 25 '14 at 08:26
0

The 16-bit UUID is a shortcut for a longer UUID. For example, blood-pressure UUID (0x1810) is the same as

UUID.fromString("00001810-0000-1000-8000-00805F9B34FB")

With that, you can do:

val ids = arrayOf(UUID.fromString("00001810-0000-1000-8000-00805F9B34FB"))
startLeScan(ids, myCallback)
KOkon
  • 636
  • 1
  • 4
  • 13