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.
Related
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've read this tutorial about data transfer in a battery efficient way.
All the lessons are based on one, simple concept: polling the server is Android is battery inefficient. For this reason, Google Cloud Messaging is introduced in order to send messages from the server to the device only when needed.
There is only one problem: I'm trying to implement a "mobile cloud", so a cloud composed by mobile devices, where each device can join/leave the network with high frequency. So I need some mechanism to detect when a device is not reachable anymore. Until now, in all the works that I've seen on the topic, the only solution was to periodically ping the main server to say "Hey, I'm still alive!" from the mobile device. Obviously this solution is battery killing, but until now I've not seen/found any better solution.
Do you know any battery efficient solution for this problem?
There's no reason why pinging the server periodically (heartbeat) is necessarily wasteful of the battery/inefficient. That depends upon how frequently you need to ping, and whether your ping needs to initiate its own transmission vs piggy backing on some other transmission.
Let me explain. Battery inefficiency depends upon whether or not you are increasing the frequency or duration of the transceiver being in an active state. If the transceiver is continually active anyway, such as it is continuously exchanging data or audio, then a heartbeat adds no additional burden. If it is not active, then there will be additional energy usage but that depends upon the frequency of your heartbeat compared to how long a ping will cause the transceiver to be powered. Even then, it's probably irrelevant to your application as I suspect "cloud" means the devices are active and connected.
Let's assume that your heartbeat is such that it will increase the duration of your transceiver being active. There are still techniques you can use to decrease this impact, such as caching your beat and sending it only when it can piggy back on another transmission. Of course, such solutions depend upon whether your heartbeat is implemented in an application, OS or kernel.
I suggest you do actual tests to see if there is truly an impact on your devices.
PS I'm not saying the tutorial is wrong. It isn't. But it is addressing a broader and more general problem then what you have.
I'm currently trying to make an Android app that will have some interaction with a BLE device. That device doesn't have the Ibeacon protocol.
What I want to do is auto connect to that device every time it is in range even (and almost 99% of the time) when the app is not in foreground. The only thing I know is that it is a BLE device, I have access to it name and address (00:1E:C0:29:BD:F8).
It is crucial tha the app connect to it every time it come in range. Even if the phone is lock it must connect no matter what (except if the phone is shut down XD). But as soon as the phone has booted and that bluetooth is activated, I must be sure that my app will be able to connect to tha device if it come in range.
I wanted to know what is the best way to do so.
The only way I can think of is to start a service as sticky, that will scan every 15 seconds (or something similar) for the device it already has registered to auto-connect.
The downfall of that method I guess is that it will surely drain the battery, I'm not sure about that but doing a scan for 3 to 4 second every 15 second must use up a lot of battery.
What do you guys think of that ?
Does anybody know a better solution I could use ?
Thank in advance for the help.
I've been given the task to create an iBeacon client for Android. The purpose of the client is to transmit the ID of the closest beacon over WIFI/3g/4g to a server when another client requests the users position.
Now, I wonder, what is the best way of doing this, with respect to battery consumption?
There are (as far as I can see) two approaches:
1). Whenever the ID of the closest beacon changes, upload the new ID directly to the server.
2). Store the ID of the closest beacon locally on the client's phone. Only upload it to the server when the server requests the client to do so.
Nr 1). means that WIFI has to be activated every time the user approaches a new iBeacon. On the other hand, 2). requires the phone to listen to a port in order to handle requests from the server.
EDIT: I read about the Radio State Machine here: http://developer.android.com/training/efficient-downloads/efficient-network-access.html
If I keep a ServerSocket running in the background, will this keep my phone in Radio Low Power? It seems to me, that option 1) will put the phone into full radio power every time a beacon ID is transmitted, but after that, the phone will fall back into Low Power/Sleep mode, which will save me battery. 2) on the other hand will prevent the phone from reaching Sleep mode, since I have to keep a persistent connection to the server.
I would go with option one because it is simpler and less brittle. If you are really worried about battery, just place limits on how often it can talk to the server(e.g. 10x per hour) so it does not get crazy.
Other things may use battery even more, so test first and make sure this really requires optimization. For example, run this in the background for 10 hours and see how much it drains a fully charged battery vs. When the app is not reporting to the server. If it is only a few percent, then it is probably efficient enough.