Android runtime permission and APP adaptation

Android runtime permission and APP adaptation

Since Android 6.0, Android has enhanced permission management and introduced the runtime permission concept. For:

1. for Android 5.1 (API 22) and earlier versions, the application permission must be declared in AndroidManifest. xml. During app installation, Android will list all the permissions required for users to confirm installation.

2. for Android 6.0 (API 23) and later versions, the application permission must be declared in AndroidManifest. xml, but the Permissions are divided into Normal Permissions and Dangerous Permissions. The differences are as follows:

General permission: does not pose a risk to user privacy

The application declaration is in AndroidManifest. xml. The system automatically grants the application without application.

Dangerous permission: the application's permission to access user's confidential data is risky.

1. This permission must also be declared in AndroidManifest. xml

2. This type of permission belongs to the runtime permission. After an application is started, you must call the system API pop-up window to authorize the user before performing operations that require this type of permission. the pop-up window content cannot be modified. If the runtime permission is missing (the user is not authorized), the app fc may be triggered when the APP forcibly performs the operation or calls the API. As follows:

3-10 04:47:44. 274 10405 8714 8714 E AndroidRuntime: java. lang. runtimeException: Unable to create service xxxxxx. smsBackgroundService: java. lang. securityException: Permission Denial: opening provider com. android. providers. telephony. mmsSmsProvider from ProcessRecord {48 bbdaa 8714: xxxxxx/u0a405} (pid = 8714, uid = 10405) requires android. permission. READ_SMS or android. permission. WRITE_SMS

Three statuses of runtime permissions: Allow, ask (USER_SET), and reject (USER_FIXED ). You can manage the status of each application permission in system permission management.

So how can an application adapt to runtime permissions? What is the standard practice?

1. List all required permissions in AndroidManifest. xml, including common and dangerous permissions.

2. after the application is started, you must call the system API, such as checkSelfPermission, before calling the API with the required runtime permission, you can continue to normally execute the API or subsequent operations. The following uses pseudo code:

If (checkSeflPermission (...)){
// The application has not obtained this dangerous permission
If (shouldShowRequestPermissionRationale (...)){
// The user rejects the permission. In this case, the application can pop up to notify the user. Note: if the user selects "no more inquiries" when the user rejects the permission, this method returns false and is no longer reliable, you can perform the following operations in the onRequestPermissionsResult method:
// For example, Baidu map will pop up to inform users of the lack of relevant permissions. Please click to jump to the settings page and enable the permissions. This is also the standard practice of most applications.
//......
} Else {
// The user queries the permission. The application can use the system API pop-up window to apply for the permission. The user operation result can be processed in the onRequestPermissionsResult of the overload method.
RequestPermissions (...);
}
} Else {
// You already have this dangerous permission and can perform related operations with ease later.
//.....
}

Finally, list all dangerous permissions. Note that the Permission group concept is available here. When applying for a specific Permission, in the dialog box that appears, the system only notifies the user of the permission group that the application needs to access. This permission is not described. If no permission is granted to an application in a permission group, a window is displayed for users to choose authorization. If an application in a permission group has been granted one of the permissions, when the application applies for other permissions in the same permission group again, it is automatically authorized by default.

Https://www.bkjia.com/topicnews.aspx? Tid = 11

This article permanently updates link: https://www.bkjia.com/Linux/2018-03/151420.htm