Handling Android M run-time permissions with multi module project - android

I have a multiple module Android M app. Several modules require "WRITE_EXTERNAL_STORAGE" & "READ_EXTERNAL_STORAGE" permissions.
I would like to ask the user for permissions once:
1. Where would be the right place to do that?
1.1 Are permissions granted per activity?
1.2 Would asking for permission in module 1 give permissions to all app?
1.3 Is there a way to ask for both READ & WRITE permissions?

Google has published guidelines describing when to ask for permissions. It depends on context. Your questions 1.1 and 1.2 can be answered with the same info: permissions are granted and denied at the app level. It applies to every part of your app package. For 1.3: they are limited together into a group. When you ask for one you automatically get everything in the group.
This talk from DroidconNYC NYC will give you more details: https://youtu.be/WGz-alwVh8A.

Where would be the right place to do that?
From somewhere in your UI, before you need those permissions.
Are permissions granted per activity?
No, they are for the entire application.
Would asking for permission in module 1 give permissions to all app?
Asking for a permission in a module will give that permission to the entire app, if the user grants you the permission.
Is there a way to ask for both READ & WRITE permissions?
In this case, AFAIK you do not need both. Just ask for WRITE_EXTERNAL_STORAGE. In general, you can request as many permissions as you want; the requestPermissions() method takes a String[] of permission names.

Related

Android Application Permissions Logging

i have a question related to Android app run time permissions.
Is it preferrable/allowed practice for developers to save users' permission preferences i.e. each user has allowed/denied any permission, on our remote server database?
Offcourse we are asking run time permission for every feature we want to use, but is it preferrable that we log on server that if user has allowed for any permission or not, please let know. Thanks
Android framework has restricted the developers to ask only those permissions which are necessary to implement a specific feature and that too if there's no other way to implement the feature without that specific permission. In your case, it seems like you have already taken care of the permissions and just want to hold the result of the asked permissions.
So the answer is YES, You can save this data and it's even considered good practice for handling permissions. Here's the reference from the official android documentation.
Greater flexibility in granting permissions
Users can deny access to individual permissions at the time they’re requested and in settings, but they may still be surprised when functionality is broken as a result. It’s a good idea to monitor how many users are denying permissions (e.g. using Google Analytics) so that you can either refactor your app to avoid depending on that permission or provide a better explanation of why you need the permission for your app to work properly. You should also make sure that your app handles exceptions when users deny permission requests or toggle off permissions in settings.
https://developer.android.com/training/permissions/usage-notes

Android Permissions should be asked on startup or only when needed?

I have built an app that use different kind of permissions like location, contacts etc.
Not all the permissions are used by all the users, instead each user only needs the permissions related to the features he/she is using it.
My question, should I ask all the permission on startup for all users or can I add them gradually while using the app and only when needed?
Thanks
If a user doesn't know why they need to accept a specific permisson, they may be suspicious and refuse (eg. camera).
If they click on a functionnality like 'Scan code' they will know why they are being asked for that permission and accept.
If you asked beforehand and the user refused, when you get to the part where you need that permission, it won't work. This is why they changed it to dynamic permissions in Android 6.

Android: Confusion in understanding the runtime permissions

I am implementing runtime permissions in my app. I have few questions though to understand them clearly.
Situation:
My application B is a child app of application A
That being said my application resides inside application A as part of it and, whenever needed I can launch it.
Question:
If a user has already granted all the necessary runtime permissions to application A (the parent app), then can the child app i.e. application B carry the same permission grant or it has to ask them again?
Do I need to ask the permissions again if I install a newer version of an app on top of the old? Let's say version 2 to 3.
Technically, yes. If app-A and app-B are two separate apps, they each need their own set of permissions and permission requests.
And no, if a permission was previously allowed, then an installation of a newer version does not reset that permission's state.
However, if you want app-B to retain the same permission states as app-A, you should look into something called android:sharedUserId. If app-A has the same sharedUserId as app-B, then app-B will have the same permission states as app-A, and vice versa.
I couldn't find any posts talking sufficiently about the shared permission states between apps with the same, but you can check out some of these posts for extra notes:
Two app with shared UserID
What is sharedUserId in Android, and how is it used?
https://stackoverflow.com/a/49492023/6668797
https://stackoverflow.com/a/8507761/6668797
I did a quick test myself and can confirm that two apps with the same sharedUserId do share permission states, so go try it yourself. Just setup a sample project/app that checks and requests a permission, clone it, give them the same sharedUserId, install both of them, allow the permission on one, and you'll see it's already in the allowed-state on the other.

Android M : Ask multiple Runtime Group Permissions together

I know how can i ask multiple permission at Runtime in android, and i am well aware about Group system in Runtime Permission Architecture.
I want to know if there is way allows to ask multiple Group permissions together as like multiple permissions at Runtime.
I want to ask Storage Group, Camera Group and Location Group permissions together.
You do not ask for rights to permission groups using the current runtime permission API. You ask for rights to permissions, not permission groups. At the moment, through Android 7.0, the way the system handles this is by asking the user to grant you rights to the associated permission groups. It may or may not do so in the future.
I want to know if there is way allows to ask multiple Group permissions together as like multiple permissions at Runtime.
No. There is no way to ask for a single permission group, let alone multiple ones.
As per current version of Android, there is no way to ask multiple Group permissions together as you want. There is other option possible is this

How to Hide the Android Manifest Permissions

is there any way for hide the android manifest Permissions for some reasons and user couldnt see during installing the app?
Taken from the support page from Google Play:
Google Play shows you which permission groups an app will be able to
access. This information can help you decide whether you want to
install the app.
The whole sole purpose of those permissions is for people to see what your app can access and decide whether they want to share (all) that information with you.
In Android L and lower, this is impossible. If you do not ask for a permission, you will get a crash when you try to access the thing that needs permission. Thus, you cannot hide permissions from users.
In Android M, the whole permission idea is changed: instead of asking for lots of permission at the install, the app is installed without permissions, and when you need a specific permission, for example for camera, the user will have the option of accepting or declining the permission. Thus, the user will have a clearer view of what a permission is asked for.

Categories

Resources