Question

My android application requires a password to be entered in the first activity. I want to be able to automatically send the application back to the password entry screen after the application has been idle for a fixed amount of time.

The application has multiple activities, but I would like the timeout to be global for all activities. So, it wouldn’t be sufficient to create a timer thread in the onPause() method of an Activity.

I’m not sure what the best definition for the application being idle is, but no activities being active would be sufficient.

Answer 1

I know another answer is accepted already, but I came across this working on a similar problem and think I’m going to try an alternate much simpler approach that I figured I may as well document if anyone else wants to try to go down the same path.enter code here

The general idea is just to track the system clock time in a SharedPreference whenever any Activity pauses – sounds simple enough, but alas, there’s a security hole if that’s all you use, since that clock resets on reboot. To work around that:

• Have an Application subclass or shared static singleton class with a global unlocked-since-boot state (initially false). This value should live as long as your Application’s process.
• Save the system time (realtime since boot) in every relevant Activity‘s onPause into a SharedPreference if the current app state is unlocked.
• If the appwide unlocked-since-boot state is false (clean app start – either the app or the phone restarted), show the lock screen. Otherwise, check the SharedPreference‘s value at the lockable activity’s onResume; if it’s nonexistent or greater than the SharedPreference value + the timeout interval, also show the lock screen.
• When the app is unlocked, set the appwide unlocked-since-boot state to true.

Besides the timeout, this approach will also automatically lock your app if your app is killed and restarts or if your phone restarts, but I don’t think that’s an especially bad problem for most apps. It’s a little over-safe and may lock unecessarily on users who task switch a lot, but I think it’s a worthwhile tradeoff for reduced code and complexity by a total removal of any background process / wakelock concerns (no services, alarms, or receivers necessary).

To work around process-killing locking the app regardless of time, instead of sharing an appwide singleton for unlocked-since-boot, you could use a SharedPreference and register a listener for the system boot broadcast intent to set that Preference to false. That re-adds some of the complexity of the initial solution with the benefit being a little more convenience in the case that the app’s process is killed while backgrounded within the timeout interval, although for most apps it’s probably overkill.