About the pitfalls of Android6.0 dynamic permission application, android6.0 dynamic permission

About the pitfalls of Android6.0 dynamic permission application, android6.0 dynamic permission

During the day, SDK23 was adapted and encountered a lot of pitfalls. Now, I have to remember this as a warning.

First of all, you must understand some definitions and basic usage methods.

First, we will introduce the dynamically applied permission groups.

The following permission groups are officially defined by Google. The purpose is to allow other permissions of a permission group as long as the user permits any permission in the same permission group when applying for permission. However, according to the high profile, it is best to use the specific permission to request this permission, because Google is happy to change or even delete the permission group one day,

group:android.permission-group.CONTACTS  permission:android.permission.WRITE_CONTACTS  permission:android.permission.GET_ACCOUNTS  permission:android.permission.READ_CONTACTSgroup:android.permission-group.PHONE  permission:android.permission.READ_CALL_LOG  permission:android.permission.READ_PHONE_STATE  permission:android.permission.CALL_PHONE  permission:android.permission.WRITE_CALL_LOG  permission:android.permission.USE_SIP  permission:android.permission.PROCESS_OUTGOING_CALLS  permission:com.android.voicemail.permission.ADD_VOICEMAILgroup:android.permission-group.CALENDAR  permission:android.permission.READ_CALENDAR  permission:android.permission.WRITE_CALENDARgroup:android.permission-group.CAMERA  permission:android.permission.CAMERAgroup:android.permission-group.SENSORS  permission:android.permission.BODY_SENSORSgroup:android.permission-group.LOCATION  permission:android.permission.ACCESS_FINE_LOCATION  permission:android.permission.ACCESS_COARSE_LOCATIONgroup:android.permission-group.STORAGE  permission:android.permission.READ_EXTERNAL_STORAGE  permission:android.permission.WRITE_EXTERNAL_STORAGEgroup:android.permission-group.MICROPHONE  permission:android.permission.RECORD_AUDIOgroup:android.permission-group.SMS  permission:android.permission.READ_SMS  permission:android.permission.RECEIVE_WAP_PUSH  permission:android.permission.RECEIVE_MMS  permission:android.permission.RECEIVE_SMS  permission:android.permission.SEND_SMS  permission:android.permission.READ_CELL_BROADCASTS

 

In fact, the definition of a permission group is very simple. The following describes how to dynamically apply for permissions.

Step 1: Check the permissions of the app.

1 if (ContextCompat. checkSelfPermission (2 mActivity, Manifest. permisson. READ_CONTACTS) 3! = PackageManager. PERMISSION_GRANTED) {4 // The current Activity does not obtain the READ_CONTACTS permission. The time limit is 5} else {6 // otherwise, 7} is allowed}

Step 2: Apply for permissions.

1 ActivityCompat.requestPermissions(2     mActivity,3     new String[]{Manifest.permission.READ_CONTACTS},4     REQUEST_CODE_PERMISSION_CONTACTS);

 

Step 3: Permission application callback method.

1 @ Override 2 public void onRequestPermissionsResult (int requestCode, String permissions [], int [] grantResults) {3 switch (requestCode) {4 case when: {5 if (grantResults. length> 0 & grantResults [0] = PackageManager. PERMISSION_GRANTED) {6 // user authorized 7} else {8 // user denied permission 9} 10 return; 11} 12} 13}

 

The three steps seem simple, but they are not that easy to use. Let's talk about the pitfalls here.

 

Trap 1: Permission application can only be applied in the context of Activity or Fragment, and getApplicationContext () cannot be used ().

Because our project needs to obtain the memory storage path and create a series of file caches during Application initialization, these operations are all written in the Application's onCreate () and called different Util tool classes, therefore, it is a little unreliable to write such a statement above Android6.0. At present, my solution is to first judge the SDK version when the application is initialized, and only create cache files for apps whose version number is earlier than 23, and initialize the files after they enter the Activity.

 

Pit 2: The request code used for permission application must be less than 16.

The reason is unclear. Maybe Google thinks that there are not many permissions, and there is no need to make the request code a lot to occupy the excess memory. When it comes to the Request Code, that is, the undefined constant value REQUEST_CODE_PERMISSION_CONTACTS in the code above. If the defined value exceeds 15, a security exception is reported during running, prompting that the request code must be less than 16.

 

At present, these two pitfalls are enough for me to work for a day. It seems that I still have insufficient experience, and I will learn more in the future.