I recently attended an iOS meetup where BLE and iBeacon were discussed. Apparently on iOS your app can receive notifications of discovery of BLE services in a passive manner. That is, the OS notifies you when a new service (device) is in range.
Is there any analog to this behavior on Android? I am familiar with both the classic scanning behavior on Android as well as the new startLeScan() on Android. The problem is that both of these behaviors are considered "battery intensive" by Google and Google says to only scan when absolutely necessary.
I would like to be in a perpetual BLE scan mode for peripherals and other centrals the way that iOS devices can be. Is this functionality currently available? If not, has this functionality been announced for any upcoming versions of Android?
Related
if i turn on bluetooth in iOS it will be discovered in beacon scanner, is it the same with Android?
Or we should turn the android to be a beacon explicitly using any libraries like alt beacon?
What am trying to achieve is to get RSSI from android by ONLY enabling Bluetooth.
No. Turning on bluetooth does not make mobile devices -- neither Android nor iOS -- advertise as beacons. If you want to make either platform advertise as a beacon, you must install a custom app that is programmed to start the advertising. The Android Beacon Library has tools to do this on Android. On iOS you can use built-in CoreLocation and CoreBluetooth.
On both iOS and Android, if you turn on Bluetooth from the settings screen and leave the settings screen up, it will emit both BLE and Bluetooth Classic packets to make it discoverable by external bluetooth scanning apps. But these advertisements will absolutely not be BLE Beacon advertisements in the strict sense. It is still possible to detect these non-beacon packets with some scanning apps.
Just enabling bluetooth on either platform might make it detectable based on what the other apps are doing. There may be pre-existing apps on the phones that emit BLE beacon advertisements, BLE GATT service advertisements, or similar. However, you cannot predict whether any individual device will do this because you can't predict what apps are installed. Nor can you know what advertisements random apps will emit in a way that is predictable. If you want to be able to rely on detecting another device with BLE in a predictable way you must get an app installed on that device.
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'm trying to build a messenger that requires no bluetooth pairing. The message will be broadcast by the user who adds it and can be received by the listeners in the neighborhood.
I have read in several places that Bluetooth 4.0 has support for this. However most examples involve reading from a ibeacon or a similar device.
Can I use Bluetooth 4.0 to build both a broadcaster and a receiver android app?
I thought of leaving this here because it might be helpful for someone else.
Bluetooth 4.0 broadcast mode requires special hardware and it's only present in a few mobile devices. (Bluetooth peripheral mode) Therefore, instead of using bluetooth low energy, I used SDP (Service Discovery Protocol). The messages are limited to 13 characters.
However due to security restrictions, the app doesn't work for platforms above Jellybean.
Here's my development work. https://github.com/malithj/Seeder
Can I have my iBeacon send push notifications to Android devices? If so what are the Android version and device limitations?
(The reason I am asking here is because this question still isn't easily found on fast google search.)
The simple answer is yes. A few caveats:
Only Android version 4.3+ supports Bluetooth LE, which is needed to detect beacons.
The Android device must have a Bluetooth LE chipset. Most devices released in late 2012 or later have this feature.
You need a third party library bundled with your app, like the Android Beacon Library, or you need to roll your own code to decode Bluetooth LE advertisements to read beacon identifiers.
You should also understand that beacons themselves don't actually push notifications to devices. Mobile devices can detect beacons, and when they do, they read their numeric identifier. A user-facing notification is often triggered upon beacon detection programmatically by tying the beacon's numeric identifier to a string message like "Welcome to our store."
I'm not a developer but I'm curious about the connectivity options between smartphones.
Looks like BLE is the only technology that is available on both Android and ios that could make an connection possible in the foreground, but is able to scan in the background?
If I walked around with my phone in the pocket, could it scan in intervalls for other devices`UUIDs/mac addresses and save the data realibly without the process being shut down after a while?
the app would have to work between Android phones, ios Devices,
and Android phones-ios Devices.
I dont want a stable connection. I'm only speaking about gathering UUIDs and mac adresses in the background. whichever is more suitable to uniquely identify a device.
Thanks in advance.
iOS devices with BLE support can act as the peripheral and/or the central role. The peripheral advertises its services, and the central discovers them (via scanning). You need Android 5.0+ to support peripheral mode.
Once a central discovers a peripheral, the central can obtain advertisement details from it, including a unique peripheral ID. This is similar to a MAC address, though some peripherals randomly generate these IDs.
In general, an iOS or Android device acts in the central role and it doesn't advertise anything. There is nothing to discover. However, you could write an app that acts as both a peripheral and a central.
On iOS, your app can perform both BLE roles in the background (your app doesn't need to be in the foreground).
You would want to do background tasks responsibly as both advertising and scanning require the radio, which uses a significant amount of power (drains the battery).
There are many issues with the current BLE stack on Android (e.g. using WIFI and BLE at the same time because they share the radio). The BLE API first became available for Android with 4.2.
The iPhone 4s and later has BLE with the API first available in iOS 6.