android permission权限与安全机制解析（上）

　　总结整理了一下android权限相关的知识，因为篇幅过长，分为两篇博客来写，上篇博客主要是详解权限和安全，下篇主要是介绍android6.0权限适配问题：

　　android permission权限与安全机制解析（下）

uses-permission

　用法为

　为了保证application的正常运行，须要系统授予app的权限声明。这个权限是在用户安装应用的时候授予的。

　android:name的值能够是其余app经过 声明的（用于两个应用之间的交互），也能够是系统的权限名称，例如

android.permission.CAMERA或android.permission.READ_CONTACTS等等。须要注意的一点是uses-permission的权限要求说明，可能会引发app在Android Market中的过滤。

android:maxSdkVersion用来标注该权限所支持的最大api版本号，若是当从某个特定版本时，不须要该权限时就能够加上该限制。

　系统权限列表有不少，各自的用途也不同，有几个连接能够参考一下：

　 blog.csdn.net/zjl5211314/…

　 developer.android.com/reference/a…

　 developer.android.com/guide/topic…

　 developer.android.com/guide/topic…

自定义permission

permission标签

　 　　　android:icon=”drawable resource”
　　　android:label=”string resource”
　　　android:name=”string”
　　　android:permissionGroup=”string”
　　　android:protectionLevel=[“normal” | “dangerous” |
　　　　　　　　　　　　“signature” | “signatureOrSystem”] /> <
　　android:description：对权限的描述，比lable更加的详细，介绍该权限的相关使用状况，好比当用户被询问是否给其余应用该权限时。注意描述应该使用的是string资源，而不是直接使用string串。

　　android:icon：用来标识该权限的一个图标。

　　android:label：权限的一个给用户展现的简短描述。方便的来讲，这个能够直接使用一个string字串来表示，可是若是要发布的话，仍是应该使用string资源来表示。

　　android:name：权限的惟一名字，因为独立性，通常都是使用包名加权限名，该属性是必须的，其余的可选，未写的系统会指定默认值。

　　android:permissionGroup： 权限所属权限组的名称，而且须要在这个或其余应用中使用 标签提早声明该名称，若是没有声明，该权限就不属于该组。

　　android:protectionLevel：权限的等级

• normal

低风险权限，只要申请了就可使用（在AndroidManifest.xml中添加 标签），安装时不须要用户确认；

• dangerous

高风险权限，安装时须要用户的确认才可以使用；

• signature

只有当申请权限的应用程序的数字签名与声明此权限的应用程序的数字签名相同时（若是是申请系统权限，则须要与系统签名相同），才能将权限授给它；

• signatureOrSystem

签名相同，或者申请权限的应用为系统应用（在system image中），与signature相似，只是增长了rom中自带的app的声明 ，尽可能不要使用该选项，由于signature已经适合绝大部分的状况。

　　对于普通和危险级别的权限，咱们称之为低级权限，应用申请即授予。其余两级权限，咱们称之为高级权限或系统权限。当应用试图在没有权限的状况下作受限操做，应用将被系统杀掉以警示。系统应用可使用任何权限。权限的声明者可无条件使用该权限。

　　下面经过指定一个BroadcastReceiver的权限来实验，首先建立了两个app：app A ，app B 。app A中注册了一个BroadcastReceiver ，app B 发送消息，app A的manifest文件：

 
    
  
  
  

 
    
  
  
  

 
    
  
  
  

 
    
  
  
  

 
        
  
  
  

 
            
  
  
  

 
                
  
  
  

 
                
  
  
  

 
            
        
        
  
  
  

 
        
  
  
  

 
            
  
  
  

 
                
  
  
  

 
            
        
    


复制代码

　　app B 的manifest 文件内容

 
    
  
  
  

 
    
  
  
  

 
    
  
  
  

 
    
  
  
  

 
        
  
  
  

 
            
  
  
  

 
                
  
  
  

 
                
  
  
  

 
            
        
    

复制代码

