Screen Unlock watcher

[8bitgentleman]

As I mentioned in #30 at this comment it would be very interesting to have a watcher that can track how many times the phone is unlocked and/or how many times the screen is turned on (ie to check if you have any notifications). It's a great metric to identify just how often you are checking your phone.

I'm no android developer but a quick look through the intents found several which could be useful
ACTION_SCREEN_ON
ACTION_USER_PRESENT
ACTION_USER_UNLOCKED

[johan-bjareholt]

Newer android versions with "Digital Wellbeing" has this feature and likely has some API for this. Whether it's an open API or not though I don't know, I was not able to find anything after som googling.

[8bitgentleman]

Looks like the code for google's Digital Wellbeing unlock counter live wallpaper is public, not sure if that would be helpful

https://github.com/googlecreativelab/digital-wellbeing-experiments-toolkit/tree/master/liveWallpaper

EDIT: Actually looks like they've got an Unlock broadcast receiver already put together as part of that app

[8bitgentleman]

Ran across another open source app that does something similar, Look Counter. Looks like that app shows how many times you have unlocked your phone as well as how many times you just turned on the screen to check notifications. Kind of interesting

Receiver which listens to SCREEN_ON, SCREEN_OFF, and USER_PRESENT events

Service which starts a receiver for the various intents

[nicolae-stroncea]

Turns out this might be a lot easier to implement than previously thought. The reason why these Apps listen to SCREEN_ON, SCREEN_OFF, USER_PRESENT is because they need to know instantly if a screen is unlocked.

AW doesn't have the same requirements. Instead it can use UsageStatsManager, as it does currently to look into the history of device events, which include KEYGUARD_HIDDEN event types:

An event type denoting that the screen's keyguard has been hidden. This typically happens when the user unlocks their phone after turning it on."

Note: I'm not sure why the documentation says "typically".

As a test, I queried KEYGUARD_HIDDEN events on my phone over the past week, and they matched exactly the number of unlocks as reported by ActionDash on each day. Unfortunately, I couldn't query more, since ActionDash requires a premium to look further back in the past.

ActionDash has a backup feature which backs up the internal state as a sqlite database, and that's all you need to restore the App. Each row in the database contains following columns: id, applicationID,type,timestamp,className.

These are the only event types it stores:

CHOOSER_ACTION
CONFIGURATION_CHANGE
KEYGUARD_HIDDEN
KEYGUARD_SHOWN
MOVE_TO_BACKGROUND
MOVE_TO_FOREGROUND
NOTIFICATION_INTERRUPTION
NOTIFICATION_SEEN
SCREEN_INTERACTIVE
SCREEN_NON_INTERACTIVE
SHORTCUT_INVOCATION
USER_INTERACTION

Since it doesn't contain anything else to reconstruct the 'unlocks' it's reasonable to expect the unlocks are based entirely on KEYGUARD_HIDDEN or a combination of KEYGUARD_HIDDEN and some other UsageStats Event types (perhaps checking the previous/next event?).

I think given the documentation for KEYGUARD_HIDDEN and the reliable testing results (admittedly on only 7 days) the most obvious implementation for now is to just check the event type is KEYGUARD_HIDDEN, consider that an unlock, then just send the event to a bucket of unlocks. I'm not sure if checking for a combination is as reliable, especially since the documentation doesn't give a guarantee of a certain order, and because the order of events might change with updates.

I think this could be implemented directly in UsageStatsWatcher, since the event is part of UsageStats so it would make sense from an architecture standpoint. This implementation looks fairly straighforward to implement, as it only requires checking the even type and then sending the event to an unlock bucket

[nicolae-stroncea]

@johan-bjareholt what are your thoughts on this approach? I can send a PR for it if you think this is the way to go

[johan-bjareholt]

@nicolae-stroncea Sounds really good, we could create a new bucket for that type of events and making a query that simply sums the amount of events and displays it in the web-ui should be trivial.