Android custom permission
Android is an operating system separated by privileges. Each application running on Android has its own system ID (Linux User ID and group ID ). Different parts of the system have different identities. Therefore, each application running on Linux is independent of each other and has nothing to do with the system.
The "permission" mechanism of Android provides fine-grained security functions by limiting the specific operations that a specific process can perform and limiting the URI permission for point-to-point access to each resource.
Because the kernel allows each application to run in an independent sandbox, the application must explicitly allocate resources and data by declaring the required permissions and the sandbox does not provide permissions. Android does not adopt a dynamic authorization mechanism that makes the user experience complex and is not conducive to security. Applications statically declare the permissions they need. During installation, the Android system prompts users to agree to these permissions.
The Android permission model is designed based on the following two objectives:
Notify users:
By listing all the sensitive operations that an application may perform, users are more aware of the potential risks of installing the application. This assumes that the user will read the permission list popped up during installation and decide whether to install the application based on the information.
Risk Reduction:
By limiting applications to access sensitive API interfaces of the Android system, you can reduce the damage (such as viruses) that the application brings to the entire system ).
Android permissions are classified into four levels:
General level:
These permissions cannot really harm users (such as changing wallpaper). When the program requires these permissions, developers do not need to specify the program to automatically grant these permissions.
Hazard level:
These permissions may cause real harm (such as making a phone call or opening a network link). To use them, the developer must declare the corresponding permissions in AndroidManifest. xml.
Signature level:
If the application uses the same signature certificate, these permissions are automatically granted to programs that declare or create these permissions. This level of permissions is designed to facilitate data sharing between components.
Signature/system level:
Similar to the signature level, system images automatically obtain these permissions, which are designed for device manufacturers.
In the process of developing Android applications, if we want to use certain services of the system (such as network, standby, and file read/write permissions), we must first look at AndroidManifest as follows. the corresponding permissions are declared in xml before these services can be accessed in code:
In addition to the various permissions provided by the Android system, we can also customize permissions to restrict other programs to access various services or components of the application. When a program wants to interact with its components, it must declare the corresponding permission to access the program successfully.
Follow these steps to customize permissions:
Take a service CalledService as an example. The procedure is as follows:
1. The AndroidManifest. xml file of the Called program is defined as follows:
The meaning of each label attribute is self-filled by the brain.
2. Declare the corresponding permissions in the AndroidManifest. mxl file of the application Call project that needs to Call this component:
3. Start and Stop the service in the Call Project of the application that needs to Call this component:
case R.id.startServiceBtnId:{Intent intent = new Intent( "com.uperone.action.SERVICE" );startService(intent);}break;
Note:If you do not declare the permission in Manifest. xml when calling a component that requires the permission, an exception is reported when running the corresponding code segment !!!!
For more custom permissions of components, see instance: Android custom permission.