安卓使用Root权限实现后台模拟全局按键、触屏事件方法(类似按键精灵)

有时我们需要使用安卓实现在后台模拟系统按键,比如对音量进行调节(模拟音量键),关闭前台正在运行的App(模拟返回键),或者模拟触屏事件。但是对于原生安卓系统而言,后台进程关闭前台进程,甚至模拟用户事件,进而操控整个系统,是不符合系统安全原则的,如果有这样的漏洞被病毒或恶意软件所利用,会非常危险。

由于一些特殊原因,我恰巧需要实现这样的功能,而又没有条件自行编译安卓系统(但是可以利用Root权限,因为Root权限的获取相对简单很多,并且很多用户的安卓设备都有Root过)。网上也看到很多人在提类似的问题,很多人讨论了半天,结果都是无解。于是我花了很大精力,最后终于找到了解决方案。

在网上查找了很多资料,主要找到两种方法:Instrumentation和IWindowManager。

使用Instrumentation接口:对于非自行编译的安卓系统,无法获取系统签名,只能在前台模拟按键,不能后台模拟。

一种是使用Instrumentation接口,这个接口原本是用来对软件进行测试而留出来的。经过尝试,发现这个接口可以模拟按键,但是前提是在应用处于前台时。而应用处于前台时,模拟按键基本上也没有太大的作用(模拟按键操作应用自身似乎没有很大意义)。

当应用处于后台时,这个Instrumentation接口就失效了。网上找到的解释是,在后台使用这个接口,需要有系统权限,也就是在Manifest中添加android:sharedUserId=“android.uid.system”。而这会导致什么问题呢?声明了系统权限的APK,只有具有系统签名的情况下,才能被安装到安卓设备上,比如系统自带的电话、短信,本质上也就是APK程序,但是这些应用具有系统权限。

安卓系统有一套签名机制,APK只有有了数字签名,才能被安装。通常调试时默认Eclipse自动对其进行签名,使用的是Debug签名。当发布应用时,开发者则使用自己独有的数字签名文件对APK进行签名(这个文件可以用Eclipse生成,签名也可以让Eclipse完成)。APK有新版本的安装时,如果检测到签名不一致,系统会提示签名不一致,只有卸载旧版本才能安装。这一机制从一定程度上避免了第三方对官方发布的APK进行修改甚至非法植入病毒等行为(当然如果用户主动卸载旧版本的官方应用、安装新版本的非官方APK也是可以的)。而具有同一签名的不同App,它们之间可以共享一些数据。

而系统签名怎么获取呢?在编译安卓系统的时候,会将一个系统签名的数字签名文件放到一起编译。对于一个已经编译完成的系统,或者为了适配不同系统,必然无法获取到这个数字签名文件,于是也无法对APK进行系统签名。最后就导致具有uid.system属性的APK无法被安装,于是Instrumentation接口后台模拟按键的方法,只能在自行编译系统的情况下才可以使用。

使用反射方法调用系统IWindowManager隐藏API:兼容性较差,稳定性不好,容易出错。另外实际编译时发生错误,原因暂时不明。

网上还有一种方法。安卓系统中有一些隐藏API,通常是利用Java的权限限制,使得这些API无法被调用。但通过反射的方式,可以突破Java的权限限制。在IWindowManager中就隐藏了可以模拟按键和触屏事件的API。尝试网上的方法,下载到一个由安卓源码编译好的jar文件,添加到工程中,然后使用发射编写了一些代码,尝试调用隐藏API。结果编译的时候Eclipse直接不响应了,可能是因为电脑配置不够,jar文件太大。尝试了几次没有成功,又考虑到这种方法有很多弊端,并且很可能最后还是需要系统权限(网上不少文章说得不是很清楚),于是就放弃了这个方法。

android模拟按键问题总结[使用IWindowManager.injectKeyEvent方法]

http://blog.csdn.net/xudongdong99/article/details/8857173

Android中使用隐藏API(大量图解)

http://163liufuliang.blog.163.com/blog/static/331651862013119114431760/

JNI调用C程序模拟按键:仍然是权限问题。

参考了网上一些资料所提出的可能的思路,发现剩下能想到的方法就是用JNI实现,通过调用C/C++程序来模拟按键。对Linux底层编程不熟悉,网上参考了一些代码,在Ubuntu下编写了一个按键模拟程序,很顺利的编译运行通过。然后又开始学习JNI的编译方法,先在C程序层写了个简单的加法运算,编译运行测试通过,然后就把模拟按键的代码贴了进去。满怀期待的写好安卓Java层代码,编译、下载、执行程序,却发现完全没有效果。

