Android Instrumention.sendPointerSync发送Event失败分析

问题场景

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

    Android4.4正常。

 

前置说明

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

 

分析过程

    1. 框架调用了Robotium的ClickOnScreen，源码以下：

    （com.jayway.android.robotium.solo.Clicker）

    

    当sendPointerSync（发送点击事件给被测app）10次都失败，便会断言异常：Click can not be completed。

    而引起sendPointerSync的异常是：SecurityException。在Android中，出现SecurityException异常是由于权限不足，通常的状况是：被测试App和测试案例的签名不一致，而这在instrumention启动被测试app就出现，不用等到instrument.sendPointerSync，这里是其余的问题引起的。

 

    2. 继续跟进问题。

    （1）android.app.Instrumentation

   

    （2）android.hardware.input.InputManager

   

    （3）android.hardware.input.IInputManager

  

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

 

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

   （1）/frameworks/base/services/java/com/android/server/input/InputManagerService.java

   

    终于发现了咱们要找的SecurityException，致使INPUT_EVENT_INJECTION_PERMISSION_DENIED是jni层的nativeInjectInputEvent。

   （2）/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp

   

   （3）/frameworks/base/services/input/InputDispatcher.cpp

   

    终于发现了INPUT_EVENT_INJECTION_PERMISSION_DENIED踪影，继续查看checkInjectionPermission：

   

    查看系统日志，发现是形成Permission验证失败的缘由是：当前windowHandle（被测app）->owneruid与注入者（instrument）->injectoruid不一致。而且windowHandle（被测app）的owneruid居然是1000（系统帐户）！

    （4） 系统日志以下：

   

    同时，根据windowHandle->getName().string()，我意外发现“凶手”的Name是：hidden nav（隐藏的nav？？….）。

 

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

    （1）/frameworks/base/policy/src/com/android/internal/policy/impl/PhoneWindowManager.java

   

   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）：

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

   

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

 

总结

    1. 我的认为这是Android设计上的bug，它的instrument在极端的状况下会失效。

    2. 除非测试案例在系统中以系统用户启动，不然在4.3如下系统，该问题没法避免！

    3. 只要有mHideNavFakeWindow的存在，原则上全部的操做都会失败，包括drag在内，但Robotium对drag的异常进行了拦截并直接丢弃，因此使用drag表面是成功的，但其实是失败，这会致使运行中出现没法解释的诡异问题。