If an error is reported while trying to play a notification,
behave as if the playback had completed.
Bug 21093153
Change-Id: Iedc7691d0b8f4d68ad75cb04292a5d7d9350552f
(cherry picked from commit a25f6fcfed)
Previously there was always a 1s delay which could even become a 5-8s
delay if the Alarm was not delivered in time.
Bug: 24355754
Change-Id: I1625c69719eee81403a1fcce1358d4d6c9fcf3e9
Only shows if translation is available, follow-up
I3e883eeca002e86d4df30c2b238e18bd63bbddea to show in
all locales.
Bug: 24167496
Change-Id: I667cde69e5d5f8aec8ac9fd105bbfb7e118ced64
When going over the handler, it could happen with a bad interleaving
we thought that Keyguard was not showing when getting the
onFinishedGoingToSleep message, so we stopped fingerprint
authentication. For some reason our state machine for canceling
/restarting authentication didn't work correctly so the fingerprint
listening state was not correct.
Bug: 24178814
Change-Id: I2a4731f195982395244c12e4d33b2b7d561c5671
We used to start fingerprint authentication in onFinishedGoingToSleep.
This was a UX issue because then users couldn't place the finger on
the sensor immediately after pressing the power button because
onFinishedGoingToSleep is significantly delayed (around 900ms after
pressing the power button).
Bug: 23570959
Change-Id: I0bf557ebd10e6a8b033ab98a78aa338bf6538dcc
In case the the screen timed out and the setting was set to "lock now"
in case the screen times out, we locked before finished going to sleep,
leading to all kinds of state messups in Keyguard, including an empty
lockscreen when authenticating with fingerprint during that period.
Bug: 23952388
Change-Id: If1629be1171c841d51ec0555422e6108002fdb73
With Android M, the system correctly handles camera arbitration
and therefore the secure camera launcher was only adding delay.
Bug: 23713450
Change-Id: Icd5e7883f3560bfd0c9b5f7bd93675847949469b
When the navigation bar was originally introduced to phones
(in change Ic613a335) we wanted it to stick to the same spot
on the display so that it felt as much as possible like a
physical button array; pressing the same fingertip-sized
spot on the glass should always invoke BACK, etc. This meant
flipping the nav bar to a vertical orientation when the
phone was in landscape, and then juggling around the window
insets and other system windows to make room for it.
For reasons that are now lost to time, in that original
implementation we made the vertical navigation bar narrower:
42dp (versus 48dp for the horizontal navigation bar, which
incidentally is always horizontal on tablet-type devices).
Nobody really noticed (except app developers looking to
hardcode this value instead of just using fitSystemWindows
or the new WindowInsets).
Here we finally make the navigation bars match perfectly in
portrait and landscape.
Bug: 23724209
Change-Id: I861be84b41c6a227d269469686c8c66a32029f1d
