Android Rights Management Knowledge Learning record

I. Background knowledge of Android permissions

Before Android 6.0, the requested permissions only need to be listed in Androidmanifest.xml, which can easily lead to a number of security risks, so at the time of Android 6.0, Google to better protect user privacy proposed a new authority management mechanism, It is also divided into two main categories:
(1) Normal Permissions
Normal permission generally does not involve user privacy, is not required to authorize users, such as mobile phone vibration, access to the network and so on.
(2) Dangerous Permission
Dangerous permission is generally related to user privacy, users need to authorize (dynamic application), such as reading SIM card status, access to Contacts, SD card reading and writing.
Dangerous permission can be viewed through the ADB shell pm list permission-d-G.
Dangerous permission generally exist in the form of permission group, as long as one permission in permission group is granted (granted), the entire permission The permissions under Group are granted.

Second, permission check and Permissions compatible 1.targetsdkversion>=23, terminal equipment is 6.0 (API 23) above the system.

You will not be granted permission at the time of installation to request the appropriate permissions from the user at run time. This part of the permission check is relatively simple, does not involve permission compatibility, using the official program can be, using context:checkselfpermission, we recommend the use of contextcompat:checkselfpermission check permissions, The general inspection process is as follows:
(1) Determine whether there is a corresponding permission
(contextcompat::checkselfpermision)
(2) Determine whether the use of the corresponding permission (Activitycompat::shouldshowrequestpermissionrationale) should be interpreted
If you need an explanation, you can display the custom permissions interface
(3) No need to explain, directly request the corresponding permission
(activitycompat::requestpermission)

2.targetsdkversion<23. Terminal equipment is 6.0 (API 23) above the system

Using the old permissions mechanism, you will be asked for permissions in the Androidmanifest.xml file when the app is installed, but users can turn off permissions in the Settings list, which can have an impact on the app's uptime.

3. Terminal system less than 6.0 (API 23)

The old authority management mechanism is, in the app installation will ask the Androidmanifest.xml file permissions, the user can not close, but there are many domestic ROM phone in 6.0 between the switch has the power off.
Adaptation Process:
1. Use Try-catch to check if permissions are turned off
The method that uses Read_phone_state permission inside already try-catch, outside cannot catch, so if this permission is forbidden by user, report an exception, the method that makes fuss in catch is useless at all.
2.contextcompat::checkselfpermission
In 6.0 you can use Context::checkselfpermission for permission checking, and in API 23 that uses the Contextcompat::checkselfpermission method in the support V4 to fail, As long as the permissions are registered in Androidmanifest.xml, the permission is considered granted, so the method fails under API 23.
3.PermissionChecker
PermissionChecker is actually using Appopsmanagercompat, and Appopsmanager is added to API 19.
Under API 23, Appopsmanagerimpl::p ermissiontoop directly returns NULL, which directly results in API 23 The following permission check will return granted, so the method under API 23, the permission check method will also be invalidated.
4.AppOpsManager
API 19 above, Google officially provides the Appopsmanager class to check permissions, there are two more important methods: Appopsmanager::checkop (int op,int uid,string packagename) ( The Hide method, which requires reflection) and Appopsmanager::checkop (String op,int uid,string PackageName) (public method, API 23 or more available).
However, when the API is below 23 o'clock, op_read_phone_state=51 cannot be found, causing the Appopsmanager::checkop method to fail to reflect, causing the _num_op of each version to be different, op_read_phone_state = 51 under 6.0 (API 23), the reflection is not found, so the read_phone_state permission check is limited to 6.0 and more than 6.0.

Third, jump to the app management permissions interface 1. Direct Jump System Settings page

        New Intent ();        Intent.addflags (intent.flag_activity_new_task);        Intent.setaction (settings.action_application_details_settings);        Intent.setdata (uri.fromparts (null));         Try {            startactivity (intent);        } Catch (Exception e) {            e.printstacktrace ();        }

Remember to add try-catch, without the possibility of crash (crashes). This way does not need to adapt to different versions of the various manufacturers of ROM, the disadvantage is that users can only jump to the System Settings page, and then go to the corresponding app rights management.

2. Standing on the shoulders of the predecessors

For different mobile phone or mobile phone system, jump Rights Management page activity or different, if not add Try-catch, will be directly crash.
For this kind of change, as the developer is generally not aware of, even if through feedback to find this problem, also may not know what actiivty is, now either search on the Internet has a similar solution, or to the corresponding ROM developer forum developer.

3. View activity for a version of a ROM's Rights management interface

(1) Find the Right Management page for the app by setting up
(2) Find the activity of the corresponding page
Method One: View the top of the stack activity with the Add tool

ADB Shell Dumpsys Activity | grep "Mfocusedactivity"

Method Two: Use the Activity Tracer tool

This article just will see the article to learn to organize records, detailed also please check the original text.

Original:Http://mp.weixin.qq.com/s/OQRHEufCUXBA3d3DMZXMKQ

Android Rights Management Knowledge Learning record