五种控制Android应用的权限的方法

这篇文章目的在于介绍Android系统上控制权限的方法，读者只要使用过Android，或是对智能机平台有所了解，就能看懂，不须要专门的编程知识。

　　1  为何Android老是事无巨细地告诉你应用索取的每一项权限？

　　相比Apple，Microsoft严格控制生态系统(从苹果给开发者的"App Store Guideline"可见一斑)，只容许经过官方应用商店安装应用，并对每份上传进行仔细地审查而言，Android的开放就意味着，Google须要向用户提供一系列用于为本身负责的流程、工具。因此在安装应用前，Android老是要事无巨细地告诉你，应用肯须要控制什么权限。

　　一样，开发者也制做了一系列易用的工具，用以鉴别可疑的应用程序，或是控制权限。

图1 Android 官方市场会强制提醒用

　　Andoird哪里开放了？

　　在Android中，用户能自由从本地安装应用，自由地对SD卡进行操做，自由选择应用市场。

　　若是愿意放弃保修，用户还能轻易地实行root，解锁基带(baseband)。只有一些产品会严密地锁定bootloader(如摩托罗拉)。

　　最重要的是，由于ASOP(Android源代码开放计划)的存在，绝大部分的Android代码都是开源的，开发者能够由此对Android系统进行深刻的修改，甚至能够自行编写一个符合Android规范的系统实例(如Cyanogen Mod)。正是由于ASOP，这篇文章才可能介绍多达5种原理不一样的权限控制方法。

图2 Android开源计划的标志

　　开放的风险

　　不考虑Symbian，Windows Phone 6.5(及如下)平台，那么几乎全部的智能手机病毒都是Android平台的，甚至官方Android Market也闹过几回乌龙。在国内水货横行的市场，状况更是火上浇油，不法业者能够在手机的ROM，甚至是bootloader中作好手脚，让用户有病没法医。

　　在Android中，用户能够容许系统安装来自"未知源"(也就是非Google官方的，或手机预置市场的)应用程序。因而，移动平台最重要的门神------数字签名就被绕过了。

图3 Android 容许未知安装未知来源的应用程

　　出于Android的开放性，也有不容许"未知源"的反例：亚马逊的Kindle Fire平板使用了深度定制的Android，它只容许安装来自亚马逊官方商店的应用程序。

图4 亚马逊的 Kindle Fire 仅容许经过自带的市场安装应用

 

　　2  Android有哪些"权限"

　　首先须要明确一下Android中的种种"权限"。Android是在Linux内核上创建一个硬件抽象层(Android HAL)，经过Dalvik以及各类库来执行android应用的。在手机启动时，首先须要由Bootloader(HTC手机上称做Hboot)引导 Linux及手机上各个硬件设备的驱动程序，以后才启动Android系统。因此其实咱们会涉及到四种不一样涵义的权限：

　　Android权限(Permission)

　　这指Android中的一系列"Android.Permission.*"对象，是本文的中心内容。

　　Google在Android框架内把各类对象(包括设备上的各种数据，传感器，拨打电话，发送信息，控制别的应用程序等)的访问权限进行了详细的划分，列出了约一百条"Android.Permission"。应用程序在运行前必须向Android系统声明它将会用到的权限，不然Android将会拒绝该应用程序访问经过该"Permission"许可的内容。

　　比方说，搜狗输入法提供了一个智能通信录的功能，用户能够在输入联系人拼音的前几个字符，或首字母，输入法就能自动呈现相关联系人的名字。为了实现这个功能，输入法必须声明它须要读取手机中联系人的能力，也就是在相关代码中加上声明"android.permission.READ_CONTACTS"对象。

图5 搜狗输入法的智能联系人功能

　　原生Android只提供了对"一刀切"式的管理，要么赞成使用，不然就根本就不安装应用程序。当用户遇到但愿使用程序的同时，又想禁止部分Permission的场合，他就无路可走。

　　因而，很多开发者就捣鼓出了"第三条道路"；惋惜的是，没有一种方法能同时作到既不须要将手机固件Root，又彻底不涉及对原始应用程序进行反向工程的方法。

　　Root

