Also made the stackscroller focusable if and only if it is
scrollable. This will allow it to be important for accessibility
again.
Change-Id: I7773ed3a19d23f6bc62a1b9a23464cfbecd0ec03
Fixes: 25673942
- ag/923796 changed the logic to always return true, so these extra
calls are no longer needed.
Bug: 28867314
Change-Id: I07a4f6ac772a1444bba1950b2f27aa4be58a8419
- Catch all exceptions thrown when docking an activity (similar to when
we start an activity) to allow us to gracefully handle the failure and
animate the task back into the stack.
Bug: 28867188
Change-Id: I3f80d261343c0161c5cbfd08a05a1fc6157f653e
- Re-inflate the contents of the NavigationBarInflaterView
- Call up to parent to notify the contents has been reinflated
- Fix how default tunable is handled, so that the resource is
reloaded on density change
Change-Id: If25f68d01eedd3319b0c270e1cf80ac382eea637
Fixes: 27227522
Because of an underflow the alpha could actually become 0xff instead
off 0 which would be visible as a black scrim. This was because of
our local updating of animators.
Change-Id: I4201a4bbfbc7cbf32819f4814c165d0e11adaadb
Fixes: 28840532
We were requiring the time to show in order to show the chronomer
which didn't make any sense.
Change-Id: Ia6d00d0932d272a6c5e20e8b41e3acfb53b7987a
Fixes: 28848113
- Do not override minimized state in SysUI when IME adjust change
comes in.
- Do not animate IME adjust if we are already animating for minimized.
This lead to problems that we animated the minimized state with the IME
adjust values.
- Make sure to update state after checking whether the IME adjust is
animating. This is to fix an issue where sometimes the IME adjust
animation didn't run because the old target was wrong.
Change-Id: Ie35e2f943a4cda99ffdc6f14663d892863759e46
Fixes: 28819201
- The home stack is still visible when a translucent activity (like
dialer) is on top, which caused us to use the logic path that just
tries to launch the next task. However, that path does not reload
the stack state (since the activity stack generally doesn’t change
while Recents is visible) so it was always launching the already top
activity. The new check ensures that we start the activity anew
as if it was coming from an occluding app.
Bug: 28767764
Change-Id: Iec0fdc0957e5070cec532c5de5cba3454c906a3b
Since LocaleList needs to depend on android.os.Parcelable, we cannot let
that class belong to "android.util" package, which causes layering
violation.
Bug: 28819696
Change-Id: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
Said callbacks poke around StatusBarIconController, which lives on
main thread and is not thread safe.
BUG=27047911
Bug:28613935
Change-Id: I880d79a237b03c06d72b5dff3db24bd60c7b8839
(cherry picked from commit 4f65092f5c95b89f48a48a916467b78d2a07ff89)
In the case where the keyguard has never been shown and thus
never been dismissed: StatusBarPolicy thought the keyguard was
still visible.
Instead of StatusBarPolicy keeping its own internal variable
for wether the keyguard is visible, directly use
StatusBarKeyguardViewManager.isShowing()
BUG:28755086
Change-Id: I1b30c0e6985aa7ff35eea41444ab5504c00ff130
- Add tracing when drawing ImageWallpaper.
- Don't force a redraw in onSurfaceRedrawNeeded. This only adds
another unnecessary draw and doesn't do anything useful.
onSurfaceRedrawNeeded is only here so the client can block.
- Delay entrance animation by one frame so wallpaper can be drawn
before the transition is starting.
- Add some delay for animating the tasks up in recents to match that
delay (it wasn't matched before at all).
- Fix an issue where launchedFromHome was wrong while docking.
Bug: 28769940
Change-Id: I2b763ed40078541328a1e04ffecf5b0a520fe019
- Added ActivityOption to mark a starting activity as a taskOverlay
activity. That is the activity will always be the top activity of the
task and doesn't cause the task to be moved to the front when it is added.
- Only set the starting window state of the ActivityRecord to shown if
window manager actually showed the starting window for the activity.
Avoids incorrectly trying to remove starting window for an activity that
didn't show any.
- When starting additional activity in a task, transfer the starting
window from the top most activity with a starting window. It is possible
the top most window does have a starting window like in the case of the
forcedResized activity.
- Only ensure visiblity of an activity we are starting in a task whose top
activity is a task overlay. They need to start in the visible-paused state
and not the resumed state which just causes extra churn in the system.
- Always add additional starting activities in a task with an overlay
activity below the overlay activity.
Bug: 28751186
Change-Id: I3624a4313ae9c406d42c67a3537f67ad685791af
