Android Instrumention.sendpointersync Send event Failure analysis

Problem Scenario

Android4.3, after entering an activity in the app being tested, the test case Clickonscreen an exception (Click can not is completed!).

Android4.4 Normal.

Front-facing instructions

The test case uses the test framework that I implemented, which calls the robotium at the bottom.

Analysis process

1. The framework calls the Robotium Clickonscreen, the source code is as follows:

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

The exception is asserted when Sendpointersync (sending a click event to the app being tested) fails 10 times: Click Can not is completed.

The exception that causes Sendpointersync is: SecurityException. In Android, the SecurityException exception is due to insufficient permissions, the general situation is: The test app and test case signatures are inconsistent, and this instrumention launched by the test app appears, There is no need to wait until instrument.sendpointersync, here is the other problem caused.

2. Follow up on the issue.

(1) android.app.Instrumentation

(2) Android.hardware.input.InputManager

(3) Android.hardware.input.IInputManager

Finally, call Binder.transect for cross-process calls.

3. The callee is a system service that can be traced to Inputmanagerservice's injectinputevent.

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

Finally found the SecurityException we are looking for, causing input_event_injection_permission_denied to be the nativeinjectinputeventof the JNI layer.

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

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

Finally found the input_event_injection_permission_denied trace, continue to view checkinjectionpermission:

Review the System log and discover that the reason for the failure of the permission verification is that the current windowhandle (tested app)->owneruid is inconsistent with the injected (instrument)->injectoruid. and WindowHandle (tested app) Owneruid unexpectedly is 1000 (System account)!

(4) The system log is as follows:

at the same time, according to Windowhandle->getname (). String (), I accidentally found that the name of "murderer" is: Hidden nav (hidden nav??). ....）。

4. In the test app source code and the Android source code to find separately, eventually sent in the "murderer" hiding in the Phonewindowmanager ...

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

Mhidenavfakewindow created the Addfackwindow,mhidenavfakewindow Owneruid=process.getmyid () (not listed here), Phonewindowmanager is the policy class for internal service Phonewindowservice, which belongs to the system user. So mhidenavfakewindow this transparent window, is also the system User level (Mhidenavfakewindow to meet a special need, have to set up for the system user) ...

Executing this branch requires a condition: When the UI is re-rendered, the tag is set: View.system_ui_flag_hide_navigation.

In the test app source code search, finally found suspected murderer:View.getrootview (). Setsystemuivisibility (View.system_ui_flag_hide_ NAVIGATION); And it really is in the activity that appears clickonscreen abnormal. Finally, after debugging, verify that the problem is true.

Reasons for inconsistent performance of 4.3 and 4.4

Compared to the code for Phonewindowmanager 4.3 and 4.4, the hair 4.4 was improved as follows (right 4.4):

And in the code of the app being tested .....

When the app is tested at 4.4, it adds a flag, which results in a change in the execution of the luck in 4.4, avoiding the creation of Mhidenavfakewindow, and thus avoiding the occurrence of anomalies.

Summarize

1. Personally think this is a bug in Android design, its instrument in extreme circumstances will expire.

2. The problem cannot be avoided unless the test case is started in the system as a system user, or in the system below 4.3!

3. As long as there is the existence of mhidenavfakewindow, in principle all operations will fail, including drag, but robotium to the drag of the exception was intercepted and directly discarded, so the use of drag surface is successful, but actually failed, This can lead to unexplained weird problems in the run.

Android Instrumention.sendpointersync Send event Failure analysis