在研究Android系统时，有时会遇到Sandbox（沙箱）这个概念。沙箱概念本身并不是太新奇，但是一直不是很清楚Android是如何实现它所称的“沙箱”的。网上不少人声称应用使用了虚拟机就是应用了沙箱，一直对这种说法表示怀疑。
最近发现Android的网站上更新了一些文档，其中包括对Sandbox的解释，这才明白Android中Sandbox的含义。
Android的”沙箱“就是在Linux的进程管理基础上对UID的使用做了改进。普通的Linux中启动的应用通常和登陆用户相关联，同一用户的UID相同。但是Android中给不同的应用都赋予了不同的UID，这样不同的应用将不能相互访问资源。对应用而言，这样会更加封闭，安全。虽然这个现象早已了解，但是一直不知道这就是Android所谓的”sandbox“。
有关英文解释见下面：
The Application Sandbox
The Android platform takes advantage of the Linux user-based protection as a means of identifying and isolating application resources. The Android system assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process.
This approach is different from other operating systems (including the traditional Linux configuration), where multiple applications run with the same user permissions.
This sets up a kernel-level Application Sandbox. The kernel enforces security between applications and the system at the process level through standard Linux facilities, such as user and group IDs that are assigned to applications. By default, applications
cannot interact with each other and applications have limited access to the operating system. If application A tries to do something malicious like read application B‘s data or dial the phone without permission (which is a separate application), then the operating
system protects against this because application A does not have the appropriate user privileges. The sandbox is simple, auditable, and based on decades-old UNIX-style user separation of processes and file permissions.
Since the Application Sandbox is in the kernel, this security model extends to native code and to operating system applications. All of the software above the kernel in Figure 1, including operating system libraries, application framework, application runtime,
and all applications run within the Application Sandbox. On some platforms, developers are constrained to a specific development framework, set of APIs, or language in order to enforce security. On Android, there are no restrictions on how an application can
be written that are required to enforce security; in this respect, native code is just as secure as interpreted code.
In some operating systems, memory corruption errors generally lead to completely compromising the security of the device. This is not the case in Android due to all applications and their resources being sandboxed at the OS level. A memory corruption error
will only allow arbitrary code execution in the context of that particular application, with the permissions established by the operating system.
Like all security features, the Application Sandbox is not unbreakable. However, to break out of