During the day, I was working on adapting the SDK23 version and encountered many pitfalls. Now I have taken the time to write it down and take this as a warning.
First of all, you need to know what pitfalls you have to understand some definitions and basic usage methods.
Then let’s first introduce the permission grouping of dynamic applications.
The following permission group is officially defined by Google. The purpose is that when applying for permissions, as long as the user allows any permission of the same permission group, the other permissions of the group are allowed by default. However, according to the expert, it is best to use the permissions when using them, because it is not guaranteed that Google will replace the permission group or even delete it when it is happy.
group: permission:.WRITE_CONTACTS permission:.GET_ACCOUNTS permission:.READ_CONTACTS group: permission:.READ_CALL_LOG permission:.READ_PHONE_STATE permission:.CALL_PHONE permission:.WRITE_CALL_LOG permission:.USE_SIP permission:.PROCESS_OUTGOING_CALLS permission:.ADD_VOICEMAIL group: permission:.READ_CALENDAR permission:.WRITE_CALENDAR group: permission: group: permission:.BODY_SENSORS group: permission:.ACCESS_FINE_LOCATION permission:.ACCESS_COARSE_LOCATION group: permission:.READ_EXTERNAL_STORAGE permission:.WRITE_EXTERNAL_STORAGE group: permission:.RECORD_AUDIO group: permission:.READ_SMS permission:.RECEIVE_WAP_PUSH permission:.RECEIVE_MMS permission:.RECEIVE_SMS permission:.SEND_SMS permission:.READ_CELL_BROADCASTS
In fact, the definition of permission group is very simple. The following briefly introduces the steps to dynamically apply for permissions.
The first step is to check the permissions that the app has.
if((
mActivity,.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
// When the current Activity does not obtain READ_CONTACTS permission}else{
// Otherwise it is allowed}
The second step is to apply for permission.
(
mActivity,
new String[]{.READ_CONTACTS},
REQUEST_CODE_PERMISSION_CONTACTS);
The third step is the callback method for permission application.
@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
switch (requestCode) {
case REQUEST_CODE_PERMISSION_CONTACTS: {
if ( > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
//The user has been authorized} else {
//User denies permission}
return;
}
}
}
Such three steps look very simple, but it is not that simple to use.
Let’s talk about the pitfalls here.
Trouble 1. Permission application can only be in the context of Activity or Fragment, and getApplicationContext() cannot be used.
Since our project needs to obtain the memory storage path and create a series of file caches when initializing the application, these operations are written in the Application onCreate() call different Util tool classes, so it is a bit unreliable to write this way above Android 6.0. My current solution is to determine the SDK version when initializing the application, and only create cache files for apps with version number less than 23. If it is higher than 23, it will be initialized after entering the Activity.
Pit 2. The request code used when applying for permission must be less than 16.
As for the reason, it is not clear. Maybe Google believes that there are not many permissions, so there is no need to make the request code large and take up excess memory. Speaking of the request code, that is, the constant value REQUEST_CODE_PERMISSION_CONTACTS undefined in the above code. If the value you define exceeds 15, a security exception will be reported during runtime, prompting that the request code must be less than 16.
The above is the problem encountered in the dynamic application permissions of Android 6.0 introduced to you by the editor. I hope it will be helpful to you. If you have any questions, please leave me a message and the editor will reply to you in time. Thank you very much for your support for my website!