ClipboardService（CBS）是Android系统中的元老级服务了，自Android 1.0起就支持剪贴功能。在Android 4.0中再遇见它时，此功能已有了长足改进。本节将集中讨论CBS中的权限管理。先来回顾一下CBS中和权限管理相关的函数调用。
checkDataOwnerLocked(clip, Binder.getCallingUid());
clearActiveOwnersLocked();
//paste方获取ClipData在CBS的getPrimaryClip函数中进行：
addActiveOwnerLocked(Binder.getCallingUid(), pkg);
1. URI权限管理介绍Android系统的权限管理中有一类是专门针对URI的，先来看一个示例，该例来自package/providers/ContactsProvider，在它的AndroidManifest.xml中有如下声明：
[-->AndroidManifest.xml]
......
android:readPermission="android.permission.READ_CONTACTS"
android:writePermission="android.permission.WRITE_CONTACTS">
......
<grant-uri-permission android:pathPattern=".*" />
</provider>
这里声明了一个名为ContactsProvider2的ContentProvider，并定义了几个权限声明，下面对其进行解释。
- readPermission：要求调用query函数的客户端必须声明一个use-permission为READ_CONTACTS的权限。
- writePermission：要求调用update或insert函数的客户端必须声明一个use-permission为WRITE_CONTACTS的权限。
- grant-uri-permission：和授权有关。
初识grant-uri-permission时，会觉得它比较难理解，下面通过举例分析帮助读者加深认识。
- Contacts 和ContactProvider这两个APP都是由系统提供的程序，而且二者关系紧密，所以Contacts一定会声明use_Permission为 READ_CONTACTS和WRITE_CONTACT的权限。如此，Contacts就可以毫无阻碍地通过ContactsProvider来查询或 更新数据库了。
- 假设Contacts新增一个功能，将ContactsProvider中的某条数据复制到剪切板。根据前面已介绍过的知识可以知道，Contacts会向剪切板中复制一个URI类型的数据。
- 另外一个程序从剪切板中粘贴（paste）这条数据，由于是URI类型的，所以此程序会通过ContentResolver来查询该uri所指向的数据。但是这个程序却并未声明READ_CONTACTS的权限，所以它查询数据时必然会失败。
或许有人会问，为什么第三个程序不声明相应权限呢？原因很简单，第三个程序不知道自己该声明怎样的权限（除非这两个程序的开发者能互通信息）。本例 ContactsProvider设置的读权限是READ_CONTACTS，以后可能换成READ_CONTACTS_EXTEND，第三个程序不太可 能知道其中的变化。为了解决类似问题，Android提供了一套专门针对uri的权限管理机制。以这套机制解决示例中权限声明问题的方法是这样的：当第三 个程序从剪切板中粘贴数据时，系统会判断是否需要为这个程序授权。当然，系统不会随意授权，而是需要考虑ContactsProvider的情况。因为 ContactsProvider声明了grant-uri-permission，所以只要第三个程序所粘贴的URI匹配其中的 pathPattern，授权就能成功。倘若ContactsProvider没有声明grant-uri-permission，或者uri不匹配指定 的pathPattern，则授权失败。
有了前面介绍的权限管理机制，相信下面CBS中的权限管理理解起来就比较简单了。
提示 感兴趣的读者可阅读SDK安装目录下/docs/guide/topics/security/security.html中关于uri Permission的说明部分。
2. checkDataOwnerLocked函数分析
checkDataOwnerLocked函数的代码如下：
[-->ClipboardService.java::checkDataDwnerLocked]
//第二个参数uid为copy方进程的uid
final int N = data.getItemCount();
for (int i=0; i<N; i++) {
//为每一个item调用checkItemOwnerLocked
checkItemOwnerLocked(data.getItemAt(i), uid);
}
}
// checkItemOwnerLocked函数分析
private final void checkItemOwnerLocked(ClipData.Item item, int uid) {
if (item.getUri() != null) {//检查uri
checkUriOwnerLocked(item.getUri(), uid);
}
Intent intent = item.getIntent();
//getData函数返回的也是一个uri，因此这里实际上检查的也是uri
if (intent != null && intent.getData() != null) {
checkUriOwnerLocked(intent.getData(), uid);
}
}
下边来分析checkUriOwnerLocked函数，其代码如下：
[-->ClipboardService.java::checkUriOwnerLocked]
......
long ident = Binder.clearCallingIdentity();
boolean allowed = false;
try {
/*
调用ActivityManagerService的checkGrantUriPermission函数，
该函数内部将检查copy方是否能被赋予URI_READ权限。如果不允许，
该函数会抛SecurityException异常
*/
mAm.checkGrantUriPermission(uid, null, uri,
Intent.FLAG_GRANT_READ_URI_PERMISSION);
} catch (RemoteException e) {
} finally {
Binder.restoreCallingIdentity(ident);
}
}
3. clearActiveOwnersLocked函数分析
clearActiveOwnersLocked函数的代码如下：
[-->ClipboardService.java::clearActiveOwnersLocked]
PackageInfo pi;
try {
/*
调用PackageManagerService的getPackageInfo函数得到相关信息
然后做一次安全检查，如果PacakgeInfo的uid信息和当前调用的uid不一致，
则抛出SecurityException。这个很好理解，因为paste方可以传递虚假的
packagename，但uid是没法造假的
*/
pi = mPm.getPackageInfo(pkg, 0);
if (pi.applicationInfo.uid != uid) {
throw new SecurityException("Calling uid " + uid
+ " does not own package " + pkg);
}
} ......
}
//mActivePermissionOwners用来保存已经通过安全检查的package
if (mPrimaryClip != null && !mActivePermissionOwners.contains(pkg)) {
//针对ClipData中的每一个Item，都需要调用grantItemLocked来检查权限
final int N = mPrimaryClip.getItemCount();
for (int i=0; i<N; i++) {
grantItemLocked(mPrimaryClip.getItemAt(i), pkg);
}//保存package信息到mActivePermissionOwners
mActivePermissionOwners.add(pkg);
}
}
//grantItemLocked分析
private final void grantItemLocked(ClipData.Item item, String pkg) {
if (item.getUri() != null) {
grantUriLocked(item.getUri(), pkg);
} //和copy方一样，这里仅检查uri的情况
Intent intent = item.getIntent();
if (intent != null && intent.getData() != null) {
grantUriLocked(intent.getData(), pkg);
}
}
[-->ClipboardService.java::grantUriLocked]
long ident = Binder.clearCallingIdentity();
try {
/*
调用ActivityManagerService的grantUriPermissionFromOwner函数，
注意第二个参数传递的是CBS所在进程的uid。该函数内部也会检查权限。
该函数调用成功后，paste方就被授予了对应uri的读权限
*/
mAm.grantUriPermissionFromOwner(mPermissionOwner,
Process.myUid(), pkg, uri,
Intent.FLAG_GRANT_READ_URI_PERMISSION);
} catch (RemoteException e) {
} finally {
Binder.restoreCallingIdentity(ident);
}
}
------------------------------
本文节选自《深入理解Android：卷II》第3章“深入理解SystemServer”第3.7.3节：CBS中的权限管理。
【内容简介】
本 书是“深入理解Android”系列的第二本，第一本书上市后得到了广大读者的高度评价，在Android开发者社群内口口相传。本书不仅继承了第一本的 优点、改正了其在细微处存在的一些不足，而且还在写作的总体思想上进行了创新，更强调从系统设计者的角度去分析Android系统中各个模块内部的实现原 理和工作机制。从具体内容上讲，本书的重点是Android Framework的Java层，对Java层涉及的核心模块和服务进行了深入而细致的分析。通过本书，读者不仅能对Android系统本身有更深入的理 解，而且还能掌握分析大型复杂源代码的能力。
全书共8章：第1章介绍了阅读本书所需要做的准备工作，包括Android 4.0源码的下载和编译、Eclipse环境的搭建，以及Android系统进程（system_process）的调试等；第2章对Java Binder和MessageQueue的实现进行了深入分析；第3章详细剖析了SystemServer的工作原理，这些服务包括 EntropyService、DropboxManagerService、DiskStatsService、 DeviceStorageMonitorService、SamplingProfilerService和ClipboardService；第4章 对系统中负责Package信息查询和APK安装、卸载、更新等工作的服务PackageManagerService进行了详细分析；第5章则对 Android系统中负责电源管理的核心服务 PowerManagerService的原理进行了一番深入的分析；第6章以ActivityManagerService为分析重点，对它的启动、 Activity的创建和启动、BroadcastReceiver的工作原理、Android中的进程管理等内容展开了较为深入的研究；第7章对 ContentProvider的创建和启动、SQLite、Cursor query和close的实现等进行了深入分析；第8章以ContentService和AccountManagerService为分析对象，介绍了 数据更新通知机制的实现，以及账户管理和数据同步等相关知识。
【作者简介】
邓凡平，资深Android开发工程师和系统工程 师，热衷于Android源代码的研究，对Android的架构设计和实现原理有非常深刻的认识和理解，应用开发经验也十分丰富。《深入理解 Android：卷I》的作者，同时也是“深入理解Andriod”系列图书的总策划。目前就职于国内领先的Android企业中科创达 （ThunderSoft），负责Android Framework的开发和维护。喜欢钻研，乐于分享，活跃于CSDN、51CTO和开源中国等专业技术社区，撰写的Android Framework源码分析的系列文章深受读者欢迎。此外，他对Linux内核、C/C++/Python相关的技术，以及高性能网络服务器和多核并行开 发等也有一定的研究。
作者博客：http://blog.csdn.net/Innost
【关于本书的各种网址】
豆瓣网：http://book.douban.com/subject/11542973/
互动网：http://product.china-pub.com/3683060
当当网：http://product.dangdang.com/product.aspx?product_id=22840152
卓越网：http://www.amazon.cn/dp/B008RVQMBK
京东网：http://book.360buy.com/11056661.html