History log of /frameworks/base/core/java/android/app/UiAutomation.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
f00cd14f17c0acd6bffe78947d32ea0a2900d139 03-Mar-2017 Phil Weaver <pweaver@google.com> Basic accessibility support for picture-in-picture

Exposing actions from the PIP InputConsumer to accessibility,
stripping all actions from a covered PIP app, and adding the
InputConsumer's actions on the PIP app's root view.

We were also using an "undefined" accessibility ID to mean
three different things: a root view, a host view of a virtual
view hierarchy, and a truly undefined view. I've introduced
new values for cases where the id could be defined.

Also gathering all window IDs into one place to reduce the
chance of collisions.

Bug: 34773134
Test: In progress. Current cts passes.
Change-Id: I97269741a292cf406272bf02359c76c396f84640
/frameworks/base/core/java/android/app/UiAutomation.java
048c2bc19af4cfcb5e959f1bc07fbfa03a72e330 09-Dec-2016 Casey Burkhardt <caseyburkhardt@google.com> Initial implementation of Nav Bar Accessibility Button

This allows an AccessibilityService to set a flag in its
AccessibilityServiceInfo that triggers the navigation bar to show an
Accessibility Button and observe callbacks when the button is clicked
or there are changes in the visibility of the navigation bar.

Test: Manual (Created a sample AccessibilityService) + CTS
Bug:29231271
Change-Id: I03d653d85bc37df28ed71d8bba94b7c75fe56e43
/frameworks/base/core/java/android/app/UiAutomation.java
27fcd9c97a2ceb50bab026237390207e5ee9e290 21-Jan-2017 Phil Weaver <pweaver@google.com> Accessibility can capture fingerprint gestures

Bug: 27148522
Test: Unit tests for two new classes in this CL, CTS in
linked CL.
Change-Id: Icb5113e00b1f8724814263b3cc7f72fe4a6f0b41
/frameworks/base/core/java/android/app/UiAutomation.java
dc589ac82b5fe2063f4cfd94c8ae26d43d5420a0 11-Nov-2016 Sudheer Shanka <sudheersai@google.com> Update usage of ActivityManagerNative.

- Remove references to ActivityManagerProxy.
- Add isSystemReady to ActivityManager.

Bug: 30977067
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts
adb shell am instrument -e class com.android.server.am.ActivityManagerTest,com.android.server.am.TaskStackChangedListenerTest \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I07390b6124fb1515821f5c0b37baf6ae74adc8fa
/frameworks/base/core/java/android/app/UiAutomation.java
4d3eec411b3a1337083fe93bfd5385a7f26c30f6 02-Sep-2016 Phil Weaver <pweaver@google.com> Keep services updated of added views.

We were marking subtree events as not important for
accessibility based on the root view, but that doesn't
take into account the fact that important children may have
changed. In particular, adding a View to the hierarchy was
sometimes marked as not important because the layout it was
attached to was not important.

Also fixing an issue with UiAutomation where it called out
to the test filter with a lock held.

Also fixing an issue where nodes that are the source of
accessibility events are always marked as important for
accessibility.

Bug: 31226561
Change-Id: Ib619948ba1bbcfd00aef1d10726152f6cf2dfccd
/frameworks/base/core/java/android/app/UiAutomation.java
e6269c3f1d93582f0bcc18e37227ed4eec001a17 16-May-2016 Phil Weaver <pweaver@google.com> Hide UiAutomation#destroy as test api.

Bug: 28771617
Change-Id: Ib113883d3d12fc6a9e8c038e2c4eb1731b026b38
/frameworks/base/core/java/android/app/UiAutomation.java
f3e5d1d483231d615f5e77032f787fcd8047488b 29-Jan-2016 Anna Galusza <agalusza@google.com> Merge "Add API for IME control by Accessibility Services."
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/UiAutomation.java
9b278112467581e2b8d99f29cf48b9fbef9cc53f 04-Jan-2016 Anna Galusza <agalusza@google.com> Add API for IME control by Accessibility Services.

Change-Id: I3bb806cf420e0551a2c9ef97d95613f73e362df9
/frameworks/base/core/java/android/app/UiAutomation.java
a6b64f5099b7be6e8384958d8bcddb97bb06ec93 05-Dec-2015 Phil Weaver <pweaver@google.com> Gesture dispatch from accessibility services.

Add public APIs to describe gestures and dispatch them from
an accessibility service. Added a new capability that
services must declare to have this capability.

Bug: 22514086

Change-Id: I9bff2d9335f0310115112d14b7ed033a6d6c2393
/frameworks/base/core/java/android/app/UiAutomation.java
a73b8fd1f4faaad00d8a49d6e496aaf249fa7003 07-Jan-2016 Jeff Sharkey <jsharkey@android.com> Add some TestApis to fix build.

