Tethering was re-evaluating everything on any connectivity change.
This was causing problems when mobile data was not available as each
re-eval was again requesting a connection which would fail and loop.
Ignore FAILED states to break this cycle in a minimal change.
bug:6668233
Change-Id: Ia1dfc6abff1fe464e9501b50185cdb8d0fbb7ff6
1. Accessibility allows querying only of the active window.
The active window is the one that has input focus or the
one the user is touching. Hence, if the user is touching
a window that does not have input focus this window is
the active one and as soon as the user stops touching
it the active window becomes the one that has input
focus. Currently the active window is not updated properly
when the user lifts his finger. This leads to a scenario
of traversal actions sent to the wrong window and the user
being stuck.
The reason is that the last touch explored event that is
used to determine where to click is cleared when accessibility
focus moves but this event is also used to determine when to
send the hover exit and touch exploration gesture end events.
The problem is that the last hover event is cleared before
it is used for sending the right exit events, thus the event
stream is inconsistent and the accessibility manager service
relies on this stream to update the active window. Now we
are keeping separate copies of the last touch event - one
for clicking and one for determining the which events to
inject to ensure consistent stream.
bug:6666041
Change-Id: Ie9961e562a42ef8a9463afacfff2246adcb66303
1. We are deciding whether the user is performing a gesture or an exploration based
on the gesture velocity. If we are detecting gesture we do the recognition at the
gesture end which is when the finger goes up. This is better than having a mode
toggle gesture for exploring and gestures detection. However, it is possible that
the user really wanted to perform an exploration but was moving too fast and
unless he lifts his finger the device is in gesture detection mode. This is
frustrating since the user has no feedback and assumes exploration does not
work.
We want to perform gesture detection only for a maximal time frame and if the
user did not lift his finger we transition into touch exploration state.
bug:6663173
Change-Id: I954ff937cca902e31b51325d1e1dfce84d239624
Call the Window client method dispatchAppVisibility when hiding or
showing wallpaper rather than wait until the next call to
performLayoutAndPlaceSurfaces.
Fixes bug 6645473.
Change-Id: I363f69f8db0affff92308e11ce52546401959d8f
Continues to check MANAGE_NETWORK_POLICY permission. This allows
SystemUI to invoke snoozeLimit() without CONNECTIVITY_INTERNAL.
Bug: 6653091
Change-Id: I464bf62b79f2647c6b6db151251a0036897d0cc0
The transition from clock to keyguard when restarting the device
was janky. The cause was that the clock app was animating away
which kept the adjustWallpaperWindowsLocked() method from setting
the keyguard as the new mWallpaperTarget. At the same time the
WindowAnimator saw that the keyguard was readyToDisplay() which
set mForceHiding true causing the clock to become hidden. Since
the clock was mWallpaperTarget the wallpaper was hidden at the
same time.
This fix does not allow mForceHiding to hide an animating
window.
Fixes bug 6649988.
Change-Id: Ie5cb0dfcc987d5ee1ad2351cf520629b8e301a2b
This keeps the background wallpaper from disappearing when expanding an
app that has a wallpaper background (e.g. clock).
Fixes bug 6649988. The second half of the bug, the first half will be
reissued as a new bug.
Change-Id: I209c9038469e4133586a927c92ef64ae43fb937f
The code was correctly inducing a 'finish' when such an activity was
being stopped, but then was not continuing with the rest of the stop
bookkeeping at that point. In some circumstances this could result
in an inconsistent state, with the activity marked as finishing but
neither in the foreground nor stopped.
Bug 6585403
Change-Id: Ib5c5be885bc6534e099e040d87a8589f7b7454ce