　　Root指得到Android所在的Linux系统的Root(根)权限，有了根权限，你才能对Linux作出任意的修改。iOS中的越狱 (Jailbreak) 至关于得到iOS系统的Root权限(iOS是一种类Unix系统，和Linux都使用Root的概念)。在已Root的设备中，一般都是使用一个叫"Superuser"(简称SU)的应用程序来向许可的程序授以Root权限。

　　Bootloader的解锁(Unlock)

　　利用数字签名，Bootloader能够限定只有正确签名的系统能够被引导。在修改固件以得到Root之前，解锁Bootloader一般是必须的。安装第三方修改、编译的固件也须要解锁Bootloader。

　　基带(Radio)解锁

　　在Android系统中，基带是上层软件与手机中无线设备(手机网络，Wi-Fi，蓝牙等)的驱动程序之间的中介。国外的网络运营商很喜欢锁定基带，从而保证用户只能使用运营商本身指定的sim卡。在我国，锁定基带是非法的，手机制造商、网络运营商也不能够经过锁定基带的方法对待违约客户。iOS的"解锁"就是解锁iOS中的基带软件。

　　为何要控制Android权限

　　鱼和熊掌不可兼得，Android的世界有不少自由，坏人也能自由地作坏事。它的生态系统很强调自主：用户能够自主地减少风险，仅使用官方市场的应用程序，也能够自主地解除安全限制，从而得到更多自由。所以，在遇到坏事的时候，用户也不得不自主一下：

　　1， 抵制不道德，乃至非法行为

　　几乎全部的Android安全软件都能对来电、信息进行控制，以减小骚扰。

　　另外一方面，不少应用都会要求它们实际功能之外的权限，表如今非(主动)告知地搜集设备序列号，位置信息，诱使用户默认地上传联系人列表等方面。

　　更坏一点的应用程序，则会踏入犯罪的范畴，好比能偷偷发出扣费信息，或是做为黑客的偷窥工具。

　　2， 减小恶意软件的损害

　　恶意软件即使潜伏成功，也难以得到权限，从而减小损失。

　　3， 用户有权自主地在抑制应用程序的部分权限时，继续使用该应用程序，而只承担因为自行设置不当而带来的后果。

　　用户拥有设备的全部权，所以有权自主控制设备上的内容、传感器等对象的访问；同时有权(不)运行，(不)编译设备上的应用程序。

　　大多数应用程序在运行时，并未达成主动告知的义务，是失误；然而即便主动告知，用户仍是能够不理会。

　　为何Android官方市场的强制提醒权限的行为不属于主动告知：

　　经过Android官方市场，"打包安装器"安装应用程序时，所显示的"权限"仅是在安装包内AndroidManifest.xml声明的值，而非应用程序实际上会调用的内容。该值仅用来代表Android系统能向应用授予的最大可能的权限。即使一个"Hello World"式的应用程序，也能够在AndroidManifest.xml中声明全部可能的Android Permission。

　　这就是说，在AndroidManifest.xml中声明的值与应用程序实际调用的权限有关联，但不等同，且这种提示是由Android系统负责实施的强制行为。

　　正确的理解是："应用程序(被迫地)让Android系统告知用户，它在AndroidManifest.xml中所声明的事项。"

　　这意味着应用程序在使用重要权限前，依然须要自行、主动地通知用户相关事宜。

图6  应用程序需要AndroidManifest.xml中声明调用到的权限

　　然而，即使只是让一半的应用程序达到以上的标准，也是不可能的。应用程序须要经过收集用户信息，程序的错误日志。从而统计用户的喜爱，改进程序。另外一方面，这也是发送精确广告但不追溯到用户身份信息的方式，这一点对于免费应用而言，是极其重要的。咱们之因此能知道不一样型号手机的占有率，应用软件的流行度，是与这样的统计不可分离的。

　　一旦每一个应用程序都专业地主动发出提醒，不专业的用户(大多数用户都是不专业的)一般会将之视为如同海啸警报通常的危机。

　　这么作对谁都没有好处------用户方的隐私权是毋庸置疑的，然而应用程序方面的获取信息记录的需求也是无可阻挡的。若是每一个用户都打算阻止，只会落得被迫接受不平等条约的下场，在温饱之前，不会有人考虑小康的问题。

