I need to pair two BLE devices(one device is android phone [central app - discovers services] and other devices BLE [peripherals - advertise the services] support hardware) with secure passkey method in android.
I googled it but no luck, I got no references about secure pairing in BLE android.
I have developed an Android Application in phone - connection, bonding is working fine but not able to find out how to do PASSKEY pairing.
I have found some links in internet regards this but in BLUETOOTH not in BLE devices.
Any suggestions?
This is all handled by the Bluetooth stack when you bond.
Per the Bluetooth specification, the security level chosen will always be the highest one supported by both devices. So just make sure the peripheral supports the desired level and Android will use that (since Android supports all security levels). There is no API in Android to select a lower level.
Related
I am searching for some way that can connect to Bluetooth devices without pairing. Or at least make a connection first and then it does not need to be established all the time. Like how wearable devices work (i.e. mi band 6 or Huawei band 6). Can someone please guide me towards some helpful demo or documentation for this somewhere?
Also, I was wondering how was the security managed since my Bluetooth is always on to communicate to the wearable device. Though, turning off discoverability does not seem to create any issues in order to communicate with the device.
Most wearables nowadays use Bluetooth Low Energy (BLE), and with BLE you don't need to pair in order to exchange data - i.e. only a connection is needed. That being said, it is recommended to pair as the data exchanged between the wearable device and the phone will be encrypted, in addition to some other benefits in terms of privacy and security, Have a look at the links below that will go over connection/pairing in more detail:-
Should one create a bond with BLE device
The Ultimate Guide to Android Bluetooth Low Energy
Making Android BLE work
https://developer.android.com/guide/topics/connectivity/bluetooth-le#roles
Central vs. peripheral. This applies to the BLE connection itself. The
device in the central role scans, looking for advertisement, and the
device in the peripheral role makes the advertisement.
To check if a device supports "peripheral"/advertisement mode it looks as though I can use getBluetoothLeAdvertiser()
getBluetoothLeAdvertiser
added in API level 21 public
BluetoothLeAdvertiser getBluetoothLeAdvertiser () Returns a
BluetoothLeAdvertiser object for Bluetooth LE Advertising operations.
Will return null if Bluetooth is turned off or if Bluetooth LE
Advertising is not supported on this device.
Use isMultipleAdvertisementSupported() to check whether LE Advertising
is supported on this device before calling this method.
Now I've heard some rumors that some devices can actually give you a BluetoothLeAdvertiser, but return false on isMultipleAdvertisementSupported() which is another issue in itself, but on the central side of things, the docs don't say anything!
Am I missing something? https://developer.android.com/reference/android/bluetooth/BluetoothAdapter doesn't say anything about central mode. Am I missing something basic here? Thanks for any help. I have heard bluetooth is a pain on Android and it is my first day exploring these APIs.
Short Answer
As DigitalNinja pointed out, an Android phone will always support Central role functionality by default, so if your phone supports BLE, then it can definitely operate in the central Role
Long Answer
You're right, the API might not be straight-forward but this is down to how Bluetooth Low Energy (BLE) API was added to Android and even down to the history of BLE technology itself.
When BLE was first introduced, it was aimed to be for sensors only (e.g. thermometer, heart rate, proximity, etc) and devices that talk to these sensors. The sensors were the peripherals in this case, and the devices that talk to these sensors are the centrals. The peripherals were the true Low Energy (LE) devices, as they would just advertise and send data once in a while. Centrals on the other hand would not be very power efficient as they would have to continuously scan for devices, connect to these devices, and remain in charge of maintaining and monitoring that connection, meaning the radio would be on for a much longer time when compared to the peripheral.
When Bluetooth Low Energy (BLE) API was added to Android, it supported Central role only. In other words, you could write an Android app to scan and connect to peripherals (sensors), but the Android device itself could not act as a peripheral (Because the assumption was that you wouldn't need an Android device to act as a sensor). This was done in Android 4.3 (API 18).
As people started to use BLE more often and the technology matured, it started being used for all sorts of different applications (e.g. virtual serial port, data transfer, beacons, etc). Moreover, standalone central devices started appearing in the market and there was a need to use them with phones or at least test them out against phones/tablets during the development stages. As such, the distinction between central and peripheral started becoming fuzzier and fuzzier, and there was a demand for Android to start supporting peripheral role. This is when the BLE API was updated to introduce peripheral role functionality, which happened in Android 5.0 (API 21).
So to answer your question, if BLE is supported on an Android device then it is safe to state that it will by default support central role as this is the foundation of the BLE functionality for Android. However, API was introduced later to support the peripheral role, which is why not all Android devices that support BLE will support peripheral role.
Finally, please note that isMultipleAdvertisementSupported is a different feature which indicates if your device supports sending out multiple adverts at the same time. Some devices support sending out different adverts simultaneously, while others don't. However, this does not mean that they do not support advertising at all. A device that supports isMultipleAdvertisementSupported will definitely support BluetoothLeAdvertiser, but the other way around is not guaranteed.
To conclude, the safest way to check if your device supports central and/or peripheral role is through the Android version and the API level used, as indicated by the two links above. On Android 5 (API 21) onwards, you can write applications that support both central and peripheral roles, whereas before that you can only write applications for the central role.
I hope this helps.
I've built a dual mode Bluetooth device using the BT 121 from Silicon Labs. The device implements SPP over the classic connection. The device name of the classic node is "XYZ Classic". It also implements a custom service (128-bit UUID) in BLE. The device name of the BLE node is "XYZ_BLE". Both nodes have the same MAC address.
When pairing under 'Bluetooth' settings, sometimes I will see 'XYZ Classic' and sometimes I will see 'XYZ_BLE'. It seems random which one it will pair to but many Android devices I've tested have a tendency to want to pair to the classic node. After pairing, a connection over classic/SPP ALWAYS works. However, I can only connect to the custom service if paired to the BLE node. If paired to classic I can see non-custom BLE services but not my custom service. To summarize:
Function Classic Pairing BLE Pairing
Spp Works Works
Cust BLE Doesn't Work Works
When I pair in code (Android) the problem also happens despite the fact that I search for the devices named 'XYZ_BLE' and then pair to the device returned. I've looked but I can't see a way to force Android to pair to the BLE node.
My only workaround thus far has been to modify my BT 121 firmware to not allow bonding in classic mode. This is not an ideal solution has any Bluetooth Classic only devices will not be able to bond with my device (In reality this might not be too big of a problem but I have one tablet in my possession that only has Bluetooth Classic).
It should be noted that I've used 'BLE Scanner' from the play store to verify that my custom service works/doesn't work depending on the pairing mode. In other words, it's not just my code. :)
So, does anybody have any ideas on how to force Android to pair to the BLE node?
I see similar issues. Some hints:
Android behaviour differs dependent on the bit flags you set in the BLE advertising. There is for example a bit called "no br/edr support" or so. There are also bits telling explicitly that br/edr dual role is supported.
Also ble pairing may be enforced if you access a characteristic which returns a "not authenticated error" from a ble app. At least on iohone, the os will initiate the ble pairing automatically.
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 would like to automatically connect via Bluetooth one Android device into another Android device as soon as that device is in it's Bluetooth coverage zone.
Cheers
This depends on the Bluetooth version supported on both devices.
BT2.1 or below requires a pin. You can hard code the pin (as many BT peripherals, such as headsets do).
For versions greater than BT 2.1, you can use 'just works' simple pairing, which doesn't require a pin but may prompt the user to allow it.
I don't know what the Android specific API to do these are though.