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.
Related
According to Android docs:
A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.
But my service get killed very quickly - around 10 seconds - when the user leaves the app or the screen gets turn off. It seems according to Android Kotlin Foreground Service stops after some time that you need some sort of mechanism to prevent the phone from getting in doze mode.
So, what is the purpose of having a service without a wake lock? And why does the documentation never mention something remotely related to wake lock when dealing with services?
You can have a Service that is doing work for an Activity. If the user navigates away from the app or dims the screen or ignores his phone long enough for it to be clear that he isn't looking at it, what is the point of the Service continuing to run? The user isn't looking at the Activity, so processing in the Service is not important enough to keep the phone from sleeping.
On the other hand, if you have a Service that is performing important work and you need to keep the phone from going to sleep, then you obviously need to get some kind of wake lock or use some other method to keep the phone on.
These are 2 different scenarios with different requirements.
I used this application from play store to identify the applications holding CPU locks and turned out almost entire suite of google apps along with a few third party application have acquired CPU wake locks.
I am amazed that even google was using it extensively while it discouraged holding it as it drains battery. Kind of defeats the purpose of wake triggers if cpu never goes to sleep.
So I was wondering whether the no of applications holding the cpu wake lock affects the performance if most of them are just network application waiting for a server response.
because if it doesn't then the recommended practise of not to acquire it would mean nothing in practical devices as some application would likely be holding the wake lock, and when its google apps themselves you won't wanna avoid it anyway.
It's not really a matter of how many apps have wake locks, but rather how they are being used. If the wake lock is only used in small windows (eg acquired for a short period of time) then its impact should be minimal. Google recommends not using them because they can be easily abused or forgotten to be released, thus preventing the system from sleeping.
Starting with marshmallow, the use of wake locks is mitigated by the platform when on battery and idle as doze mode ignores wake locks.
Let's say an Android application acquires a wake-lock, and then launches another application by sending it an explicit intent. Does the effect of acquisition of wake-lock last while the other application is in the foreground ?
As described in Keeping the Device Awake it's perfectly natural for a background application to grab and hold a CPU wakelock:
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.
This action is pretty common. For example, imagine a music playing application. Even though the screen is off, or some other activity is in the foreground, it's fine for a background application to hold a wake lock to keep playing music.
Although that last line should really take a warning. As described in Wakelocks and Battery Drain those things tend to burn through battery pretty fast; and worse yet, is that it's a pretty common problem to not release them properly, and end up putting the device into a sleepless mode, where it never goes to sleep.
I am currently developing an app that runs a service from time to time. Currently, the service acquires a wakelock, reads some sensors and sends some information over WIFI (if any). Now what I want to know is weather a wakelock influences sensors and connectivity or not. Is it possible to do these tasks without any wakelock?
Cheers
A wake lock is essentially used to lock the device in an "awake" state, in which the CPU will be on, and the screen may or may not be on.
It is not possible to do these tasks without a wakelock if the phone is in sleep otherwise, as then the CPU is also in sleep mode. However, if the user is using the device for something else, and your app is in the background, you can do these tasks without a wakelock.
Keep in mind that almost everything you're doing is battery intensive (sensors, WiFi, wakelock) and you should not do it too often so that you don't degrade the user's battery life.
The rules for holding cpu partial wake locks are very vague. Can someone explain when and why we should acquire one? When can the system decide the service should be suspended while doing some work on a thread?
I would like to understand the details of the cpu scheduler / activity / service manager.
Is the best place the android source code? if so which package?
Can someone explain when and why we should acquire one?
You acquire one when you need the CPU to stay running to complete some bit of work. You release it when that work is done.
So, for example, suppose you have an IntentService triggered by AlarmManager. You want the IntentService to check for new email messages for your email client. You would want to acquire a WakeLock so the CPU will not fall asleep while you are in the middle of doing that, then ensure that you release it. This sort of pattern is why I created the WakefulIntentService.
When can the system decide the service should be suspended while doing some work on a thread?
The fact that you are doing "some work on a thread" is immaterial. The CPU will fall asleep based on user inactivity. If the user is not keeping the device awake, and you are not keeping the device awake with a WakeLock, the device will fall asleep.
Having the CPU fall asleep is very important for power consumption. If you, say, decide that you are going to keep the CPU running 24x7, the battery will run dry relatively quickly.