Develop Reference

Is wake lock commutative?

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.

Android: When is WakeLock needed?

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.

Tips for reducing battery drain for android services?

I wrote an app recently and, well I'm quite disappointed about how much battery the service consumes. I go to make a call yesterday to find my battery is at 9%; I check the android system statics for the battery and find that my app is responsible for 60% of the battery drainage
My question is, what can one do to reduce the battery usage on an app that runs and then sleeps for 60 seconds? The service is reading from a SQLite database; I could cache the data, but would that really account for that much battery usage? What are some standard ways to reduce battery drainage in a service?

You should look into using AlarmManager to schedule your app or service to be called when necessary. This has a big advantage over your current wake lock method, because even a partial wake lock will keep the CPU running. An AlarmManager alarm can wake the phone even from CPU sleep.
Basically, get rid of your existing wake lock and schedule an AlarmManager alarm—which can repeat once a minute, if that's what you need—to wake up the device, if necessary, and send you a message.
The AlarmManager itself will take out a wake lock while calling an onReceive() method to notify you of the alarm, and relinquish it when onReceive() finishes, letting the phone go back into deep sleep if it wants to.
Note that this means that if you want to do extended work—e.g. firing something off on a background thread—you'll probably want to take your own wake lock out in onReceive() and relinquish it when your work is done, otherwise the phone may go to sleep while you're in the middle of the work.
This is all pretty well-explained in the AlarmManager docs, but the best explanation I've seen is in Mark Murphy's The Busy Coder's Guide to Android Development; he also provides a library for exactly this pattern on Github. Definitely worth a look.

what is the difference between Sleep mode and Deep sleep mode?

I would like to know what is the difference between Sleep mode and Deep sleep mode in android phone and what will be the impact of when phone goes to sleep mode and deep sleep mode.
Please provide me the answer in details.
regards,
Piks

Deep sleep mode doesn't have anything to do with hibernate and boot time, as somebody wrote in deleted answer.
You should not avoid the phone sleep, this will drain your battery very fast. To receive messages from server, you should use [C2DM] GCM which has the same basic characteristics as old fashion deprecated C2DM.
More info about the android sleep here:
http://developer.android.com/reference/android/os/PowerManager.html

You can use WAKE_LOCK to prevent device going to deep sleep. But you must take into account battery drain. More info: http://developer.android.com/reference/android/os/PowerManager.html

Deep sleep: turns your phone CPU central processing unit ie brain to the lowest clock cycle speed. On mine it is 200mhz, where max is 1600mhz.
it also disables some sensors it figures you might not be using, such as dependin on phone camera, gyro, etc. some of it gets shut off to save power.
When you wake up your phone depending on governer, it rams cpu clock cycle up to 500mhz, or 800mhz, or 1600mhz, and re activates the sensors, sending power back to the camera, cyro, magnet, etc that your phone may have proxi sensor
This is more or less what deep sleep really IS. program, to save power, by disableing unused sensors, and clocking cpu way down to minimum.
Credits: vrigil kellogg http://forums.androidcentral.com/sprint-galaxy-s-iii/247066-what-deep-sleep.html post#14

Android: Sleep stages/levels on an Android device?

Is there a notion of sleep stages/levels on Android?
From browsing the mailing lists, I'm aware that there exist a stage called "Deep Sleep". Do execution for all apps halt when device reaches this state? If so, besides user hitting the power button, what else could wake the device back up?

From browsing the mailing lists, I'm aware that there exist a stage called "Deep Sleep".
There is not really a separate stage called "deep sleep". There is only "awake", "asleep", and "off".
Do execution for all apps halt when device reaches this state?
Execution of all processes ceases when the device goes to sleep or is powered off.
If so, besides user hitting the power button, what else could wake the device back up?
An alarm from AlarmManager
An incoming phone call
An incoming text message
If you have a socket open on wireless data (not WiFi), an incoming packet on that socket
Those are the big ones. There might be others.

I've noticed the following behaviour:
You have your activity open and stop interacting with it
After a few seconds (it depends on how the device is configured) the screen will go off.
When the screen goes off, onSaveInstance and onPause are called.
A few seconds later (usually ~15s) the device enters into sleep mode (is this the correct name?)
When this happens, the following methods are invoked: onStop (calling isFinishing returns false), onRetainNonConfigurationInstance and onDestroy.
So far so good. Now, the strange behaviour begins: just after the last onDestroy finishes, another activity is created: onCreate, onStart, onRestoreInstanceState, onResume and finally onPause are invoked.
I find no reason for this strange behaviour. Why would another activity be created just to go straight to pause mode? This happens immediatly after onDestroy of the original activity!
This was tested on Galaxy S. I didn't test what happens after a few hours with no activity. I'm not sure if anything else will happen.
I hope this will help you.

