代码改变世界

Android Instrumention.sendPointerSync发送Event失败分析

2014-09-26 17:18  hyddd  阅读(5537)  评论(1编辑  收藏

问题场景

    Android4.3,进入被测app某个Activity后,测试案例ClickOnScreen出现异常(Click can not be completed!)。

    Android4.4正常。

 

前置说明

    测试案例使用的是本人实现的测试框架,它底层调用了Robotium。

 

分析过程

    1. 框架调用了Robotium的ClickOnScreen,源码如下:

    (com.jayway.android.robotium.solo.Clicker)

     clicker

    当sendPointerSync(发送点击事件给被测app)10次都失败,便会断言异常:Click can not be completed。

    而引发sendPointerSync的异常是:SecurityException。在Android中,出现SecurityException异常是因为权限不足,一般的情况是:被测试App和测试案例的签名不一致,而这在instrumention启动被测试app就出现,不用等到instrument.sendPointerSync,这里是其他的问题引发的。

 

    2. 继续跟进问题。

    (1)android.app.Instrumentation

    2

    (2)android.hardware.input.InputManager

    3

    (3)android.hardware.input.IInputManager

   4

    最后是调用Binder.transect进行跨进程调用。

 

   3. 被调用者是系统服务,可追朔到InputManagerService的injectInputEvent。

   (1)/frameworks/base/services/java/com/android/server/input/InputManagerService.java

    5

    终于发现了我们要找的SecurityException,导致INPUT_EVENT_INJECTION_PERMISSION_DENIED是jni层的nativeInjectInputEvent

   (2)/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp

    x

   (3)/frameworks/base/services/input/InputDispatcher.cpp

    7

    终于发现了INPUT_EVENT_INJECTION_PERMISSION_DENIED踪迹,继续查看checkInjectionPermission:

    8

    查看系统日志,发现是造成Permission验证失败的原因是:当前windowHandle(被测app)->owneruid与注入者(instrument)->injectoruid不一致。并且windowHandle(被测app)的owneruid竟然是1000(系统账户)!

    (4) 系统日志如下:

    9

    同时,根据windowHandle->getName().string(),我意外发现“凶手”的Name是:hidden nav(隐藏的nav??….)。

 

    4. 在 被测app源码 和 Android源码中分别查找,最终发在“凶手”匿藏在PhoneWindowManager中……

    (1)/frameworks/base/policy/src/com/android/internal/policy/impl/PhoneWindowManager.java

    10

   mHideNavFakeWindow的创建了addFackWindow,mHideNavFakeWindow的owneruid=Process.getmyid()(这里不列代码了), 而PhoneWindowManager是内部服务PhoneWindowService的策略类,属于系统用户。所以mHideNavFakeWindow这个透明的窗口,也是系统用户级别了(mHideNavFakeWindow为了满足某特殊需要,不得不设置为系统用户)…

而执行这个分支,需要满足一个条件:在重渲染ui界面时,被设置了标记:View.SYSTEM_UI_FLAG_HIDE_NAVIGATION。

    在被测App源码代码中search,终于发现疑似凶手:view.getRootView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_HIDE_NAVIGATION); 而它确实就在出现ClickOnScreen异常的Activity里。最后经调试,确认问题确实如此。

 

4.3 与 4.4表现不一致的原因

    对比PhoneWindowManager 4.3和4.4的代码,发4.4做了改进,如下(右为4.4):

11

    而在被测app的代码中…..

    12

   就是 被测试App 在4.4时,会增加一个flag,导致了它撞大运般地在4.4中执行流程发生了改变,避免了mHideNavFakeWindow创建,从而也避免异常的发生。

 

总结

    1. 个人认为这是Android设计上的bug,它的instrument在极端的情况下会失效。

    2. 除非测试案例在系统中以系统用户启动,否则在4.3以下系统,该问题无法避免!

    3. 只要有mHideNavFakeWindow的存在,原则上所有的操作都会失败,包括drag在内,但Robotium对drag的异常进行了拦截并直接丢弃,所以使用drag表面是成功的,但实际上是失败,这会导致运行中出现无法解释的诡异问题。