...or settings from lock screen
When a window is drawn, the code to determine whether it should now
be shown was calling WindowState.isReadyForDisplay(). Part of the
condition of this function is that it is not ready if a policy is
forcing the window to be hidden -- which is the case when the lock
screen is shown. As a result, we wouldn't show the window at that
point, so wouldn't tell the activity manager that the token's windows
are visibible, and wouldn't tell the lock screen to go away.
This adds a new variation WindowState.isReadyForDisplayIgnoringKeyguard(),
which is the same as the original method but ignores the policy visibility
for app windows. This allows windows to be go through the complete
path of handling when the window is finally drawn and telling the
activity manager about it, even if behind the lock screen. By making it
a separate function, we don't impact any other code that is calling the
old function and may be relying on its behavior.
Also cleaned up a little of the dumpsys output. Most important, the
new ANR section is now moved to the top, since we want
"adb shell dumpsys window" to still give a nice summary of what we
normally care about -- the window stack and important global state.
Change-Id: Ica3ea85ce46f3f5f5cd2cc30fbd9de13d3885a57
This fix adjusts the sensitivity of the gesture recognizer by
eliminating gesture rotation in the recognition process.
Bug:6697119
Change-Id: Ic767f513c05210b27e583338c4f0adcaa1c4c625
Was counting on moving the app to the top to clear the flag
indicating that the app was being sent to the bottom. Since this
did not always happen the sendingToBottom flag was occasionally
left set. In this case the focus was skipped for that app and
consequently input was never propagated to it.
This fix clears the sendingToBottom flag each time the app
animations are completed.
Fixes bug 6691421.
Change-Id: I6f851dc5bedca95182db8490d87c876a71ad5fde
NetworkPolicy currently uses a single background thread to process
various broadcasts. When processing other broadcasts, this thread
can block our handling of SCREEN_ON/OFF, which are sent as ordered
broadcasts.
This change moves SCREEN_ON/OFF handling to the main thread, and
dispatches a one-way message to the background thread, allowing the
ordered broadcast to always proceed.
Bug: 6677047
Change-Id: I52de2c7b75beb8059bb87e123689ba4a9c4ae349
This fix forces the path through the updateLightsLocked method to turn
the screen on immediately if mWaitingForFirstLightSensor is true. Also
do not clear mWaitingForFirstLightSensor if mPreparingForScreenOn
is true. Wait until it turns false.
Fixes bug 6612418.
Change-Id: I03407e748cce4906a73de1f15df1654649b133c4
...for a smoother OOB experience
Way provided.
Put your defaults in system/etc/preferred-apps/*.xml.
Figure out what to put there with "adb shell dumpsys package preferred-xml".
Bug: 6680894
Change-Id: Ia06bb0061876274a5f80bf06d1ba5ad155edc323
Currently just grabbing the window state but we could grab
other things as part of the last ANR report.
Bug: 6680398
Change-Id: I23aa70907b1bdcb21c8acc556fde196ca790ef6a
...in Developer options is on
Don't respect stay awake while on as long as a time to lock limit
is being enforced. When we start enforcing one, make sure the
setting is off (since we won't be respecting it anyway).
Bug: 6664140
Change-Id: Id07cb528afa0c64c7766341841c51771f507121d
Weren't cleaning out any ActivityOptions that are still attached
to a finishing activity.
Bug: 6636731
Change-Id: If0520bbcbf1d4ce19d46ff769918893cefda9c87
People generally expect, if they are using FLAG_KEEP_SCREEN_ON,
that the screen won't immediately dim after it is cleared, even
if it has been passed the user activity timeout since the last
user interaction. So include the flag to reset the user activity
timeout when releasing its wake lock.
Change-Id: If7a8fea8faef3edbf13dff10a2f248adc9e3ff0b
The foreground activity is stopped when the device goes to sleep,
and started again when the device is unlocked. We now distinguish
this case from a "normal" stop, and do not finish() a foreground
noHistory="true" activity inappropriately when the device sleeps.
We also detect the case where an activity is started while the
device is still asleep, in which case the foreground noHistory
activity is cleaned up as part of bringing the new activity to
the foreground.
Bug 6657549
Change-Id: I9c6a0830aed0e47e4207b62803b90067c8486112
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
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
Was canceling ongoing animations when starting a new animation which
caused the window of the first animation to restart. This looked
janky. The original cancellation was put in to stop the incorrect
animation being selected when quickly switching between an incoming
app and the homescreen. Reversing the cancellation no longer exposes
the original problem it was put in to fix.
One way to duplicate what this is fixing.
1. Slow down animations to 10x.
2. Run ApiDemos/App/Alert Dialogs/List dialog
3. Tap outside the list dialog and then tap the home button.
Tapping outside the list dialog causes the list dialog to animate
away. Tapping the home button then causes the app to animate away.
Before this fix the list dialog would revert to full size before
the app animates away. With this fix the list dialog continues its
original animation as the app animates away.
Fixes bug 6600726.
Change-Id: I29c940254808a321c3b6c2e4f4b7c78a72b47899
It turns out that sometimes the wallpaper target is migrated to the
bottom of the window stack and then mWallpaperTarget is set to null.
In particular this happens when the launcher all-apps screen is
brought up. When this happens the layer of the wallpaper is
correctly set below the previous wallpaper target.
An optimization in WindowAnimator was keeping the layer update from
propagating to the Surface object. This fix removes that optimization.
Fixes bug 6631717.
Change-Id: I800dd043ce8df83b4e5edbf710503135396bc01e
