Android naturally inherits the security mechanism of the Linux kernel, and at the same time combines the specific application characteristics of mobile terminals to make many useful improvements and enhancements.
Traditional operating systems such as window and unix/linux are user-centered, assuming that users are not trustworthy, and more consideration is given to how to isolate different users from resources (storage areas and user files, memory areas and users) processes, underlying devices, etc.). In the Android system, it is assumed that application software is not trustworthy, and even applications installed by users are not trustworthy. Therefore, it is first necessary to limit the functions of the application, that is, to place the application in a "sandbox" , achieve isolation between applications, and set permissions to allow or deny API calls, and control application access to resources, such as access to files, directories, networks, sensors, etc.
Android extends the user and permission mechanism of the Linux kernel security model, and cleverly transplants the user isolation mechanism of multi-user operating systems into application isolation. In Linux, a user identification (UID) identifies a given user; on Android, a UID identifies an application. Assign a UID to the application when it is installed. While the application exists on the device, its UID remains unchanged. Use only to allow or restrict application (not user) access to device resources. In this way, Android's security mechanism is perfectly connected with the Linux kernel's security model! Different applications belong to different users. Therefore, the application runs in its own independent process space. Applications with different UIDs naturally form resource isolation, thus forming an operating system-level application "sandbox".
The security between application processes and between the application and the operating system is implemented by the standard process-level security mechanism of the Linux operating system. By default, applications cannot interact with each other. Applications running in the process sandbox are not assigned permissions and cannot access the system or resources. Therefore, both applications running directly on the operating system and applications running on the Dalvik virtual machine receive the same security isolation and protection. Applications restricted in their respective "sandboxes" do not interfere with each other and do not interfere with each other. Damage to the system and other applications is minimized. The "sandbox" mechanism of Android applications is as shown below. Applications that do not have a trust relationship with each other are isolated from each other and run independently:
In many cases, applications originating from the same developer or development organization , there is a trusting relationship between them. The Android system provides a so-called shared UID (SharedUserID) mechanism so that applications with trust relationships can run in the same process space. Typically, this trust relationship is determined by the application's digital signature and requires the application to use the same UID in the manifest file.
*** Share UID application process space