http://blog.csdn.net/iefreer/archive/2009/09/10/4537371.aspx

安全和许可Security and Permissions

Android是一个多进程系统，每个应用程序（以及系统的部分）运行在它自己的进程里。大多数程序和系统之间的安全性通过基础的Linux机制在进程级别进行支持，如分配给应用程序的用户和群组IDs。更多细化的安全特性通过“许可”机制来提供，它实施对一个进程能够执行的特定操作方面的限制，和对于每个URI的特定数据段的特许访问的授权。

Android安全架构中的一个设计要点是在默认情况下应用程序没有权限执行对其它应用程序、操作系统或用户有害的操作。这些操作包括读/写用户的隐私数据（例如联系方式或e-mail），读/写其它应用程序的文件，执行网络访问，保持设备激活，等等。

应 用程序的进程是一个安全的沙箱。它不能干扰其它应用程序，除非明确声明它需要额外的基本的沙箱不能提供的功能的许可权。这些许可权请求能够被不同方式的操 作所处理，常见的是基于证书和用户提示的自动允许或禁止。应用程序的权限请求被声明为静态的，这样后面在安装时能够知道它们而且不会被改变。

所有的Android应用程序（.apk文件）必须用证书进行签名认证，而这个证书的私钥是由开发者保有的。该证书可以用以识别应用程序的作者。该证书也不需要被认证机构签名。Android应用程序完全允许而且一般也都是使用自签名（self-signed）证书。证书是用于在应用程序之间建立信任关系，而不是用于控制程序是否可以安装。签名影响安全性的最重要的方式是通过决定谁可以进入基于签名的许可，以及谁可以共享用户IDs。

每一个Android应用程序（.apk文件）都会在安装时就分配一个独有的Linux用户ID，这就为它建立了一个沙盒，使其不能与其他应用程序进行接触（也不会让其它应用程序接触它）。这个用户ID会在安装时分配给它，并在该设备上一直保持同一个数值。

由于安全性限制措施是发生进程级，所以两个package中的代码不会运行在同一个进程当中，他们要作为不同的Linux用户出现。我们可以通过使用AndroidManifest.xml文件中的manifest标签中的sharedUserId属性，来使不同的package共用同一个用户ID。通过这种方式，这两个package就会被认为是同一个应用程序，拥有同一个用户ID（实际不一定），并且拥有同样的文件存取权限。注意：为了保持安全，只有当两个应用程序被同一个签名签署的时候（并且请求了同一个sharedUserId）才会被分配同样的用户ID.

所有存储在应用程序中的数据都会赋予一个属性-该应用程序的用户ID,这使得其他package无法访问这些数据。当通过这些方法getSharedPreferences(String, int), openFileOutput(String, int), 或者openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory)来创建一个新文件时，你可以通过使用MODE_WORLD_READABLE与/或MODE_WORLD_WRITEABLE标志位来设置是否允许其他package来访问读写这个文件。当设置这些标志位时，该文件仍然属于该应用程序，但是它的全局读写权限已经被设置，使得它对于其他任何应用程序都是可见的。

一个基本的Android程序通常是没有任何许可与之关联的，这就是说它不能做任何扰乱用户或破坏数据的勾当。那么为了使用设备被保护的特性，我们就必须在AndroidManifest.xml添加一个或多个<uses-permission>标签，用以声明你的应用程序需要的许可。

例如，一个想要监控接收短消息的应用程序需要指定：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

    package="com.android.app.myapp" >

    <uses-permission android:name="android.permission.RECEIVE_SMS" />

</manifest>

在应用程序安装时，该应用程序请求的权限许可是通过package installer来授予的。package installer是通过检查该应用程序的签名和/或用户的交换结果来确定是否给予该程序request的权限。在用户使用过程中不会去检查权限，也就是说要么在安装的时候就批准该权限，使其按照设计可以使用该权限；要么就不批准，这样用户也就根本无法使用该feature,也不会有任何提示告知用户尝试失败。

