121e0c073992658ca0ba055f40bf3b130caa819a |
|
09-May-2014 |
Svetoslav <svetoslavganov@google.com> |
Adding shell command execution to UiAutomation. The UiAUtomation APIs are an extension object on instrumentation and is not null only if the instrumentation was started from the shell. The UiAutomation APIs allow performing privileged operations for testing. Since UiAutomation tests are just regular instrumentation tests they cannot take advantage of the rich set of command line utilities on the platform. This change adds a capability to UiAutomation to execute shell commands. bug:12927198 Change-Id: Ifb764c8e89943654f3e35d7a0c65b0b730db672f
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
1376d600d8e0eefdbc0aa11d398cf7517fc77129 |
|
13-Mar-2014 |
Svetoslav <svetoslavganov@google.com> |
Adding render stats APIs to UiAutomation (framework). bug:12927198 Change-Id: Iae21481c75ae58dcdab3731bf5f1e2844e29d434
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
9663fd09e9dc14a17d3828665ab11a256c4a5c96 |
|
01-Nov-2013 |
Svetoslav <svetoslavganov@google.com> |
Uninitialized UiAutomationConnection incorrectly enforces caller id. When a client of a UiAutomationConnection is set it remembers its UID and allows subsequent operations only from this UID. The connection If the connection was not used, i.e. its client is not set, and an attempt to destroy it is made the connection enforces the caller UID to be that of the owner but it does not have an owner yet. Now if the destroy method is called on a connection that is never used (has no client) we do not enforce caller UID. bug:11465888 Change-Id: I739dfc45e772ea970b6ab384e4420184724333a3
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
11adf6dc2438260c3e0d79cc189bcb4f6f15e9f4 |
|
24-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
The touch exploration capability is dynamically granted pre-JellyBeanMR2. Since the enable touch exploration capability is dynamically granted by the user for apps targeting pre-JellybeanMR2 API level, we have to properly update the accessibility service info for that service and also avoid caching copies of the service info. bug:8633951 Change-Id: I83dd1c852706ec55d40cda7209ad842889fb970a
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
db7da0eb8b7d515c168d5b410764e24c9a0f9431 |
|
23-Apr-2013 |
Svetoslav <svetoslavganov@google.com> |
Fixing bugs exposed when moving accessibility CTS tests to UiAutomation. 1. UiAutomation#executeAndWaitForEvent method was invoking the passed runnable while holding the lock which may lead to a deadlock. For example: a runnable that calls getActivity() gets us into a state like this. 2. UI automation services did not get all capabilities such a service can have. Now a UI test service gets all of them. 3. When UiAutomation was exiting for event fired as a result of a performed action, it was checking whether the received evnet time is strictly before the time of executing the command that should fire the event. However, if the execution is fast enough, i.e. less than one millisecond, then the event time and the execution time are the same. This was leading to a missed signal in rare cases. 4. AccessibilityNodeInfoCache was not clearing the relevant state for accessibility focus clearing event. 5. Accessibility text traversal in TextView was partially using text and partially content description - broken. Now we are using the text since for text view and content desc for other views. In other words, we are using the most precise text we have. 6. AccessibilityManagerService was not granting capabilities of a UiAutomation service - plainly wrong. CTS change:https://googleplex-android-review.googlesource.com/#/c/300693/ bug:8695422 bug:8657560 Change-Id: I9afc5c3c69eb51f1c01930959232f44681b15e86
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
3c55e5c6595d28c64f5a760947c66fdefa2481e2 |
|
28-Feb-2013 |
Svetoslav <svetoslavganov@google.com> |
Fake accessibility service used by UiAutomation not destroyed. UiAutomation registers a fake accessibility service to introspect the screen. Upon the death of the shell process that started an instrumentation in which a UiAutomation resides the connection between the UiAutomation and the system is kept alive allowing the instrumentation to introspect the screen even after the death of the shell process. bug:8285905 Change-Id: I1a16d78abbea032116c4baed175cfc0d5dedbf0c
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
3866f0d581ceaa165710feeee9f37fe1b0d7067d |
|
12-Feb-2013 |
Mathias Agopian <mathias@google.com> |
split Surface in two classes: SurfaceControl and Surface SurfaceControl is the window manager side; it can control the attributes of a surface but cannot push buffers to it. Surface on the other hand is the application (producer) side and is used to push buffers to the surface. Change-Id: Ib6754c968924e87e8dd02a2073c7a447f729f4dd
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
80943d8daa6ab31ab5c486d57aea406aa0730d58 |
|
02-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding UI test automation APIs. This change adds APIs support for implementing UI tests. Such tests do not rely on internal application structure and can span across application boundaries. UI automation APIs are encapsulated in the UiAutomation object that is provided by an Instrumentation object. It is initialized by the system and can be used for both introspecting the screen and performing interactions simulating a user. UI test are normal instrumentation tests and are executed on the device. UiAutomation uses the accessibility APIs to introspect the screen and a special delegate object to perform privileged operations such as injecting input events. Since instrumentation tests are invoked by a shell command, the shell program launching the tests creates a delegate object and passes it as an argument to started instrumentation. This delegate allows the APK that runs the tests to access some privileged operations protected by a signature level permissions which are explicitly granted to the shell user. The UiAutomation object also supports running tests in the legacy way where the tests are run as a Java shell program. This enables existing UiAutomator tests to keep working while the new ones should be implemented using the new APIs. The UiAutomation object exposes lower level APIs which allow simulation of arbitrary user interactions and writing complete UI test cases. Clients, such as UiAutomator, are encouraged to implement higher- level APIs which minimize development effort and can be used as a helper library by the test developer. The benefit of this change is decoupling UiAutomator from the system since the former was calling hidden APIs which required that it is bundled in the system image. This prevented UiAutomator from being evolved separately from the system. Also UiAutomator was creating additional API surface in the system image. Another benefit of the new design is that now test cases have access to a context and can use public platform APIs in addition to the UiAutomator ones. Further, third-parties can develop their own higher level test APIs on top of the lower level ones exposes by UiAutomation. bug:8028258 Also this change adds the fully qualified resource name of the view's id in the emitted AccessibilityNodeInfo if a special flag is set while configuring the accessibility service. Also added is API for looking up node infos by this id. The id resource name is relatively more stable compared to the generaed id number which may change from one build to another. This API facilitate reuing the already defined ids for UI automation. bug:7678973 Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|