奇技指南：一说到沙箱，相信大家都有一个大概的认识：每个App会被分配一个uid，互相之间数据不能随意访问。

虽然做上层开发有这么个大概的认识基本也就够了，不过深入了解一下可能会给你的开发带来新的思路。今天我们就深挖一下所谓的沙箱机制。

大家都知道Android底层是Linux内核，而这一切也都源于Linux的权限机制。

Linux 权限机制用户 uid gid gids

进程 uid gid gids，继承于所属用户，子进程继承父进程

文件系统，uid gid 以及相对应rwx权限

Android

先看adb shell，我们先记住下面这个结论，后面会给出解释：

adb shell 实际上是以“shell”这个uid启动shell进程

adb shell xx 则是fork一个shell进程的子进程xx

因此xx进程的uid、gid与shell的uid、gid一致：id=2000

'id' 命令可以查看user信息：

'cat /proc/xxx/status'查看进程信息，包括uid、gid、groups

以上是Android中user和进程的uid gid，那么在Android中文件系统的uid、gid又是怎样的呢？file 事实上是在文件系统创建时对目录和文件设置了相对应的uid、gid以及权限，这里涉及到一个重要文件 fs_config.c

对目录的定义：

对文件定义：

device node 的uid、gid定义则在各个ueventd.*.rc文件中

由于都是基于Linux的权限机制，因此Android中进程要访问文件那势必也要获取到合理的uid或者gid。

怎么获取？System Process

我们知道在init进程的最后阶段，核心系统服务servicemanager、vold、surfaceflinger等进程都会被启动，他们的uid、gid也都是通过相应的.rc文件指定的。就拿suerfaceflinger来说，surfaceflinger.rc.

App Process

每个app安装之后被分配uid

Users、Groups 在android中定义 android_filesystem_config.h

我们可以看到熟悉的身影：

AID_ROOT 0

AID_SYSTEM 1000

AID_SHELL 2000

而对于正常的app will be assigned AID above 10000, and the GID、UID will be the same as AID.

以微信为例，微信的data目录权限如下：

我们看到这些文件的uid、gid都是u0_a504，这个u0_a504前半部分u0是userID，后面a504是根据微信安装后系统分配id为10504。因为这个id是唯一不重复的，只要不卸载那么10504就只能是微信uid，因此也只有微信的进程uid/gid = u0_a504，也就是说只有微信的进程可以访问微信data目录下的文件，这就保证了app私有数据的独立性与安全性。

那么除此之外，还有什么方式可以获取权限来访问文件呢？这就和上层的permisson扯上关系了。

其实核心文件是：platform.xml

看到这个文件大家应该就明白了，我们可以看到每个permission都会对应一个group，里面的gid是不是很熟悉。没错，对于任何申请了这些权限的app来说，它的任何进程的gids都包含了对应的gid，因此才可以访问相应的文件。就拿我们最熟悉的android.permission.WRITE_MEDIA_STORAGE权限来说，我们看下sdcard目录的文件权限：

我们看到sdcard目录下的文件其gid都是sdcard_rw，如果一个app在AndroidManifest中申请了这个权限，那么这个app所有进程的gids一定包含sdcard_rw这个gid，那么进程就有相应的rwx权限，就可以访问这些文件。(为保证主线清晰，这些牵线搭桥的逻辑就不一一贴代码溯源了)

到这里有人一定会说：我理解的permission不是这样的啊，我manifest里面声明的permission根本没有这么复杂，另外你上面那个platform.xml文件就只有很少的几个permission，我平时用到的大部分permission都不在里面呢？

这个问题我觉得还是有必要说一下，因为确实容易产生疑问。

我们要清晰的知道，Android的permisson分为两种：底层统一控制(上面讲的)

对于非Android特有的Service(底层平台已经提供，如File访问，TCPIP数据收发等)，可以多种形式来访问：Android API，Java API，NDK C API，shell都可以访问。这样权限控制就聚口在底层，所以在底层统一控制。这个底层统一控制其实就是基于传统的Linux文件读写执行权限(rwx)。例如android.permission.WRITE_MEDIA_STORAGEframework逻辑控制

绝大部分的permission权限控制发生在framwork层，在ams pms wms 中你会遇到大量调用以下方法的地方：

关于这块的逻辑因为不是本文重点，大体说一句：哪些package在manifest中申请了哪些权限，以及动态权限是否授予，这些信息都会被事先扫描或者动态加入到缓存中，然后framwork会在需要判断这些权限的时候调用checkPermission读取缓存信息。如果申请并且被授予了则放行，否则抛异常。

adb shell

我们再回头来解释一开始说到的adb shell xxx进程uid的问题。通过ps命令我们可以追溯一下adb shell进程父子链：init -> adbd -> /system/bin/sh -> xxx

我说的shell进程即 /system/bin/sh

事实上init进程的uid是root，那么正常情况adbd后面进程也都应该是root啊，为什么从adbd开始uid就成了shell呢？这一度也是我疑惑的地方，看了adbd源码发现原来adbd对uid、gid另外进行了设置。

adbd流程节选：

另外我们看看framwork中shell包的权限声明：shell权限

我们看到几乎所有的permission都在shell包里声明了，因此adb shell可以说是权限之王(个别权限也没有，否则你把root搁那>_<>

我们举个例子：

example : adb shell pm grant package_name permission_name

具体pm实现这里就不贴了，pm grant是需要验证调用者是否具有android.permission.GRANT_RUNTIME_PERMISSIONS权限，这个权限是@hide，普通app肯定没有这个能力，但是shell这个uid是有的。因此adb shell pm grant就可以给其他package授予某个权限，当然具体代码里还会根据protection_level来限制可以授予哪些权限。

清楚了这些我们可以会对adb shell了然于胸，在debug或者研究东西的时候充分利用adb shell，因为shell拥有海量权限。

当然我们也应该很清楚，在你的app中试图使用下面的代码来达到授权的目的其实是无效的：Runtime.getRuntime().exec('pm grant package_name permission_name');

为啥就不用我说了吧，我们通篇可都是在强调uid。