1. In touch exploration mode the system clicks in the center of the
accessibility focus rectangle. However, if this rectangle is only
partially shown on the window or on the screen the system may not
be able to perform the click, if the accessibility focus center
is not on the screen, or click on the wrong window, if the access
focus center is outside of the window.
This change clips the rectangle to the window bounds which and the
display bounds. This will ensure no clicks are sent to the wrong
window and no clicks are sent outside of the screen.
bug:7453839
Change-Id: I79f98971e7ebcbb391c37284467dc76076172c5f
1. The accessibility layer has a back door for a UI test automation code running
from the shell to attach. The unregister code does an incorrect identity check
and as a result the register UI test automation service is not disconnected
until its process is killed. The fix is super safe and simple.
bug:7409261
Change-Id: I4b1da18be6c5619dadd4a58fca6724529bc59dea
1. We cache some events to see if the user wants to trigger magnification. If no
magnification is triggered we inject these events with adjusted time and down
time to prevent subsequent transformations being confused by stale events.
After the cached events, which always have a down, are injected we need to also
update the down time of all subsequent non cached events.
bug:7379388
Change-Id: I41d8b831cc1016a0ee8f9c5ef5f42eb60a6f64d9
1. When magnifier, if a dialog that popped up is wider than the scree we pan to its upper
left corner. We now show the upper right corner if the locale direction is RTL.
2. Keyguard dialogs are not centered since they are used as a sign to recompute the
magnified area but an unnecessary else statement prevents such dialogs from being
properly show via a pan.
bug:7374331
Change-Id: I285e46b822a29f0082c502cb642f9da32dabfe6a
1. In the magnifier we are caching the touch events until we figure
out whether the user is triple tapping to enable magnification.
If the user is not trying to engage magnification we deliver the
stashed events. However, these events are stale and the subsequent
transformations such as the touch explorer get confused when trying
to detect a tap since the delay is longer than the tap slop.
This change compensates for the time the events were cached
before sending them to the next transformation in the chain.
bug:7362365
Change-Id: Idd8539ffed7ba4892c5a916bd34910fd2ef50f75
1. Sometimes unlocking the device when the IME is up and triple tapping on the keyboard
toggles screen magnification. The core reason is that when the kayguard window is
shown we hide all other windows and when it is hidden we show these windows. We did
not notify the screen magnifier for windows being shown and hidden. Also when the
windows are shown we may reassign layers to put the IME or the wallpaper in the
right Z order. The screen magnifier is now notified upon such layer reassignment
since window layers are used when computing the magnified region.
bug:7351531
Change-Id: I0931f4ba6cfa565d8eb1e3c432268ba1818feea6
1. We auto pan when certain type of window pop up to make sure the user
knows about the context change. This does not happen however for
fragment dialog since its window type is not in the list of one
we auto pan for. Updating the window type list.
bug:7332090
Change-Id: I9b097c57df929d2e4e807a948c3a0540f4092a76
1. If a bad magnification scale is persisted, i.e. it is
not between the min and max, the screen magnifier gets
into a bad state which even a reboot does not fix since
the scale is persisted in settings.
This change ensures that only valid scales are presisted.
In general a bad value should not be attempted to be
persisted but at this point this is the safest change.
bug:7288239
Change-Id: I3e9c7c091772fa64128ab8403c2127ce65cb94b8
1. The active window is the one that the user touches or the one
that has input focus. We recognize the user touching a window
by the received accessibility hover events and the user not
touching the screen by a call from the touch explorer. It is
possible that the user touches window that does not have
input focus and as soon as he lifts finger the active one
will become the window that has input focus but now we get
he hover accessibility events from the touched window which
incorrectly changes the active window to be the touched one.
Note that at this point the user is not touching the screen.
bug:7298484
Change-Id: Ife035a798a6e68133f9220eeeabdfcd35a431b56
1. We are showing a warning dialog if the user enables an accessibility
service that requests explore by touch. This dialog was shown only
for the owner but should be shown for the current user.
bug:7304437
Change-Id: I692b5112df16405e6d2e4890aafbfde79981f973
1. The reason is that the screen magnifier computes that the whole
screen is not magnifiable. The miscalculation was caused due to
an incorrect assumption that the non-magnified area is only at
the bottom. In fact, on a phone in landscape the non-magnified
area is both on the right and at the bottom. This change adds
a correct algorithm for computing the magnified region.
2. Increasing the delay for computing the magnified area when the
keyguard goes away to allow all windows hidden by the keyguard
to be shown. In rare occasions the previous delay was not long
enough resulting in a state where the keyboard is considered
a part of the magnified region.
3. Removed some dead code.
bug:7293097
Change-Id: Ic5ff91977df8bcf4afd77071685c3eb20555d4f3
1. The active window is the one the user is touching or the one
that has input focus. It has to be made current immediately
after the user has stopped touching the screen because if the
user types with the IME he should get a feedback for the
letter typed in the text view which is in the input focused
window. Note that we always deliver hover accessibility events
(they are a result of user touching the screen) so change of
the active window before all hover accessibility events from
the touched window are delivered is fine.
bug:7296890
Change-Id: I1ae87c8419e2f19bd8eb68de084c7117c66894bc
Created a new flag that indicates that a window should be shown
to all users. For the flag to be valid the owner of the window
must have system permissions.
Also separated system window types into those that show to all
users (e.g. StatusBar, Keyguard, ....) and those that appear only
to the owning users (e.g. Drag, ANR, TOAST, ...). Those that appear
only to their owner can override their default behavior using
the new flag (e.g. LowBattery).
Fixes bug 7211965.
Change-Id: I1fdca25d57b7b523f0c7f8bceb819af656c388d4
1. The initial implementation was not sending the gesture start and end
events until the the user has moved more than a given slop and did not
do it faster than a given velocity. However, there is the case where
if the user did not move or just taped on the screen an exploration
occurs. The system was not sending the exploration start and end
events for the latter case.
2. The delaued command for long press was not canceled when the pointer
moves more than the slop distance.
bug:7282811
Change-Id: I7d98470cd4d9ea9b2519326e5e550ff68b040747
1. Accessibility events for changes in the content of a given window, such as
click, focus, etc. are dispatched to clients only if they come from the
active window.
Events for changes in the state of a window, such as window got input focus
or a notification appeared, are always dispatched. The notification events
do not contain source, so a client cannot introspect the notification area
(unless the user explicitly touches it which generates hove events). The
events for a window getting input focus change the active window so they
have to be dispatched.
Events that are a result of the user touching the screen, such as hover
enter, first tocuh, etc. should always be dispatched.
bug:7282006
Change-Id: I96b79189f8571285175d9660a22394cc84f39559
1. During a drag in touch exploration we have two pointers moving in the same
direction but inject only one of them. If the dragging pointer goes up we
send an up to the view system and wait for all pointers to go up to transition
to touch exploring state. At this point the dragging pointer id is cleared
and if a new pointer goes down we are trying to send up (rather do nothing)
for the dragging pointer which we already did and due to the invalid pointer
id we get an exception when splitting the motion event.
bug:7282053
Change-Id: I690bf8bdf6e2e5851ee46a322c4a1bb7d484b53a
1. The up event was not injected when the last pointer went up, i.e.
at the end of the drag. This patch sends an up event if the dragging
pointer goes up for both cases, when the dragging pointer goes up
first and when it goes up second.
bug:7272830
Change-Id: I708a2b93ee2d0a4c46dbeea002841666e919602d
Includes telephony, WindowManager, PackageManager, and debugging
settings. Update API to point towards moved values.
Bug: 7231764, 7231252, 7231156
Change-Id: I5828747205708872f19f83a5bc821ed0a801cb79
1. If tocuh exploration and screen magnification are enabled and the screen
is currently magnified, gesture detection does not work well. The reason
is because we are transforming the events if the screen is magnified before
passing them to the touch explorer to compensate for the magnification so
the user can poke what he thinks he pokes. However, when doing gesture
detection/velocity computing this compensating shrinks the gestured shape/
decreases velocity leading to poor gesture reco/incorrect velocity.
This change adds a onRawMotionEvent method in the event transformation chain
which will process the raw touch events. In this method of the touch explorer
we are passing events to the gesture recognized and the velocity tracker.
2. Velocity tracker was not cleared on transitions out of touch exploring state
which is the only one that uses velocity.
bug:7266617
Change-Id: I7887fe5f3c3bb6cfa203b7866a145c7341098a02
1. The accessibility layer announces user switches. Even though
the initial switch to the owner on a singe user device is a
valid use switch we should not announce it for accessibility.
bug:7264693
Change-Id: Idf022fab6b74c84b7a96bc4ed7c7fee2b83029a6
1. A recently added check was preventing touch exploration being
disabled when the last touch exploring service was turned off.
As a consequence enabling explore by touch was initializing the
input filter with the magnification and the not disabled
screen magnification features.
bug:7256223
Change-Id: I9ed5457705d625805462e4d316b2c8a5af9aabca
1. In explore-by-touch when the user slides two fingers in the same
direction we consider it a drag gesture. We merge the pointers into
one and deliver a touch event. When one of the pointers goes up
we were transitioning into touch exploring state. This means that
were transitioning to another state in the middle of a gesture which
creates complications and leads for interaction end event not being
sent.
This change transitions out of dragging state when all pointers go up
- simple and all events are properly sent. Consequentially, staring a
drag the user has to lift all pointers to touch explore. Since usually
users either drags or touch explores this seems the simplest and
*least risky* fix.
bug:7253731
Change-Id: Ie8588fbe9b26cb81312bd7fd377c94732e41e3f8
1. The touch explorer is relying on the hover exit accessibility event to be sent
from the app's view tree before sending the exploration end and last touch
accessibility events. However, if the app is buggy and does not send the hover
exit event, then the interaction ending events are never sent. Now there is a
timeout in which we wait for the hover exit accessibility event before sending
the gesture end and last touch accessibility events. Hence, we are making a
best effort to have a consistent event stream.
2. Sneaking in the new nine patch for the border around the magnified region
since the current one is engineering art.
bug:7233616
Change-Id: Ie64f23659c25ab914565d50537b9a82bdc6a44a0
1. The problem is that we have a gesture detection timeout after which we transition
to touch exploration state. This handles the case where the user is using too high
velocity while trying to touch explore. The delayed command that transitions from
gesture detection state to touch exploration state was not firing an event for the
end of gesture detection and begin of touch exploration before doing its main work
to transition to touch exploring state.
bug:7233819
Change-Id: I5c4855231aa3826dadbee324e74a3c9e52c96cd9
1. If an accessibility service does not specify that it handles any
event types it was never added to the list of services while
the system is bound to it. Since the service is not in the list
with enabled services we never unbind it, hence it consumes
resources without doing nothing. This is also semantically
incorrect because a sevice may not want to receive events while
handling only gestures.
bug:5648345
Change-Id: Id478a4704cdeeb1729330f6ae4b8ff9e06320952
1. This change adds a global gesture for enabling accessibility.
To enable this gesture the user has to allow it from the
accessibility settings or use the setup wizard to enable
accessibility. When the global gesture is enabled the user
can long press on power to bring the global actions dialog
and then hold with two fingers for a few seconds to enable
accessibility. The appropriate feedback is also provided.
2. The global gesture is writing directly into the settings for
the current user if performed when the keyguard is not on. If
the keygaurd is on and the current user has no accessibility
enabled, the gesture will temporary enable accessibility
for the current user, i.e. no settings are changed, to allow
the blind user to log into his account. As soon as a user
switch happens the new user settings are inherited. If no
user change happens after temporary enabling accessibility
the temporary changes will be undone when the keyguard goes
away and the device will works as expected by the current user.
bug:6171929
3. The initialization code for the owner was not executed due
to a redundant check, thus putting the accessibility layer in
an inconsistent state which breaks pretty much everything.
bug:7240414
Change-Id: Ie7d7aba80f5867b7f88d5893b848b53fb02a7537
IStatusBarService.collapseQuickSettings is gone;
collapseNotifications is now collapsePanels, which does what
collapse() used to do. Similarly,
IStatusBar.animateCollapseQuickSettings is now simply
IStatusBar.animateCollapse().
Bug: 7245229
Change-Id: Id157d2fdf34926d3c85ffa8b81c741a5359aede4
1. Added APIs for opening the quick settings to the StatusBarManagerService
and the local StatausBarManager. The new APIs are protected by the old
EXPAND_STATUS_BAR permission.
Renamed the expand* and collapse* non-public APIs that are expanding
the notifications to expandNotifications* collapseNotifications* to
better convey what they do given that this change adds
expandQuickSettings* and collapseQuickSettings*.
Added a global action to the accessibility layer to expand the quick
settings which is calling into the new status bar manager APIs.
bug:7030487
Change-Id: Ic7b46e1a132f1c0d71355f18e7c5a9a2424171c3
1. The initial user was set to USER_NULL but some clients were registering
before the user change callback happens. Since the initial user is
the owner the current user id defaults to USER_OWNER.
2. The check for global clients and window connections was using the
calling UID but there are processes that run in a per user basis
as system UID (Setting for example). Now the check is stronger
and comparing the caller PID with that of the system process.
3. The code for finding the focused window id was not checking the
global window token list in addition to that of the current user.
4. The code updating the active window id was calling out into the
window manager with a lock held.
bug:7224670
Change-Id: I9f4b7ea67eb5598b30ee7d1b68a1d3ce0cf8cfb4
1. The active window for accessibility purposes is the either the
window the user is touching or the window that has input focus. We
were using the touch exploration gesture end event to figure
when the user stops touching the screen so we can set the active
window to the input focused one. However, we do not send such
gesture end if the user does not touch explore. If the user only
taps we do not consider this touch exploring. We now have dedicated
accessibility events for first and last touch and this change uses
them as a guide when to update the active window.
bug:6523219
Change-Id: I6262c0c5f408b02dbaa127664e4b426935d7f81f
1. The crash was happening if: two active pointers are performing a drag;
there are some inactive pointers down; the main dragging pointer (we are
merging the dragging pointers into one) goes up; now an inactive pointer
goes up and the explorer tries to inject up for the dragging pointer
which is no longer in the event resulting in a crash. Basically two
problems: inactive pointers were not ignored; 2) having only one
active pointer should not only send the up event but also transition
the explorer in touch exploring state.
bug:6874128
Change-Id: I341fc360ebc074fe3919d5ba3b98ee5cb08dd71e
1. The keyguard force hides some windows when it is shown and as soon
as the keyguard goes away there windows are made visible. However,
the window transition that the keyguard is moving away is reported
before the force hidden windows are shown which makes the screen
magnifier compute the magnified region with an incomplete list of
windows of interest.
bug:7215285
Change-Id: I3abc4d97b7a74de8183ad20477dadf66c82da037
1. Since adb is restarted on user switch it makes no sense to
try to reconnect the ui automation service since it will
be killed on a user switch.
Disabling touch exploration on UI automation service
connect since it can explicitly put the device in this
state if needed.
bug:6967373
Change-Id: I8cfde74f28f3f03d4ccf24746d43b8178ae2b5ef
