| b5e89c6debca90be92bf5bc2e0e79d109de6d08f |
|
02-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Support direct-boot tests.
Add shell commands to check on current FBE status and system ready
status. Mark variables without first-class locking as volatile.
Fix bug where UI automation would crash while device was locked by
marking it as forced direct-boot aware.
Bug: 26498834
Change-Id: Ib4dfb9350925e5413f93a09baacf84c62f2ba0ea
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
| 1dd872260b3ccfbe492d1be0bdbb3f98235b3ba3 |
|
27-Jan-2016 |
Phil Weaver <pweaver@google.com> |
Optionally support accessibility with UiAutomator
Adding a flag to AccessibilityServiceInfo that only works
for UIAutomator that supresses other services. This flag
is set by default for UIAutomation to match the current
behavior, but tests may clear the flag and enable other
services.
Needed to improve cts coverage of AccessibilityService.
Bug: 26592034
Change-Id: Icfc2833c1bd6546a22a169008d88a6b15e83989c
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
| e2239c9346b9efb8c879c1925d90f70c4eb2405c |
|
13-Jan-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Explicitly pass userId to getWindowToken
UiAutomationConnection.clearWindowContentFrameStats method currently clears
calling identity before calling mAccessibilityManager.getWindowToken. This
doesn't work properly when a call is made by a secondary user, because it
wouldn't pass a check in getWindowToken. This is now fixed by explicitly
passing ID of the calling user.
Bug: 26498396
Change-Id: I8f0cdde33e18f04adb1833c6c0d0c329de921018
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
| 52153f4c0540a991b5b7214f4f14b5a891479a3c |
|
11-Aug-2015 |
Svet Ganov <svetoslavganov@google.com> |
Add GTS test to ensure valid default permission grants - framework
The platform grants runtime permissions by default to apps on the
system image that provide core device use cases which a user expects
to work out-of-the-box. We are now adding a test to ensure that
OEMs cannot pregrant premissions on non approved components.
bug:23043018
Change-Id: Id76717cce0ee59678956bd0be347d3c045fe4c51
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
| 843b992b51d18c893f3665325ea3045a692832ac |
|
08-Jun-2015 |
Guang Zhu <guangzhu@google.com> |
clean up Process instance after we are done with the sub process
Per java doc of java.lang.Process, #destroy() should be called
after the parent process is done with the sub process.
Bug: 20435160
Change-Id: I254982388c5b46c93c214b37a1e8563f21805e82
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
| 14e260125e951c2c6372dae80b603996cbb4d362 |
|
19-Mar-2015 |
Guang Zhu <guangzhu@google.com> |
pass stream contents in separate thread for executeShellCommand
Doing it in binder thread will cause deadlock if stdout of
process under execution is larger than buffer of
java.lang.Runtime#exec(String).
Bug: 19829679
Change-Id: Icf0fccd3e2e80b0db4cc1115e501f79066adf091
/frameworks/base/core/java/android/app/UiAutomationConnection.java
|
| 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
|