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.
Related
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
I develop watchfaces for WearOS. I'm trying to modularize my code, by creating a base module that contains the common code for all my projects. Amoung other things, it should contain the code responsible for the in-app purchases. For this reason, I have to add <uses-permission android:name="com.android.vending.BILLING"/>. However, some projects don't have an in-app purchase. Therefore, these projects would inherit the BILLING permission, but actually woudn't need it.
So my questions are:
Is there a way around it? Like a way to conditionally specify aspects of the Manifest?
What are the consequences if I simply let this BILLING permission in, even if it's not required?
More generally, are there more "dangerous" permissions to let in when not required?
When uploading the app, you need to complete a Permissions declaration and the app goes through review. What you're seeking to do seems to explicitly run counter to the Play Store "Permissions policy" guidelines:
You may only request permissions that are necessary to implement current features or services in your app that are promoted in your Play Store listing.
I would expect your app to fail the review in light of this (or if it did pass the first time somehow, to possibly fail future reviews if it gets caught at a later stage).
Is there a way around it? Like a way to conditionally specify aspects of the Manifest?
I think there is no way of not declaring permissions in the manifest:
What are the consequences if I simply let this BILLING permission in, even if it's not required?
If it is a install-time permission the system will grant it automatically. But if it is a runtime-permission you must request the permission at runtime before usage.
So if you declare permissions that you do not need, in best case nothing happens. But I am not that much aware what kind of security issues can arrise from doing that.
Be aware that requesting permissions that you do not need in your App is against good practice:
Caution: Carefully consider which permissions you declare in your app's manifest. Add only the permissions that your app needs. For each permission that your app requests, make sure that it offers clear benefits to the user and that the request is done in a way that's obvious to them.
See also this post
Remove Permissions
You can also consider removing permissions in your (sub)modules that you declared in your base modules:
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" tools:node="remove"/>
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.
I was recently reading up about custom permission for our application in android.
uses-permission is clear. It contains the permission that your application will need in order to access some of user data or device features, etc and to function properly.
Now, we come to permission element. It declares permissions that activities or services might require other applications hold in order to use your application's data or logic
Now, say I use permission tag in my application's manifest file such as:
<permission android:name="my.pkg.CUST_PER"/>
This will imply that my application may have this possible permission.
And enforce that permission using it in my Activity tag like this:
<activity
android:name=".MyApp"
android:permission="my.pkg.CUST_PER">
Now, as per my understanding, only applications that have requested my indicated permission will be able to access my application's secured components.
If other app tries to access those components without my custom permission, what will happen? I think it should crash, and will that be seen in logcat as:
SecurityException: Missing permission: my.pkg.CUST_PER
If so, isn't that a security breach?
How to protect application data in such a circumstance?
uses-permission is clear. It contains the permission that your application will need in order to access some of user data or device features, etc and to function properly.
<uses-permission> means that your app wishes to hold the permission named in the <uses-permission> element. What is defended by that permission is up to other developers. In some cases, it may be defending some things that allow you "to access some of user data or device features".
This will imply that my application may have this possible permission.
No, it does not. It simply defines a new permission. It does not state that your app, or any other app, has anything else to do with the permission.
Now, as per my understanding, only applications that have requested my indicated permission will be able to access my application's secured components.
More accurately, only apps with the <uses-permission> element could qualify to access the secured component. In addition, as Mr. Orlowski notes, the protectionLevel of the <permission> indicates if user acceptance is involved (a protectinoLevel of normal or dangerous), if the app needs to be signed by the same signing key as the app that is defending itself with the permission (a protectionLevel of signature), or if the app needs to be installed on the /system partition (a protectionLevel of system).
If other app tries to access those components without my custom permission, what will happen? I think it should crash, and will that be seen in logcat as: Requires this permission: my.pkg.CUST_PER
Correct.
If so, isn't that a security breach?
Not particularly.
How to protect application data in such a circumstance?
Don't expose it in the first place. The complete and entire point behind having android:permission is because you want other apps to have access to the data, subject to user acceptance, signature match, etc. If you do not want other apps to have access to the data, do not export the component. For activities, services, and manifest-registered receivers, this is usually accomplished by not having an <intent-filter>. For <provider> elements, you will want to manually have the android:exported attribute set to false.
How to protect application data in such a circumstance?
You should have read whole docs as android:protectionLevel exists exactly to address this problem and is explained here:
https://developer.android.com/guide/topics/manifest/permission-element.html#plevel
I am trying to use another third party application into my application. Basically using some of the services from third party app. But these services need custom permissions defined in the third party application. So I have added those permission in my applications manifest file.
Suppose if my application is installed before installing the third party application then it won't get those permissions and so if I try to access the services from third party app, I am getting Security exception.
Is there a way to ask for permissions again or any other suggestions.
The permissions you request in your manifest are the permissions your app will receive regardless of when it is installed. Period. The permissions granted to another application are accessible by that application only. If there is a permission you need to use, it should be in your manifest. If it is there, permission will be requested from the user upon installation.
This is actually a known limitation of custom permissions. Even if both apps where yours, the one that defines the custom permission needs to be installed first, otherwise you will get an exception. If you control both apps, you need to define it in both apps. Otherwise, there is really no workaround: a permission needs to be know to the system to be granted.
BTW, you can use a third-party permission, as long as it is not a signature permission, requiring your app to be signed with the same key.