In marshmallow's runtime permission, user can choose "never ask again" in permission requests. In this case, we have to redirect user to app settings to let them enable the permissions for the app. Also, Android permissions are group based, it will be very handy to display names of the permission groups that the app needs before we send the user to the settings.
I've seen the strings in android.Manifest such as "android.permission-group.LOCATION". Is it possible to get the permission group names programmatically?
getPermissionGroupInfo() on PackageManager returns a PermissionGroupInfo for that group name (android.permission-group.LOCATION). On that, call loadLabel(), supplying the PackageManager as input, to get the human-readable name of the permission group. This should be localized for the user's chosen device locale.
Related
NOTE: This question IS NOT for customizing the text in a permission request dialog (shouldShowRequestPermissionRationale() mentioned in OP).
Are the message strings displayed when calling requestPermissions() standard, or vendor specific? Are these strings accessible for reuse?
In OnRequestPermissionsResult(), if the user denies Android.Manifest.Permission.WriteExternalStorage, I would like to show a dialog saying "<app-name> requires " + "Allow <app-name> to access photos, media, and files on your device" (or something to that effect), instead of writing a different message like "SD-Card write access required to continue." (which is something more suited shouldShowRequestPermissionRationale()).
I'd prefer the messages match to avoid confusion, so that when the user is re-prompted they know exactly what permissions are required to allow.
Here is an example of my usage of OnRequestPermissionsResult
Are the message strings displayed when calling requestPermissions() standard, or vendor specific?
Anything can be changed by device manufacturers. Even for the subset of devices that are part of the Google Play ecosystem, message text like this could be changed.
Are these strings accessible for reuse?
They appear to come from the description of the <permission-group> to which your permission belongs. Presumably you can use PackageManager and PermissionGroupInfo to get the values at runtime.
update(samusarin):
PermissionGroupInfo pgi = this.PackageManager.GetPermissionGroupInfo(Android.Manifest.Permission_group.Storage, PackageInfoFlags.Permissions);
string desc = pgi.LoadDescription(PackageManager);
I just discovered that, during app initialization my registerContentObserver for Contacts requires READ_CONTACTS permission. Obviously, for a new user on Android 6 and later, this permission won't yet be granted.
It seems to me it would be sufficient to ignore the permission during registration and check permission when the app listener tries to access contacts - which I'm sure it already does.
Same for Calendar.
Should I make an Android change request - why is this coding "penalty" being imposed?
Please let me know what is identity permissions? And how to implement from code this kind of permission?
II have already implement contacts read and other runtime permission but unable to find anything about identity permission.
GET_ACCOUNTS was previously in the Identity permission group.
It moved to the Contacts permission group in Android 6.
https://developer.android.com/reference/android/Manifest.permission.html#GET_ACCOUNTS
Android 6.0 permission.GET_ACCOUNTS
Identity – With this permission the app can find accounts on the device, see and modify the owner’s contact card and add or remove contacts from the device. The permission **group CONTACTS deals with the user’s contacts while ACCOUNT_MANAGER deals with the user’s accounts.**
<uses-permission android:name="android.permission-group.CONTACTS"/>
<uses-permission android:name="android.permission.ACCOUNT_MANAGER"/>
At code level one can set permission by using **https://developer.android.com/training/permissions/requesting.html**
First check
// Assume thisActivity is the current activity
int permissionCheck = ContextCompat.checkSelfPermission(thisActivity,
Manifest.permission.group.CONTACTS);
Is there a way to choose which order the user is prompted for permissions in Android Marshmellow's new permissions dialog?
When the user launches the camera in my app, I'm prompting for:
Manifest.permission.CAMERA
Manifest.permission.WRITE_EXTERNAL_STORAGE
Manifest.permission.RECORD_AUDIO
Because it makes the most sense (e.g. open camera, app requests camera permissions), I want the permissions to be requested in that order as well. But they aren't requested in that way - the Permissions dialog seems to just ignore the order I have in the String array.
Code below, using the EasyPermissions library, but the same thing happens without the EasyPermissions library.
ArrayList<String> permissionsToRequest = new ArrayList<String>();
permissionsToRequest.add(Manifest.permission.CAMERA);
permissionsToRequest.add(Manifest.permission.WRITE_EXTERNAL_STORAGE);
permissionsToRequest.add(Manifest.permission.RECORD_AUDIO);
EasyPermissions.requestPermissions(
this,
"To take pictures & record video, we need access to your device's camera & storage. Allow?",
R.string.acceptPermission, R.string.declinePermission,
RequestConstants.REQUEST_CAMERA_PERMISSIONS,
permissionsToRequest.toArray(new String[0])
);
Regardless of how I order the permissions in permissionsToRequest, the user is prompted in the same order (Audio, Storage, Camera), which in my opinion is the least intuitive order. Any way to fix this?
Although there isn't a clear way to define the order of permission, I found that it is somehow related to the order defined in the AndroidManifest.xml and in the array passed in Activity.requestPermissions(String[] permissions, String requestCode)
In a device, the order of the permission array was the order it showed in the screen. In a different device, the order defined in the manifest prevailed.
Hope this helps.
Been doing some Android permission research and ran across an application that - according to the AndroidManifest.xml file - only declares WRITE_EXTERNAL_STORAGE as a permission. The Android Market only reports this as well. Using the aapt tool to dump the uses-permission it also only reports the one permission.
However, in code running on the Android device (or emulator), doing the following:
PackageManager pm = getPackageManager();
List<PackageInfo> pkgList = pm.getInstalledPackages(PackageManager.GET_PERMISSIONS | PackageManager.GET_SIGNATURES);
...
PackageInfo p = pkgList.get(i); // where i is the index of the apk in question
String[] perms = p.requestedPermissions;
I get 2 permissions for this APK, READ_PHONE_STATE and the one in the manifest, WRITE_EXTERNAL_STORAGE. Looking at the "Manage Apps" screen and selecting details for this also shows the additional READ_PHONE_STATE permission.
Are there cases where permissions can be/are 'implied' (in code, by feature use, etc) that would not be required in the Android Manifest? Or put another way, why does aapt return one set of permissions and the getPackageManager().getPackageInfo() API return a different set?
EDIT:
Searching with "more better" terms discovered the answer I was looking for: Android permissions: Phone Calls: read phone state and identity
In short, APKs compiled with earlier version of the SDK did inherit some permissions for free...
As far as I know permissions must always be explicitly set in the manifest.
If an application needs access to a feature protected by a permission, it must declare that it requires that permission with a element in the manifest. Then, when the application is installed on the device, the installer determines whether or not to grant the requested permission by checking the authorities that signed the application's certificates and, in some cases, asking the user. If the permission is granted, the application is able to use the protected features. If not, its attempts to access those features will simply fail without any notification to the user.
source
The difference you are seeing I believe is due to the protectionLevel attribute on permissions. Any permissions that are set to "normal" are not required to be OK'd by the user so they just show up in the Details section.