于是，不少开发者就捣鼓出了“第三条道路”；可惜的是，没有一种方法能同时做到既不需要将手机固件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自身的权限系统中添加了一个开关。