　　因而，现状就变得有趣：用户人享受着相同的服务；其中大部分用户出于不知情/好意，默默地向开发者、广告商提供了信息，剩下的少数用户则能阻断这种劳务。而做为维持Android平台的信息商人Google，只确保在它的地盘里，不会发生触碰底线的事情。

　　一句话总结：

　　设备是个人，无论你怎么说，反正我说了算，但我说的话大可能是不算数的。    

　　3  权限控制的方法

　　这里开始介绍各类控制Android权限的办法。惋惜的是，几乎全部的手段都须要对设备进行Root，若是不这么作，则须要付出不小代价。

　　App Shield(国内常见的名字:权限修改器)

　　它是一个须要付费的Android应用，其原理是修改应用程序的apk安装包，删除其中AndroidManifest.xml文件内，用于声明权限的对应"Android.Permission.*"条目，而后再用一个公开的证书对安装包从新签名(须要容许"未知源")，这样一来，应用程序就不会向系统申请原先所需的权限。当应用运行至相应的流程时，系统将直接拒绝，从而达到用户控制权限的目的。

　　对于已安装的应用，AppShield也会按照一样方法制做好apk安装包，而后让用户先卸载原始的应用，再安装调整过的应用。除了该应用数字签名外，用户能够随时经过执行一样的流程，将吊销的权限恢复。

图7 AppShield

　　Apk文件的结构

　　Android应用都是打包成以.apk扩展名结尾，其实是zip的文件格式。

　　一个合法的apk至少须要这些成分：

　　根目录下的"AndroidManifest.xml"文件，用以向Android系统声明所需Android权限等运行应用所需的条件。

　　根目录下的classes.dex(dex指Dalvik Exceptionable)，应用(application)自己的可执行文件(Dalvik字节码) 。

　　根目录下的res目录，包含应用的界面设定。(若是仅是一个后台执行的"service"对象，则没必要需)

　　Apk根目录下的META-INF目录也是必须的，它用以存放应用做者的公钥证书与应用的数字签名。

　　当应用被安装后，这个apk文件会原封不动地移至设备的data/app目录下，实际运行的，则是Dalvik将其中Classes.dex进行编译后的Classes.odex(存放在Dalvik缓存中，刷机时的'cache wipe就是清除Dalvik的odex文件缓存')。

　　优势：

　　彻底不须要Root，适用于全部版本的Android设备。不会损坏系统，能够吊销任意一项Android权限。

　　问题：

　　1，须要从新安装应用，该行为可能会丢失应用的配置、历史记录。

　　2，执行权限吊销的应用的数字签名会被更改，没法直接更新。对于那些设计不良(没有意料到'不声明权限'状况的)，或有额外自校验的应用，可能会没法运行。

　　3，没法用于设备上的预装应用，除非制造商好心地将该应用设置为"能够删除"的状态。

　　4，这个方法修改了apk包中的内容------尽管实际上AndroidManifest.xml和数字签名并不算是应用程序的自己，但修改它们可能引起著做权的问题。

　　5，须要开启"未知源"。

　　6，这是一个收费应用。 

　　CyanogenMod 7.1(及以上版本)

　　Cyanogenmod是一款著名的第三方编写的开源Android ROM。

　　CM7.1加入了控制权限的开关，官方的名称是"Permission Revoking"，任何非系统/保护应用在安装后，可直接吊销任意一项权限，其效果等价于直接删除apk包中AndroidManifest.xml的对应条目，但不会引起自校验的问题。CM的权限工具的做用等同于AppShield，无非是在Android自身的权限系统中添加了一个开关。

图8 Cyanogen Mod 7.1中的权限吊销(Permission Revoking)设定

　　优势：

　　免费，使用简便，可随时，任意地吊销、恢复非预装应用的任意一项权限；不存在数字签名的问题，于是不影响使用自校验的应用程序。

　　问题：

　　此功能仅在Cyanogen Mod 7.1及以上版本提供，没法用于其它rom。由于是由Android系统出面吊销权限，其实现原理与App Shield彻底相同，一样的，应用程序会由于设计不良而出现崩溃。  

　　Permission Denied

　　这是能够吊销任意Android应用(注意，不当地吊销系统应用的权限可能会致使手机固件损坏，没法启动)的任意权限，对权限的修改在重启后生效。

