Before, the requests our team needed were just declared in the manifest. Later, when there was a runtime permission request, I was not familiar with permissions. Many of them were added on their own, so that the program could run, but sometimes, when I saw foreign programs, those concise permission lists, just I felt too casual again. I have also had permission request experience before, but they are all search->copy->debug, why I have not figured out why, anyway, isn't the ultimate goal to run it. Now, though, I hope, it's a little bit clearer, and not more muddled.
Era:
In Android 5.1.1 (API22) and before, it is an install_time permission request. However, in Android 6.0 (API23) and later versions, it will be a runtime permission request, which means that when a dangerous permission is required, it is necessary to check whether it is in the code. Granted.
Distinguish permission and hardware features:
First of all, they are all defined in the manifest, at the same level as <application>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.snazzyapp">
<uses-permission android:name="android.permission.CAMERA"/>
<uses-feature android:name="android.hardware.camera" android:required="false" />
<application ...>
...
</application>
</manifest>
According to the official documentation, if there is no uses-feature, the default is that the app must have this feature. If not, Google Play will not install the app on the phone. Otherwise, like android:required="false" in uses-feature in the code, it can be considered that this feature is not necessary and can be installed. Of course, the corresponding should be checked in the code.
Permission classification:
Permissions are officially divided into 3+1 categories: normal, signature, dangerous and special permissions. Normal -> the system can automatically authorize, Dangerous -> need to ask the user. Signature -> system application (with system signature) can be obtained. But the official also said that this will not affect the installation of the APP, but in fact you just can't get it. Special permissions are mainly SYSTEM_ALTER_WINDOW and WRITE_SETTINGS , which need to be requested.
Also, since API-23, there is the concept of permission group, but I personally think that since the official said that the grouping may change, don't rely on this mechanism, so I think its existence only allows us to understand this kind of It's just behavior, and it doesn't seem to be useful to developers.
Domestic situation:
Since most of the roms in our country are deeply customized, many of them have their own rights management mechanism. Therefore, I personally think that you should not trust the results returned after applying for permission, but you should check whether you have this permission yourself.
Request permission:
When adapting to API level 23 and above, the dynamic application for permissions needs to be handled in the code. According to the official documentation, if there is a requirement to adapt to a lower version, it is very convenient to use the support library.
process:
- Check permissions
- Does it need to be explained, yes -> explain
- request for access
- result callback processing
// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
// Should we show an explanation?
if (ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
Manifest.permission.READ_CONTACTS)) {
// Show an expanation to the user *asynchronously* -- don't block
// this thread waiting for the user's response! After the user
// sees the explanation, try again to request the permission.
} else {
// No explanation needed, we can request the permission.
ActivityCompat.requestPermissions(thisActivity,
new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
// MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
// app-defined int constant. The callback method gets the
// result of the request.
}
}
Result processing:
@Override
public void onRequestPermissionsResult(int requestCode,
String permissions[], int[] grantResults) {
switch (requestCode) {
case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
// If request is cancelled, the result arrays are empty.
if (grantResults.length > 0
&& grantResults[0] == PackageManager.PERMISSION_GRANTED) {
// permission was granted, yay! Do the
// contacts-related task you need to do.
} else {
// permission denied, boo! Disable the
// functionality that depends on this permission.
}
return;
}
// other 'case' lines to check for other
// permissions this app might request
}
}
The above two paragraphs are examples of direct copying from the official website, which are clear enough.
Official website link
Off topic:
I believe that many times we do not process business in the activity, but this permission request must be in the activity, and the result callback must be rewritten by the activity. This annoys a lot of people a bit when they have the schema. For the fragment, the activity can directly getActivity(), but the result is still not available. In fact, this is often the case. I basically pass the business code into the activity through interfaces and listeners, and I didn't think of any good solutions. Looking at the online examples, it is better to write it myself.
summary:
In Android 6.0 (API level 23) and later, the use of dangerous permissions must be dynamically applied. In previous versions, the permissions were all granted at the time of installation.
In fact, roms in China have already had permission control, but they are controlled at the system level. As for how it interacts with the application, I personally think it is cheating. .