奇技指南：一说到沙箱，相信大家都有一个大概的认识：每个App会被分配一个uid，互相之间数据不能随意访问。
虽然做上层开发有这么个大概的认识基本也就够了，不过深入了解一下可能会给你的开发带来新的思路。今天我们就深挖一下所谓的沙箱机制。
大家都知道Android底层是Linux内核，而这一切也都源于Linux的权限机制。
先看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_STORAGE
framework逻辑控制
绝大部分的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。
联系客服
