ignition icon indicating copy to clipboard operation
ignition copied to clipboard

isApplicationBroughtToBackground doesn't work as advertised

Open skykelsey opened this issue 13 years ago • 5 comments

Hi there. I ran across this method on Stackoverflow, and decided to use it. But it turns out it doesn't always work as advertised. Specifically, in the case where I have defined an extra Activity in my Application with a different package than the Application. Because you are comparing packages, isApplicationBroughtToBackground() will return true when I launch this child Activity. My solution checks to see if the new topActivity is defined in the current Application. If not, returns true:

public static boolean isApplicationBroughtToBackground(final Activity activity) {
  ActivityManager activityManager = (ActivityManager) activity.getSystemService(Context.ACTIVITY_SERVICE);
  List<ActivityManager.RunningTaskInfo> tasks = activityManager.getRunningTasks(1);
  if (!tasks.isEmpty()) {
    ComponentName topActivity = tasks.get(0).topActivity;
    try {
      PackageInfo pi = activity.getPackageManager().getPackageInfo(activity.getPackageName(), PackageManager.GET_ACTIVITIES);
      for (ActivityInfo activityInfo : pi.activities) {
        if(topActivity.getClassName().equals(activityInfo.name)) {
          return false;
        }
      }
    } catch( PackageManager.NameNotFoundException e) {
      return false; // Never happens.
    }
  }
  return true;
}

If you want this, I'd be happy to submit a pull request.

skykelsey avatar Aug 03 '12 00:08 skykelsey

Yes, that's true. I will probably remove this method from the library at some point, it also doesn't work with custom launchers like ADW (for the same reason.)

Better not use it at all, it's a pretty old leftover from the former Droid-Fu library. We used it to detach location listeners when the users leaves the app, and since customization in terms of custom home screens wasn't that commonplace back then, it did the job.

We don't use it anymore in our app either.

mttkay avatar Aug 03 '12 07:08 mttkay

Actually, forget what I just said. The problem I mentioned with the different home screens was already fixed (that method actually used to check for Android's launcher package explicitly to determine if the user arrived at the home screen).

But your point remains of course.

mttkay avatar Aug 03 '12 07:08 mttkay

And another problem with this method is that it requires an extra permission, and it's a permission that's difficult to communicate to the user why you need it.

mttkay avatar Aug 03 '12 07:08 mttkay

HI Matthias, thanks for the reply.

I totally understand that you may not want to bother with this method. The trouble is, this method seems to be referenced all over the internet as a way to distinguish a home button press vs a back button press. I was hoping that droid-fu could be updated to save some people some pain, but since this project has superseded droid-fu, I filed the bug here.

Do you still intend to remove the method altogether?

skykelsey avatar Aug 03 '12 18:08 skykelsey

Just so you know, a few months ago a customer let us know that Google refused to feature their app while the GET_TASKS permission was used. We had to find a different approach. So that is more evidence that this is not the correct approach.

skykelsey avatar Jun 25 '13 18:06 skykelsey