I'm trying to update my application to support v23 properly especially in terms of the new permission model. Unfortunately I'm kinda confused when it comes to the GET_ACCOUNTS permission. According to Table 1 (Dangerous permissions and permission groups) the GET_ACCOUNTS permission is classified as dangerous though when you look at the Manifest.permission docs the Protection Level is set to normal which basically means that I don't need to request the permission from the user.
I've looked at the App Info -> Permissions page and the contacts permission can be revoked which seems to indicate that it is indeed a dangerous permission.
So basically the questions are:
Is it really a dangerous permission?
Is this permission required for GCM if my app is targeting only API-Level 14 and higher? (seems like this isn't the case)
Yes, the permission is dangerous since dp3. And no with the latest Google play services, this permission is not needed to use GCM.
Related
I see that the ACCESS_BACKGROUND_LOCATION permission (which according to Google needs to be requested individually) requires a prominent disclosure (which according to Google needs to be also shown individually).
I also see that ACCESS_BACKGROUND_LOCATION permission requires prior ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION permissions (which according to Google these need to be requested together).
My question is, would I also need to show a prominent disclosure message for these permissions?
Directions are a bit fuzzy.
Yes. Those are categorised as "dangerous permissions". You need to ask the user at runtime for those permissions with a system UI dialog.
How does I determine which permissions should I ask at runtime and which one is 'enough' to have declared in the manifest?
From the documentation:
System permissions are divided into two categories, normal and dangerous:
Normal permissions do not directly risk the user's privacy. If your app lists a normal permission in its manifest, the system grants the permission automatically.
Dangerous permissions can give the app access to the user's confidential data. If your app lists a normal permission in its manifest, the system grants the permission automatically. If you list a dangerous permission, the user has to explicitly give approval to your app.
See the documentation on normal permissions and dangerous permissions for more details.
Dangerous permissions should ask in runtime, normal enough in manifest. List of dangerous and normal permissions you can see here.
From docs:
System permissions are divided into several protection levels. The two
most important protection levels to know about are normal and
dangerous permissions:
Normal permissions cover areas where your app needs to access data or
resources outside the app's sandbox, but where there's very little
risk to the user's privacy or the operation of other apps. For
example, permission to set the time zone is a normal permission. If an
app declares that it needs a normal permission, the system
automatically grants the permission to the app. For a full listing of
the current normal permissions, see Normal permissions.
Dangerous
permissions cover areas where the app wants data or resources that
involve the user's private information, or could potentially affect
the user's stored data or the operation of other apps. For example,
the ability to read the user's contacts is a dangerous permission. If
an app declares that it needs a dangerous permission, the user has to
explicitly grant the permission to the app. Special Permissions There
are a couple of permissions that don't behave like normal and
dangerous permissions. SYSTEM_ALERT_WINDOW and WRITE_SETTINGS are
particularly sensitive, so most apps should not use them. If an app
needs one of these permissions, it must declare the permission in the
manifest, and send an intent requesting the user's authorization. The
system responds to the intent by showing a detailed management screen
to the user.
For details on how to request these permissions, see the
SYSTEM_ALERT_WINDOW and WRITE_SETTINGS reference entries.
You should always put every permission you want access to in the Manifest. Devices before Android Marshmallow cannot handle runtime permissions, so unless you are targeting only Marshmallow and above, this part is important.
You do not need to ask at runtime for any "Normal Permissions". Only permissions designated as "dangerous" are not given automatically.
If you're targeting Android Marshmallow and above, you've to request for dangerous permissions at runtime. You can find the list here. You should also read this.
I have read Dengerous permission and Normal permission as well. but I didn't find this permission anywhere. I just want to know what kind of permission is it?
WRITE_SETTINGS
added in API level 1
String WRITE_SETTINGS
Allows an application to read or write the system settings.
Note: If the app targets API level 23 or higher, the app user must explicitly grant this permission to the app through a permission management screen. The app requests the user's approval by sending an intent with action ACTION_MANAGE_WRITE_SETTINGS. The app can check whether it has this authorization by calling Settings.System.canWrite().
Protection level: signature
Constant Value: "android.permission.WRITE_SETTINGS"
Special Permissions
There are a couple of permissions that don't behave like normal and dangerous permissions. SYSTEM_ALERT_WINDOW and WRITE_SETTINGS are particularly sensitive, so most apps should not use them. If an app needs one of these permissions, it must declare the permission in the manifest, and send an intent requesting the user's authorization. The system responds to the intent by showing a detailed management screen to the user.
Source: https://developer.android.com/guide/topics/permissions/requesting.html#perm-groups
The protection level is signature. You must ask the user to be granted this permission if your API level is greater than or equal to 23.
You can find the documentation on all permissions here,
and you can find the documentation for the permission you specified here.
I'm trying to grant some runtime permissions to my app automatically, these include ACCESS_FINE_LOCATION, READ_PHONE_STATE as well as ACTION_MANAGE_OVERLAY_PERMISSION. Do note that this requires at least Device Administrator access rights, which I have.
While the first two work flawlessly via
dpm.setPermissionGrantState(componentName, "com.my.app", Manifest.permission.READ_PHONE_STATE, DevicePolicyManager.PERMISSION_GRANT_STATE_GRANTED);
dpm.setPermissionGrantState(componentName, "com.my.app", Manifest.permission.ACCESS_FINE_LOCATION, DevicePolicyManager.PERMISSION_GRANT_STATE_GRANTED);
ACTION_MANAGE_OVERLAY_PERMISSION does not work at all. I believe this might be due to the fact that it's not part of Manifest.permission but instead android.settings.action.MANAGE_OVERLAY_PERMISSION. However it still is a permission that I want to be granted automatically.
Edit: While it seems that this permission is granted automatically to any app that requests it, this only is the case for apps distributed via the playstore. Unfortunately my App is NOT distributed that way.
include ACCESS_FINE_LOCATION, READ_PHONE_STATE as well as ACTION_MANAGE_OVERLAY_PERMISSION
ACTION_MANAGE_OVERLAY_PERMISSION is not a permission.
but instead android.settings.action.MANAGE_OVERLAY_PERMISSION
That is not a permission. That is an Intent action.
The permission that you probably want is SYSTEM_ALERT_WINDOW.
I was able to automatically grant this permission, from my device owner app:
devicePolicyManager.setPermissionGrantState(compName, this.packageName, Manifest.permission.SYSTEM_ALERT_WINDOW, DevicePolicyManager.PERMISSION_GRANT_STATE_GRANTED)
You also need in your manifest:
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>
After this Settings.canDrawOverlays() returns true, and the permission is granted in the settings app. Although unlike other permissions granted this way, it seems like the user can choose to disable it in settings. My targetSdkVersion is 26
It is a new behaviour introduced in Marshmallow 6.0.1.
Every app that requests the SYSTEM_ALERT_WINDOW permission and that is installed through the Play Store (version 6.0.5 or higher is required), will have granted the permission automatically.
If instead the app is sideloaded, the permission is not automatically granted. You can try to download and install the Evernote APK from apkmirror.com. As you can see you need to manually grant the permission in Settings -> Apps -> Draw over other apps.
These are the commits [1] [2] that allow the Play Store to give the automatic grant of the SYSTEM_ALERT_WINDOW permission.
After all the hassle of searching on google, I have managed to request storage permission, to make my apps "compliant" with the new permission system introduced in android Marshmallow. But now, I noticed, I actually didn't need to make all that effort as permissions get granted by the system automatically without requesting. Just having the permissions in Manifest was enough.(seen while installing ES File Explorer, or my own apps). Is it necessary to ask for permissions on Android 6+?
This is what my Manifest.xml looks like:
android:versionCode="100"
android:versionName="1.0.0" >
<uses-sdk android:minSdkVersion="14" />
<uses-permission android:name="android.permission.GET_ACCOUNTS" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
PS: I am using a Samsung Galaxy S7
Do we actually need to request permissions?
No. If you set target API to 22 or below(ANdroid 5.x) the permission system isn't set up and thus, when downloading the app the user has to grant every permission to download the app.
HOWEVER
The user can still revoke any permission on the "dangerous"-level. If your app uses any of these, you can't ask for them back either. In addition, it will cause crashes as the app will not be programmed to handle what happens when the app doesn't have access to the permissions.
You only need to ask for permission on the permissions that have the danger-level of "Dangerous". "normal"-permissions are granted automatically and can not be revoked. Here is a list of the dangerous permissions that you need to ask for.
Considering:
Revoking
User security(and privacy conserns from users who really care about this)
it is best to ask for permissions. This will also prevent crashes when permissions are revoked. even targeting API 22 and below, the permissions can still be revoked and cause problems where ever you call something that require these permissions.
Only when targeting API 23, and requesting permissions, can you control your app. You can ask for permissions where you need them, and without access you can block features and also let the user know what the permission is being used for, and giving the user the feeling that the permission isn't being used for something malicious or privacy-violating.
As mentioned in this answer to your question:
Yes, We need to request permission from user. Beginning in Android 6.0 (API level 23), users grant permissions to apps while the app is running, not when they install the app.
It is not a requirement, but if you target API 22(Android 5) the permissions are still asked for when the app is installed. A lot of apps would not be allowed to install if apps that targeted API 22 were "incompatible" with ANdroid 6.
If the device is running Android 5.1 or lower, or your app's target SDK is 22 or lower: If you list a dangerous permission in your manifest, the user has to grant the permission when they install the app; if they do not grant the permission, the system does not install the app at all.
Apps targeting Android 5.x and lower will still install the same way on Android 6: You cannot allow or disallow single permissions on install if the app targets API 22. Permissions can be revoked from settings, but no permissions can be blocked from install when it is targeting API 22.
In ANdroid Manifest, you still have to list all your permissions, both normal and dangerous. If the app targets API 23, it will require all the permissions on Android 5.x and lower, and request on API 23 and up(remember to check if the user is on API 23 or up before requesting).
To summarize:
Requesting is not a requirement. It is, however, a good idea to do so and make sure you design the app to only do what it has permission to. Thus: You do not have to request permissions, but it is a very good idea to do it.
When targeting API 23, no permissions are granted automatically. You have to ask for them. When targeting API 22, the permissions are automatically granted and consented to when the user installs the app.
Also note:
Android is progressing fast. Android 7(API 24 &25) also use the permission system. In a few years, all Android-devices may run on the permission system, at which point it is a good idea to already have integrated the permission-system into your app.
Yes, We need to request permission from user.
Beginning in Android 6.0 (API level 23), users grant permissions to apps while the app is running, not when they install the app. This approach streamlines the app install process, since the user does not need to grant permissions when they install or update the app. It also gives the user more control over the app's functionality; for example, a user could choose to give a camera app access to the camera but not to the device location. The user can revoke the permissions at any time, by going to the app's Settings screen.
System permissions are divided into two categories, normal and dangerous:
Normal permissions do not directly risk the user's privacy. If your app lists a normal permission in its manifest, the system grants the permission automatically.
Dangerous permissions can give the app access to the user's confidential data. If your app lists a normal permission in its manifest, the system grants the permission automatically. If you list a dangerous permission, the user has to explicitly give approval to your app.
However, the effect of that declaration is different depending on the system version and your app's target SDK level:
If the device is running Android 5.1 or lower, or your app's target SDK is 22 or lower: If you list a dangerous permission in your manifest, the user has to grant the permission when they install the app; if they do not grant the permission, the system does not install the app at all.
If the device is running Android 6.0 or higher, and your app's target SDK is 23 or higher: The app has to list the permissions in the manifest, and it must request each dangerous permission it needs while the app is running. The user can grant or deny each permission, and the app can continue to run with limited capabilities even if the user denies a permission request.