想看一下到底是哪一步出错了,就在C程序里面改了改,用LogCat打印出C程序的返回值,发现在打开按键设备的时候出错,看来肯定又是权限的问题了。

尽管系统已经Root,APK也允许使用Root权限,但是Root权限没法传递给C程序,权限不够,程序无法执行。在网上找了一通有关Linux、安卓权限的资料,也没找出来什么思路。其实当时很疑惑,在Linux系统中,Root权限是最高的权限,安卓也不例外,有文章指出,Root权限>系统权限>用户权限。尽管能获取到Root权限,却不能完成系统权限所能完成的任务,总感觉不应该。

安卓按键精灵:使用Root权限而不需系统签名,实现后台模拟按键和触屏等事件是可行的。

当时很绝望,感觉估计只有自行编译系统才能解决问题了。就在那时候,突然想起了按键精灵软件。以前用过电脑版,在安卓市场一找,果然也有安卓版。下载使用发现,按键精灵就可以实现在后台模拟按键操作,需要Root权限,但是是什么原理却不得而知。本想尝试反编译源码查看,但是当时出了一些问题,反编译没有成功。在网上搜索安卓按键精灵的原理,除了之前的那两种依赖源码环境才能使用的API,也没有找到结果。不过至少说明了,使用Root权限而不需要系统签名,实现模拟按键、并且兼容大量安卓设备是可行的。

最终解决问题:使用Shell调用ADB指令实现。

继续在网上搜索安卓按键模拟(其实那时都不知道用什么关键字好了,能想到的关键字都用遍了,但是搜索出来的结果,都是之前提到的那几个依赖源码环境和系统权限的方案)。发现有很多介绍ADB调试,向手机发送按键事件的文章。刚好之前做过在Root权限下,用Java调用安卓底层的Linux Shell,然后执行pm指令进行APK的安装卸载。这时我突发奇想,能否用Shell调用ADB指令呢?

于是就进行了尝试,使用Java执行Runtime.getRuntime().exec(“su”).getOutputStream(),获取了一个具有Root权限的Process的输出流对象,向其中写入字符串即可以Root权限被Shell执行,ADB模拟按键的指令为 “input keyevent keyCode”,keyCode为按键的键值,例如KeyEvent.KEYCODE_VOLUME_UP表示音量加。

编译完程序安装执行,终于实现了预期的效果,当时非常高兴。至于触屏或鼠标事件,只要调用相应的ADB指令即可。但是有一点问题,就是反应速度非常慢,尤其是连续模拟多个按键的时候,甚至会死机。而按键精灵运行的就相当流畅,我又开始好奇按键精灵是怎么实现的。

后来终于还是找到了原因,模拟按键时,不应每次都调用Runtime.getRuntime().exec(“su”),因为每次调用这个代码的时候,都会获取Runtime实例,并且执行"su"请求Root权限,反应就会很慢(我的理解是相当于每次都新开一个命令行窗口);而应该只是在一开始执行一次,并获取一个OutputStream实例,后来每次执行一条Shell指令,只需向其中写入相应字符串,这样就快了很多。

下面贴出可用的代码。要求设备已经Root,不需要其他任何特殊权限或签名。由于用的是ADB指令,兼容性也不会有太大问题。首次运行程序时(其实也就是执行Runtime.exec(“su”)的时候),会请求Root权限。

/**
* 用root权限执行Linux下的Shell指令
*
* @author jzj
* @since 2014-09-09
*/
public class RootShellCmd {

private OutputStream os;

/**
* 执行shell指令
*
* @param cmd
* 指令
*/
public final void exec(String cmd) {
try {
if (os == null) {
os = Runtime.getRuntime().exec(“su”).getOutputStream();
}
os.write(cmd.getBytes());
os.flush();
} catch (Exception e) {
e.printStackTrace();
}
}

/**
* 后台模拟全局按键
*
* @param keyCode
* 键值
*/
public final void simulateKey(int keyCode) {
exec("input keyevent " + keyCode + “\n”);
}
}

写这篇文章的主要目的,并不是要强调这件事的难度,也不只是为了提出问题的解决方案(那样就没必要写前面那么多过程了)。而是想把我解决问题的过程完整的写出来,对我而言算是一个记录,对读者而言,没准能从中找到一些东西。

解决这个问题之后,后来意外的发现,这个问题其实有人已经解决了,并且发了博客。不幸的是,那篇博客被大量使用前两种思路的博客掩埋了,当时我怎么也没找到。这篇博客地址在此:

http://blog.csdn.net/aminfo/article/details/7785975

顺便说明一点,这篇博客中作者提到的缺点:反应速度较慢。前面提到我也越到了同样的问题,也已经给出了解决方案。