　　实现原理应该与Cyanogen Mod 7.1+彻底相同，适用于任何已经Root的系统，由于通常的Android系统虽然事实上支持权限吊销，但没有像Cyanogen Mod那样放置接口，所以须要重启后才能应用权限配置。一样也有系统出面拒绝权限而致使的崩溃现象。

图9 Permission Denied免费版吊销应用程序权限的场景

　　优势：

　　效果与Cyanogen Mod中的权限吊销效果一致，且可吊销系统应用的权限。同时提供了免费与收费版本，免费版并无基本功能的缺失。适用于全部版本号不低于1.6的Android设备。

　　问题：

　　调整后的权限须要重启才能生效。设计不良的应用会崩溃。不恰当的权限修改会损坏系统，致使没法开机。  

　　PDroid

　　PDroid其实是一个Android内核补丁加上一个用于管理的外部应用。补丁须要在Recover环境中刷入系统，也能够由开发者自行移植入系统。该软件在Android ASOP 2.3.4代码基础上开发，仅适用于没有改动内核的Android 2.3系统，目前还未支持Android 4。

图10 PDroid的界面

　　为了不Cyanogen Mod 7.1+权限吊销(Permission revoking)致使的崩溃问题，以及后台服务(如LBE，QQ手机管家等，PDroid的做者认为经过后台服务拦截权限并非好办法)，PDroid 并不阻止应用程序声明权限，但会在其实际索取相关信息时，予以阻止。通俗地说，就是签署协议但不执行。在PDroid的用户界面，用户能随时精确地控制涉及隐私的各项权限。对于某些内容，除了阻止外，用户还能够伪造一个随机或指定的数据。

　　可控制的内容包括：

　　IMEI(可伪造)

　　IMSI(可伪造)

　　SIM卡序列号(可伪造)

　　手机号码(可伪造)

　　来，去电号码

　　SIM卡信息

　　当前蜂窝网络信息

　　(以上七者均来自Android.Permission.READ_PHONE_STATE)

　　GPS定位信息 (可伪造，来自Android.Permission.FINE_LOCATION)

　　基站定位   (可伪造，来自Android.Permission.COARSE_LOCATION)

　　系统自带浏览器的历史，书签(Android.Permission.BOOKMARKS)

　　联系人    (android.permission.READ_CONTACTS)

　　通话记录   (android.permission.READ_CONTACTS)

　　系统日志   (android.permission.READ_LOGS)

　　当前帐户列表   (android.permission.GET_ACCOUNTS)

　　当前帐户的受权码  (android.permission.USE_CREDENTIALS)

　　短信，彩信 (可能与这5个权限有关)

　　　　　　　　　　android.permission.READ_SMS

　　　　　　　　　　android.permission.RECEIVE_SMS

　　　　　　　　　　android.permission.SEND_SMS

　　　　　　　　　　android.permission.WRITE_SMS

　　　　　　　　　　android.permission.RECEIVE_MMS

　　日历    android.permission.READ_CALENDAR

　　PDroid的内核补丁并不通用，每个Rom都须要特定的补丁。开发者除了提供了几个特定机型下Cyanogen Mod，HTC Sense修改版ROM的专用补丁外，还推出了一个补丁生成工具(PDroid Patcher)，用户能够给本身的ROM生成专用的内核补丁。使用该Patcher须要安装JDK(java Development Kit)。

　　优势：

　　PDroid避免了经过Android系统进行权限吊销的致使的潜在崩溃问题，也不须要后台服务。对隐私信息的控制是最精细的。尽管设备必须Root，但应用自己不须要Root权限。

　　问题：

　　安装过程是最繁琐，最不可靠的，容易致使ROM损坏，适用范围也小，须要用户有至关的技能(能安装JDK，会刷机)才可以使用；只提供对隐私有关权限的控制，不提供网络访问，的控制。以这些为代价，它几乎没有其它缺点。  

　　LBE安全大师

　　实际上最经常使用的是以LBE为表明的经过一个Root权限的后台服务来拦截相关行为的工具。除了LBE外，还有QQ手机管家等应用。这里以LBE安全大师为例介绍。

图11 LBE安全大师

