Android marshmallow dynamic permission change kills all application processes

Question

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?

Answer 1

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).

Answer 2

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.