Quite a few android applications have to authenticate users and as a security measure have to implement a timeout logic to ensure that the user is signed out of the application. I have seen implementations where in a thread is started and it periodically posts a message to main thread's handler and thats one way to sign out the user. The downside is the extra thread, context switch, additional application logic etc.
Android's Activity Manager had a hidden feature which can be used for applications implementing a 30 minute timeout. The original idea behind this feature is that when user performs a task like sending an email with a picture attachment, its possible that the user might have to do something else while in the gallery activity (to attach the picture), the entire task could be pushed to background and user might return to this task later on. In this case, the odds of the user remembering as to why the gallery activity was open is less, should he return back to the task after a while (30 minutes as per Android Framework). Hence the framework developers decided to implement a automatic time based force finish of activities in all tasks.
Now, this shouldn't be the case for all tasks like a list view of mails and a detailed view of a mail which makes more sense to the user and there shouldn't be any reason to finish the detailed view. This differentiation is based on an activity property, taskAffinity. Activity Manager never tried to finish activities belonging to the same taskAffinity.
So how could this feature be reused for login based applications? Well, the login activity could be of a specific affinity and all other activities in the application (which requires authentication) could be of a different affinity. And thats the only application code needed, and it worked like a charm. Now, if the user moves on to a different application from an authenticated activity, Activity Manager would take care of restoring the application to Login screen, should the user return back to the application after half an hour.
LoginActivity
android:name="com.example.loginapplication.app.LoginActivity"
android:label="@string/title_activity_login"
android:taskAffinity="com.tuto.loginapplication.primary"
SettingsActivity
android:name="com.example.loginapplication.app.SettingsActivity"
android:label="@string/title_activity_settings"
android:taskAffinity="com.tuto.loginapplication.secondary"
This app was based on Gingerbread and worked as expected. However, later versions of Android doesn't behave as per android's documentation (Clearing the back stack)
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, only the root activity is restored.
Turns out that this feature was disabled by 621e17de87f18003aba2dedb719a2941020a7902
Android's Activity Manager had a hidden feature which can be used for applications implementing a 30 minute timeout. The original idea behind this feature is that when user performs a task like sending an email with a picture attachment, its possible that the user might have to do something else while in the gallery activity (to attach the picture), the entire task could be pushed to background and user might return to this task later on. In this case, the odds of the user remembering as to why the gallery activity was open is less, should he return back to the task after a while (30 minutes as per Android Framework). Hence the framework developers decided to implement a automatic time based force finish of activities in all tasks.
Now, this shouldn't be the case for all tasks like a list view of mails and a detailed view of a mail which makes more sense to the user and there shouldn't be any reason to finish the detailed view. This differentiation is based on an activity property, taskAffinity. Activity Manager never tried to finish activities belonging to the same taskAffinity.
So how could this feature be reused for login based applications? Well, the login activity could be of a specific affinity and all other activities in the application (which requires authentication) could be of a different affinity. And thats the only application code needed, and it worked like a charm. Now, if the user moves on to a different application from an authenticated activity, Activity Manager would take care of restoring the application to Login screen, should the user return back to the application after half an hour.
LoginActivity
android:name="com.example.loginapplication.app.LoginActivity"
android:label="@string/title_activity_login"
android:taskAffinity="com.tuto.loginapplication.primary"
SettingsActivity
android:name="com.example.loginapplication.app.SettingsActivity"
android:label="@string/title_activity_settings"
android:taskAffinity="com.tuto.loginapplication.secondary"
This app was based on Gingerbread and worked as expected. However, later versions of Android doesn't behave as per android's documentation (Clearing the back stack)
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, only the root activity is restored.
Turns out that this feature was disabled by 621e17de87f18003aba2dedb719a2941020a7902
diff --git a/services/java/com/android/server/am/ActivityStack.java b/services/java/com/android/server/am/ActivityStack.java
index 51dc84e..b4ea036 100644
--- a/services/java/com/android/server/am/ActivityStack.java
+++ b/services/java/com/android/server/am/ActivityStack.java
@@ -99,8 +99,8 @@ public class ActivityStack {
static final int DESTROY_TIMEOUT = 10*1000;
// How long until we reset a task when the user returns to it. Currently
- // 30 minutes.
- static final long ACTIVITY_INACTIVE_RESET_TIME = 1000*60*30;
+ // disabled.
+ static final long ACTIVITY_INACTIVE_RESET_TIME = 0;
No comments:
Post a Comment