这样app B 给app A 发送消息，A就能够收到了，若未在app B的manifest文件中声明使用相应的权限，app B发送的消息，A是收不到的。 另外，也可在app B 的manifest文件中声明权限时，添加android:protectionLevel=“signature”，指定app B只能接收到使用同一证书签名的app 发送的消息。

permission-tree标签

　　 　　　　android:label=”string resource”
　　　　android:name=”string” />
　　　　

　　该标签包含于在< manifest >标签中。
　　该标签声明权限树的基础名称。 应用程序拥有树中的全部名称。 能够经过调用 PackageManager.addPermission() 在权限树中动态添加新的权限。 树中的名称以句点（’.’）分隔。 好比，假定基础名称为com.example.project.taxes，则可加入相似如下格式的权限：

　　com.example.project.taxes.CALCULATE
　　com.example.project.taxes.deductions.MAKE_SOME_UP
　　com.example.project.taxes.deductions.EXAGGERATE
注意本元素并非声明权限，而只是为后续要加入的权限定义一个命名空间。

　　android:icon
　　表明树中全部权限的图标。 本属性必须设为对 Drawable 资源的引用。
　　android:label
　　供用户阅读的权限组名称。 为了方便起见能够将其直接设为字符串， 但在应用程序准备发布时，应该设为对字符串的引用，以便对其进行本地化。
　　android:name
　　权限树的基础名称，用做树中全部权限的前缀。 为了保证名称的惟一性，应该采用 Java 风格的域名规则。 名称的路径必须至少包含两个句点分割的字段 — 好比：com.example.base 能够，但 com.example 就不行。

permission-group标签

　　Android在定义 permission 时， 为每一个Permission都进行了分组，一个权限主要包含三个方面的信息：权限的名称；属于的权限组；保护级别。一个权限组是指把权限按照功能分红的不一样的集合。每个权限组包含若干具体 权限，例如在 COST_MONEY 组中包含 android.permission.SEND_SMS ， android.permission.CALL_PHONE 等和费用相关的权限。具体以下SDK所示：
　　developer.android.com/reference/a…
　　再来看看源码(在frameworks/base/core/res /AndroidManifest.xml)：

 
    
  
  
  

 
    
  
  
  

 
    
  
  
  

 
    
  
  
  

 
    
  
  
  

 复制代码

　　能够看到，这边先定义了一个permissiongroup :　android.permission-group.COST_MONEY， 而后又定义了两个permission :android.permission.SEND_SMS 和 android.permission.CALL_PHONE ， 须要注意的是，这两个权限中都有一个android:permissionGroup属性，这个属性就指定了这个权限所属的PermissionGroup。

　　android:description
　　这个属性用于给权限组定义一个用户可读的说明性文本。这个文本应该比标签更长、更详细。这个属性不该该直接使用字串，而应该使用字符串引用。
　　android:icon
　　这个属性定义了一个表明权限的图标，这个属性应该使用资源文件来定义。
　　android:label
　　这个属性给权限组定义了一个用户可读的名称。
　　android:name
　　这个属性定义了权限组的名称，它是可以分配给 元素的permissionGroup属性的名称。
　　

安全机制

组件权限

　　Android是一个权限分离的系统，这是利用Linux已有的权限管理机制，经过为每个Application分配不一样的uid和gid，从而使得不一样的Application之间的私有数据和访问（native以及java层经过这种sandbox机制，均可以）达到隔离的目的 。与此同时，Android 还在此基础上进行扩展，提供了permission机制，它主要是用来对Application 能够执行的某些具体操做进行权限细分和访问控制，同时提供了per-URI permission 机制，用来提供对某些特定的数据块进行ad-hoc方式的访问。
　　经过AndroidManifest.xml文件能够设置高级权限，以限制访问系统的全部组件或者使用应用程序。全部的这些请求都包含在你所须要的组件中的 android:permission属性，命名这个权限能够控制访问此组件。

