I'm trying to scan for Bluetooth devices using the Bluetooth discovery method. At the moment I have implemented something similar to the following (top answer): How to periodically scan for bluetooth devices on android
However, as mentioned in the top answer this only scans every 12 seconds where I need this scan time to be reduced down to < 1s~. Can't seem to find much useful information online.
The Bluetooth modules I'm scanning for do support BLE, if that helps.
12 seconds is a default scanning interval and could be stopped by the cancelDiscovery(), so call this function after 1s of scanning.
Related
I'm using BluetoothLeScanner to scan for BLE devices, which I start using:
startScan(null, settings.getScanSettings(), scanCallback);
Every once in a while, a call to startScan() does not discover any BLE device, even though some devices are actually advertizing (They are discovered using nRF Connect app).
When this happens, the next call to stopScan() and startScan() does discover devices.
I know that since Android 7, the number of start and stop scans is restricted to 5 times in a window of 30 seconds. However, I've noticed the problem sometimes also occurs if no stopScan()/startScan() has been called for more than 30 secs.
Has anyone experienced such issue ?
Could it be something else my app is doing while starting the scanner that could the scanning to fail ?
I have this problem using Android 10 and lower versions.
Android phone limited BLE scan duration to save energy. So you can not scan BLE advertising for a long time. It is system limitation so APP layer have no way to change that.
In older phone (maybe under 4.4) do not set the limitation, but it will make the phone getting hot.
If you want to scan BLE advertisement for a long time, change your design is a better way.
I have a requirement to complete the continuous scanning of bluetooth in the background of Android phone based on bluetooth 4.0. In Android 8.1 and above, when the phone screen is black, the bluetooth information cannot be scanned. I set filter to complete this function. But bluetooth continues to scan in the background for a period of time, the scan is not any information. In addition, I set up a loop operation. After 10 seconds of bluetooth scanning, the scan was stopped for 5 seconds and then continued. After 5 cycles, no information is scanned. Has anyone had this problem?
I want to continuously scan for BLE Devices but as many posts from the internet and many answers from StackOverflow, starting with Android N, Android prevents an app from stopping and starting BLE scan more than 5 times in a window of 30 seconds.
I am not concerned about battery usage as this is for a specific purpose and will be continuously powered by cable and it is not for a normal end user.
I am not able to find the working solution so far.
is there any workaround/trick to achieve this with reliability?
Do you really have to stop and start scan that often? Your title says you want to scan continuously.
Also if you perform a filtered scan you can run it for how long time as you want.
I have looked on numerous topics on android BLE stack in various website. From what i gathered, the bluetooth stack in android is unreliable and not suitable for any fast and concurrent connection.
I am currently assigned to a project that uses BLE as their main business idea. The idea is to setup BLE devices on the top of each door to advertise to the phones using ibeacon frame (to support both iOS and Android). Whereas the android app will read the advertisement and connect to it via GATT and do a characteristic write. The biggest problem is that the project requires a fast write for each beacon it pass by (within 6s to connect and write characteristic) .
This means that scanning and writing must be done frequently for each door it pass by. I know for a fact that android 7 and above have a max of 5start/stop scan for each 30second. Therefore my logic uses a interval of 3second scan and then followed by a 3second write for each beacon it discovered. EG. During the 3s scan period, the app found 3 beacon, those 3 are added into a queue. Write period of 3second the queue is dequeued and proceed one by one to connect and write for each beacon found.
Scanning and writing are mutually excursive as i heard and encounted many problems when doing them together. Such as high failure rate when doing connecting ble -> write characteristic. However by making them mutually excursive, this means that i can only connect and write to a limited number of beacon if i walk pass through multiple doors with ble beacon.
My connect and write logic contains a default timeout of retry for 1.5s with max of 3 retry. Each gatt action such as .connect, .discovery contains a delay of 200ms.
I am wondering the following question
What is the average time required for ble connect then ble write characteristic (not including scanning). I have tried and seems that certain phones takes as slow as 500ms, whereas some other phone takes as long as 4.5s or just fail to establish connect and write .
Is the whole idea viable? The whole project requires at most 6s to connect and write characteristic to each door it pass by which has ble beaconattached on it.
Any improvement to be make?
Requirement : I have a requirement where I have to scan for near by ble devices at continuous basis.If an attribute of ble device changes,the device emits the ble signal which my app captures.But these things should be done at continuous mode.
Problem : In some of the android device (such as one plus 1,samsung tab 3,Moto droid turbo) the scancall back wil get triggered only once and is not scanning at continuous basis as per my requirement.I have tested some of other devices (such as one plus 3,samsung tab 4,moto g2)where in the scan callback gets triggered every single time.Is there any solution where in even other devices to get scan callback everytime...I have checked with all the scan modes,but yet the same problem persists...
Unfortunately some of the Android devices do not return Scan results continuously as this is not mandatory according to BLE protocol (I witnessed it on LG devices). The workaround is to initiate Start and stop scan. See This useful thread