I have a BLE peripheral that connects to an iOS7 device via JUST WORKS
We have control over the peripheral and the iPad App source code.
It is my understanding that in order to encrypt, the peripheral it has to pair
Pairing causes the iOS 7 device to display a notification - "Bluetooth pairing request"
Is there a way to remove this notification so that the iOS device automatically pairs.
Note - This is not a question of Bonding. I realize that if bonded the request will not happen. We do not wish to bond.
Related
After days of research and trial and error my colleagues and I have to hope that the StackOverflow community has a working solution.
We got an Android Smartwatch. We developed an app which acts as the BLE central. The App shows a QR-Code encoding an UUID which is unique for every Smartwatch. While showing that QR code it's actively scanning for a device advertising a service with that UUID.
We also developed an iOS app which can scan that QR code and start advertising with the service UUID it received. The Android Smartwatch then connects very quickly to the iOS device.
One purpose of the Smartwatch is to show push notifications from the iOS device. So when the connection is successfully established, the Smartwatch-App subscribes to the ANCS Data Source and Notification Source characteristics. This initiates "Just Works" pairing, so you just have to click on "Pair" on the iOS device. Afterwards you have to allow that iOS notifications are shared to the Smartwatch and then the Smartwatch successfully receives notifications.
ANCS is also the reason why the iOS device MUST BE in the peripheral role.
Until here everything works fine.
When the user leaves the bluetooth range or dis- and enables bluetooth on the iOS device, an automatic reconnect should be triggered. It DOES reconnect when the iOS app is in foreground. Unfortunately it DOES NOT work when the iOS-App is in background. This is probably related to the fact, that the iOS device is not advertising with the required UUID when the app is in background as described in the CoreBluetooth documentation:
All service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey advertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them.
We tried many different ways to reconnect from the Android Smartwatch to iOS. From my understanding it should be working when making the first connectGatt with autoConnect=false and when the connection is lost, calling connectGatt on the lost device with autoConnect=true, but it never reconnects. At least not within 15 minutes. Scanning again also wouldn't work, as the UUID is not advertised in background anymore.
We also tried to additionally let the Android device act as peripheral, so the iOS can connect to it. After connecting we wrote data to an "INITIATE_ANCS"-characteristic and let the Android device call connectGatt on the device which was passed to onCharacteristicWrite. This led to interesting behavior:
- The connection was working, we could read a Smartwatch-Characteristic from iOS.
- When subscribing to the ANCS characteristics, it initiated pairing. But instead of "Just Works" pairing it showed a 6-digit code on the iOS device which we had to type onto the Smartwatch.
- The pairing was inititated on every new connect and it always created a new device in the systems device managers on both Android and iOS.
- The pairing WAS NOT inititated when the iOS app was in background.
We really did a thorough research and couldn't find a solution. Did we understand something wrong on how BLE for iOS and Android works? We really hope to find an expert here that has the knowledge what has to be done to make the reconnect work.
Edit:
The Android device is running on Android 5.1.1 and currently it's no option to update.
The iOS testing device is running iOS 13.3 and it should be compatible with iOS 13+
When I make a BLE device talk to an Android device, is there a way for the android device to distinguish what advertising channel the BLE device is on? If doing so is impossible in Android, is it possible with Adafruit BLE devices?
No, it's not. The information is discarded before the advertisement packet is sent by the receiving Bluetooth controller to its host (Android) over hci. Why do you want this info anyway?
It seems you can do it on Adafruit though, since it uses nRF softdevice, which gives you this info.
I'm using Android Things 1.0.4 in a prototype where it acts as BLE peripheral device: advertising services and running a GATT server.
I encounter an issue in the BLE pairing process when trying to bond the Android Things board (Raspberry Pi 3) and a smartphone.
Since the device has no display, I set using BluetoothConfigManager:
IoCapability = BluetoothConfigManager.IO_CAPABILITY_NONE
which results in the error AUTH_FAILED every time.
Instead,
IoCapability = BluetoothConfigManager.IO_CAPABILITY_OUT
logs the pairing key and prompts the smartphone to enter it during pairing, but it results in the REMOVED error.
Questions:
Is Android Things in peripheral role capable of handling BLE pairing or not yet?
Are there more things that need to be implemented in the app's code to replicate the full-fledged Android logic?
Here's the source code of the Android Things app to test BLE pairing and bonding
The same code stripped from Android Things specific elements completes BLE pairing and bonding successfully when running on an Android phone as Peripheral (server), and an Android device or iPhone as Central (client).
Generally speaking, if you attempt to read an encrypted GATT characteristic before pairing (which triggers the pairing logic automatically), this results in GATT error 137 returned from the read request (AUTH_FAIL). This is because the device doesn't have enough time to finish setting up the bond before a response is sent by the Bluetooth stack. Retying the read request again generally succeeds.
I have not tested this with an iOS client device, but it certainly holds true with an Android client connecting to an Android (Things) peripheral. As such, I would recommend a few things:
Have the client (mobile) device explicitly initiate pairing, and Android Things should simply react to these incoming requests in the BluetoothPairingCallback. This lets the mobile device decide the pairing type based on the reported capabilities of the IoT device.
Separate the pairing flow from the GATT flow. Pair to the discovered device separately from making any attempts to read the characteristics. This tends to be the best way to avoid timing problems.
Regarding capability choices, this depends on your device. In my experience, if you choose IO_CAPABILITY_NONE this results in PAIRING_VARIANT_CONSENT inside of onPairingInitiated() and the pairing operation succeeds once finishPairing() is called. If you adjust your capabilities, you should be prepared for any number of the variants requiring you to display a PIN for the mobile device to enter. I have not not personally tested these paths.
I'm wondering whether or not we can make a specific BLE peripheral device with having this ability to be supported by iOS/Android for automatic scanning for automatic reconnecting, i.e without using any extra app.
I think some standard BLE accessory devices (like Heart sensor) are already known by smartphones, so after first-time pairing, the smartphone's OS itself will scan for finding them again automatically for re-connecting each time when the connection gets lost.
Yes. If the device is a HID device then the system will auto connect to the device until you disable it in Android and unpair it in iOS.
But what's the purpose if you don't have an app?
I am working on Android BLE as a peripheral connected to a custom device that runs Nordic NRF51 as a central. The project requires Android peripheral to connect to two NRF51 central devices.
Android is advertising two different Advertisement UUIDs one for left and other for right Nordic NRF51 devices. Ideally, I would like to have both Nordic Centrals to connect to the Android at the same time.
I have two main issues.
First issue. Android can get both connections fine. The problem occurs when Android sending notification or Android sending reply back as result of Write Request from the central. When both Centrals are connected, often notification nor the send reply works. I confirmed that the Nordic central does not receive the notification nor the reply. Does anyone have experiences in Android as a Peripheral supporting multiple connections at the same time? I have tried two BluetoothGattServer instances (one for each device) as well as one instance of BluetoothGattServer and based on the connected device, I can tell which Central the event if for and handle it correctly. It is sending notification or send reply to Write Request that at times it does not get sent from Android. I am using synchronized methods on the GattServerCallback event handlers.
Second Issue. Due to the first issue, I am now only advertising one UUID at a time. The idea is to switch between two advertising UUIDs, thus have only one connection at time. The problem now is switch advertising. About 1 out 3 times, when I start advertising with first UUID with its name (LFDroid), it appears that it is actually advertising second UUID with its name (RTDroid) briefly (1 or 2 seonds) and then advertises what was requested. Note that second UUID advertising was stopped on previous switching. It almost looks like when I ask to advertise, it starts to advertise with the last advertised UUID and name and then quickly advertises what is requested. This now causes problem because both Nordic Centrals sees the advertisement and connects.
Any suggestions would be appreciated.