很多时候, 一个许可失败会导致一个SecurityException被抛回该应用程序. 但是Android并不保证这种情况会处处发生。例如，当数据被deliver到每一个receiver的时候，sendBroadcast(Intent) 方法会去检查permissions,在这个方法调用返回之后，你也不会收到任何exception。几乎绝大多数情况，一个permission failure都会打印到log当中。

Android系统定义的权限可以在Manifest.permission中找到。任何一个程序都可以定义并强制执行自己独有的permissions，因此Manifest.permission中定义的permissions并不是一个完整的列表（即有肯能有自定义的permissions)。

一个特定的许可可能会在你的程序操作过程中的很多地方都被实施：

²  当系统有来电的时候，用以阻止程序执行其它功能。

²  当启动一个活动（activity）的时候，会阻止应用程序启动其它应用程序的Acitivity。

²  在发送和接收广播的时候，去控制谁可以接收你的广播或谁可以发送广播给你。

²  当进入并操作一个内容提供器（content provider）的时候

²  当绑定或起动一个服务（service）的时候

为了实施你自己的permissions，你必须首先在AndroidManifest.xml文件中声明该permissions.通常我们通过使用一到多个<permission> tag来进行声明。

例如，一个应用程序想要控制谁能启动它的活动，可以为该操作声明许可如下：

</manifest>

这里<protectionLevel>属性是必需的，通过声明该属性，我们就可以告知系统如何去通知用户哪些应用程序需要这个许可，或者谁可以拥有该许可。具体请参看链接的文档。

<permissionGroup>属性是可选的，只是用于帮助系统显示许可permission给用户（实际是告知系统该许可是属于哪个许可组permission group的）。你通常会选择使用标准的system group来设定该属性，或者更为少见的用你自己定义的group。推荐使用一个已经存在的group，因为这样UI给用户显示许可的时候会更简单。

需要注意的是标签（label）和描述（description）都是需要为许可提供的。这些都是字符串资源，当用户去看许可列表(android:label)或者某个许可的详细信息(android:description)时，这些字符串资源就可以显示给用户。label应当尽量简短，之需要告知用户该许可是在保护什么功能就行。而description可以用于具体描述获取该许可的程序可以做哪些事情，实际上让用户可以知道如果他们同意程序获取该权限的话，该程序可以做什么。我们通常用两句话来描述许可，第一句描述该许可，第二句警告用户如果批准该权限会可能有什么不好的事情发生。下面是一个描述CALL_PHONE 许可的label和description的例子：

你可以通过shell指令 adb shell pm list permissions 来查看目前系统已有的permissions. 特别的，"-s"选项会以一种用户会看到的基本相同的格式来显示这些permissions：

...

在清单文件里实施许可Enforcing Permissions in AndroidManifest.xml

用于限制进入系统或应用程序的Components的高级别许可可以再AndroidManifest.xml中实现.所有这些都可以通过在相应的component中包含 android:permission 属性，命名该permission以使其被用以控制进入的权限。

Activity许可（应用于<activity>标签）限制了谁才可以启动相应的活动。permission会在Context.startActivity()和Activity.startActivityForResult()的时候进行检查。如果caller没有所需的权限，则会抛出一个SecurityException。

Service许可（应用于<service>标签）用于限制谁才可以start或bind该service。在Context.startService() , Context.stopService()和Context.bindService()调用的时候会进行权限检查。如果caller没有所需的权限，则会抛出一个SecurityException。

BroadcastReceiver许可(应用于<receiver>标签)用于限制谁才可以向该receiver发送广播。权限检查会在Context.sendBroadcast() 返回时进行，由系统去发送已经提交的广播给相应的Receiver。最终，一个permission failure不会再返回给Caller一个exception；它只是不会去deliver该Intent而已。同样地，Context.registerReceiver()也可以有自己permission用于限制谁才可以向一个在程序中注册的receiver发送广播。另一种方式是，一个permission也可以提供给Context.sendBroadcast() 用以限制哪一个BroadcastReceiver才可以接收该广播。

