I have made an Bluetooth Low Energy Scanner android app and I would like it to always scan at the background.
My case now is when user open the application, it will start scanning but once I clear the task manager of the phone the application will stop scanning.
I would like the application to always scan all the time, even when the user clears the task manager.
Thank you.
BLE scanning doesn't use much power at all. Not particularly more than having Wi-Fi enabled. As described in https://developer.android.com/reference/android/bluetooth/le/ScanSettings.Builder.html#setScanMode(int), you can choose between SCAN_MODE_LOW_POWER, SCAN_MODE_BALANCED or SCAN_MODE_LOW_LATENCY. Note however that scanning with highest duty (SCAN_MODE_LOW_LATENCY) may have bad effects on Wi-Fi throughput since it occupies the radio.
To make sure the app stays alive even though Activities have shut down, you can have a foreground service running in your process (https://developer.android.com/guide/components/services.html#Foreground). Note that with some chinese phones (Xiaomi, Oppo etc.) the user also needs to go into System settings and enable background execution for your app.
Why do you need scan all the time? it will waste so mush power.
Android task manager can kill application and application's service.
I think it can not be achieved.
Related
I want to get the location of the device once when the service is running in the background (the tracker monitors the change in the database and then executes the code that should get the geolocation of the phone). I encountered a problem: the program receives location data when the application is running, but when it goes into the background, the location data stops being received in a few seconds. I tried all the codes and options that I could find, but everything stops working when the program goes into the background. For this I use AndroidStudio Java. So how do I implement this and is it even possible? Thanks.
On Android there are two types of Services- foreground and background. Background (the default) on modern Android are killed 2 minutes after your app is no longer in the foreground. Foreground services are kept for longer, require you to have a notification so the user knows you're tacking him (think of Uber and the notification you can't swipe away you get while its running), but can still be killed for resources if other apps need it. You cannot rely on any Service running permanently.
So the answer is going to be either Foreground Service, or its going to be a completely different architecture for your program. The second really depends on exactly when and why you want to get the location.
There are many limitations on getting on getting location in background, refer to this
Do you target API level 29 or up? if yes, have you add ACCESS_BACKGROUND_LOCATION permission in manifest? If this is not declared, app can only access location while in foreground.
Even after declaring ACCESS_BACKGROUND_LOCATION permission, app can only get location data a few time in an hour due to limitations. Maybe you can consider using foreground service instead to avoid such limitations.
I have to work on a project Where I have to upload users' locations every 15 minutes. For that, I searched a lot and found Recurring work with PeriodicWorkRequest. But the problem is that the WorkManager might not work when the app is closed/killed per the answer given here. Then I found about Service in android.
So I want to know If I want to send users' locations every 15 min even when the app is killed then how to approach this?
If an application is Force Stopped, the OS cancel all the Job related to that application. This is not a WorkManager only problem. The OS interprets a Force Stop as an user request to the OS that they don't want this application to run anymore.
Even if you use JobScheduler or a Service, the application is gone. But a force stop should be a user decision.
Some OEMs have implemented in the past some changes to the Android OS so that a swipe out of an application from the launcher was interpreted as a force stop with all the negative effects on scheduled jobs. This is where the problems start.
WorkManager is this case has implemented some mitigation, but the application cannot do anything if it is force stopped till the user launch it again.
If have a problem with a specific OEMs, please open an issue on the Android issuetracker as this maybe a CDD violation. Google can contact the OEM and request that they fix the ROM. This is going to take time, in the meanwhile, you can take a look at sites like don't kill my app to understand what are the constraints on a specific device and use a library like autostarter to help the user to navigate to the right setting.
I have an app that sends TCP messages. I need the messages to be sent as long as the app is alive. So, I granted access to battery optimization and added all the required wake_locks and everything seems to work fine even when screen is off.
The problem is that I noticed that every time that I leave my phone with the app in the background, when I come back after few hours(or less) no messages are being sent, and when I enter my app it loads as new instance and not like an app coming from background. What can I do to have my app not being killed by Android?
I guess that this is what happens
You need to use a foreground Service; a service started via startForeground().
The service does not "re-open" your activity; it is a component of your application that may be long-lived. You might prefer to think of it as an activity without any views.
Yes, as the others mention you have to use Service for background execution.
Additionally, also, keep in mind of the Background Execution Limits for Oreo and above.
You can also look at JobScheduler for managing asynchronous tasks efficiently.
Create a 1px*1px transparent view on the desktop, such as toast.(the Android os will level up your priority as a foreground process)
Suggest your user to add your app in the white list.(in some rom)
Always put your app`s notification in the notification bar.(also need a service)
create a guard process, when your app die, send a broadcast to guard and let guard restart your app. when guard die, send a broadcast to app and let app restart your guard.
Be careful of battery consumption and don`t trouble your users too much
The background services are not encouraged any more from Android Oreo (>25). I want the socket to keep connected in my chat application even when the app is closed.
How can I implement new changes to android 26?
Some people says, use JobIntentService
Some people says, use JobService
Some people says, use JobScheduler
Some people says, start service as Foreground Service
Any help would be appreciated.
I faced the exact same problem working on a chat application so I know your pain. Our conclusion was:
you don't keep a connection alive 24/7, if you need to deliver a
message to an user that has no connection alive, send a push message
via Firebase.
If you want to keep a connection alive in background, you will face many problems. The first one, targeting Oreo, is that if your app is in background (definition of "background" in this context is here) it won't be allowed to run except for small time windows.
You can definitely use JobScheduler to run periodic tasks, they won't be executed at exact intervals or times to reduce battery usage (which is good) but it won't help you in keeping a connection alive. At best, you can use JobScheduler to periodically pull messages from you server. In order to use JobScheduler you need to create a JobService class.
JobIntentService is a new class introduced in API 26 of support library. It is a replacement for IntentService, it will run as a JobService on android API 26+ and as a Service (similar to IntentService in the sense that it will execute code in a background thread) on older APIs. On Oreo its background execution will still be limited so it won't help you in keeping a connection alive.
Using a foreground Service can really help you reducing the likelihood of the process being killed, but, you will need to display a permanent notification. It doesn't sound like a good solution for a chat app.
If you still think that having a 24/7 connection alive is a viable option, you need to consider also doze mode. You could ask the user to whitelist your app to run even in doze mode but you should have a very good reason to do that. Again, you would face the other bg execution limit in Oreo.
Another issue you will face is other apps. There are resources management apps that will aggressively kill other apps in bg to reduce memory and battery usage. For instance, I cursed this one quite a bit.
Another issue is created by android. When the system is running low on memory, it will start killing processes of apps in bg. There is a an order in which they're killed, if I recall correctly should take into account last time it was in fg and current memory usage. Not the worst of the problems but still, it happens.
Then, if I still haven't convinced you in giving up the idea of the permanent connection, let me share with you yet another problem you would face. Some vendors implements extremely aggressive policies when it comes to killing bg processes, so that they're battery will last longer. For instance, Xiaomi.
Last tip, unrelated, but it took us a while to figure this out so I'm going to share it. If the user force stops your app from settings, your app is dead (that is, "stopped state") until the user actively launches it again, it won't even receive Firebase push messages.
If your server is configured on XMPP, then it would be easy for you.
Actually, there isn't any need to keep the socket alive at all the time. This is very expensive for the battery and I'm sure you don't want that.
Case: You are working on a Messaging app.
If your socket is broken, then the client will receive the message in the form of Google FIREBASE notification. And the moment your client will receive a notification from firebase, just enable the socket, and you'll be back on track.
The reason I suggested you to use XMPP is because XMPP maintains a queue of undelivered/offline messages. And when your socket is connected again, you simply pull the offline messages from the server.
I don't think this will help you out, but this may make a room for some another idea for you.
Can i make a service which recognize voice even when phone is idle or screen off? I mean can phone listen to what the user will say even on idle state.
This is the entire program on how to make that happen.
http://developer.android.com/guide/topics/media/audio-capture.html
That shows how to record audio, the same implementation could be used to listen for audio.
Also, DEV GUIDE on what services are.
Right from developer.android.com
A service is a component that runs in the background to perform
long-running operations or to perform work for remote processes. A
service does not provide a user interface. For example, a service
might play music in the background while the user is in a different
application, or it might fetch data over the network without blocking
user interaction with an activity. Another component, such as an
activity, can start the service and let it run or bind to it in order
to interact with it. A service is implemented as a subclass of Service
and you can learn more about it in the Services developer guide.
This should give you all the information you need:
http://developer.android.com/guide/topics/fundamentals/services.html
You will have to aquire a wakelock in a service too keep the phone from sleeping so you can record audio. You can probably stick with a PARTIAL_WAKELOCK since you will not need the screen to be on.
You also need the wakelock permission.
Keeping the device active and processing sound continuously will however not be sensible for any implementation I can think of.
It is a horrible idea for most purposes since it will drain your battery in a matter of hours (tops).
I've been working at getting a background audio recorder (while screen is off), and these are the options I've found:
A full wakelock lets you keep recording, but keeps the screen on. (not ideal)
A partial wakelock would be good, except it doesn't actually work -- at least on my phone. (the cpu is kept active, but the data from the microphone becomes just 0s after a couple minutes)
Use a foreground service which starts a background thread that records the audio. This is the best since it lets the screen turn off, while still recording indefinitely.
See here for an example: https://stackoverflow.com/a/57260468/2441655