Starting from Android 6.0, users need to request permissions at runtime. This article introduces the application and processing of runtime permissions, and discusses some handling of new and old versions when using runtime permissions.
A brief introduction to Android application permissions The default situation of
an Android application It does not have any permissions, that is to say, by default, an application does not have the right to perform some operations that may cause adverse effects. These adverse effects may be on other applications, operating systems, Or the user.
If the application needs some additional capabilities, it needs to statically declare the corresponding permissions in AndroidManifest.xml.
If the application does not declare permissions in the manifest, but uses the corresponding functions, when the corresponding functions are called , an exception will be thrown.
For example, if the program wants to send a request, but forgets to add Internet permission, then the program will throw an exception when sending this request. Generally, the exception will not be caught, so the program will crash directly:
Caused by : java.lang.SecurityException: Permission denied (missing INTERNET permission?)
Before the release of Android 6.0 (API 23), all the permissions were displayed to the user when installing the application, and the user chooses to install to accept all these permissions, and then cannot Revoke the authorization of these permissions.
Since Android 6.0, some of the more dangerous permissions need to pop up the box explicitly when the program is running, requesting user authorization.
As for when to pop this box, it is up to the application itself.
For other permissions, I think it is not very important . Dangerous, so still maintain the original practice, authorize when the user installs the application.
It should also be noted that in the settings, the user can selectively authorize or close the dangerous permissions of the application.
The protection level of Permission The protection level
of permission is set by the protectionLevel attribute, there are 4 types: normal, dangerous, signature, signatureOrSystem.
For details, please refer to the introduction: http://developer.android.com/guide/topics/manifest/permission-element. HTML
signatures are relatively uncommon, the remaining two are normal and dangerous.
These two types are discussed in Guides: Official website Guides: https://developer.android.com/guide/topics/security/permissions. html#normal-dangerous
can be summed up as follows: all permissions are still statically declared in the manifest, normal permissions are automatically authorized during installation, and dangerous permissions require the application to explicitly request user authorization.
Of course, for mobile phones below Android 6.0, or For old applications developed before, dangerous permissions are also authorized during installation, see the discussion in the next section for details.
Dangerous Permissions:
Table 1. Dangerous permissions and permission groups.
Permission Group Permissions
CALENDAR
READ_CALENDAR
WRITE_CALENDAR
CAMERA
CAMERA
CONTACTS
READ_CONTACTS
WRITE_CONTACTS
GET_ACCOUNTS
LOCATION
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
MICROPHONE
RECORD_AUDIO
PHONE
READ_PHONE_STATE
CALL_PHONE
READ_CALL_LOG
WRITE_CALL_LOG
ADD_VOICEMAIL
USE_SIP
PROCESS_OUTGOING_CALLS
SENSORS
BODY_SENSORS
SMS
SEND_SMS
RECEIVE_SMS
READ_SMS
RECEIVE_WAP_PUSH
RECEIVE_MMS
STORAGE
READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGE
想要查看所有dangerous的权限, 也可以用命令:
adb shell pm list permissions -g -d
手机版本和程序版本的不同处理
这里引用一段Guides里面的原文:
If the device is running Android 6.0 (API level 23) or higher, and the app's targetSdkVersion is 23 or higher, the app requests permissions from the user at run-time. The user can revoke the permissions at any time, so the app needs to check whether it has the permissions every time it runs. For more information about requesting permissions in your app, see the Working with System Permissions training guide.
If the device is running Android 5.1 (API level 22) or lower, or the app's targetSdkVersion is 22 or lower, the system asks the user to grant the permissions when the user installs the app. If you add a new permission to an updated version of the app, the system asks the user to grant that permission when the user updates the app. Once the user installs the app, the only way they can revoke the permission is by uninstalling the app.
Pay attention to the use of and and or , indicating that the new dynamic permission mechanism will only be adopted when the targetSdkVersion and the actual device version are both 23 and above. In other cases, as before, all permissions are authorized when the application is installed and upgraded.
It can be summed up as:
1. All permissions are declared in the manifest.
2. If (1) your app's targetSdkVersion is 23 and above, and (2) the app runs on Android 6.0 and above devices, dangerous permissions must be requested dynamically .
When the permission is denied, the app should still be able to use it, but some functions related to the permission cannot be used.
3. The two conditions (1) and (2) in the previous article are not satisfied at the same time, that is, it belongs to other situations. All permissions are in the Request when installing, if the user doesn't accept it, don't install it.
Pay special attention to this situation: the old application and the new system.
If the targetSdkVersion is less than 23, it is considered to be an application developed before the release of Android 6.0, and it is not compatible with 6.0.
Even if this application is installed on an Android 6.0 machine, it uses the original version. The installation grants the permission logic, and all permissions are authorized when the app is installed.
After installing an app with a targetSdkVersion less than 23 on an Android 6.0 device, you can view it in the app's settings and find that all dangerous permissions are turned on.
So Don't worry that old apps will crash in various ways on Android 6.0.
But users can still disable permissions in the system settings:
when clicking the authorization switch on the emulator, the following prompt pops up:
If the user insists on canceling the authorization, the app does not It will crash directly, but the function will become silent, and the return value may become null or 0, which will cause unpredictable behavior or crash.
Why do you need to upgrade targetSdkVersion in time?
This is because each version of the API may generate new Permissions, these newly added permissions are automatically obtained for applications whose targetSdkVersion is lower than the API.
Therefore, it is best to write the latest targetSdkVersion in time, so as to prevent the application from automatically acquiring the new permissions added by the new API.
Conclusion: The targetSdkVersion is also Permissions that do not exist are automatically acquired.
See: API Guides: https://developer.android.com/guide/topics/security/permissions.html
The paragraph "Automatic permission adjustments". All permissions in the
Permission group
have their own permission group.
When the system pop-up box requests a permission, it only specifies its category. When the user agrees, the system will give it the permission.( There is only this one).
But if the app already has another permission under the group, the system will automatically grant the permission (that is, the callback requesting the permission will return directly), and there will be no interaction with the user during this process.
The realization of dynamic permission
request : https://developer.android.com/training/permissions/requesting.htmlBecause
the API related to dynamic permission check is only added in Android 6.0, so when minSdkVersion is not 23, it is recommended to use SupportLibrary to achieve, the advantage is: no need in the program Add if to judge the version of the current device.
1. Check the permission status
If the operation you perform requires a dangerous permission, you must check whether you have this permission every time you perform an operation, because the user can freely change it in the application settings Authorization, so you must check whether you have permission before using it.
The method of checking permission: ContextCompat.checkSelfPermission() The two parameters are Context and permission name.
The return value is: PERMISSION_GRANTED if you have the permission, or PERMISSION_DENIED if not.
For example:
copy code
if (PackageManager.PERMISSION_GRANTED == ContextCompat.checkSelfPermission(MainActivity.this, Manifest.permission.READ_CONTACTS)) {
//has permission, do operation directly
ContactsUtils.readPhoneContacts(this);
Log.i(DEBUG_TAG, "user has the permission already!");
} else {
//do not have permissionCopy
code
2. Dynamically request permission
If the result of the above permission check is DENIED, then you need to explicitly request this permission from the user.
Android provides several A method to dynamically request permissions, calling these methods will display a standard Dialog, which cannot be customized at present.
2.1 Sometimes you may need to explain why you need this permission
Sometimes you may need to explain to the user the purpose of the permission .
Note that not every permission needs to be explained, the obvious ones can be left unexplained, too many explanations will reduce the user experience.
One way is, when the user has denied this permission, but uses this function again, then it is very likely that the user I don't quite understand why the app needs this permission, so I can explain it to the user first.
In order to find this kind of situation that the user may need to explain, Android provides a utility class method: shouldShowRequestPermissionRationale()
If the app has previously requested the permission and was denied by the user, this method will return true.
If the user previously denied the permission, check it If the "Don't ask again" option in the dialog box is selected, then this method will return false.
If the device policy prohibits the application from having this permission, this method will also return false.
Note that the dialog that explains the reason needs to be implemented by itself, the system does not Provide.
2.2
Request permission The method of requesting permission is: requestPermissions() Pass in an Activity, an array of permission names, and an integer request code.
This method is asynchronous, it will return immediately, when the user and dialog interaction is completed After that, the system will call the callback method to return the user's selection result and the corresponding request code.
Code:
Copy code
if (PackageManager.PERMISSION_GRANTED == ContextCompat.checkSelfPermission(MainActivity.this, Manifest.permission.READ_CONTACTS)) {
//has permission, do operation directly
ContactsUtils.readPhoneContacts(this);
Log.i(DEBUG_TAG, "user has the permission already!");
} else {
//do not have permission
Log.i(DEBUG_TAG, "user do not have this permission!");
// Should we show an explanation?
if (ActivityCompat.shouldShowRequestPermissionRationale(MainActivity.this,
Manifest.permission.READ_CONTACTS)) {
// Show an explanation to the user *asynchronously* -- don't block
// this thread waiting for the user's response! After the user
// sees the explanation, try again to request the permission.
Log.i(DEBUG_TAG, "we should explain why we need this permission!");
} else {
// No explanation needed, we can request the permission.
Log.i(DEBUG_TAG, "==request the permission==");
ActivityCompat.requestPermissions(MainActivity.this,
new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS ) ;
// MY_PERMISSIONS_REQUEST_READ_CONTACTS is an // app
-defined int constant. The callback method gets the
// result of the request . The "Don't ask again" option will only appear when the previous state of the permission is Denied. It has never been authorized before (that is, the first time the box pops up), or the previous state is Granted (of course, this In general, there will be no pop-up box to ask), and the pop-up box that appears does not have the option of not asking again. 2.3 Processing the response to request permission
When the user responds to the dialog requesting permission, the system will call the onRequestPermissionsResult() method to return the user's response.
The request code in this callback is the parameter passed in when calling requestPermissions(), which is an integral part customized by the app. Type value.
If the request is canceled, the returned array will be empty.
Code:
@Override public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
switch (requestCode) { case MY_PERMISSIONS_REQUEST_READ_CONTACTS: { // If request is cancelled, the result arrays are empty. if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) { // permission was granted, yay! Do the
// contacts-related task you need to do.
ContactsUtils.readPhoneContacts(this);
Log.i(DEBUG_TAG, "user granted the permission!");
} else {
// permission denied, boo! Disable the
// functionality that depends on this permission.
Log.i(DEBUG_TAG, "user denied the permission!");
}
return;
}
// other 'case' lines to check for other
// permissions this app might request
}
}
复制代码
系统自动回调的情况:
有一些情形下,调用
1. Automatic authorization: If the user has allowed an A permission in the permission group, then when the requestPermissions() method is called next time to request the B permission in the same group, the system will directly call the onRequestPermissionsResult() callback method and return PERMISSION_GRANTED 2.
Automatic denial: If the user chooses not to ask for this permission again, then when the app calls the requestPermissions() method again to request the same permission, the system will directly call the onRequestPermissionsResult() callback and return PERMISSION_DENIED.
Demo address: https://github.com/mengdd/AndroidMRuntimePermissionSample
Best Practices
Original: https://developer.android.com/training/permissions/best-practices.html
Best Practices Summary:
1. Use Intent to start other applications to complete functions.
2 .Only use the permissions you really need.
3. Don't bother users by requesting multiple permissions at a time. Some permissions can be requested until they are used.
4. Explain to the user why this permission is needed.
5. Starting from Android 6.0, For each permission, you need to test whether the two states of the switch can make the application run normally, rather than crash.
And related permissions may need to test different combinations.
ADB commands
can be used to manage permissions from the command line:
Use the adb tool to manage permssions from the command line:
List permissions and status by group:
$ adb shell pm list permissions -d -g
Grant or revoke one or more permissions:
$ adb shell pm [grant|revoke] <permission-name> ...
参考资料:
API Guides: https://developer.android.com/guide/topics/security/permissions.html
Training: https://developer.android.com/training/permissions/index.html
Runtime permissions: https://source.android.com/devices/tech/config/runtime_perms.html
permission element: http://developer.android.com/guide/topics/manifest/permission-element.html
设计Patterns -> Permissions: https://www.google.com/design/spec/patterns/permissions.html
Blog post: http://jijiaxin89.com/2015/08/30/Android-s-Runtime-Permission/
3rd party library:
PermissionsDispatcher: https://github.com/hotchemi/PermissionsDispatcher
RxPermissions: https://github. com/tbruyelle/RxPermissions
Grant: https://github.com/anthonycr/Grant
Address of this article: http://www.cnblogs.com/mengdd/p/4892856.html
Address of Demo of this article: https://github.com/ mengdd/AndroidMRuntimePermissionSample
android 6.0 permissions
Guess you like
Origin http://10.200.1.11:23101/article/api/json?id=326570742&siteId=291194637
Recommended
Ranking