Add a new SystemUI component to watch for keyboard attachment /
detachment. If the config specifies the name of a keyboard that is
packaged with the device, then SystemUI will ask the user if they
would like to enable BT (if disabled) and then attempt to pair to the
device.
Bug: 22876536
Change-Id: I786db35524d49706d5e61d8b8bc71194d50113f3
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 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
- Scrims: When dismissing Keyguard, don't wait until the next frame
to start the animation. Saves 16ms
- Scrims: Skip first frame, because it's completely black anyways.
Saves 16ms.
- Don't wait with navigation bar to show until the screen has turned
on. Window manager is blocked on DisplayPowerController anyways, so
the animation will exactly be started when the screen turns on. Fixes
some jank as well.
- Window manager: Don't wait for the window below Keyguard for draw
completion until turning on screen. Saves a lot of time depending on
how the app is behaving.
Bug: 23401557
Change-Id: I9734f9a12143f0e3c0647e9aa066831a29a6de63
- Move all fingerprint related to logic in on central class in
SystemUI that knows all the state of the UI so there is exactly ONE
place in which we decide what to do when we acquire a fingerprint.
- When pulsing and we get a valid finger, we fade the contents of the
Keyguard out and fade the scrim out almost the same way as we would do
in a normal wake-and-unlock sequence.
- Hide shadows while dozing, so we don't see the artifacts when we fade
the dozed Keyguard out.
Bug: 23225107
Change-Id: I82f78e61f2530cf7d507ade80f6f0a340c082567
The problem is that, for 12-hour locales, we cut the "a"
part of the time format out to show it in a separate
TextView so it can be animated independently of the actual
time. Unfortunately, while TTS is smart enough to pronounce
"1:15 AM" as /wʌn fɪftin eɪ ɛm/, "AM" on its own looks like
the English word "am" and is pronounced /æm/.
To fix this, a TextClock must be able to accept separate
formats for its content description than its presentation.
With this capability we can place the complete 12-hour time
format (including am/pm) in one of the views and suppress
the other one, so that the utterance creates an identical
experience to visual inspection: "1:15 AM" for all users.
Bug: 21718000
Change-Id: Ic9920d71ae4d4ad41ba86d7bd96f9a19b07e2108