　　LBE是国内一个叫"LBE安全小组"开发的工具，支持Android2.0～4.0。它的核心功能是像杀毒软件通常，经过一个须要Root权限的后台服务，劫持全部调用权限的行为，并放行用户许可的部分(其官方宣传为'API级别拦截')。它和PDroid同样几乎不会引起应用程序崩溃，它支持拦截几个涉及用户的关键权限(LBE手机管家3.1/3.2)：

　　读取短信  (android.permission.READ_CONTACTS)

　　联系人记录  (android.permission.READ_CONTACTS)

　　通话记录  (android.permission.READ_CONTACTS)

　　定位   (Android.Permission.COARSE_LOCATION

　　　　　　　　Android.Permission.FINE_LOCATION)

　　手机识别码  (与Android.Permission.READ_PHONE_STATE有关)

　　通话状态  (与Android.Permission.READ_PHONE_STATE有关)

　　发送短信(具体原理不明，一样相似于禁止这五个权限

　　　　　　　　android.permission.READ_SMS

　　　　　　　　android.permission.RECEIVE_SMS

　　　　　　　　android.permission.SEND_SMS

　　　　　　　　android.permission.WRITE_SMS

　　　　　　　　android.permission.RECEIVE_MMS)

　　拨打电话  (android.permission.CALL_PHONE)

　　通话监听  (android.permission.PROCESS_OUTGOING_CALLS)

　　除此之外，LBE还能够分别控制应用在Wifi，手机网络的联网权限，其原理是依靠IPtables防火墙，而非经过Android的"Internet"权限。

　　此外LBE手机管家还提供基于智能内容审查的短信拦截、来电归属地显示，以及禁用系统(保护)应用，进程管理，杀毒等功能。

　　LBE提供两个版本，一个叫"LBE安全大师"，是一个全面的手机管家类应用，更新比较频繁，另外一个版本(LBE手机隐私卫士，LBE Security lite)仅提供权限方面的管理。

　　考虑到主要市场在国内，LBE的发行策略看上去有些奇怪，它在Google的官方市场并不发行最新版。一般只能只能在LBE的官方网页，以及国内的应用市场得到最新版本。

　　优势：

　　使用很是简单，功能强大而全面，风险很小，能够控制系统应用。适用范围广，有不少替代产品。

　　问题：

　　须要后台服务 (尽管蚕豆网有个评测，认为它对能耗几乎没有影响)，不能控制全部的Android权限。     

　　4  自启动的控制

　　Android对后台服务有着最好的支持。

　　在Android中能够自由地开发一种称为'Service'的后台运行的对象，加上没有苹果公司对应用程序的严格限制。诸如QQ挂机，即时调用第三方应用程序之类的形式均可以轻易实现。

　　为了全面支持后台服务，也为了适应移动设备资源紧张，不得不常常清理内存的问题，应用可在系统中设置触发器，当系统发生了某个特定特定事件时(系统启动，拨打电话，收发信息，安装、卸载应用，插上电源等，或应用程序自行定义的事件)，就会触发启动应用程序。

　　AutoStarts 自启动管理

　　AutoStarts是一个收费应用，经过它，用户能了解系统中每一项程序会在什么场合下被触发运行。若是提供Root权限，则还能禁止这样的行为。

　　这里以Google Maps应用6.2版为例。默认状况下，这款应用老是会保持后台运行，并每小时向Google发送一次当前用户的位置信息。为了阻止这样的行为，须要联合使用AutoStarts与任意一款进程管理应用：在AutoStarts中，阻止Google Maps的自行启动(如图)，在每次使用完后，把Google Maps的进程杀掉。

图12 AutoStarts能够对自启动项目进行修改 

　　5  其余

　　Root带来的风险

　　有一个钻牛角尖的说法认为，一旦对设备进行了Root，便无安全一说，只要恶意程序一旦偷偷得到Root级别，一切都是空谈。

　　这种说法之因此钻牛角尖，是由于：一方面Android中的Root权限一般都是须要用户经过Superuser应用进行受权的，这已经够用，虽然不能期望Superuser无懈可击；另外一方面，控制Android权限主要是为了让应用程序在"灰色地带"的行为收敛一些，它们实际显然不是病毒等犯罪软件。

　　著做权的问题 (做者不是法律方面的专家，如下言论仅供参考)