A short addition to the commonsware's list. After looking for a way to run methods periodically while phone is asleep, I've found out that TimerTask functions during sleep mode.
TimerTask is, in my experience, easier to work with if all you want is to run methods from a service and not to start an activity.

In Android API 23 the way 'sleep' works was been changed. They have added Doze and App Standby. You can read about both of them here.
Doze: This would be 'sleep'. A few minutes after the screen shuts off the phone will enter this mode shutting down all network connections. Then at certain intervals (maybe a linear back-off policy for example) the apps will be 'allowed' to access the network for ~10 seconds. There is no real way around this if you want to publish your app to Google Play outside of using Google FCM. It might also be worth noting that uptimeMillis is not guaranteed to be updated during Doze because the CPU can enter deep sleep mode (elapsedRealtime will still be accurate).
App Standby: This will essentially stop your app if the device determines that the app is 'idle'. An idle app is a state that is determined by these factors
Has the app been launched by the user?
Has the app run a foreground service?
Has the app generated a notification?
Is the app an active device admin app?
If the answer to all of these is no, the app will be set to 'idle' and have greatly restricted network access (allowed once a day and/or while charging only). I am not sure how long an app must meet these criteria. However, it seems to be at least a few days before the App Standby state will be entered.
Bonus: Device States (managed by DeviceIdleController)
ACTIVE - In use, or connected to a power source.
INACTIVE - Device has come out of the active state (user turned off the screen or unplugged it)
IDLE_PENDING - About to enter idle mode.
IDLE - Device is idle (Different than an app being flagged as idle from App Standby. This is the entire device.).
IDLE_MAINTENANCE - Open for applications to do processing (10 second window).
If you want a background service or worker to check if the app is in the IDLE state then you can use the function isDeviceIdleMode (only works when entering Deep Doze, see below).
Example
(getSystemService(Context.POWER_SERVICE) as PowerManager).isDeviceIdleMode
Some more complications
API 24 added more complexities to the Doze mode (Light Doze and Deep Doze). This essentially puts nested states inside the device states.
API 28 added "Adaptive Battery" prediction, which makes use of Doze to hibernate user apps the OS determines the user will not use.
API 28 also added "App Standby Buckets" to add more states to App Standby than just idle and active.

Besides the "awake", "asleep", and "off" states that #CommonsWare mentioned, there is the distinction between whether the CPU is asleep, or just the screen is. For example, the official docs here describe it this way:
To avoid draining the battery, an Android device that is left idle
quickly falls asleep. However, there are times when an application
needs to wake up the screen or the CPU and keep it awake to complete
some work. [emphasis added]
In the three-stage framework that CommonsWare described, a device whose screen is dark is probably not categorized as "asleep" unless the CPU is also stopped. But as the above paragraph implies, the screen-dark state can legitimately be referred to as "asleep." No doubt this is why people refer to "deep sleep" to clarify that they're talking about the CPU being asleep.
This doc page also mentions
When an Android device is left idle, it will first dim, then turn off
the screen, and ultimately turn off the CPU. This prevents the
device's battery from quickly getting drained.
So if you want to be comprehensive, you could add "dim" to the list of "sleep stages/levels":
awake
dim
screen off
CPU off (true "sleep" or "deep sleep")
power off
Apparently the transition from 2 to 3 to 4 is pretty fast when the idle timeout occurs. But there are other times when the screen can be off without a transition to deep sleep; e.g. when playing audio (at least in certain apps).
I wish I could tell you how to predict when the device will transition from screen off to CPU off -- e.g. how long the timeout is -- but I haven't found that information. What I have found is FLAG_KEEP_SCREEN_ON and WAKE_LOCK to prevent one or the other from happening.
P.S. If you want to be exhaustive, you could count daydream in your list of "sleep stages":
Daydream is a new [as of Android 4.2] interactive screensaver mode for Android devices. It
activates automatically when the device is inserted into a dock or
when the device is left idle while plugged in to a charger (instead of
turning the screen off).
From the point of view of the previously-running app, it sounds like daydream behaves like switching to a different app. So it's not really a matter of the device sleeping, though your activity does get stopped, I would assume.