After reset (docking) Pixel C Keyboard that was previously paired with
a device goes into so-called non-discoverable mode, where it will
establish connection only with device that it has connected before. When
scanning for available devices we need to wait till the keyboard starts
advertising itself as discoverable, and only then try to pair.
Also, let's flush the device cache when we attach the base to make sure
the device that we seen before and cached again in the right state after
reset.
Bug: 24915541
Change-Id: I136c1c4235080a25529b4b1c2b1da9bc18508811
Ensure that the user has had a chance to see it for a few
seconds after screen recording has ended.
Bug: 19121797
Change-Id: I52b69b2029439d42163ead5dc8748889b4f61934
In the new ranking, notifications with fullscreen
intents always take priority over those without,
such that when you get a call and a message
in succession, you would always see the
call on top and are able to pick it up.
Bug: 22778349
Change-Id: Ia9aaf009998fc9493f513dc71f2649d38ccf7a79
Unlike the implementation in LMR1, this is a countdown condition
(a countdown until the time of what was the next alarm when the
rule was created). The rule will not change if alarms change.
Also, alarms up to 7 days in the future will be considered.
Bug: 21648799
Change-Id: Id7fa9dbdbad1539e4da19b1d0e0c4395bb13e6cb
(cherry picked from commit 0842fe87b27b9e4a7aecfec25b93dba2d39f398a)
Only show zen footer if the active stream is affected by the current
zen mode.
Bug: 23844466
Change-Id: I08770882f12f11c3458e1e48a287139480ae7aa3
(cherry picked from commit 6aa83b4ca0859c3f59413ef092f8d843f8646f0e)
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 a25f6fcfed280136a16ce5800fcaabae17291dd7)
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 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
