14

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?

Nikolai Samteladze
  • 7,699
  • 6
  • 44
  • 70
zer0stimulus
  • 22,306
  • 30
  • 110
  • 141

5 Answers5

21

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.

LarsH
  • 27,481
  • 8
  • 94
  • 152
CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Would you know if there's a way to get notified when the device gets into any of these 3 states? – zer0stimulus Feb 15 '11 at 20:03
  • 3
    @zer0stimulus: Not really. It is difficult to tell you that the CPU is powered down for sleep mode, because the CPU is powered down for sleep mode. Similarly, it is difficult to tell you that the device is shut down, because the device is shut down. There are some broadcast `Intents` that are somewhat related to these states (e.g., `ACTION_SCREEN_OFF`), but that's about it. – CommonsWare Feb 15 '11 at 20:19
  • 1
    how long will the device stay awake? should we aquire a wake lock immediately after reading from the socket to process the message? – Erdal Mar 20 '11 at 05:50
  • Thank you for this information. Can you give me a link, please, where this is described in the documentation? I mean the events that can wake the device up. – CITBL May 22 '11 at 07:21
  • @smsrecv: "Can you give me a link, please, where this is described in the documentation? I mean the events that can wake the device up." -- sorry, there is no such link. Hence my "there might be others" statement. – CommonsWare May 22 '11 at 10:59
  • 1
    @CommonsWare - Deep sleep is an actual state. See http://developer.android.com/reference/android/os/SystemClock.html#uptimeMillis() for example. – Erez A. Korn Nov 07 '11 at 10:37
  • @ErezA.Korn: That's the only page I can think of that refers to it as "deep sleep". Generally, it's simply "sleep". More importantly, unlike some devices/OSes, there is only the one sleep level (vs. separate "sleep" and "deep sleep" states). – CommonsWare Nov 07 '11 at 12:14
  • 1
    I believe incoming packet on open sockets won't wake up the device whether on Wi-Fi or on RAN (radio access network). Not to mention that periodic application level data must traverse the socket in order to keep it open otherwise WAP gateway will kill your connection. – Zamel Mar 21 '12 at 11:35
  • Disclaimer on my previous comment: a server socket (set to receive) would wake up on incoming packets. – Zamel Mar 21 '12 at 12:01
  • @CommonsWare if the process is killed using force stop will an alarmManager or jobscheduler job create a new process to do background execution. – KingKongCoder Oct 01 '17 at 19:48
  • 1
    @randomaspirer: Presumably yes, since each should involve an explicit `Intent`. That being said, I have not tested these scenarios. – CommonsWare Oct 01 '17 at 19:49
  • @CommonsWare i have tested this with notification, normally notifications are displayed but after i do force stop the notification is not displayed which means alarm in not triggered, is there any specific thing that i should handle in this kind of situation. I am using alarmManager with 1 minute intervals which is default batch minimum time, the device is active not in sleep mode. – KingKongCoder Oct 01 '17 at 21:04
  • 1
    @CommonsWare got the answer from your book, it says from Android 3.1+ nothing will happen after force stop unless we schedule it again when the user opens the application. Does this mean that process is killed and not recreated for alarm manager events. – KingKongCoder Oct 01 '17 at 21:12
  • 1
    @randomaspirer: Ah, yes. I was focused on whether the app's components would run and forgot about the fact that the alarms and jobs would be deleted. Sorry about that! – CommonsWare Oct 01 '17 at 21:22
4

I've noticed the following behaviour:

  1. You have your activity open and stop interacting with it

  2. 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.

  3. 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.

Pedro Loureiro
  • 11,436
  • 2
  • 31
  • 37
1

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.

Nikolai Samteladze
  • 7,699
  • 6
  • 44
  • 70
user728732
  • 15
  • 6
  • 2
    Funny, because at the end of http://groups.google.com/group/android-developers/browse_thread/thread/9e2878053a422718 Mark Murphy specifically states that `TimerTask` "does not prevent the device from going to sleep and does not wake the device back up." – Giulio Piancastelli Dec 14 '11 at 16:42
1

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

  1. API 24 added more complexities to the Doze mode (Light Doze and Deep Doze). This essentially puts nested states inside the device states.
  2. API 28 added "Adaptive Battery" prediction, which makes use of Doze to hibernate user apps the OS determines the user will not use.
  3. API 28 also added "App Standby Buckets" to add more states to App Standby than just idle and active.
user6574932
  • 61
  • 1
  • 5
0

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":

  1. awake
  2. dim
  3. screen off
  4. CPU off (true "sleep" or "deep sleep")
  5. 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.

LarsH
  • 27,481
  • 8
  • 94
  • 152