with Androids new permission system, I was wondering how to implement it right. The tutorials about how and when to use the permissions seem to be pretty clear. However, I don't know who requests the permissions and where to request them.
So, basically my question is: should the Activity, who starts another Activity request the permission beforehand or should the Activity which requires the permission place the request?
If the Activity which requires the permission should request for it, should I call requestForPermission inside onCreate or in onStart?
Though it seems to be very simple questions, I haven't found any hints in the documentation.
Thanks.
should the Activity, who starts another Activity request the permission beforehand or should the Activity which requires the permission place the request?
That is up to you. The main guidance is that there should be a clear tie from something the user does to your request for permissions:
If your app needs certain permissions to do anything meaningful, ask for them when your app starts up, perhaps after any sort of "welcome" presentation to advise them about why you need the permissions.
If your app needs certain permissions to do something based on the user performing some in-app action, like tapping on an action bar item or ListView row, ask for the permission when the user performs that action.
Asking for permissions at semi-random points in the app will simply lead to user confusion ("what did I do? why is it asking me this? and why are these questions appearing in an Stack Overflow answer?!?").
If your app can't function properly without a particular permission might be good to have a welcome permission flow where you explain why need the permissions and ask for the grants. For example : Google maps and location permission
If some specific parts of the app need a separate permission you can call the permission check just before doing a method call that needs permission. In this case you can create a wrapper for your function that needs contact permission and always call that wrapper instead of the actual method. For example : Google maps and microphone permission when you try to use the search with voice functionality
More details http://inthecheesefactory.com/blog/things-you-need-to-know-about-android-m-permission-developer-edition/en
also check out https://github.com/permissions-dispatcher/PermissionsDispatcher could reduce a lot of permission code.
When ever your X task struck due to some "Y" permission then only ask for permission. There is no point of asking in onCreate or onStart method.
if you ask for "Y" permission at the start of Activity then there is no difference between Android M and below model. Exploit the beauty of Android M. for example if your require storage permission for creating a temp it's better make a temp file in App internal area i.e /data/data/your package name/files/ rather than asking for storage permission to users. Overall my point is exploit these options as much as you before it become necessary condition to ask for "Y" permission.
Regarding Activity concern , your task must be running be over some fragment or activity let that activity handle the onRequestPermission results.
Related
I couldn't find any information about what happens when the user disables an app's permission while the app is running.
Is the application re-initilized?
I saw that in some apps if a Dialog or BottomSheet is open while I disable the permission, the dialog is no longer displayed when I return to the app.
Can anyone explain what happens in-detail when a permission is denied at runtime? Or does anyone have some useful links for me?
I would be especially interested in which lifecycle events are called when returning to the app.
When a previously granted permission is revoked through settings, the app is force stopped. You can see this by watching your app in the debugger. The app process is marked DEAD as soon as the permission is revoked.
Returning to the app will launch it from the main activity. I've never really looked into why this happens, but I assume it's because when a granted permission is revoked, the user could be deep into the app at a place where it is assumed the permission is granted. When the permission is revoked, there's no way to know if the screen they are currently in is even valid anymore.
Upon returning to the app, the app's state is restored and your current activity will be restarted, similar to a configuration change. If the activity you are in assumes a certain permission is granted, you should probably check that permission again in onCreate() to make sure you have it.
Simply put, That depends on what the app is trying to do when it needs permission.
For example: If we live in a country that requires you to be an adult to watch any video on YouTube, nothing will work with Location permissions denied
Another example: If you want to take photos using your phone via an app, the Camera permission should be permitted.
Under some circumstances, just part functions of app can not be used, but at an Extreme case, app would throw Security Exception and crash.
According to your point :
I saw that in some apps if a Dialog or BottomSheet is open while I
disable the permission, the dialog is no longer displayed when I
return to the app.
There is no lifecycle callback about what you do once permission is denied, but there's method on ActivityCompat which gives you flag if you want to show your own Dialog/BottomSheet
So, you can call shouldShowRequestPermissionRationale() method from ActivityCompat & make your own logic work when it's true.
shouldShowRequestPermissionRationale :
Gets whether you should show UI with rationale for requesting a permission. You should do this only if you do not have the permission and the context in which the permission is requested does not clearly communicate to the user what would be the benefit from granting this permission.
For example,
if you write a camera app, requesting the camera permission would be expected by the user and no rationale for why it is requested is needed.
If however, the app needs location for tagging photos then a non-tech savvy user may wonder how location is related to taking photos. In this case you may choose to show UI with rationale of requesting this permission.
While disabling permission for first time will give you callback in onRequestPermissionResult() method.
I am implementing a service that uses LocationManager to get and utilize the tablet location. This service is start and stop from an activity.
The latest Android requires that permissions are requested on runtime. Now I have managed to do this on an activity by using requestPermission in onCreate , checkSelfPermission everytime I use some Location manager function, and adding the requestPermission function and overriding the onRequestPermissionResult.
It works great.
Now for my service I need to do the same, but these functions seems to work only for activities. How can I activate permissions in a Service?
just in case, I have already asked for permissions in the activity that starts and stops the services
How can I activate permissions in a Service?
You don't. You activate (i.e., request) permissions from an activity. That is not negotiable.
Ideally, you request permissions before the activity starts the service or does something that will eventually cause the service to start (e.g., schedules the job with JobScheduler).
If you determine that your service no longer has the necessary permissions — perhaps the user revoked them from Settings — you could raise a Notification that leads the user to an activity where you re-request the permissions.
It is technically possible for a service to start an activity which requests the permissions. Usually, this is not a good idea, as you may not know what the user is doing at that moment, and the user may be unhappy to have you interrupt them with this permission request.
How can I activate permissions in a Service?
You can't request for permissions from services. Permissions should be asked explicitly which should be visible to the user in UI. However you can ask permission from activity and, if succeed, you can access those resources until user again turned off permission for your app.
how can you "transfer" these permissions to the service?
Permission is assigned for the entire app, so you don't need to transfer it from one activity to another or from one activity to service. Once you get a permission in an Activity, that permission is assigned to the entire app and your services can access the resources then after. cheers :)
The PlacePicker is a useful widget added in com.google.android.gms:play-services-places:9.4.0. Find the description here: PlacePicker
The documentation clearly states that you need the ACCESS_FINE_LOCATION permission for it to work.
On Marshmallow and above you also must ask the user to grant this permission.
But it seems to work without doing any of this! My app does
provide a maps API key
not define the permission in the AndroidManifest
not ask the user to grant this permission at any time
But running the app on an Marshmallow device DOES start the PlacePicker and I can
correctly select a place (not possible without the API key).
go to "My Location" via the MyLocation-Button (possible without API key)
Can anyone confirm this or has an explanation why this widget works without proper permissions granted?
The question is almost an year old but I was trying to find the same answer so it can help somebody else.
It's because PlacePicker works with "intent based request". The documentation is not very clear with it, but it says
1: Only use the permissions necessary for your app to work. Depending on how you are using the permissions, there may be another way to do what you need (system intents, identifiers, backgrounding for phone calls) without relying on access to sensitive information.
Source
And give some clue here:
If your requirement for access to user data is infrequent — in other words, it's not unacceptably disruptive for the user to be presented with a runtime dialogue each time you need to access data — you can use an intent based request. Android provides some system intents that applications can use without requiring permissions because the user chooses what, if anything, to share with the app at the time the intent based request is issued.
Source
I've figured it out testing permissions use cases with Marshmallow and Lollipop devices, comparing the result with PlacePicker that I thought could be using intent based permissions with MediaStore that use this kind of permission according to documentation:
For example, an intent action type of MediaStore.ACTION_IMAGE_CAPTURE or MediaStore.ACTION_VIDEO_CAPTURE can be used to capture images or videos without directly using the Camera object (or requiring the permission). In this case, the system intent will ask for the user’s permission on your behalf every time an image is captured.
For example, an intent action type of MediaStore.ACTION_IMAGE_CAPTURE or MediaStore.ACTION_VIDEO_CAPTURE can be used to capture images or videos without directly using the Camera object (or requiring the permission). In this case, the system intent will ask for the user’s permission on your behalf every time an image is captured.
Source
I'm looking into porting some existing code to take Android M's new way of dealing with permissions into consideration. However the permission API needs to have an activity associated with it (for example the requestPermissions() method's first parameter is an activity).
So how should a service that needs to check if a permissions has been granted and request for permissions use this new API if the service doesn't have an activity?
Is it possible for the service to create a dummy invisible activity just for use with the permissions API? (if its possible I don't like the thought of doing that anyway though).
Or suppose its not a service but a model class that needs to perform a permissions check, in MVC a model shouldn't have any knowledge of the Vs and Cs and yet now either it has to in order to know which Activity to use with the permission API. Or potentially lots of code might have to migrate from model code into Activity code.
Any thoughts on how to migrate non activity based code that needs to check/prompt for permissions over to Android 6.0?
Update: I left out an important piece of information - this is code that is pre-installed (our company provides code that device manufacture's place in rom) and often may be run at device boot time and run in the background. Therefore the usual situation of a user being prompted for permission when they launch the app or later (and there therefore being an activity at that point) does not necessarily apply.
So how should a service that needs to check if a permissions has been granted and request for permissions use this new API if the service doesn't have an activity?
There is almost always an activity, except for pre-installed apps and plugins for other apps. Otherwise, your service is unlikely to ever run, as nothing will have used an explicit Intent to start up one of your app's components, so it will remain in the stopped state.
For the ~99.9% of Android apps that have an activity already, if the permissions are needed for the whole operation of the app, request them on first run. As Snild Dolkow notes, if the user later revokes the permission through Settings, you can detect that without an activity, then use other UI options (e.g., Notification, app widget) to let the user know that operation is suspended until they grant you the permissions again, which they would then do through your activity.
Is it possible for the service to create a dummy invisible activity just for use with the permissions API?
Presumably you can have a Theme.NoDisplay activity use requestPermissions(). However, from the user's standpoint, it will not make much sense, unless there's some alternative UI (app widget?) that they are interacting with. Popping up a permission dialog out of nowhere is unlikely to make you popular.
UPDATE 2019-06-15: Note that Android Q bans services popping up activities frmo the background. Please use a notification instead.
in MVC a model shouldn't have any knowledge of the Vs and Cs and yet now either it has to in order to know which Activity to use with the permission API
Do not touch the models until you have requested the permission, and gracefully fail if the permission is revoked. You already have to gracefully fail in other circumstances (out of disk space, no Internet connection, etc.), so a revoked permission should be handled in much the same way.
using this new 6.0 API seems like an recipe for bad design and tight coupling
You are welcome to your opinion. Based on what I have read, the Android engineers believe that asking the user for permissions is part of the user experience and is best handled at the UI layer as a result.
Again: the vast majority of Android apps will not have a problem with this, as they have a user interface. Apps that do not have a user interface and need dangerous permissions are in for some amount of rework.
this is code that is pre-installed (our company provides code that device manufacture's place in rom) and often may be run at device boot time
First, please understand that this is so far from normal that you can't even see normal from where you are due to the curvature of the Earth. :-) You can't really complain that Google did not optimize this particular scenario.
As I understand it, even system apps should be asking for runtime permissions. The Camera app did, for example, on the 6.0 preview. That being said, there's gotta be some database on the device somewhere that is tracking what has been granted, and presumably there is some way to pre-populate it. However, the user could still revoke it from Settings, presumably. But, the manufacturer could pull some stunts (e.g., messing with the Settings app) to possibly even preclude that scenario. I'd be looking in the same area as "how do I get it so my app cannot be force-stopped?" that device manufacturers can do.
Your alternatives would be to get rid of the dangerous permissions or to migrate your app off the SDK and into a standard Linux binary that would be run as part of the boot process and be put into a Linux user group that has access to the stuff that you need.
Ask for it when the user enables whatever feature your service provides. They'll be in one of your activities at the time. Yes, it means that your activities need knowledge of what permissions your services will require.
The service can always check for the permission by itself, though, since checkSelfPermission() is available in all Context instances. So you don't need an activity for that.
I guess an alternative would be to have your service post a notification saying "feature X requires you to approve more permissions". Actually, that may be a good idea regardless, in case the user goes into settings and revokes any permissions after the fact. That notification would then take the user to some activity with an "enable feature X" button/checkbox -- ask for the permission when that is selected.
You can send a notification. Look this library to manage the permissions: permission library
I have a service which monitors the activity stack to get the top activity on the stack, and performs an action based on the top activity. I figured out a way to do this using the GET_TASKS permission. But the problem is that adding a new permission forces my users to manually update their application. So I wanted to know if there is any way to get the currently running activity without using the GET_TASKS permission?
No. The permission is there for a reason. The docs for that permission say:
Allows an application to get information about the currently or recently running tasks.
and clearly you want to get information about currently running tasks, so you need this permission. Just explain in your release notes why you require the new permission and if your application has enough value to your users, they'll update it anyway.