Replacing ACTION_SCREEN_ON withy ACTION_USER_PRESENT?

Question

I have a long-running service listening for sensor input. To conserve battery power, I've stopped the sampling of the sensors on ACTION_SCREEN_OFF and started it back up again on ACTION_SCREEN_ON.

Often, however, I just turn my phone on for a quick glance at the clock on the lock-screen (to check the current time) and then turn it off again without unlocking the phone. In that case, there's no reason to spin up the sensors just to shut then down again at once.

So therefore I tried replacing ACTION_SCREEN_ON with ACTION_USER_PRESENT in my broadcast listener. This worked fine except for one special case: When the screen goes off and I press the power button (or home button) at once, the lock screen is skipped. And then the ACTION_USER_PRESENT is never received, only the ACTION_SCREEN_ON.

Is there a way for me broadcast receiver, upon receiving an ACTION_SCREEN_ON to know if the screen-lock is active and to expect a ACTION_USER_PRESENT later? Or if the lock-screen is skipped, not to wait upon ACTION_USER_PRESENT and go ahead and restart the sampling at once?

Answer 1

Till Android 4.4, if screen is turned on and lock screen is disabled, only ACTION_SCREEN_ON is fired. Frm Android 5.0, in this case, both ACTION_SCREEN_ON and ACTION_USER_PRESENT are fired.

Answer 2

I have a long-running service listening for sensor input.

Bear in mind that users don't like "long-running services", and unless you are using startForeground(), Android may shut down your service.

I've stopped the sampling of the sensors on ACTION_SCREEN_OFF and started it back up again on ACTION_SCREEN_ON.

Unless you are using a WakeLock, the device should still fall asleep while your sensor listener is registered. I'm not sure you are gaining anything by the ACTION_SCREEN_OFF/ACTION_SCREEN_ON stuff.

is there a way for me broadcast receiver, upon receiving an ACTION_SCREEN_ON to know if the screen-lock is active and to expect a ACTION_USER_PRESENT later?

You can try inKeyguardRestrictedInputMode() on KeyguardManager. That looks like it should work, though I have not tried it.