#4 楼 @fresh 之所以用这个方式，是考虑到这个框架本身已经对这些操作封装得比较好了，对于使用者来说，很有可能他没有用过 uiautomator，不熟悉对 uiautomator 的相关操作。这个方法唯一的好处就是方便，简单，没有什么复杂的东西在里面，仅此而已。如果要单说跨进程，确实倒是有不少的方法和手段可以达到。

4.4 的版本还没有测试过，如果命令重构过的话，就要看看源码里面具体有什么改动了。一般来说，可以直接在 shell 命令行里面直接查询/system/bin 下的 uiautomator 的调用权限，只要有调用权限，调用就应该是正常的。

#10 楼 @yangchengtest 报 InputStream Cannot be null 的异常原因基本查明，是 adb 运行在手机内受到 android 系统目录权限的问题导致的。具体的分析可以参考：http://blog.csdn.net/qingchunjun/article/details/43343735。
我重新修改了下原来的框架源码，把 uidump 那个方法针对手机环境进行了重写，你可以从http://download.csdn.net/detail/qingchunjun/8419323 下载下来试试看还有没有问题。

@yangchengtest 我用的 4.2.2 的版本。你可以试试自己导出 uidump 放到对应的路径上，再试试脚本能不能正确执行，关于 uiautomator 的启动问题，回头再研究研究。

@yangchengtest 关于这个 ShellUtils.shell("uiautomator dump /data/local/tmp/uidump2.xml");没有生成 uidump 的文件这个问题我也遇到过，当时记得是修改了下生成文件的超时时间，后来再试了下就没有问题了，但确实有些人用了这个框架都反应了有这个问题，貌似是不稳定，后续再检查下有没有什么方法来避免这个问题。现在如果实在你那边生成有问题的话，建议手工先导出 uidump.xml，稍微修改下源码，然后放到指定目录让脚本去读，应该就没问题了，你可以试试。

#3 楼 @yangchengtest 如果你后面还要玩 IOS，那建议直接上 appium，免得后面还得重新又去搞 appium，很累。技术没有绝对的好坏，适合的就是最好的。

1. robotium 跨进程的操作方式非常多，借助 adb 来跨进程不是什么高深的技术，它突出的是两个字：简单，更多地是针对那些不想花太多精力而又想突破 robotium 的进程限制去做一些跨进程的操作的人。
2. 既然选择了 robotium 那肯定大多数测试都是针对单个 app 的，跨进程的操作不会特别多，封装那么多 API 来干嘛呢？而且这里可能会有很多人误会了这个 adb 框架的作用，它仅仅用作于协助你更方便地帮你完成跨进程操作，针对单个 app 的操作，请还是使用 robotium 自身的方法，它并不能取代 robotium，谢谢。
3. 很多人纠结底层是不是用 uiautomator 去绕，其实用纠结么？我们更多地是使用框架给出的 API，原理我们心知肚明就行，在使用时的操作简单就行，何必太过于纠结底层是怎么绕的呢？

如果仅仅为了跨进程而去用 appium，一般操作用 robotium，那我才觉得是更绕了，完全没必要去维护两套框架的脚本。
个人愚见，欢迎拍砖！

#1 楼 @seveniruby 谢谢，大家一起努力，打造更强的测试工具，呵呵。

我今天也遇到同样的问题。查了下，android4.2.2 下的 uiautomator 源码里面确实没有 Configurator 类的定义，至少要在 4.3 版本上才有，所以基本可以断定，要想成功运行，至少必须在 4.3 或以上的版本才行。