Android 29_Android privilege mechanism
Many people know that when accessing some system resources, or when some system settings, such as network settings, we need to apply for permissions, but they don't know why Android wants to set such things, and why they put forward run-time permissions.
Android privilege mechanism
Some operations are risky operations, i.e. those involving user security issues. Android will do these operations in the form of permissions. Before 6.0, when we install a program, we can find a lot of permission applications in the installation interface. And if we reject one item, APP It can't be installed. It's very painful. So after 6.0, run-time permission is proposed. When user's operation needs permission, we apply again. This way is more reasonable and user experience is better. 
Classification of privileges
- General permissions
- Dangerous authority
- special competencies
Special privileges can be ignored. All privileges can be viewed on Android's developer website. Here is a Chinese link. https://developer.android.google.cn/guide/topics/security/permissions.html
The purpose of classification is to enhance the experience, not everything will involve security issues, users do not want to flip over and over the authorization, the system will automatically authorize ordinary permissions, and dangerous permissions need to pay attention to, this is the operation of users should be asked.
So what we need to note is that dangerous permissions are declared in manifest before 6.0, but after 6.0, we need a new way of writing after the operation permission mechanism is injected, otherwise we will find that the program needs to run perfectly before 6.0, and explode directly after 6.0.
Running permission writing
Here we take CALL_PHONE as an example.
Writing before 6.0
1. Application Authority
<uses-permission android:name="android.permission.CALL_PHONE"/>
2. Start-up system dial-up interface
private void callPhone(String phoneNumber) throws SecurityException{
Intent intent = new Intent(Intent.ACTION_CALL);
Intent intent1 = intent.setData(Uri.parse("tel:" + phoneNumber));
startActivity(intent);
}
Mobile phones before 6.0 can run this code very well, but after 6.0 can not, will directly make mistakes. Because after 6.0 we need to use the runtime permissions. It's easy to understand that all the calls here are OK. If the right to send text messages is allowed during installation, and some careless users don't even look at it, then security problems will arise later, which is very serious. Android can also see that it's really conscientious to do so.
Writing after 6.0
public class NextActivity extends AppCompatActivity {
final int REQUEST_CAllPHONE_CODE = 1;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_next);
findViewById(R.id.callBtn).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
if (ContextCompat.checkSelfPermission(NextActivity.this, Manifest.permission.CALL_PHONE)
!= PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(NextActivity.this, new String[]{Manifest.permission.CALL_PHONE}, REQUEST_CAllPHONE_CODE);
} else
callPhone("10000");
}
});
}
private void callPhone(String phoneNumber) throws SecurityException {
Intent intent = new Intent(Intent.ACTION_CALL);
intent.setData(Uri.parse("tel:" + phoneNumber));
startActivity(intent);
}
@Override
public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
super.onRequestPermissionsResult(requestCode, permissions, grantResults);
switch (requestCode) {
case REQUEST_CAllPHONE_CODE:
if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED)
callPhone("10000");
else
Toast.makeText(this, "This permission is not allowed", Toast.LENGTH_SHORT).show();
break;
}
}
}
Process analysis
