本文转载自CSDN的jzj1993，原文连接：http://blog.csdn.net/jzj1993/article/details/39158865
有时我们需要使用安卓实现在后台模拟系统按键，比如对音量进行调节（模拟音量键），关闭前台正在运行的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权限。
1 /**
2 * 用root权限执行Linux下的Shell指令
3 *
4 * @author jzj
5 * @since 2014-09-09
6 */
7 public class RootShellCmd {
8
9 private OutputStream os;
10
11 /**
12 * 执行shell指令
13 *
14 * @param cmd
15 * 指令
16 */
17 public final void exec(String cmd) {
18 try {
19 if (os == null) {
20 os = Runtime.getRuntime().exec("su").getOutputStream();
21 }
22 os.write(cmd.getBytes());
23 os.flush();
24 } catch (Exception e) {
25 e.printStackTrace();
26 }
27 }
28
29 /**
30 * 后台模拟全局按键
31 *
32 * @param keyCode
33 * 键值
34 */
35 public final void simulateKey(int keyCode) {
36 exec("input keyevent " + keyCode + "\n");
37 }
38 }
写这篇文章的主要目的，并不是要强调这件事的难度，也不只是为了提出问题的解决方案（那样就没必要写前面那么多过程了）。而是想把我解决问题的过程完整的写出来，对我而言算是一个记录，对读者而言，没准能从中找到一些东西。
解决这个问题之后，后来意外的发现，这个问题其实有人已经解决了，并且发了博客。不幸的是，那篇博客被大量使用前两种思路的博客掩埋了，当时我怎么也没找到。这篇博客地址在此：http://blog.csdn.net/aminfo/article/details/7785975
顺便说明一点，这篇博客中作者提到的缺点：反应速度较慢。前面提到我也越到了同样的问题，也已经给出了解决方案。