I am developing an android application and I want to reduce the power consumption. The method I believe is to put the phone into sleep mode whenever the user activity stops for a certain threshold period. I have three questions regarding this.
If I release the wakeLock and no other application is holding the wakeLock after how much time would the phone go to sleep?
I have multiple HandlerThreads running where I use sendMessageDelayed() function. Would these messages get delivered even after the phone goes to sleep mode?
Does putting the phone into aeroplane mode save more power rather than just putting the phone to sleep. if yes, then why is it because the only difference in those two modes is the use of cellular network.
If I release the wakeLock and no other application is holding the
wakeLock after how much time would the phone go to sleep?
There really is no definitive answer, but, from personal experience, I'd say it is likely that it will happen within 30 seconds to 1 minute.
I have multiple HandlerThreads running where I use
sendMessageDelayed() function. Would these messages get delivered even
after the phone goes to sleep mode?
I really wouldn't count on it because I've never seen anything that says it will wake up the device to send said Message. You can always test it, but I wouldn't trust it to work because the documentation does not claim that it will.
Does putting the phone into aeroplane mode save more power rather than
just putting the phone to sleep. if yes, then why is it because the
only difference in those two modes is the use of cellular network.
If you put it into sleep mode AND airplane mode, then you will save more battery than JUST sleep mode.
The reason for that is that even with the CPU pretty much asleep, the phone must keep a constant connection with the cellular network in order to know if you get a text or phone call. To do this, it must use the battery to constantly keep the antenna turned on. If you put it into airplane mode, it would basically turn the antenna off, and then the phone would not be using battery for that function.
Related
Our company is developing an android application that uses network communication to send GPS signals from devices. The devices are the same and they are all work tools, so we do not have to worry about battery draining, or etc. Currently the activity has a thread, which communicates with the server. The problem is that when the device is locked and it goes to sleep, the network communication breaks.
I've tried to put a partial wake lock to the onPause method to keep the CPU on, and release the wakelock in the onResume method, but it seems not to work. Any idea how to prevent the sleep, or keep flowless communication between the client and the server?
Unfortunately, it is the new behavior, You can read here:
https://developer.android.com/about/versions/nougat/android-7.0-changes.html
See the Doze section.
When a device is on battery power, and the screen has been off for a certain time, the device enters Doze and applies the first subset of restrictions: It shuts off app network access, and defers jobs and syncs. If the device is stationary for a certain time after entering Doze, the system applies the rest of the Doze restrictions to PowerManager.WakeLock, AlarmManager alarms, GPS, and Wi-Fi scans.
It can be solved by using Foreground Service like mentioned above in comments by #egoldx.
It is surely a bad practice to try holding a wakelock, even partial, all the time.
I have a scenario that the android device exchanges data with a FTP server via Roaming service. I hope to make OS enter proper sleep mode by setting WakeLock type during the data transferring because it really has no interaction with enduser.
I am going through the sleep threads and trying to verifying that what units will be shut down in sleep mode to prevent data sending. So far, no official doc indicates them .
So , Would you please help to enlighten me on the questions: When Android enters sleep mode , what components will stop working , like WIFI , Data Roaming ?
Thanks a lot.
When Android enters sleep mode, almost everything is shut off. Only basic system apps and GSM/CDMA radios are left on to receive texts, calls, push notifications etc. Services, Activities are all shut off, and the CPU is put into a low power mode. Depending on what the user chose in the wifi settings, the wifi connection may or may not switch to mobile data or shut off completely.
If you want to keep processing, but don't need the screen on to interact with the user, you should acquire a PARTIAL_WAKE_LOCK in which the screen and keyboard are off, but the CPU is kept on. However, remember to release the wake lock when you are done, as PARTIAL_WAKE_LOCK is the only one of the four wake locks in which the CPU will continue to run until you release it or your app is killed. Forgetting to release the wake lock can be a huge drain on the user's battery.
When the power off button (lights off) is pressed by user then phone into sleep mode.
Sleep mode means CPU will be in sleep mode and will accept only command from radio interface layer and alarms. Within fraction of seconds the CPU will go into sleep mode.
When we need only CPU on and other things off we use PARTIAL_WAKE_LOCK which suits perfect in your scenario. Weather this lock is generally used in apps like mp3 player etc.
As you want data transfer here in this mode then you have to override already given methods from class PowerManager with specifically by allowing some function to be turned on in this mode.
I have service running in android to sync files when user wants.
This is not a 24/7 service, only runs for a period of file transfers over wifi, so the user when done transferring files quits the app and therefore the service exits.
So the scenario could be that user has left the mobile and it might get locked/screen off automatically.
Regardless of screen on or off is there a way to ensure wifi is always performing the same with low latency ?
There are multiple apis in relation to this, Wifi lock, Wifi-sleep-policy, screen lock .. People seem to use a combination of them to keep good wireless performance .
Is wifi lock enough to ensure it ? or do I need to use combination of APIs ?
Thank you.
EDIT: this post was helpful
PARTIAL_WAKE_LOCK vs SCREEN_DIM_WAKE_LOCK in download thread
To be on the safe side, a WifiLock as well as a WakeLock would be optimal, with the WakeLock being the more important lock to aquire. The WakeLock ensures the device stays on, and the WifiLock ensures the radio is operating. This should ensure consistent latency. However, you can't expect anything when it comes to data transfers so have your app be ready to handle random connection losses.
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
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.