I’m doing an application that listens to the android.intent.action.SCREEN_OFF in a Service (if that matter) and then it is supposed to wait a few seconds and launch an action, I’ve tried a timer schedule method, thread and handler postDelay method but all of them seems to fail, they are never executed on a device, it seems like it’s being freezed/killed after phone is locked. It works on emulator and on device attached to USB, but never with device working on battery only, which actually is a main scenario.
Do you know any solutions to this?
I cannot test this now (not near my Android device at the moment), but...
Does the broadcast receiver fire at all?
If so, right as you get called, you will need to grab a partial Wake Lock so the CPU stays awake until the timer fires.
chances are you have your phone set so that when it is plugged in, it never actually locks or sleeps (its one of the developer settings) and imagine the emulator behaves the same way. so you will either have to override the phone's lock settings or change your method. the general rule is that when the screen shuts off, your activity ends.
A partial wake lock keeps the CPU running, so you should acquire it inside your broadcast receiver for screen_off, and release it after you're done with whatever you're doing. When you're plugged into the USB, the CPU stays on to service the USB connection (in fact, the usb stuff in the kernel holds its own wake lock).
And to answer your other question, yes, even background threads. As soon as everyone is done handling the screen_off broadcast, the CPU is turned off, and you won't run again until someone turns the CPU back on.
Related
My application have a realtime module that should ping the server every 60 seconds. Without this, the connection will be dropped and the device will need to reconnect again.
The first attempt was to use a Thread.Sleep to make the pinging thread runs at the desired frequency. The second attempt was to use the ScheduleExecutorService. Both worked very well, but only when the device was charging or with the screen turned on.
After reading a bit, I realized that this behavior happens because the device's processor sleeps and this interferes on the timers. So, the recommendation is to use the AlarmManager...
After start using it, I noticed the my device's screen started to be turned on frequently and I think that this is caused by the alarmmanager that 'wakes the device up'. I searched o bit to see how to use AlarmManager to execute some background actions even if the device is sleeping, without turning the screen on, but nothing was found.
So, there is anyway to use AlarmManager or other approach to accomplish this? Execute a background task even if the device is sleeping, without turning the screen on?
PS1: I know the battery consumption implications due this approach and the request about not turning the screen on is to minimize it's impact.
PS2: The AlarmManager's intent is being consumed by a background service.
Alarm Manager does not turn the screen on. From the docs,
When an alarm goes off, the Intent that had been registered for it is broadcast by the system, automatically starting the target application if it is not already running.
I am using it in my code and it does not turn the screen on unless I explicitly set a wake lock policy that turns it on. Take a look at WakeLock
The last 3 are deprecated as of API level 17.
I recommend you to use a PARTIAL_WAKE_LOCK for your task. or you can take a look at WakefulBroadcastReceiver
If you are using onReceive() method, that may be acquiring your wakelock. Remove the WakeLock parameter in onReceive().
i've got a problem with my Android FileObserver.
I have a background service running (returns START_STICKY), which references two FileObservers.
Everything is working fine until the device is set to sleep mode, which will stop the service, as far as i know.
Does anybody know what exactly happens to the Service/FileObserver when a device is put to sleep mode?
Can the service get notified before freezing so I can save a file list of the observed folder and compare it to a new list when the device gets waked up again?
I don't want to use a wakelock because of its impact on battery life.
Will the FileObserver Event be fired for changes to folders which happend while my service was set to sleep, as soon as I turn the screen back on?
That can't really test it because usb debugging keeps the device awake.
Thanks for your help!
Everything is working fine until the device is set to sleep mode, which will stop the service, as far as i know
No, it stops the CPU.
Does anybody know what exactly happens to the Service/FileObserver when a device is put to sleep mode?
The CPU is stopped. Stopped CPUs will not execute instructions. It is reminiscent of putting your development computer in suspend mode.
(the details are significantly more complicated but usually are not relevant at the SDK level, IMHO)
Can the service get notified before freezing so I can save a file list of the observed folder and compare it to a new list when the device gets waked up again?
No.
Will the FileObserver Event be fired for changes to folders which happend while my service was set to sleep, as soon as I turn the screen back on?
I haven't tried that.
That can't really test it because usb debugging keeps the device awake.
Then unplug the USB cable. Use Log statements to record the results that you wish to monitor. Plug in the USB cable after your test period to examine LogCat and see your logs.
Generally speaking, your overall solution (continuously-running service) is user-hostile. Please don't complain when users attack you with task killers and the Force Stop button.
I am developing an application that uses a Service as Contdown. When the user starts the countdown from the activity and the activity goes in background after the sleep button is pressed, I am using this Service to continue the countdown. When the count is finished the Service shows a notification with ringtone.
I use wait() "to count" the time in the Service. The strange behavior occurs when I use the application on a real device, but in debug mode. When Eclipse debugger is attached, the Service works well; when I test the application on the device without Eclipse debugger attached, the Service doesn't show the notification when the countdown is finished, unless the sleep button is repressed and the monitor is activated - then the notification and the ringtone are activated.
Can anyone can explain what causes this strange behavior? Maybe the issue is is related to Wake lock or a similar construct?
I use wait() "to count" the time in Service.
That is poor programming practice. Time elapses even without your tying up RAM to do it.
Anyone can explaine why this strange behavior?
The device fell asleep. This is normal, and desirable, behavior, to conserve battery life. With the USB cable plugged in, the device does not need to fall asleep, and if you checked the appropriate option in Developer Options, the device specifically will not fall asleep while plugged in.
Maybe is connected with Wake lock
Please do not use a WakeLock to keep the device awake for you to watch the clock tick by. Please use AlarmManager to get control when the countdown period is over. You can use a _WAKEUP-style alarm to arrange to wake up the device, and your BroadcastReceiver that gets control at that point can "launch a notification and ringtone". As a bonus, you can get rid of your service, so that your app can be better behaved on the user's device.
wait() calls are not guaranteed to wait for the right amount of time if the device goes to sleep. You should use AlarmManager to trigger your countdown timer instead.
I have created an app which will start a service. In my service, I created a timer that will do something periodically. I didn't use any wakelock.
After I press the power button and wait for sometime, it seems that my service still keeps printing something periodically into the eclipse( I keep the usb connected in order to see the message in eclipse).
So my service is still running and will never go sleep even the power button is pushed?Then it will keep draining the battery? Is that caused by the usb connection? Does anyone have such experience?
Keeping the phone plugged in prevents it from going to sleep. A better test would be to disconnect it from adb, wait until a couple of the timer intervals have passed, and then plug the phone back in and check logcat. I don't recall offhand if eclipse shows the time associated with each logcat message. If not, you can use adb logcat -vtime to get this information.
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.