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.
Related
I have a Danalock V3 Smart Lock. It's working as advertised, but I want my own Android application to detect whenever I come in-range of this device. So my application needs to be "constantly aware" of whether the device is in-range or not. My question is: is this feasible? If yes, how?
As far as I can tell, the device is not bonded to the phone. If I iterate through the list of bonded devices, it doesn't show:
// example code
for (dev in btAdapter.bondedDevices) {
val string = "${dev.name}: ${dev.address}"
println(string) // <-- All my bonded devices are listed, not the Danalock device
}
The device is managed through Danalocks own proprietary app (as mentioned this is working). But it is a Bluetooth device, so I figured I should be able to detect it's presence in my application, somehow.
This is a bit tricky because theoretically, it should be doable. As Michael Kotzjan said, as long as you know the name of your device (e.g. using nRF Connect), you can continuously scan for this name in the background mode and then as soon as you detect it, you can get a notification in your Android app. The whole BLE beacon technology works like this so it's certainly doable.
Practically, you will be facing a few challenges when it comes to BLE background mode. Since Android P, the OS has an adaptive battery optimisation feature that might kill off some apps in the background. There are a few ways around this but it will not be completely straight-forward. Have a look at the links below which cover the subject in more detail:-
Beacon scanning in background - Android O
Is it possible to share data between Android devices when screen is off
The Ultimate Guide to Android BLE Development (specifically check "Staying connected in the background")
Background scanning on Android 8+
Background BLE scan in doze mode on Android devices
I have a security system where moving a Bluetooth LE device causes my android application to do some work. After some of the newer Android updates, I believe API 26, I could no longer get these updates if the Android device's screen was off. I was trying to think of a way around this and came up with an idea:
What if I paired the Android device and the Bluetooth device - would this allow for the message to be received when the Android screen is off?
Previously, all my BLE devices were part of a mesh, so I would regularly have the Android app check for changes in the mesh and turn the screen on to notify the user if needed. Now, because of the background execution limits introduced, I must require the Android device to have the screen on at all times, which leads to the death of display over time.
I'm not that great at programming in C, which is the language the BLE chips are programmed in, so I wanted to ask this first before spending hours just to see this NOT work. So, just to repeat the question: Will having a BLE device paired with the Android device allow a message through these restrictions when the Android screen is off?
If not - is there a way I can make this work?
Thank you for any info!
Use notifications instead of advertisements. This will deliver data instantly and works even if the screen is off. Newer versions of Android have introduced more restrictions for BLE scanning when the screen is off.
Use connectGatt with autoConnect set to true to automatically connect and reconnect in case the connection drops.
Use a Foreground Service in your app process to prevent the app process from being killed. If your app process exits, all Bluetooth connections are dropped as well.
You could use CompanionDeviceManager to gain some extra permissions.
You don't really need to be paired but it has some benefits such as faster connection setup and correctly remembering the address type (flaw in the API that this is missing).
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.
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 am aware if it is possible to wake up an app when the user is close it a beacon. It know it is possible to do it on iOS. I have not found a clear solution on the web. Do you know if it is possible?
Yes, it is possible with the open source Android Beacon Library. It works by starting a low-power background beacon scanning service for your app when the phone boots, or when it is connected/disconnected from power.
Details about how you set this up, how it works, and its limitations are available here.