五种控制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，用户随时可以对该应用作出任意不违反版权的干预。
所以，在没有另行规定的前提下，用户总是可以自行决定，通过给应用程序分配自定义的权限；或是在应用程序调取内容，对象时予以阻断。同时，用户也需要自行承担因不当操作产生的后果。
