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
Restricting to pkg="android" didn't filter out things like
open wifi networks, etc. So now we have a whitelist:
notifications must be sent the "android" pseudo-package,
*and* they must have one of these "kind" tags:
- android.system.imeswitcher (IME switcher, needed by SUW)
- android.system.update (OTAs)
Note that OTAs currently use a fullScreenIntent, so they
bypass this logic anyway, but for consistency's sake we now
allow OTA icons in the status bar explicitly.
Bug: 6645469
Change-Id: Ib2e2f22d7a0817a1acaf8137ed4f3c7d3ddf8af5
- Sometimes the black background would flash; changing
animation durations to make this much less likely
- Fixing issue in Recents where we sometimes forgot
to disable drawing caches on views after enabling them
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