1. Activity 权限 (使用 标签) 限制可以启动与Activity权限相关联的组件或应用程序。在Context.startActivity()和Activity.startActivityForResult()期间检查；


2. Service 权限(应用 标签)限制启动、绑定关联服务的组件或应用程序。此权限在Context.startService()，Context.stopService() 和 Context.bindService() 期间要通过检查；


3. BroadcastReceiver 权限(应用 标签)可以为相关联的接收者组件或应用程序设置限制。在 Context.sendBroadcast() 返回后此权限将被检查，同时系统设法将广播递送至相关接收者。所以，权限失败将会致使抛回给调用者一个异常；它将不能递送到目的地。为了接收你的广播，你请求一个接收器的应用程序必须持有要求的那个权限（如上面例子所示），并且sendBroadcast的相关几个函数中也能够加入permission参数用来指定只带有该permission的接受者能够接受该广播。


4. ContentProvider 权限(使用 标签)用于限制可以访问 ContentProvider 中的数据的组件或应用程序。若是调用者没有请求权限，那么会为调用抛出一个安全异常( SecurityException )。数据库自己的读写能够处理多线程问题，可是数据的前后能够考虑同步问题，设置android:multiprocess=”true”属性来保证数据的正确性

　　对于组件而言，除了使用权限限制与外部交互的实体外，还有一个属性也具备该功能，那就是android:exported，这个属性用于指示该服务是否可以被其余应用程序组件调用或跟它交互。若是设置为true，则可以被调用或交互，不然不能。设置为false时，只有同一个应用程序的组件或带有相同用户ID的应用程序才能启动或绑定该服务。

　　它的默认值依赖于该服务所包含的过滤器。没有过滤器则意味着该服务只能经过指定明确的类名来调用，这样就是说该服务只能在应用程序的内部使用（由于其余外部使用者不会知道该服务的类名），所以这种状况下，这个属性的默认值是false。另外一方面，若是至少包含了一个过滤器，则意味着该服务能够给外部的其余应用提供服务，所以默认值是true。

权限检测

　　首先是root用户和system用户拥有全部的接口调用权限，而后对于其它用户可使用如下这几个函数来检测 ：

　　PackageManager.checkPermission (String permName, String pkgName)

　　用来检测一个package中是否授予了指定permission。

　　Context.checkCallingOrSelfPermission (String permission)

　　用来检测本身或者调用进程中是否授予了指定permission。

　　Context.checkCallingOrSelfUriPermission (Uri uri, int modeFlags)

　　用来检测本身或者调用进程中是否授予了一个uri经过modeFlags指定的permission。
　　Context.checkCallingPermission (String permission)
　　 检查正在处理的调用者进程是否授予指定permission 权限，若是调用者是本身那么返回 。
　　Context.checkCallingUriPermission (Uri uri, int modeFlags)
　　用来检测调用进程中是否授予了一个uri经过modeFlags指定的permission。
　　Context.checkPermission (String permission, int pid, int uid)
　　用来检测指定uid和pid的进程中是否授予了指定的permission。

　　checkSelfPermission (String permission)
　　23版本api添加，用来检测本身是否授予了指定permission

　　Context.checkUriPermission (Uri uri, int pid, int uid, int modeFlags)
　　用来检测指定uid和pid的进程中是否授予了一个uri经过modeFlags指定的permission。

　　Context.checkUriPermission (Uri uri, String readPermission, String writePermission, int pid, int uid, int modeFlags)

　　比上面的方法多了一个检测permission的功能，至关于同时调用checkPermission(String, int, int)和checkUriPermission(Uri, int, int, int)。
－－－－－－－－－－－－－
　　 下面这一组和上面一一对应，区别就在于若是遇到检查不经过时，会抛出异常，打印消息 ：
　　Context.enforceCallingOrSelfPermission(String permission, String message)
　　Context.enforceCallingOrSelfUriPermission(Uri uri, int modeFlags, String message)
　　Context.enforceCallingPermission (String permission, String message)
　　Context.enforceCallingUriPermission (Uri uri, int modeFlags, String message)
　　Context.enforcePermission (String permission, int pid, int uid, String message)

