The spec property requires an accessible getter and setter. This code
will be removed in a following CL that refactors magnification spec
animation.
Change-Id: Ia8fecf98700d18e62ae30aa437b81b061c9a9542
First step in moving ownership to AccessibilityServiceManager so that we
can implement the magnification control APIs.
The magnification Region and the current/sent MagnificationSpecs are now
private to the controller, and all access is handled through accessor
methods. Comments have been added to all public accessor methods.
Bug: 22718911
Change-Id: Ia50ee93513785585aac5424543fc1d730b84bd90
This also adds a return value to the callbacks on
AccessibilityGestureDetector.Listener, so that the listener can indicate if the
event has been consumed, and processing should be halted.
b/25021896
Change-Id: If4d366ff207c1cebd0e3f7dab5f27a2037ddb510
The goal is to make this value shareable with Settings code (without
adding dependency on com.android.server)
Change-Id: Ic41af575dcf8081de69bdcdb20fba430bcf3257e
Makes AccessibiilityInputFilter aware of current user ID, and pasess the
user ID to event stream filters that have per-user parameters:
- AutoclickController -> for per-user autoclick delay
- ScreenMagnifier -> for magnification scale
While doing this, make AccessibilityInputFilter.disableFeatures private,
and replace usage in AccessibilityManagerService with
setUserAndEnabledFeatures with feature flags set to 0:
Using disableFatures directly leaves input filter in inconsistent state
where internal mEnabledFeatures flags don't match real state of enabled
features.
BUG=23113412
BUG=24265227
Change-Id: Ib295f4c08de1a3743e55714459844b6d80787637
This was originally introduced in change id
Idd8539ffed7ba4892c5a916bd34910fd2ef50f75 to fix an issue with touch event
handling in TouchExplorer. The original issue has been fixed, so this
workaround is no longer needed.
b/24470877
Change-Id: Ie2a782b162b837e9bdc4904a486ed292989f83d8
When there is docked stack, we want to show a "handle" through which the
user will resize the docked stack. We add it from the system process,
because we want to avoid IPC calls.
Change-Id: If15fd2a0fcb7077446d1ba6c533acb3028a42039
Instead of hardcoding autoclick delay, use
Settings.Secure.ACCESSIBILITY_AUTOCLICK_DELAY value.
Adds logic for observing the setting's changes and updating the delay
that should be used when scheduling automatical click.
BUG=23113412
Change-Id: Iffe3df0cb64ab28f13d2803d01d581280aedf422
Settings in question are:
- accessibility_autoclick_enabled -> Whether the feature is enabled
- accessibility_autoclick_delay -> Amount of time mouse pointer has to
stay still before performing click
Enable/disabled AutoclickController event stream transformation (which
implements the feature) based on the accessibiilty_autoclick_enabled
value
BUG=23113412
Change-Id: I8178d10c09d86713bb4c725c95268a7c5f432eb4
The event stream transformer (AutoclickControlelr) observes motion
events from mouse in order to detect mouse movement. Once movement
is detected, a click event sequence gets scheduled with a delay. The
scheduled click gets rescheduled on every further detected mouse
movement, so the click is performed only when mouse movement stops.
Mouse movement detection has tolerance to jitter that may be caused
by user's poor motor control (that may prevent click ever being triggered
when mouse gets to target, or unwanted clicks when mouse is stationary).
Clicks are scheduled by posting delayed tasks to main loop. When
rescheduling click, previous tasks is not always removed and a new
created. Instead, if possible, new task is scheduled when previous,
delayed task is run. In order to do this, click scheduler keeps track
of scheduled click time and, when scheduled task is run, checks that
scheduled time is not greater than the current time (if it is, a new
delayed task is scheduled).
Detecting events from other input source types, or mouse events other
than movement (like clicks, scroll) cancels the scheduled click.
BUG=23113412
Change-Id: I8a72e768cd45cccb93c19476fe6e2c23e8e84f27
Updates AccessibilityInputFilter to pass keyboard and mouse events
through enabed EventStreamTransformations.
This is done in preparation for implementing Autoclick on mouse stop
feature, which depends on those events.
Existing EventStreamTransformation implementstions are modified to
non touchscreen motion events and key board events.
Adds stub EventStreamTransformation (AutoclickController) that will
be used to implement autoclick feature.
Implements key event filtering as a separate EventStreamTransformation
(instead of doing it directly in AccessibilityInputFilter).
Introduces private EventStreamState classes to AccessibilityInputFilter,
which keep track of whether event sequences for different input sources
have started, and help reduce code duplication when determining whether
an event should be fed to registered EventStreamTransformers.
BUG=23113412
Change-Id: If115799bbe4debce48689370ff5ea9fa6dab9639
I need to make some changes to get the tests pass. First a11y service
will now disable when no service is specified, I need to re-enable
a11y after services are enabled. Second the old event used in tests
seems to be filtered out by the service, I need to pick a new event.
Also the timeout waiting for mock service to start is extended, I hit
the old timeout quite often with N9.
Bug: 19913735
Change-Id: I8fe1b7b5d93b6a52df0a8940a08761ea5fbf5084
This CL checks for the return value for Rect.intersect(Rect) for whether
there is actually an intersection before taking the calling rect as the
intersection. In the case of no intersection (Rect.intersect(Rect) returns
false), the calling rect would not have been changed, so here in this CL
it will be manually set empty.
Bug: 7368679
Change-Id: I7494c1a1649eca09e34412f0a59b795e8b3a82aa
Now that we have a separate foreground service proc state
(above a sleeping top app), update various system services
to put their bindings into this state when appropriate.
There are two new bind flags for this -- one that just always
makes it a foreground service, another that only does it when
the device is awake (useful for things like the wallpaper).
And with all of that, tweak network policy manager to only
include apps that are at least foreground service state when
in power save and device idle modes. This will allow us to
further reduce the set of apps that have network access
(in particular not giving access to the current top app when
the screen is off), hopefully leading to even better battery
life.
Change-Id: I91d85a5c5ed64e856149e9a5d94a634a7925ec7f
TYPE_APPLICATION_ABOVE_SUB_PANEL will be displayed on top of their
attached window and any TYPE_APPLICATION_SUB_PANEL panels.
Bug: 20135562
Change-Id: I711de3c19c01432c44de205bf09934a8b23b53fd
We do not want to accidentally disable the user's currently-enabled
accessibility service(s); presumably they turned them on during
setup for a reason. We now merge the prior + current states rather
than simply replacing the current state with the former.
Bug 19427367
Change-Id: I96eb47df57318c88066c5da6862f23f656639148
This change refactors ScreenMagnifier to use resources for its triple-tap
adjustment and scale threshold values. New values more appropriate for
wearable form factors are supplied. This also fixes a bug in the triple-
tap detection logic where the incorrect ViewConfiguration value for the
tap threshold was used, prematurely disqualifying some touch events as
potential taps.
Change-Id: If47e556aadb5beb1bad24644122560c6fbe33bad
We were using an approximation to determine where to send a pair of down
and up events to click on the view that has accessibility focus. We were
doing reverse computation to figuring out which portion of the view is
not covered by interactive views and get a point in this region. However,
determining whether a view is interactive is not feasible in general since
for example may override onTouchEvent. This results in views not being
activated or which is worse wrong views being activated.
This change swithes to a new approach to activate views in accessibility
mode which is guaranteed to always work except the very rare case of a
view that overrides dispatchTouchEvent (which developers shouldn't be
doing). The new approach is to flag the down and up events pair sent
by the touch explorer as targeting the accessibility focused view. Such
events are dispatched such that views predecessors of the accessibility
focus do not handle them guaranteeing that these events reach the accessibiliy
focused view. Once the accessibiliy focused view gets such an event it clears
the flag and the event is dispatched following the normal event dispatch
semantics.
The new approach is semantically equivalent to requesting the view to perform
a click accessiblitiy action but is more generic as it is not affected by
views not implementing click action support correctly.
bug:18986806
bug:18889611
Change-Id: Id4b7b886c9fd34f7eb11e606636d8e3bab122869
If there is a window with the accessibility focus we want to click
on the accessibility focused view in this window. The logic to
compute the bounds of the window was using the wrong window id,
hence getting an incorrect result. As a consequence in some cases
the user could not click on accessiiblity focused controls in the
nav bar.
bug:18889611
Change-Id: I89aee3ae2ffe27fe29819049c287a7155154c65b
only when it's been enabled. The idea is to set accessibility services package
status to disabled_until_used by default. Change the status to enabled once user
turn the service on.
It is first part of CL in framework, that returns installed accessibilityServices
even they been set disabled_until_used
Second part of CL will be in Settings, where we read/write package status
based on the service has been turn on or off.
The similiar logic has been used for preventing never used IME from auto updated
b/18205549
Change-Id: I1a9cba0221e3de0499ba5ac91ca382696bcb7043
It is possible that the accessibility windows list is null which
is treated as if there is no window information. The getWindows
method was accessing properties of the windows filed witgout a
null check.
bug:18522998
Change-Id: Ieefe678d3da3d6e8f96c0e4bedac0c55975621fa
If an accessibility service opts-in for the new window introspection APIs
when calling into a window for accessibility node infos we compute the
window's interactive region, i.e. the portion that is touchable and not
covered by other touchable windows, in roder to deterine whether these
nodes are visible, i.e. the user can interact with them. There was a bug
in the interactive region computation what we were not ignoring accessibility
overlay windows which are intended to not change what an accessibility
service can "see" and are put by such a service.
bug:18652374
Change-Id: I24ce54069087af9bc308e0c6a7b2aa6b952a6136
Accessibility services may opt-in to introspect the interactive
windows on the screen. If window introspection is enabled there
is a case where some events from a showing window are received
before the updated window state from the window manager. Now the
window manager sends over the windows before notifying the app
for the focus change.
bug:18625996
Change-Id: Ic481e01efbe12dc92f090f799feeb236672fc7b3
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
Updating the accessibility layer behavior to reflect the new
model where accessibility no longer overrides strong encryption.
Now enabling an accessibility service lowers the encryption
level but the user can bump it up in settings if desired.
bug:17881324
Change-Id: Ic60d760c267d3f934040a42e1963b179bd8b9f5f
