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
Added BandwidthTest annotation and BandwidthTestRunner to start
and stop the network traffic profiler
Change-Id: Id29ac21ab99ff36bd864121276db59b61eb6e154
Added the ability for the test runner to return the bundle object
so the tests can get access to input arguments
Change-Id: I73a704bb2279238bd91a376aacecbe5f607af649
This fixes a problem where the test runner would die when a
test case has tests that are not methods of the test class.
Change-Id: I5adc464bb4a0c8d282428895e422a47dcb6bfe1f
This commit fixes two somewhat related problems:
- Attempting to run a method which does not exist caused a runtime
exception which stopped the test run. Change this so the runner reports
an individual test failure instead
- A runtime exception during the test run would cause it to stop
completely, with no information dumped to the logcat or stdout. Now
exceptions are trapped and reported to stdout.
Also added associated unit tests to test these two conditions.
Related bug 2812262.
Change-Id: I383f9b9bad99f14cb51071800fa9bdbf6a6a1119
And ability to exclude tests with given annotation.
Also fix class cast compile warning in emma output method.
Bug 2239240
Change-Id: I56273a51a8c58a690680bdb612615fab69e6e13f