　　Context.enforceUriPermission (Uri uri, int pid, int uid, int modeFlags, String message)

　　Context.enforceUriPermission (Uri uri, String readPermission, String writePermission, int pid, int uid, int modeFlags, String message)
－－－－－－－－－－－
　　Context.grantUriPermission (String toPackage, Uri uri, int modeFlags)
　　为指定package添加访问指定uri 的读或者写权限
　　Context.revokeUriPermission (Uri uri, int modeFlags)
　　为指定package删除访问指定uri 的读或者写权限。
　　以上函数中check开头的，只作检查。enforce开头的，不单检查，没有权限的还会抛出异常。
　　checkPermission相关函数

1. 若是传入的 permission 名称为 null ，那么返回PackageManager.PERMISSION_DENIED 。


2. 判断调用者uid是否符合要求 。

• 若是uid为0，说明是root权限的进程，对权限不作控制。

若是uid为system server进程的uid，说明是system server，对权限不做控制。

若是是 ActivityManager 进程自己，对权限不做控制。

若是调用者uid与参数传入的req uid不一致，那么返回PackageManager.PERMISSION_DENIED。

若是经过 2 的检查后，再调用 PackageManagerService.checkUidPermission ，判断这个uid是否拥有相应的权限，分析以下 ：

• 首先它经过调用getUserIdLP，去PackageManagerService.Setting.mUserIds数组中，根据uid查找uid（也就是package）的权限列表。一旦找到，就表示有相应的权限。

若是没有找到，那么再去PackageManagerService.mSystemPermissions中找。这些信息是启动时，从/system/etc/permissions/platform.xml中读取的。这里记录了一些系统级的应用的 uid 对应的 permission 。

返回结果 。

　　CheckUriPermission函数

1. 若是uid为0，说明是root用户，那么不控制权限。

不然，在ActivityManagerService维护的mGrantedUriPermissions这个表中查找这个uid是否含有这个权限，若是有再检查其请求的是读仍是写权限。

URI权限

　　到目前为止咱们讨论的标准的permission系统对于content provider来讲是不够的。一个content provider可能想保护它的读写权限，而同时与它对应的直属客户端也须要将特定的URI传递给其它应用程序，以便其它应用程序对该URI进行操做。一个典型的例子就是邮件程序处理带有附件的邮件。进入邮件须要使用permission来保护，由于这些是敏感的用户数据。然而，若是有一个指向图片附件的URI须要传递给图片浏览器，那个图片浏览器是不会有访问附件的权利的，由于他不可能拥有全部的邮件的访问权限。
　　针对这个问题的解决方案就是per-URI permission：当启动一个activity或者给一个activity返回结果的时候，呼叫方能够设置Intent.FLAG_GRANT_READ_URI_PERMISSION和/或 Intent.FLAG_GRANT_WRITE_URI_PERMISSION （ 另一篇intent博客中也有介绍到）。这会使接收该intent的activity获取到进入该Intent指定的URI的权限，而不论它是否有权限进入该intent对应的content provider。
　　这种机制容许一个一般的capability-style模型，这种模型是以用户交互（如打开一个附件， 从列表中选择一个联系人）为驱动，特别获取fine-grained permissions（更细粒化的权限）。这是一种减小没必要要权限的重要方式，这种方式主要针对的就是那些和程序的行为直接相关的权限。
　　这些URI permission的获取须要content provider（包含那些URI）的配合。强烈推荐在content provider中提供这种能力，并经过android:grantUriPermissions或者 标签来声明支持。

android:sharedUserId

