I have some questions concerning wake lock and services
1- I try to test my service when the screen is off and not acquiring the wake lock, i was expecting that system will kill my service but it didn't happen, so what is the purpose of wake lock?
2- I want to know when then the system goes into doze mode, is it when i turn off the screen or after some time of turning it off? and what happens to my service in this case? and how to know that the system is in doze mode?
3- I know that since Android O normal background service will be killed after nearly one minute, i tried to test that by making intent service and make it running for more than one minute, it was already killed but started again and continued execution, so what is the purpose of killing it and starting it again?
4- does doze mode affect foreground service? and should i acquire wake lock in case of foreground service or is it acquired by default?
Code of Intent service
Logcat
I know they are lots of questions but i am confused with these topics
thanks in advance
The device may fall asleep if the user is inactive and nothing is keeping the device awake. A WakeLock is used to ensure the device stays awake.
You may check those links for additional information: Good answer Official Documentation
Information about Doze mode, Standby and some other things that you may be interested in:
link
Background Service Limitations: While an app is idle, there are limits to its use of background services. This does not apply to foreground services, which are more noticeable to the user.
link
Processes which have a current running foreground service are supposed to be unaffected by Doze. Bound/unbound, started/not-started, and wakelocks do not affect this whitelisting process.
link
--- Update ---
Some things could change from the moment of those questions were asked, so prefer to read documentation or search for the actual information about it. Also it's a good idea to check information about modern solutions for back ground like WorkManager.
Related
Question
I am wondering if we need to aquire the WakeLock or if the service.startForeground() command does that anyway for us? I didn't find anything in the documentation.
Goal
We want to remove unnesessary stuff which might slow down the service start as we want to start capturing the sensor data as soon as possible and as the service might be restarted frequently.
Context
We're developing an Android library to capture sensor data with ~ 200 Hz for up to a couple of hours (research environment). Right now we aquire a WakeLock and start the capturing service as ForegroundService to make sure our capturing isn't stopped when the device is not used.
To answer my own question (if no one else finds more details on this):
In my understanding "foreground" just describes that the user would notice if the app was killed e.g. when browsing a large page. For this reason the system is asked to try to avoid killing the service.
Just because a foreground service is running probably not implies
that the CPU can't go into deep sleep mode.
In order to collect sensor data all the time from user-defined start to stop we still need to aquire the WakeLock ourselves.
No, wakelock can be used to make sure your foreground services run when device goes to sleep
If you must use partial wake locks, follow these recommendations:
Make sure some portion of your app remains in the foreground. For example, if you need to run a service, start a foreground service instead. This visually indicates to the user that your app is still running.
https://developer.android.com/topic/performance/vitals/wakelock#best_practices
If I have an IntentService that simply updates the SharedPreference, is a (partial) WakeLock needed?
I understand that a WakeLock keeps the CPU awake, but when is it needed?
If you need to keep the CPU running in order to complete some work before the device goes to sleep, you can use a PowerManager system service feature called wake locks. Wake locks allow your application to control the power state of the host device.
Creating and holding wake locks can have a dramatic impact on the host device's battery life. Thus you should use wake locks only when strictly necessary and hold them for as short a time as possible. For example, you should never need to use a wake lock in an activity.
One legitimate case for using a wake lock might be a background service that needs to grab a wake lock to keep the CPU running to do work while the screen is off. Again, though, this practice should be minimized because of its impact on battery life.
Unfortunately, some poorly-coded, malicious, or simply buggy apps might create an abnormal amount of undesirable wakelocks. Other apps require constant Internet access in order to operate in a normal fashion - Facebook and Messenger are probably the most popular representatives. They persistently request information from the web (the so-called "polling" for new events), which is causing subsequent wakelocks.
In other cases, an update to a given app can also cause certain issues, which usually result in partial wakelocks. The latter keep your CPU constantly humming in the background, sometimes without your knowledge, and prevent your device from "going to sleep". That's a pretty substantial prerequisite for anomalous battery drain. Thus, it is advisable to regularly monitor the wakelocks on your device and see which of your apps go harsh on our system's resources.
Read more at:
What-are-wakelocks-how-they-affect-the-battery-life-of-your-Android-device-and-how-to-Greenify
Reference: https://developer.android.com/training/scheduling/wakelock.html
It is needed when you don't want CPU to sleep when user locks the screen for example.
If you have an IntentService without acquired WakeLock it will pause after a while if user locks the screen and it will continue its work when user wakes a device. With WakeLock acquired your service will work even if the screen is locked.
As #My God mentioned, it impacts on battery life a lot, so, use it only when you really need to finish some operation and you cannot wait till user wakes a device.
I know foreground services have "unlikely to kill" behavior. According to Android documentation:
It is still theoretically possible for the service to be killed under
extreme memory pressure from the current foreground application, but
in practice this should not be a concern.
I think this solves the low memory concern for most cases. But I cannot find any documentation on whether the CPU goes to sleep while a foreground service is running.
Does a foreground service automatically acquire PARTIAL_WAKE_LOCK or one has to call it explicitly if needed?
Is there any way to check/log which application/services are using PARTIAL_WAKE_LOCK?
Android foreground service and PARTIAL_WAKE_LOCK have nothing to do with each other.
Foreground service -> it tells the OS to put your service in the highest priority queue. If OS needs memory for any reason, it will kill your service at LAST, and it will start with queue at lowest priority (I believe there are 5 priority queues, and foreground is the highest).
PARTIAL_WAKE_LOCK -> it tell the OS not to put the CPU to sleep when device goes to sleep (whenever this happen).
So, even if you have a foreground service, if device goes to sleep the cpu might go to sleep as well (it might not if some other app acquired a PARTIAL_WAKE_LOCK).
I don't think there is a way to check which applications acquired wake lock programmatically, but you can plug your device to DDMS and you will see PowerManager logs when someone acquires a wake_lock.
Hope it helps !
I am relatively new to Android, so what I am asking may seem obvious (although I have read all the similarly titled questions, and have searched extensively). I need to monitor the accelerometer continuously for long periods. Two approaches have been suggested:
1) acquire a partial wake lock that is held the entire time the acceleromtere is being monitored; and
2) monitor the accelerometer in a foreground service.
The first approach appears to use a lot of battery life. The second approach should result in a service that is only killed rarely, but I'm not sure what "rarely" means. Which approach should be used, and are there alternatives that I should consider?
Holding a WakeLock and a foreground Service are not really related and shouldn't be compared are to which direction is best.
Android OS is built to swap out processes based on a variety of factors. This means your process might get killed at any point by Android and it provides a framework to help you, the developer, to ensure your app can save and restore its state when this happens.
A WakeLock simply prevents the CPU from sleeping which helps save battery when the phone is not in use.
Now, a combination of both would help you achieve what you want but at great user cost. I wouldn't want an app in my phone to keep the CPU constantly running or a notification icon to show up constantly in the notification bar (that's what a foreground service does).
Keep in mind, starting a service in foreground mode does not guarantee your app will not get killed. It might still happen albeit rarely.
What is it you are trying to achieve here? Why keep monitoring the devices accelerometer? Perhaps you should only monitor it only when an Activity of your app is in the foreground instead.
I had exactly the same need and problem. I believe the solution is to use both a partial wake lock and a foreground service. Android will try not to kill a background service that holds a wake lock but is free to kill it when it needs the resources and possibly restart it later. That's fine for a lot of purposes but at least in my case that is not good enough. Putting a service into the foreground state is the way to tell Android that that killing it is unacceptable. Yes, it might still happen in extreme situations but that would now be a violation of the API contract whereas with a background service Android is free to kill it. You should therefore probably code as if that that will never happen but just know that this is a possible but probably rare error.
I'm writing an app with alarm functionality, i.e. it will have to continue running while the device goes into standby. Apparently, this is not the case. How can I achieve that?
It would be even better if I could prevent the device from going into standby at all - can I do that?
Android applications can prevent the device from going into standby with a wake lock but this should be used only for short periods of time for specific tasks which require the user to look at the screen without touching it.
For any other long time purposes, you have to use the system AlarmManager to schedule future actions of your application.
Using a permanent wake lock would make your app a battery drainer.
A service runs always, even in standby, so you should use it.
Preventing standby can be done with a wake lock. Be careful, there are only a few apps that should prevent standby (like games, video players...).