　　咱们知道，Android中的应用程序是基于Java语言编写的。而为了达到跨平台的目的，Java软件是以字节码(或叫中间代码，bytecode)，而非计算机能直接执行的机器码(Machine Code，有时也叫做Binary)的形式存在。所以执行Java软件时，须要一个Java虚拟机(Android系统中的Java虚拟机就是 Dalvik)负责解释运行，有的时候，虚拟机还会经过即时编译(JIT)的方法将字节码编译为机器码后再运行，以提升程序的执行效率。

　　这就出现一个颇有趣的现象：

　　除非另行规定，做为设备的拥有者，用户老是能够自行决定如何使用软件，能自行决定程序可否访问用户本身的计算机(移动设备亦然)里面的各个内容、对象。

　　由此衍生出，在须要对代码编译、解释的场合，用户也能经过对编译器(解释器)的干预，来影响代码的执行效果。在Android中，用户还能够在Dalvik解释、编译的时候动手。

　　这是由于，著做权仅保护了软件代码不受到非受权的反向工程，未受权传播等侵犯。另外一方面，对于Android上的Java，网页中的 javascript程序，赋予用户解释、编译的权利是程序能执行的先决条件；同时，软件发行者发一般也会主动提出放弃这种权利(表现为'软件按原样提供 '、'不对使用软件形成的后果负责'等条目)

　　在编译、解释的过程当中，须要经过汇编(Assemble)，链接(Link)等方法将编译好的对象(Object)、方法(Function)联系起来。默认状况下，这些行为是由原始的代码(源代码、中间代码)与编译器(解释器)决定的，可是用户能够经过制约编译器(解释器)的设置，从而影响到最终代码。这么作是没有问题的。

　　还有一种，应用程序在安装后，会在系统中产生一些缓存，或注册一些信息。当其中的内容有关用户数据时，读取或修改它们也是没有问题的。这就是所谓"只要是你的东西老是你的"；也是Cyanogen Mod、Permission Denied不会涉及版权问题的缘由所在。

 　　总之，一个Android应用之因此能运行的前提是：

　　1，首先，用户容许使用这个应用

　　这也能够理解成：用户安装了应用(以及所以设定的后台对象)，购买了预装应用的手机。这一点即不影响应用程序的主动通知义务，也不影响用户过后的干预。

　　2，接下来，用户容许Dalvik对该应用使用"解释"，"JIT"的方法，从而该应用程序得以执行。

　　3，用户随时能够对该应用做出任意不违反版权的干预。

　　因此，在没有另行规定的前提下，用户老是能够自行决定，经过给应用程序分配自定义的权限；或是在应用程序调取内容，对象时予以阻断。同时，用户也须要自行承担因不当操做产生的后果。    

　　附录:

　　一、 数字签名

　　数字签名是一种使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。一套数字签名一般定义两种互补的运算，一个用于签名，另外一个用于验证。数字签名能够轻易地验证完整性(正确性)，合法签署的数字签名具备不能否认性。 (摘录自维基百科"数字签名"条目，有修改)

　　二、 版权声明

　　文章中引用的图标，图片或图片的部分，以及部分文字的引用，仅出于合理使用的目的，多是持有人版权全部的。

　　三、 一些行为的说明

　　不道德行为

　　应用程序在启动时，或在主动告知之前，试图索取、收集电话号码、邮箱地址、位置信息等与我的身份直接关联的内容。若是是与我的关联，但不能直接联系到我的信息的IMEI等设备、SIM卡的串号，则稍微好一些。

　　附图1，不道德的应用程序在启动的第一时间就试图获取隐私信息

(新浪微博2.8)，不管用户是否绑定了手机，应用都会第一时间记录当前手机的号码

(UC浏览器，快拍二维码)，应用老是会不主动通知地记录设备的位置信息

　　没有实行主动通知的例子

附图2 这个应用程序在第一次启动时便开始收集位置信息，用户须要切换六次屏幕才能看到有关位置信息的提示。这项提示还有意忽略应用程序自己就会记录用户位置信息，即使用户并不使用须要位置信息的服务

　　主动通知的例子

附图3 主动通知就是在第一屏的醒目处，或用醒目的对比色等强调方式进行通告