　　安装在设备中的每个apk文件，Android给每一个APK进程分配一个单独的用户空间，其manifest中的userid（userid的特色： 做为APK身份的标识 ；userid对应一个Linux用户，因此不一样APK(用户)间互相访问数据默认是禁止的）就是对应一个Linux用户都会被分配到一个属于本身的统一的Linux用户ID，而且为它建立一个沙箱，以防止影响其余应用程序（或者其余应用程序影响它）。用户ID 在应用程序安装到设备中时被分配，而且在这个设备中保持它的永久性。因此让两个apk使用相同的userID，这样它们就能够看到对方的文件，若是在此基础之上再加上相同的android:process，他们就能够运行在一个进程中，可以作更多的事情了。为了节省资源，具备相同ID的apk也能够在相同的linux进程中进行(注意，并非必定要在一个进程里面运行)，共享一个虚拟机。
　　因此当两个应用公用一个userid的时候就可使用SharedPreference之类的机制进行文件数据共享：

//第一个应用程序为的menifest文件代码以下：

   
   
   

  
   
  //第二个应用程序的menifest文件代码以下： 
 
    

  复制代码

　　上面给出了两个程序的menifest定义，二者共用一个ShareUserId，下面咱们看看从一个程序里面如何获取另一个程序的Context。假设咱们从package=“com.android.demo_A”的程序获取package=”com.android.demo_B”的程序的context：

Context ct=this.createPackageContext("com.android.demo_B", Context.CONTEXT_IGNORE_SECURITY);复制代码

　　这样咱们就可以获取到另一个应用的Application context了，获取到上下文以后就可以实现数据共享和通讯，具体能够查看个人 IPC通讯博客。

总结

　　只要signature相同，就算不显式声明 也能access设定了normal或dangerous权限设定的数据或功能。
　　拥有system级别权限的使用者能够access其余普通signature权限声明设定过的功能。因此，设定为拥有system级别权限便可。
　　应用程序安装的时候，应用程序请求的permissions是经过package installer来批准获取的。package installer是经过检查该应用程序的签名来肯定是否给予该程序request的权限。在用户使用过程当中不会去检查权限，也就是说要么在安装的时候就批准该权限，使其按照设计可使用该权限；要么就不批准，这样用户也就根本没法使用该feature，也不会有任何提示告知用户尝试失败。
例如高级权限用有system级别权限设定的api时，须要使其apk拥有system权限。好比在 android 的API中有供给SystemClock.setCurrentTimeMillis()函数来修改系统时间。有两个方法：
　　第1个方法简单点，不过须要在Android系统源码的状况下用make来编译：

在应用程序的AndroidManifest.xml中的manifest节点中插手android:sharedUserId=”android.uid.system”这个属性。

修改Android.mk文件，插手LOCAL_CERTIFICATE := platform这一行

使用mm命令来编译，生成的apk就有修改系统时间的职权范围了

第2个方法麻烦点，不过不用开虚拟机跑到源码环境下用make来编译：

同上，插手android:sharedUserId=”android.uid.system”这个属性。

使用eclipse编译出apk文件，可是这个apk文件是不能用的。

用压缩软件打开apk文件，删掉META-INF目录下的CERT.SF和CERT.RSA两个文件。

使用目标系统的platform密钥来从新给apk文件签名。这步比较麻烦，首先找到密钥文件，在个人Android源码目录中的位置是”build/target/product/security”，下面的platform.pk8和platform.x509.pem两个文件。而后用Android提供的Signapk工具来签名，signapk的源代码是在”build/tools/signapk”下，用法为”signapk platform.x509.pem platform.pk8 input.apk output.apk”，文件名最好使用绝对路径防止找不到，也能够修改源代码直接使用。

引用文章：

blog.csdn.net/xyz_lmn/art…

blog.csdn.net/t12x3456/ar…

yelinsen.iteye.com/blog/101274…

berdy.iteye.com/blog/178285…

my.oschina.net/u/589963/bl…

blog.csdn.net/vshuang/art…

www.chawenti.com/articles/12…

ee.ofweek.com/2012-04/ART…

blog.csdn.net/liujian885/…

maoruibin.github.io/%E6%8A%80%E…

www.zhihu.com/question/37…

blog.csdn.net/wirelessqa/…