Change-Id: Icf0d8d63f3a41d99e46ebe96003863bae637bd9d
/frameworks/base/core/java/android/app/UiAutomation.java
214fb68767502f5fede643a062c1dc5975d75b27 17-Nov-2015 Alan Viverette <alanv@google.com> APIs for querying and controlling display magnification

Also separates magnification state and touch event handling. Moves
callbacks for window manager changes and display state changes into
the magnification controller.

Bug: 22718911
Change-Id: I3a8ba060a07d8f1f51856855a5f85601766fd45d
/frameworks/base/core/java/android/app/UiAutomation.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/UiAutomation.java
a9f6a9b769b71d89382b9b8c158b168cd7b4c692 07-Apr-2015 Quddus Chong <quddusc@google.com> Fixed broken link in UiAutomation.setRunAsMonkey() method description.
bug: 19711873

Change-Id: I4ebb50e03e6e979486ebd3a7c15f21358734574e
/frameworks/base/core/java/android/app/UiAutomation.java
3a5c721072c60c7ed9c8a95d0a65d0e3cb4eb9bb 14-Oct-2014 Svetoslav <svetoslavganov@google.com> APIs for an accessibility service to put interaction tracking overlays.

An accessibility service may register to observe the interactive windows
on the primary display. These windows are the one that has input focus and
ones a sighted user can touch. It is sometimes beneficial for an
accessibility service to overlay a window to intercept user interaction
and based on that introspect and perform an action on the windows that
are on the screen. This is problematic as overlaying a full screen window
that is touchable prevents the accessibility service to introspect the
content under this window.

This change adds a special type of window that only an accessibility service
can place which does not affect what an accessibility service can "see" on
the screen. Hence, even putting such a window full screen the service will
be able to interact with the other interactive windows it covers.

Change-Id: I053ccc3a5c6360a98dc40bdb172b54dab35d8b31
/frameworks/base/core/java/android/app/UiAutomation.java
b101ebe8a63ee1b6fc90135d661f4fe19c2e5f07 02-Jul-2014 Leon Scroggins III <scroggo@google.com> Recycle original screenshot after rotation.

After copying the Bitmap to a new Bitmap, there is no need to keep
the original pixels.

This may help memory pressure when running automated tests and taking
lots of screenshots, although it does not fix the main source of the
problem.

BUG:15454296
Change-Id: I7e61886fbb46a8068db3e8dfa1fcb0afd88ea430
/frameworks/base/core/java/android/app/UiAutomation.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/UiAutomation.java
1e0d4af9986c8c2a658769a63bf8b385d25e0435 11-Apr-2014 Svetoslav <svetoslavganov@google.com> Adding system support for a single accessibility focus.

Now that we have APIs to query all interactive windows and allow
an accessibility service to put accessibility focus in each of
them we have to guarantee that there is a single accessibility
focus. This is required for correct operation of the touch
explorer as on double tap in clicks in the center of the focused
area, hence having more that one focus is an issue. Also the
system is maintaining a single input focus so now accessibility
focus behaves consistently with that.

bug:13965563

Change-Id: I0b5c26dadfabbf80dbed8dc4602073aa575ac179
/frameworks/base/core/java/android/app/UiAutomation.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/UiAutomation.java
8e3feb15c5aec2c72b0ef120a1da325e1e8f0dda 24-Feb-2014 Svetoslav <svetoslavganov@google.com> Added accessibility APIs for introspecting interactive windows.

1. The old introspection model was allowing querying only the active window
which is the one the user is touching or the focused one if no window is
touched. This was limiting as auto completion drop downs were not inspectable,
there was not way to know when the IME toggles, non-focusable windows were
not inspectable if the user taps them as until a screen-reader starts
introspecting the users finger is up, accessibility focus was limited to
only one window and the user couldn't use gestures to visit the whole UI,
and other things I can't remember right now.

The new APIs allow getting all interactive windows, i.e. ones that a
sighted user can interact with. This prevents an accessibility service
from interacting with content a sighter user cannot. The list of windows
can be obtained from an accessibility service or the host window from an
accessibility node info. Introspecting windows obey the same rules for
introspecting node, i.e. the service has to declare this capability
in its manifest.

When some windows change accessibility services receive a new type
of event. Initially the types of windows is very limited. We provide
the bounds in screen, layer, and some other properties which are
enough for a client to determined the spacial and hierarchical
relationship of the windows.

2. Update the documentation in AccessibilityService for newer event types.

3. LongArray was not removing elements properly.

4. Composite accessibility node ids were not properly constructed as they
are composed of two ints, each taking 32 bits. However, the values for
undefined were -1 so composing a 64 long from -1, -1 prevents from getting
back these values when unpacking.

5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added
a check that enforces such trees to be well formed on dev builds.

