3
Planned

Add Keyguard Lock State Listener (API Level 33; Android 13)

New In Android 13:

KeyguardManager  |  Android Developers

Please add support for the new KeyguardLockedStateListener class so that, in addition to the, "Display Unlocked" we may also have, "Display Locked." From a security hardening perspective, this is an essential feature.

This allows for features like putting the device into a paranoid-level of security so that -- in the case of a malicious actor -- if someone uses known-exploits (via USB) to remove a user's secured lockscreen while the device is on and logged into, Tasker can protect the user. This, combined with amazing features like an "Overlay+/Allow Outside of Boundaries" Scene, allows us to add a secondary keyguard using Tasker to which there are no known (to me, at least) exploits to remove.

Other applications seem to accomplish this same end result without requiring API level 33 (Android 13), but this is the most proper way.

Follow

3 replies

Votes Newest Oldest
G

Could you also look into adding support for this in A12 and below? Even if they do not support the KeyguardLockedStateListener class, there might be workarounds.

I currently use some java code to determine the keyguard status, and use that task with the display off, on and unlocked events to set a %Locked variable.

The downside to this is that it really pollutes the log entries, making it difficult to diagnose other issues.

Comment
NB

If you're on a Samsung phone, you can create a profile with System -> Intent Received and for the action, input: 

com.samsung.keyguard.KEYGUARD_STATE_UPDATE

Then check the (automatically generated) variable %showing (true when keyguard is showing, false/unset otherwise). There are a couple other variables, but they're useless. It fires fairly often, so you cannot assume that it firing means the screen locked.

If it's a phone other than Samsung (and not Motorola since they use AOSP), then there may be other vendor-specific implementations.

As for this enhancement request, it's unlikely that Tasker will be approved for ROLE_ASSISTANT, do don't count on João completing it.

NB

Hey Joao,

There are a lot of scenarios actually. The top two most common include:

- Secure setting (Secure) lock_screen_lock_after_timeout > 0 ("Auto Lock When Screen Turns Off"). This is probably the most common.

- Google's SmartLock enabled and condition is met, so lock screen's "Device Secure" (or "Keyguard Secure", I forget) is false and will allow the keyguard to be dismissed without credentials.

There are very likely others, especially when you take into account a device that has a security app with Device Owner which then throws everything you know about the lock screen into chaos.

Comment

Hi Nick! Thanks for the request! Can you clarify in which situations the "Locked" event is not the same as the "Display Off" event?

Comment
NB

(See above comment too, but also*...)

... A good scenario (in the context of making a secondary lock screen) that is difficult to handle is when lock_screen_lock_after_timeout is greater than 0 and the display turns off. Now, if the user turns the screen back on before that timeout value is reached, it is very undesirable to the user to have to unlock that secondary lock screen just because there's no reliable and timely way to detect that the device never entered a secure state (keyguard shown). Sure, we could have timers and a bunch of fancy business, but Tasker's profile condition matching + task execution is far too slow for that. In the case of SmartLock, it is equally complicated.

(*I wrote this with the intent that "user" refers to someone using an App Factory version of my Tasker security hardening project, not a user of Tasker directly.)

Thank you! Ok, makes sense. I'll move this to my "Planned" list. Thank you :)

Reply