Android之安全权限

   从Android6.0开始，Android系统对权限的处理产生了很大的变化。如果APP运行的设备系统版本为Android6.0或更高，并且target在23或更高，那么dangerious级别的权限将由之前的安装时授予变成运行时动态申请。这样一来，当运用到系统权限相关的功能时，就需要手动处理好权限申请的用户交互问题。本文将结合官网中的介绍，来全方位了解权限相关知识点，并介绍一些实际工作中可能用到的技巧。

    Android是一个权限分离的操作系统，每个应用以唯一的身份标识（Linux用户ID和组ID）运行。系统的不同部分也分成不同的身份。因而Linux把应用之间以及应用与系统之间相互隔离起来。 

    附加细粒度的安全功能是通过一个“许可”的机制，限定特定的进程能够执行指定的操作以及给予对每一个资源点对点的访问的URI许可。 
安全体系结构 

    Android安全体系结构设计中心是没有任何一个应用程序在默认情况下可以执行对其他应用程序、操作系统或者用户有害的操作。其中包括读写用户的私有数据（例如联系人或者电子邮件），读写其他应用程序的文件，进行网络访问或者唤醒设备，等等。 

    由于内核让每个应用程序运行在独立的沙盒中，应用程序必须明确的分配资源和数据。他们通过声明他们所需要的但是沙盒没有提供的权限来做这些。应用程序静态的声明他们所需要的权限，android系统在程序安装时提示用户同意它们获取这些权限。Android没有准许动态权限机制，因为它会使用户体验复杂对安全不利。 

    内核独自地为彼此的沙盒应用负责。特别Dalvik虚拟机不是一个安全的边界，而且任何的应用程序都能够运行本地代码（查看Android NDK）。所有类型的应用程序——java、native和混合的——均用相同的方式置于砂箱中并且有着相同的安全等级。 
应用程序签名 

    所有的Android应用程序（apk文件）必须使用一个开发人员掌握私钥的证书进行签名。证书用于识别应用程序的作者。该证书并不需要由证书颁发机构进行签名：它是非常宽松的，典型的Android应用程序使用自签名的证书。Android证书的目的是区分应用程序的作者。这样就可以允许操作系统授予或者拒绝应用程序使用签名级别的权限和操作系统授予或者拒绝应用程序请求和其他应用程序相同的Linux身份。 

一、为什么要引入权限？

      Android系统引入权限的目的是为了保护Android用户的隐私。Android安全架构设计中一个明确点，默认情况下App是没有权限对其他App、操作系统和用户进行有害的操作。这些有害操作包括读写用户的隐私数据（如通讯录、电子邮件等）、读写其它App的文件、调起硬件设备（如蓝牙、Wifi、相机等），访问网络等。App如果想要进行这些操作，就需要申请相应的权限。

二、官方文档关于权限保护级别的说明

    “权限保护级别是指由android:protectionLevel指定的值。”protectionLevel描绘了权限所蕴含的潜在风险，并且指明了系统在赋予某个app请求的权限时所要遵守的规程（procedure）。Android标准的权限有着事先定义好的、固定不变的protectionLevel。

  自定义的权限的protectionLevel属性可以取下面列表中的‘Constant’值，如果有多个’Constant’值，则需要用‘|’分隔开。如果没有定义protectionLevel，则默认权限为normal。

  权限级别可以分为两类：基础权限级别和附加权限级别。

基础权限级别
 有3种：normal、dangerous和signature。（注：signatureOrSystem处于弃用状态，不建议使用）

附加权限级别
 0x10及其之后的权限级别都属此类，例如，privileged、appop等。它们必须附加在基础权限上。目前貌似只能附加在signature权限上。

 三、Android app中的权限是必须先声明后使用吗？
     *在本文中，声明权限是指在AndroidManifest.xml中使用了<permission>，使用权限是指在AndroidManifest.xml中使用了<uses-permission>。**获得权限（或赋予权限）*是指真正的可以通过系统的权限检查，调用到权限保护的方法。

    场景：App A中声明了权限PermissionA，App B中使用了权限PermissionA。那么App A必须比App B先安装，App B才能获取到权限吗？

答案是不一定，要看具体情况而定。这个具体情况就是权限的保护级别。

    情况一：PermissionA的保护级别是normal或者dangerous App B先安装，App A后安装，此时App B没有获取到PermissionA的权限。即，此种情况下，权限必须先声明再使用。即使App A和App B是相同的签名。

    情况二：PermissionA的保护级别是signature或者signatureOrSystem App B先安装，App A后安装，**如果App A和App B是相同的签名，那么App B可以获取到PermissionA的权限。**如果App A和App B的签名不同，则App B获取不到PermissionA权限。即，对于相同签名的app来说，不论安装先后，只要是声明了权限，请求该权限的app就会获得该权限。

    这也说明了对于具有相同签名的系统app来说，安装过程不会考虑权限依赖的情况。安装系统app时，按照某个顺序（例如名字排序，目录位置排序等）安装即可，等所有app安装完了，所有使用权限的app都会获得权限。

四、Android 权限变化趋势

   Android M之前，应用的权限请求是在安装时提示，确认后权限就会拥有。

    但Android M出来后，将这个权限在运行时做了进一步的检查，用户随时可拒绝权限。

● 从平台角度看:Android权限集不断扩展，但不是以提供更细粒度的权限为目标，而是为访问新的硬件功能提供安全保障。特别地，Dangerous权限集的数量也在不断增多;

● 从第三方应用和预装应用角度看：大量应用并未遵守最小特权原则，而是存在大量过多申请权限的情形。值得注意的是:许多预装应用使用大量高级别的权限，带来很大的安全隐患。

    用户只有通过不断学习，充分理解新加入的权限说明，才能在安装软件时从Android权限警告中获取足够的信息，从而做出正确的决定。鉴于Android系统每隔数月就有较大的版权更新，并引入较多新的权限，这为用户提出了很高要求。