29

Observation: Manually changing permission of Android application killed all processes for this application.

Procedure: Go to Settings->Apps Select application and Permissions. Disable one of the permissions. Device: Nexus 6 device running Android Marshmallow 6.0

When I started the application from the launcher, it started the activity that was on top before permission of this application was changed. That is a different behavior from when we kill the application process by swiping out the application from UI multi-task menu. In that case, launcher activity is created first. That is, for application to work correctly when launched after changing permission, it cannot have a dependency on launcher activity to be started.

Is this expected behavior with dynamic permissions on all Android 6.0+ devices? Why is there a difference in behavior from when the application process is killed by swiping it out from UI multitask menu?

user802467
  • 951
  • 2
  • 14
  • 22

2 Answers2

16

That is, for application to work correctly when launched after changing permission, it cannot have a dependency on launcher activity to be started.

That has been the case for years. For example, if your process is terminated due to low memory conditions, but the user has been in it recently (say, within the past half-hour), when the user visits the overview screen (what you call the "UI multi-task menu") and goes to return to your app, control will return to a fresh instance of whatever activity the user had been in last (i.e., had been on the top of the BACK stack).

Is this expected behavior with dynamic permissions on all Android 6.0+ devices?

Yes. It is also expected behavior in all previous Android devices, for other cases where your process was terminated but your task is still outstanding and recent.

Why is there a difference in behavior from when the application process is killed by swiping it out from UI multitask menu?

Swiping a task off the overview screen removes that task. Hence, that task cannot be reused when the user tries returning to your app (e.g., via a home screen launcher icon).

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 4
    I don't understand why they keep the task on permissions change. Why not kill the process AND remove the task ? It forces us to check permissions everywhere needed in the app, whereas we could just have a single entry point to request them (the critical ones at least). Do you know if there is a way to force a new task after permission change ? I tried to mix various activity configuration but I failed poorly... – tbruyelle Nov 10 '15 at 13:04
  • 6
    @tbruyelle: "Do you know if there is a way to force a new task after permission change ?" -- there is nothing specific for a permission change. If nothing else, check to see if you hold the permissions in the top of every `onCreate()` (perhaps via a common activity base class), and if you're missing something critical, start your entry point activity with the `Intent` flags to clear the task, so your `requestPermissions()` call is handled centrally. – CommonsWare Nov 10 '15 at 13:07
  • Thanks I was designing something like that, I'll go on. – tbruyelle Nov 10 '15 at 13:14
  • Instagram has a control on this issue. If you try to disable storage permission from settings and resume the app, it doesn't kill the application. Momently, a white background is shown; then recent activity appears where it left. – Orcun Sevsay Dec 01 '15 at 13:42
  • 3
    @MiloRambaldi: "If you try to disable storage permission from settings and resume the app, it doesn't kill the application" -- it certainly kills all processes associated with the app. Instagram cannot stop that. "Momently, a white background is shown; then recent activity appears where it left" -- that sounds like normal `savedInstanceState` processing, along with reloading any necessary data from disk or the network. – CommonsWare Dec 01 '15 at 13:44
  • do we have any Android documentation url of the following implementation ? – Murtaza Khursheed Hussain Mar 09 '16 at 11:55
3

I guess the rationale for the killing is the following. It's about concurrency. The system may choose one of 3 possible approaches:

  1. To revoke a permission silently. The app has no way of checking against this, because between any 'check' and 'use' moments still there can happen a revoke.

  2. To notify the app. This kind of notification must be acknowledged by the app, meaning that no its thread is going to access the disabled API anymore and the system may turn the API off now. This is graceful, but is hard to program for inexperienced programmers.

  3. To kill the app, making sure the next time it starts it will properly realize that permission was revoked.

beefeather
  • 1,040
  • 5
  • 8