I have been using the reference app for Altbeacon on various devices and have seen the following errors in the logcat. I am not setting any foreground or background scan timings, I am using a foreground service with bootstrap regions.
Android 8.1 on Nokia 8
Screen off app in background:
Logcat->
12-12 13:03:27.156 10226-10226/net.beaconsdkdemo I/ScanJob: Scan job running for 300000 millis
12-12 13:03:27.159 2277-4762/? E/BtGatt.GattService: App 'net.beaconsdkdemo ' is scanning too frequently
12-12 13:04:53.335 2277-4762/? E/BtGatt.GattService: App 'net.beaconsdkdemo ' is scanning too frequently
12-12 13:05:01.628 2277-4762/? E/BtGatt.GattService: App 'net.beaconsdkdemo ' is scanning too frequently
12-12 13:05:06.596 2277-4762/? E/BtGatt.GattService: App 'net.beaconsdkdemo ' is scanning too frequently
12-12 13:08:27.374 10226-10226/net.beaconsdkdemo I/ScanJob: Scan job running for 300000 millis
12-12 13:08:27.377 2277-2290/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:10:13.493 2277-2615/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:15:13.661 2277-2615/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:15:21.623 2277-2615/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:15:26.928 2277-2615/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
App opened and running in foreground:
Logcat->
2-12 13:20:04.391 10226-10226/net.beaconsdkdemo I/BeaconService: set scan intervals received
12-12 13:20:04.393 10226-10226/net.beaconsdkdemo I/CycledLeScanner: Adjusted nextScanStartTime to be Wed Dec 12 13:15:21 GMT+11:00 2018
12-12 13:20:13.848 2277-2615/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:20:46.932 2277-4762/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:20:51.345 2277-4762/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:20:53.556 2277-2615/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:21:06.829 2277-2290/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
12-12 13:21:20.099 2277-2290/? E/BtGatt.GattService: App 'net.beaconsdkdemo' is scanning too frequently
Android 6 on Samsung Galaxy Mini 5
Logcat->
12-12 13:01:59.480 3390-3559/? E/BtGatt.GattService: [GSIM LOG]: gsimLogHandler: net.beaconsdkdemo, msg: MESSAGE_STOP_SCAN
12-12 13:02:01.595 26097-26097/net.beaconsdkdemo E/CycledLeScannerForLollipop: Scan failed: app cannot be registered
Are the "Scanning too frequently" entries for Android 8 an indication that the app will be at some point killed?
What's with the scan nextScanStartTime time being in the past?
12-12 13:20:04.393 10226-10226/net.beaconsdkdemo I/CycledLeScanner: Adjusted nextScanStartTime to be Wed Dec 12 13:15:21 GMT+11:00 2018
Is the "Scan failed: app cannot be registered" for Android 6 due to my app configuration or is it a bluetooth glitch?
I notice that on Android 8, after a period of time, the service is killed and not restarted.
There is a long discussion of this issue here.
A summary of what we know: This log line appears to be caused by a Huawei-specific customization to Android. The specifics are proprietary and unpublished, so we have only been able to minimally reverse-engineer what is going on. The basic idea is that Huawei has added some code that monitors the number of scans initiated in the background and starts blocking those scans if the number started exceeds some unpublished threshold in certain unknown conditions.
While this is only known to affect certain Huawei devices, There are consequences to seeing this log message. Scans will basically be blocked when you see this.
If you are using a foreground service with default scan settings, those scan settings will scan at a rate of 1100 ms on, then off for 0 ms, meaning that scanning gets restarted every 1100ms. Once you detect the same beacon twice in a 1100ms period, this cycling will turn off and the scan will remain on constantly, which should cause these log messages to disappear. So if your app starts up scanning when beacons are around, this probably won't happen on Huawei. But if it starts up when beacons are not around it will.
Currently, there is no known workaround for this problem, as even scans once every 15 minutes will trigger this error messages on Huawei devices. It seems beacon scanning with the screen of is simply unreliable on Huawei devices.
It may be worth trying to whitelist your app against battery optimizations to see if this helps. If you find any new information, please post on the library discussion thread.
Related
Application process being killed by iOS internal, when the application was background for more than 30 secs and application is consuming Bluetooth Asseceries frameworks (data transmission or just Bluetooth connected, no data transmission) or periodic network upload is progress in background
Not observed this issue in till iOS 15 beta 6. Observed after upgrading iOS version to 15 Beta 7 and 8
am I missing any new configuration to run the application in background other than External BLE Accessaries and Uses Bluetooth LE Accessories in Background ? is it Possible to run the application in background with above scenarios for 10 mins?
Hello I'm new developer so i need some help Now. I was Bullied app doing Brodcast and Scan Beacon i used flutter_beacon 0.3.0
and for Brodcast i use beacon_broadcast 0.2.1 its working good for Advertising and Scan event when app is Background,but when app is kill or i remove app from list Running applications the Scan and Brodcast not Working
Now My Question is How to running code scan and Brodcast when app is killed or Finished ???
Yes, it is absolutely possible to resume beacon scanning on both Android and iOS after an app is killed. But the specifics of how you do this are different between iOS and Android. Further, the use of non-native development frameworks like FlutterBeacon make things more complicated as the documentation is not as complete for this use case.
While I am not an expert on FlutterBeacon, I am the lead developer on the underlying Android Beacon Library which it uses under the hood. I am also very familiar with how iOS CoreLocation works (which it also uses under the hood.)
In general here are the rules to get apps to detect after being killed:
iOS:
Start beacon monitoring (not just ranging) in the didFinishLaunching method of the AppDelegate
Obtain ALWAYS Location permission
After the app is killed it will be re-launched in the background when all beacons disappear or the first beacon appears in a monitored region.
Android:
Start beacon monitoring in the onCreate method of an Android application class using RegionBootstrap. See here for a discussion on the FlutterBeacon github
Obtain BACKGROUND_LOCATION permission from the user.
On Android 8+, your app should restart within 25 minutes of being killed and give you a callback to the BootstrapNotifier methods as appropriate.
I've developed an iOS app that connects to a BLE peripheral and retrieves heart rate data of one person during the night.
The app runs on the foreground and also on background using Bluetooth accessories background mode.
It receives heart rate data every second and appends it into a file, in order to save a report for the whole night.
The app is working fine in some devices (it writes data during the whole night), but in other devices (tested an iPhone 5s) it relaunches automatically every 1.5 or 2 hours. I found that sometimes iOS kills background apps due to memory pressure, so I made some memory tests with the profiler, but the app only consumes 8MB, and it never gets more than that, so there is no memory issue.
It is really important for me to prevent the app suspending, so I can detect any possible anomaly on the heart rate and trigger an alert.
Any clue on this?
When I'm testing my iBeacon enabled iOS application for different scenarios with iOS 9, I've found that it doesn't discover the iBeacon for a quite a while after I toggle on Bluetooth.
Scenario is as follows,
I kill my application, turn Bluetooth off and then lock the phone. Then I wake the phone via power button and in the lock screen I turn on Bluetooth via the Control Center and wait till the iBeacon monitoring starts.
In the device log I've noticed that the iBeacon monitoring and app ranging has not started even after several attempts.
This scenario fails more often than not in an iPhone 5 which is updated to iOS 9.0.2 and recently I've noticed that this is there in iOS 8.4 device as well.
Any sort of help would be appreciated.
Thanks.
I am planning to develop an iOS application using CoreBluetooth framework which monitors a pedometer peripheral continuously and counts the footsteps.
I know that if backgroud execution mode is set to BLE Central, the application will continue to receive BLE events even in the background.
Apple documentation states that in case the app gets terminated due to low memory, the system can keep track of BLE events for a particular Central Manager if state preservation and restoration is adopted.
Assume I have an iOS application that operates in Central mode. The app is subscribed to receive notification from a Pedometer when ever the footstep characteristic changes.
I have adopted the following in my app.
BLE Central background mode
BLE State preservation/restoration for Central Manager
I start my app, Scan, Pair and Connect to the pedometer and the app starts receiving footsteps.
My Questions:
Now if the iPhone reboots, Will I continue to receive BLE events so that my app will be launched in the background without the user having to manually launch the application again and connect to the pedometer?
If the app is terminated by the user explicitly using the multitasking gesture, Will the app be able to receive BLE events without the user having to manually launch the application again and connect to the pedometer?
Is there a way to launch my application on iOS boot up?
Now if the iPhone reboots, Will I continue to receive BLE events so that my app will be launched in the background without the user having to manually launch the application again and connect to the pedometer?
Your app won't receive BLE events because all apps are started in the terminated state after a reboot (despite remaining in the app switcher). The user will have to manually launch your app at least once after reboot in order for it to use BLE.
If the app is terminated by the user explicitly using the multitasking gesture, Will the app be able to receive BLE events without the user having to manually launch the application again and connect to the pedometer?
Same as above, the app has entered the terminated state, so it won't be able to communicate using BLE until it is explicitly launched again.
Is there a way to launch my application on iOS boot up?
iOS doesn't provide any way to launch your application on boot.
The one exception to all of this that I can find is iBeacons. If your app registers to receive updates for a specific iBeacon, iOS will launch your app when it finds it (even after a reboot or if the user explicitly kills it from the switcher). When you get the iBeacon callback you can start all your BLE logic and it will then run in the background per usual. Of course this means you need to advertise as an iBeacon on your pedometer, which may or may not be feasible.
Bear in mind the detection of the iBeacon is pretty finicky, especially after a reboot. You have little guarantee as to how fast or even if you will be delivered the iBeacon callback to start your app. But it's something.
Source