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).
Related
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 need to show an activity on push received, but I am getting Background activity start from package-name blocked. system Toast.
This is an authentication activity where user needs to perform some task. I do not manage phone or NFC interaction thus I don't need to actually start 'special' service but showing notification is not enough - I need that activity.
SYSTEM_ALERT_WINDOW permission doesn't help.
So, should I re-implement all my flows to work only with notifications? Is there any possibility to start activity when application was closed (No activity in back stack)?
Android Q places restrictions on when apps can start activities. This behavior change helps minimize interruptions for the user and keeps the user more in control of what's shown on their screen.You can see the full document here
As of Android Q Beta 4, this change has the following properties:
Affects your app if you launch activities without user interaction
Mitigate by using notification-triggered activities
Disable restrictions by turning on the Allow background activity starts developer option
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.
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 want my application to start when someone modifies a content provider. A setting to be specific. The settings framework calls "notify" when a value is set.
If my app was started I would use registerContentObserver() I guess, but is is not started.
Can define some intent-filter in my manifest that wakes up my application. A back up plan would be to have a service running all the time that has registered a listener, but that seems like a wast or resources.
Thanks, Ola
This isn't directly supported by the Android device because starting an app every time a ContentProvider's data changes is a path to really killing your battery. To do the query, you'd need to do it in a service, which as you said is understandably undesirable.
Secondly, starting an intent is a user action. Android really doesn't support allowing an application to start all on its own without user request... Doing so would be impolite! What if your user was doing something important and then your app pops up on top? Remember the user is in control, not you. Instead of starting an application, consider placing a Status Bar Notification so the user can deal with it when it's convenient for them.