ContentProvider许可(应用于<provider>标签)用于限制谁才可以访问ContentProvider提供的数据。（Content providers有一套而外的安全机制叫做URI permissions，这些在稍后讨论）不同于其它的Components，这里有两种不同的permission属性可以设置: android:readPermission 用于限制谁可以读取provider中的数据，而 android:writePermission 用于限制谁才可以向provider中写入数据。需要注意的是如果provider同时被读写许可，如果这时只有写许可并不意味着你就可以读取provider中的数据了。当你第一次获取provider的时候就要进行权限检查（如果你没有任何permission，则会抛出SecurityException）, 并且这时你对provider执行了某些操作。当使用ContentResolver.query()时需要读权限，而当使用ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete()时需要写权限。在所有这些情况下，没有所需的permission将会导致SecurityException被抛出。

发送广播时实施许可Enforcing Permissions when Sending Broadcasts

除了之前说过的Permission（用于限制谁才可以发送广播给相应的BroadcastReceiver），你还可以在发送广播的时候指定一个permission。在调用Context.sendBroadcast()的时候使用一个permission string，你就可以要求receiver的宿主程序必须有相应的permission。

值得注意的是Receiver和broadcaster都可以要求permission。当这种情况发生时，这两种permission检查都需要通过后才会将相应的intent发送给相关的目的地。

其他权限实施Other Permission Enforcement

在调用service的过程中可以设置任意细化的许可。这是通过Context.checkCallingPermission()方法来完成的。呼叫的时候使用一个想得到的permission string，并且当该权限获批的时候可以返回给呼叫方一个Integer（没有获批也会返回一个Integer）。需要注意的是这种情况只能发生在来自另一个进程的呼叫，通常是一个service发布的IDL接口或者是其他方式提供给其他的进程。

Android提供了很多其他的方式用于检查permissions。如果你有另一个进程的pid，你就可以通过Context.checkPermission(String, int, int)去针对那个pid去检查permission。如果你有另一个应用程序的package name，你可以直接用PackageManager的方法PackageManager.checkPermission(String, String)来确定该package是否已经拥有了相应的权限。

到目前为止我们讨论的标准的permission系统对于内容提供器（content provider）来说是不够的。一个内容提供器可能想保护它的读写权限，而同时与它对应的直属客户端也需要将特定的URI传递给其它应用程序，以便对该URI进行操作。一个典型的例子是邮件应用程序的附件。访问邮件需要使用permission来保护，因为这些是敏感的用户数据。然而，如果有一个指向图片附件的URI需要传递给图片浏览器，那个图片浏览器是不会有访问附件的权利的，因为它不可能拥有所有的邮件的访问权限。

针对这个问题的解决方案就是per-URI permission: 当启动一个activity或者给一个activity返回结果的时候，呼叫方可以设置Intent.FLAG_GRANT_READ_URI_PERMISSION和/或 Intent.FLAG_GRANT_WRITE_URI_PERMISSION。这赋予接收活动（activity）访问该意图（Intent）指定的URI的权限，而不论它是否有权限进入该意图对应的内容提供器。

这种机制允许一个通常的能力-风格（capability-style）模型，以用户交互（如打开一个附件, 从列表中选择一个联系人）来驱动细化的特别授权。这是一个很关键的能力，可以减少应用程序所需要的权限，只留下和程序行为直接相关的权限。

这些URI permission的获取需要内容提供器（包含那些URI）的配合。强烈推荐在内容提供器中实现这种能力，并通过android:grantUriPermissions或者<grant-uri-permissions>标签来声明支持。

更多的信息可以参考Context.grantUriPermission(), Context.revokeUriPermission()和Context.checkUriPermission()方法。