Question

My application relies on the intent ACTION_USER_PRESENT being fired, and so I set up a receiver in the manifest and I have a class that starts a service when it receives the intent.

However, when a user is using a lock-screen replacement app like WidgetLocker, the ACTION_USER_PRESENT intent may never be sent, or can be sent a bunch of times. (Once it was sent 5 times…) WidgetLocker’s website explains that the application does send its own intent for unlocking, com.teslacoilsw.widgetlocker.intent.UNLOCKED. In certain configurations of WidgetLocker, ACTION_USER_PRESENT may be fired before the user even unlocks the screen, so I was told that it would be best to set up a check for com.teslacoilsw.widgetlocker.intent.LOCKED, and then wait to receive the UNLOCKED intent and do my work.

My problem is that I’m not sure how to set up a receiver for a third party intent. I’ve added the actions to my receiver in the manifest just find, and I know that my broadcast receiver picks them up, but I need to filter them out. Mainly, if I pick up the LOCKED intent, I want to ignore any ACTION_USER_PRESENT intents, and instead wait for the UNLOCKED intent, but I don’t know how to wait for an intent upon receiving a different one.

Answer 1

Mainly, if I pick up the LOCKED intent, I want to ignore any ACTION_USER_PRESENT intents, and instead wait for the UNLOCKED intent, but I don’t know how to wait for an intent upon receiving a different one.

Step #1: Create separate BroadcastReceivers for the WidgetLocker actions vs. ACTION_USER_PRESENT.

Step #2: Upon receipt of LOCKED, use PackageManager and setComponentEnabledSetting() to disable your ACTION_USER_PRESENT receiver.

Step #3: Upon receipt of UNLOCKED, use PackageManager and setComponentEnabledSetting() to re-enable your ACTION_USER_PRESENT receiver.

This could get a bit dicey in edge cases (e.g., user pops out the battery while LOCKED), but it’s a starting point.