I want to create an android application with background scanning of BLE beacon (like Eddystone or ibeacon). All I need is the detection of a beacon with a specific ID on my phone. I do not need distance between devices.
Is there any beacon with the ability to send signals through cca 3 walls in a building (or 1 flood up/down) in an area with a radius around 30m?
Can my app scan in the background every few seconds all day? (or just when Bluetooth is on, obviously...)
I tried some solutions, but android changed some politics about background running apps, or bluetooth receiver (to detect, when bluetooth is on). My solution sometimes works even 7 hours, but when I restart phone, the app is not restarted. I want a full background run, not foreground service with notification.
Thank you!
Two points:
All bluetooth beacon formats use the same radio transport mechanism. Radio power is limited by international regulatory bodies making transmitters weak.
The laws of physics decide how well they will travel between floors of a building, which will vary based on construction materials, but results will generally be poor. Again, this will be the same for all beacon formats.
Android 8+ limits detections of BLE in the background without a foreground service. You can do at most one scan every 10-25 minutes (this is randomized) when the phone is not in deep sleep mode. the only alternative is a foreground service with an ever present notification.
I realize these are not the answers you want to hear, but it is important to recognize and accept real-world limitations that exist and come up with creative solutions that work within these limitations.
Related
I'm working on an Android app that needs to detect if other users of the app are close to each other (lets say within the same room or Bluetooth range). The app needs to be able to detect this without any user interaction.
Geolocation is not an option as this is too inaccurate indoors.
The app runs only on company owned phones that stay on company ground, privacy is not a concern.
All devices are always connected to the same wifi network and BT is always enabled.
My idea is to detect if users are within a close distance of eachother by periodically Bluetooth scanning and checking the results against a list of MAC adresses that contain all the devices that have the app installed.
The MAC adresses of all devices are send to a server, the devices then grab this list of mac adresses from the server to compare to the results of a BT scan.
Problem is, BT and Google's seem to use Advertisement / Discovery patterns where one device acts as the server and one device acts as the client. For this to work properly i feel like the devices need to always be discoverable.
Will an implementation based on Google's Nearby or BT work for my needs ?
Is it possible to detect the presence of a nearby device without it being discoverable ?
As battery life is a concern (need to be able to do this for atleast 8 hours a day) is BLE an option?
You can almost certainly handle 8 hours a day if the phones aren't really used for much else. There are a lot of variables, however.
Many older phones require a different type of scanning using infinite scanner restarts in order to properly report "seeing" a peripheral. This can dramatically decrease battery life.
If the phones are running Marshmallow or later, they have a doze mode which interrupts scanning. This can be circumvented using an AlarmManager, JobService/Dispatcher, or WorkManager. This can dramatically decrease battery life.
If the phones are running Oreo or later, they require a foreground service (persistent notification) in order to prevent the app from being automatically killed by the OS to save battery. The app should also be whitelisted from battery optimization because even with the foreground service, the app will still be killed off by the OS.
Finally, scanning and broadcasting and using location services is pretty expensive battery-wise. If you're attempting to cluster phones and guess their position based upon what other phones are nearby, at some level you'll still need the location data off of the phones to figure out where they're at.
You're much better off just scanning. You could carpet your company property with beacons, where each individual beacon's location is recorded. When the phone "enters a region" (comes within range of a beacon), it should send something to your api reporting which beacon it just found. This will tell you what room/area it's in.
Another less flashy (and potentially less accurate) way to track everything would be via the IP addresses of the wireless access points they're connected to. Use a WorkManager to periodically update an api with some unique ID for the phone and the IP address of the AP. Your IT department should know the locations of each of them. This way you get reasonably good tracking and virtually no battery drain.
I'm making an app that executes some actions after a device detects a beacon while monitoring for beacons after app is killed.
I am currently using altbeacon for detecting beacons on android. It works fine on stock android phones but on a few devices like OnePlus i need to run a foreground service to detect beacons which results in a notification which indeed looks a bad user experience.
In a few devices like xiaomi, I need to enable a few permissions, which differs from manufacturer to manufacturer, thus making it nearly impossible to redirect users to those settings to enable those permissions.
Could anyone please provide a workaround?
Currently I am monitoring beacons during app kill and once detected I range beacons in order to get the uuid, major and minor since I need to differentiate between a huge number of beacons.
From what I understand monitoring provides you information when a region has become visible in the vicinity of your scans (with callbacks like regionentered, regionexit etc) and then ranging gives your information about beacons in that region.
So behind the screen is same bluetooth scan sufficient to call both callbacks? Or we need to start separate scans for each?
In theory, one scan is enough for doing all these. The scan callback provides enough information to calculate beacon region/ranges. (You can use libraries or write your own algorithm for these.)
However practically the app need to restart separate scans, just to protect the Bluetooth stack on your device. There are quite some device specific issues if you run one Bluetooth scan for long time. Restarting scan periodically will improve the stability significantly on some devices.
I will make the app about searching periodically with a bluetooth in Android.
The app is operating in background and the period may be too short, about 1 min.
but i dont know how I decide that.
I heard the energy with bluetooth gets low.
So. I want the quantitative data about searching with bluetooth.
Or approximate data, fine.
Plz give a hand to set the period.
android.net.wifi.WifiManager has the startScan() method to perform a passive scan of the WiFi channel and when the scanning is completed onReceive() method is called to access the WiFi channel readings.
However, as this webpage shows, which I have also confirmed with my own code implementation, the passive scanning of the WiFi channels take different times with different phones. Sometimes, some platforms are even around 10 times slower..
I would like to know what causes the phones to use so much time. Is it the driver? Is it some energy saving features? Or none of them and something very different is the reason?
The article gives you a hint:
Passive scans are slower to perform, because the device needs to
listen on every channel for some period of time, waiting for
broadcast beacons. Beacon frames are transmitted by APs periodically
to announce the presence of a wireless LAN. Beacon frames contain all
the information about its network. This approach consumes less energy,
since the radio doesn't use transceiver, but only the receiver. It
also takes more time to finish, since it has to listen on every
channel.
Some period of time is different for each device. If you listen for too short a time on a channel, you might miss a beacon frame. Too long and it might take a while to enumerate all the available APs when the user first scans a new location.
Furthermore, I didn't see actual details on how those results were generated. One might imagine a smart algorithm would use a longer listen time when first in a new location but switch to shorter ones after it's been there for a while.