Explain Android runtime permissions and app adaptation methods in detail

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

1. For Android 5.1 (API 22) and previous versions, application permissions must be declared in androidmanifest.xml. During application installation, Android will list all permissions required for users to confirm installation.

2. For Android 6.0 (API 23) and later versions, the application permissions must be declared in androidmanifest.xml, but the permissions are divided into normal permissions and dangerous permissions. The differences are described below:

General permission: no risk to user privacy

The application declaration is in androidmanifest.xml, and the system will grant it automatically without application.

Dangerous permission: the application has the permission to access the user's confidential data, which will be at risk

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

2. This kind of permission belongs to runtime permission. After the application is started, it needs to call the system API pop-up window for user authorization before performing relevant operations requiring this kind of permission. The pop-up content application cannot be modified. If the runtime permission is missing (the user is not authorized), the app FC will be caused if the application forcibly executes the operation or calls the API. As follows:

There are three statuses of row time permission: allow, query (user_set), and reject (user_fixed). Users can manage the status of each application permission in the permission management of the system.

So how should an application adapt to runtime permissions, and what is its standard practice?

1. List all required permissions in androidmanifest.xml, including normal permissions and dangerous permissions

2. After the application is started, call the system API before calling the API with the required runtime permission, such as checkselfpermission, to query whether it has obtained the relevant permission. If it has, it can continue to execute the API or subsequent operations normally, which is represented by pseudo code below:

Finally, list all dangerous permissions. Note that there is the concept of permission groups. When applying for a specific permission, the system will only inform the user of the permission group to which the application needs to access in the pop-up window, and will not describe the specific permission. If none of the application permissions in a permission group has been authorized, a window will pop up for users to select authorization; If an application in a permission group has been authorized with one permission, it will be automatically authorized by default when it applies for other permissions in the same permission group again.