Android Permission 机制

2011年03月04日 星期五 17:35

AndroidManifest.xml里面的sharedUserID能够让不同的apk运行在同一个进程里，分享里面的数据，比如Contacts等，当然这个sharedUserID可以设置成“android.uid.system”就可以运行在系统进程中，有权修改系统数据。

但仅仅有着一个sharedUserID并不能够保证你的apk一定能运行成功，怎么办？签名啊。如果你有Android的源码就比较方便了，直接把Android.mk里面的LOCAL_CERTIFICATE 赋值为platform就行了。然后mm编辑，就能安装了。因为在安装的时候，PackageManager会检查，如果sharedUserId是system的，它会看这个apk的签名是不是system.crt，如果不是，会报出permission deny的error。而把LOCAL_CERTIFICATE改成platform就等于给APK签名。

进而可以通过这个问题研究一下整个Android permission的机制。系统的安全机制通过给每个用户分配单独的uid和gid来实现，Android系统中pid代表进程ID，这个是有系统在程序运行时分配的，这一点可以防止地址空间的数据共享，增强内存空间的安全性。对于外部则用到了uid进行封锁。

系统会给于用户进程单独的uid，当然系统也是要运行进程的，比如System，Radio，蓝牙，IO设备。系统中的init.rc文件会详细定义这些文件的权限。Android中对uid的定义是Root最高，其次是system，最低的是app。这是基于Linux系统的结果。

那么在APP里，要对一些进程进行访问，或者接受Broadcast，或者启动Activity、Service都是需要权限的，不能说你的app什么都能做，这也是需要在manifest file中设置的。

比如在startActivity时，如果你start自己apk里的activity，它们会在同一个application下，那么自然也就使用一个uid，start过程自然没有什么问题。如果你需要start别人写的Activity或者service，都需要用到同一个shareUserId才行，因为在ActivityManagerService要启动activity的之前，会首先检查uid，用checkPermission方法，透过binder获得pid和uid，检查你activity的binder的权限，如果你有权限则已，没权限的话就会抛出security exception。至于broadcast，检查则更为严格，会双向的检查发出者和接受者的权限。