So, what applications used to do when changing permission while you are in app, app gets killed and everything works fine.
But the app im developing now doesn't get killed, it stays alive.
This is the scenario:
I start application, get asked for permissions, i accept them all, now, i put app in the background, and go to settings and disable all permissions, app doesn't get killed, it only reloads the same activity it was in when I put it in background. How can I kill the process when user changes permission?
You have to again perform the check permissions in your onResume method for all your Activity's in order to keep track of the Permission granted to your App.
And if you find that the permission is not available either ask again for the permissions or just finish your app with a message describing why you are closing the app.
Related
From the android documentation, the ACCESS_BACKGROUND_LOCATION permission should be stated for app that access the background location, user should see the "Allow all the time" option in the permission page of the application.
Yet, there are a lot of sports app, say strava, that track the gps of user continuously, even when app killed or app in background. They didn't even state the permission of ACCESS_BACKGROUND_LOCATION. This can be verify when going to their app permission page, only allow only when using app, ask every time and refuse options are shown. I understand they use foreground service to do such thing, but how come they didn't state for the ACCESS_BACKGROUND_LOCATION permission? Isn't this a must for apps to track user in background as required by Google? Can anyone give me some explaination on this? Thanks
One-time permissions are described here as follows:
In Android 11, whenever your app requests a permission related to location, microphone, or camera, the user-facing permissions dialog contains an option called Only this time, as shown in Figure 1. If the user selects this option in the dialog, your app is granted a temporary one-time permission. Your app can access the related data only while one of the following remains true:
Your app's activity has been visible ever since the user granted the
one-time permission.
Your app was visible when the user granted the
permission and has been running a foreground service ever since then.
As long as the foreground service keeps running, your app will retain
the permission even if the user moves your app to the background.
If neither condition is true, you need to ask the user for the
permission again, regardless of target SDK version.
So, to try out this new feature, this is what I did:
I created an app that uses the camera, with no foreground service.
When prompted, I granted the app one-time Camera permission.
After that, I tried pressing Home or open another app to send my app to the background.
I thought this is when the permission is supposed to be revoked, but it's not. When I came back to my app, I can still open the camera.
So, when exactly is a one-time permission revoked? Many thanks!
Based on my experimentation, it appears that the one-time permission is good for the current process. Once your process terminates — for any reason — the permission grant lapses.
However, it is unclear if this is a documentation bug or an implementation bug. Keep track of this issue to see what happens in future Android R releases.
Based on experimenting with the camera permission, once the one-time permission is granted, it remains that way until the app's process is killed either by the user or the system.
If the user kills the app, the system revokes the permission 5 seconds later. This allows the app not to lose the permission if it's immediately restarted.
If the user backgrounds the app, the system revokes the permission 1 minute later, thus killing the app's process.
I have an android application which was supporting till lollipop. Now I'm migrating it to support Marshmallow.
I am stuck in a case where if we manually changed the app permission in marshmallow it kills all the process.
I get it as explained by #CommonsWare in similar question here.
But in my case I have to kill the app and need to restart the app. Because my app each activity is dependent on previous activity some data is shared. I just need to know when we manually change the permission is there a way our app get noticed.?
I meant any callback occurs. if Not is there anyway I can handle this case.? Please Let me know if the question is too broad I'll update my question
Thanks in advance
I just need to know when we manually change the permission is there a way our app get noticed.?
Your process is terminated. This is indistinguishable from any other reason why your process might be terminated.
I meant any callback occurs.
No. You get ordinary lifecycle callbacks (e.g., onPause(), onStop()) as the user navigates over to Settings to be able to revoke the permission, but that's it. There is no specific callback related to losing the permission.
Also note that the user could leave your app, your process could be terminated for other reasons, the user could then go into Settings and revoke your permission, then the user could return to your app. If all of that happens within ~30 minutes, Android will still try to rebuild the outstanding task. You certainly would not get a callback of any sort in this case, as your process was not running before the permission was revoked, let alone after.
I figured that in M requestPermissions() can only be called by an Activity class. I have an app that has no UI screen. It runs as a background service. Does this mean that I have to put a spinner screen if checkSelfPermissions returns denied?
I have an app that has no UI screen.
Then it will never run, unless it is preinstalled on an Android device or custom ROM, or it is a plugin to some other app. Otherwise, your app will remain in the stopped state forever. Pretty much every app distributed through normal channels, including the Play Store, needs an activity.
Does this mean that I have to put a spinner screen if checkSelfPermissions returns denied?
I do not know what "a spinner screen" is. AFAIK, the recommended pattern for a service needing a runtime permission that it does not have is to:
Raise a Notification, to let the user know that the service cannot do its work without this permission.
Have the Notification trigger an Activity that can call requestPermissions(). Optionally, this activity can have Theme.Translucent.NoTitleBar, so the only visible UI is the permission dialog.
If onRequestPermissionResult() indicates that you have the permission, the activity can tell the service to go ahead (e.g., via a call to startService()), then finish() itself. If onRequestPermissionResult() indicates that the user denied the permission, do whatever makes sense (e.g., show the Notification again, gracefully shut down, suggest to the user that the user uninstall the app).
I didn't know this was possible until recently I force quitted an app and when I restarted my phone I found it had a service running in background and the force quit button became unclickable. There are a lot permissions in that app one of them is modify system setting, does it have anything to do with this permission? what methods use this permission? how can I do the same with me app?
The problem is your app is now in a stopped state because you force stopped it. While in this state, its components are not active and will not run until the user launches the app through the launcher. This is also the case when the app is first installed. That's why it is not receiving the BOOT_COMPLETED broadcast.
You need to have an Activity that the user can manually launch in order to move your app out of the stopped state.