| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
1. AccessibiltiyAction was incorectly throwing an exception when
a custom action was constructed.
2. AccessibilityManagerService should no longer enforce only standard
actions as we allow custom ones too.
bug:15110963
Change-Id: Iea57e0a6449b87bd8d103c55ca255e80705f2565
|
| |
|
|
|
|
|
|
| |
Makes the inversion bit public so apps can be smarter about rendering
images non-inverted (if they are so inclined).
BUG: 14680114
Change-Id: I8ca2b2517af2ffc13446d7e0b4e859c1171e2d0e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For user profiles the accessibility layer will use the accessibility
state of the their owner. A profile cannot have its own plugins or
settings. The rationale behind this is that if a user with impaired
vision is using the device with different profiles linked to his
main one, then he/she should be able to interact with the device no
matter what profile the app is being run with. Hence, The behavior
of the accessibility features should be consistent across apps run
with different profile.
bug:14564491
Change-Id: Id19ce81e1a2dfa48015c7ab3053d66c058be3e46
|
| |\
| |
| |
| |
| | |
* commit '0f7ed1f4776844f3ee8d3ce9d903f62cace66a06':
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
|
| |\ \
| |/
| |
| |
| |
| |
| |
| | |
Conflicts:
core/java/android/view/IWindowManager.aidl
tools/layoutlib/bridge/src/android/view/IWindowManagerImpl.java
Change-Id: Idcbc581294cc52b53eabefd61e5c20cbcea611db
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
bug:12927198
Change-Id: Iae21481c75ae58dcdab3731bf5f1e2844e29d434
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
* commit 'bc1a8f42d9eb5f1d91c872904a9a283781291fcb':
Active window not correctly computed.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The accessibility manager service was not handling the focused
window properly which as a result was breaking the active window
tracking.
bug:13788022
Change-Id: Iaa3fadfbf7b9545f5151e3603beeda2662fe7618
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change achieves a couple of things:
- Let Keyguard be a library, so we can use it in SystemUI.
- Introduce FLAG_KEYGUARD for windows and deprecate TYPE_KEYGUARD. Make
all the TYPE_KEYGUARD behaviour dependant on the flag.
- Implement a new KeyguardService in SystemUI, and bind that service
from PhoneWindowManager.
- Introduce BaseStatusBar.setKeyguardState and inflate
KeyguardSimpleHostView there and use FLAG_KEYGUARD for the window, such
that the status bar window essentially gets the Keyguard.
Bug: 13635952
Change-Id: I059d80d8b9b9818a778ab685f4672ea2694def63
|
| |
|
|
| |
Change-Id: I8b14db034a42a7ffd211a46fa3fee7bf2a6eac8f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Bug: 12872344
Change-Id: I85a3805ab0c34b96a7d4228f2382c8ff664e36e8
|
| |\
| |
| |
| |
| |
| |
| | |
services" into klp-modular-dev
* commit 'a5a93f559d337ad5b79716b05ea43707eb779dc8':
Check feature bits before loading optional services
|
| | |
| |
| |
| |
| |
| |
| |
| | |
At startup, we check with PackageManager whether a system service is
available before attempting to load it. A system service is available
if its associated feature (similar to hardware features) is present.
This does not remove unavailable services from the compiled jar.
Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
|
| |\ \ |
|
| | /
| |
| |
| | |
Change-Id: I6239d90fa0b813e37878f8fc31caf7a2d70fa3ba
|
| |/
|
|
|
| |
* commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce':
Move some system services to separate directories
|
|
|
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
|