6. Removed an necessary code for piping the touch exploration state to
the policy as it should just use the AccessibilityManager from context.

7. When view's visibility changed it was not firing an event to notify
clients it disappeared/appeared. Also ViewGroup was sending accessibility
events for changes if the view is included for accessibility but this is
wrong as there may be a service that want all nodes, hence events from them.
The accessibility manager service takes care of delivering events from
not important for accessibility nodes only to services that want such.

8. Several places were asking for prefetching of sibling but not predecessor
nodes which resulted in prefetching of unconnected subtrees.

9. The local AccessibilityManager implementation was relying on the backing
service being ready when it is created but it can be fetched from a context
before that. If that happens the local manager was in a broken state forever.
Now it is more robust and starts working properly once the backing service
is up. Several places were lacking locking.

bug:13331285

Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
/frameworks/base/core/java/android/app/UiAutomation.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/UiAutomation.java
26257a09a54cda5e8a0bc5b1edb0a5b401983a3b 13-Apr-2013 Svetoslav Ganov <svetoslavganov@google.com> Merge "Allow for setting test type as a monkey." into jb-mr2-dev
8f6f1f43eeb0d7263b626978ee2c21d4053bf610 10-Apr-2013 Adam Momtaz <amomtaz@google.com> Allow for setting test type as a monkey.

1. This allows UiAutomation type tests to run as if an
android monkey test is running. This allows applications
that recognize that they are drive by a test framework and
avoid performing certain actions such as calling 911.

2. Fixed a bug where the UiAutomation#disconnect() was not
called when the instrumentation is shutdown.

bug: 8588857

Change-Id: I9e3624dfbe2b8f81f27805711de1098ea2edd03d
/frameworks/base/core/java/android/app/UiAutomation.java
c4fccd183f1bb47a027bb303af5e65bec2f68b1b 09-Apr-2013 Svetoslav <svetoslavganov@google.com> Adding APIs for an accessibility service to intercept key events.

Now that we have gestures which are detected by the system and
interpreted by an accessibility service, there is an inconsistent
behavior between using the gestures and the keyboard. Some devices
have both. Therefore, an accessibility service should be able to
interpret keys in addition to gestures to provide consistent user
experience. Now an accessibility service can expose shortcuts for
each gestural action.

This change adds APIs for an accessibility service to observe and
intercept at will key events before they are dispatched to the
rest of the system. The service can return true or false from its
onKeyEvent to either consume the event or to let it be delivered
to the rest of the system. However, the service will *not* be
able to inject key events or modify the observed ones.

Previous ideas of allowing the service to say it "tracks" the event
so the latter is not delivered to the system until a subsequent
event is either "handled" or "not handled" will not work. If the
service tracks a key but no other key is pressed essentially this
key is not delivered to the app and at potentially much later point
this stashed event will be delivered in maybe a completely different
context.The correct way of implementing shortcuts is a combination
of modifier keys plus some other key/key sequence. Key events already
contain information about which modifier keys are down as well as
the service can track them as well.

bug:8088812

Change-Id: I81ba9a7de9f19ca6662661f27fdc852323e38c00
/frameworks/base/core/java/android/app/UiAutomation.java
550b48fa18f8b392be1aab46c5bb4ec92ac3328b 12-Feb-2013 Svetoslav <svetoslavganov@google.com> Adding public event callback instead of the internal one to UiAutomation.

It appears that com.android.internal.util.Predicate is in the public
APIs but it is in the internal package. Leaking the predicate APIs is
a mistake and while we cannot fix that, this change is adding legit
public filter interface.

bug:8183223

Change-Id: I3e2c0ef685d7a832630aaa3ec2e8eae3fb058289
/frameworks/base/core/java/android/app/UiAutomation.java
bbfa585d70a6e406ccb59c17eec73ccd55e5c8e0 12-Feb-2013 Svetoslav <svetoslavganov@google.com> Adding new APIs to UiAutomation.

1. Accessibility service may set a flag to request a compressed
view of the node tree representing the screen. The compressed
state does not contain nodes that do to react to user actions
and do not draw content, i.e. they are dumb view managers. This
compressed hierarchy was very beneficial to the test team and
this change is exposing the APIs. The compression has to be
configurable since old tests are written against uncompressed
view tree. Basically we do not hide the fact that UIAutomation
is simply an accessibility service with some other useful APIs.

bug:8051095

2. Accessibility service can perform global actions such as opening
notifications, opening recent apps, etc. These are also needed
for UI testing since there is no other way to do it via the
existing UIAutomation APIs. Basically we do not hide the fact
that UIAutomation is simply an accessibility service with some
other useful APIs.

bug:8117582

Change-Id: I7b6e24b5f7a973fdada0cc199cff9f882b10720b
/frameworks/base/core/java/android/app/UiAutomation.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/UiAutomation.java