I have question about wakelock. In cases shown below, does android OS release wakelock (PARTIAL_WAKE_LOCK
if you need to specify) to prevent wakelock was left acquired and wasting battery until turning power off (not sleep).
Case 1-a:
App has acquired wakelock (w/o timeout option) in one of its threads (please think it is reasonable in this case) and it was designed to release wakelock when critical task was finished. App can be killed by taskmanager or notorious taskkiller, and app has no chance to let its thread release wakelock. What happens to that wakelock?
Case 1-b:
(If answer to case 1-a is "Yes, don't worry", then please ignore this case.)
Same as case 1-a but app gave timeout option to wakelock, say 3 seconds. Is this timeout option kept valid?
Case 2-a:
Please imagine there is a service which was started by AlarmManager (via Broadcast receiver) and the service has acquired a wakelock (w/o timeout option). This service is designed to make wakelock-acquired-time minimum. But unfortunately, Android OS picked this service to kill due to memory crunch. (I don't know if OS won't kill service when wakelock is acquired, but I guess OS doesn't care. But I hope OS will release wakelock later.) What happens to that wakelock?
Case 2-b:
(If answer to case 2-a is "Yes, don't worry", then please ignore this case.)
Same as case 2-a but service gave timeout option to wakelock, say 3 seconds. Is this timeout option kept valid?
WakeLock Implementation Overview
When we use
pm.newWakeLock
to create a new wakelock, thePowerManager
simply creates a new WakeLock object and returns. The WakeLock object is not a binder object, so it cannot be used through multiple processes. However, in that WakeLock object, it contains a Binder object named mToken.So when you call acquire or release on this WakeLock object, it actually passes that token to
PowerManagerService
.Look at how
PowerManagerService
works when acquiring or releasing a wakelock will help you answer your question.The key statement is the
lock.linkToDeath(wakeLock, 0);
. Thatlock
is exactly the mToken we mentioned before. This method registers the recipient (thewakeLock
) for a notification if this binder goes away. If this binder object unexpectedly goes away (typically because its hosting process has been killed), then thebinderDied
method will get called on the recipient.Notice that the WakeLock in
PowerManagerService
is different from the WakeLock inPowerManager
, it is an implementation ofIBinder.DeathRecipient
. So check out itsbinderDied
method.The
handleWakeLockDeath
will release that wakelock.So I think in both cases in your question, the answer is don't worry. At least in Android 4.2 (where the code comes from), it is true. Moreover, there is a finalize method on the WakeLock class in
PowerManager
, but this is not the key to your question.I would assume (I don't know this for certain) the Android system does not keep wakelocks for killed processes. Most likely when it kills a process with sigkill it also removes any wakelocks held by that process.
Otherwise, as you say, crashes would lead to the phone always being awake, which I have not observed.