| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reload the content description whenever the
configuration changes.
Bug: 24977838
Change-Id: I875f0d83976b7d007a9bb2e56b28ff8fb6365a38
|
|\ \ \ \
| |/ / /
|/| | | |
|
| |/ /
| | |
| | |
| | |
| | | |
Bug: 20751989
Change-Id: I9b1093b98f303656a299c18b503c1d8c9f032335
|
| | |
| | |
| | |
| | |
| | | |
Bug: 23978877
Change-Id: I01a9e756d7eeef7aa239ca0c67d4084624aaed12
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
mnc-dev
* commit '31f19c444f5f9d22c81fcb339e51bee465ba10f9':
Send next alarm's show intent via PendingIntent
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also send all IntentTile intents via PendingIntent.
Bug: 23909438
Change-Id: I0bb277c8385b7936fbda03cd76f02248c4fc55de
|
|\ \ \ \
| |_|/ /
|/| | |
| | | | |
mnc-dr-dev
|
| | |/
| |/|
| | |
| | |
| | | |
Bug: 24841350
Change-Id: Id5d91ee8adbb638caf66976d701cfbc0befaca04
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)
|
|/ /
| |
| |
| |
| | |
Bug: 24167496
Change-Id: I3e883eeca002e86d4df30c2b238e18bd63bbddea
|
| |
| |
| |
| |
| | |
Bug: 24244260
Change-Id: I922d45e6dcc4eb85fc7d93824e7d01645a90266e
|
|\ \
| | |
| | |
| | | |
in" into mnc-dr-dev
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|/ / /
| | |
| | |
| | |
| | | |
Bug: 24304031
Change-Id: I606bccf4b62b651e17c6e6d9472648deeab703da
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | | |
Change-Id: Ib0f4cb4c7a011ce6df4100189b79ed4c2476c2c6
|
| | |
| | |
| | |
| | |
| | | |
Bug: 23970549
Change-Id: I899d8a92050c257217fa8528c33cb4592ad6d76a
|
|\ \ \
| | | |
| | | |
| | | | |
mnc-dr-dev
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|/ /
| |
| |
| |
| | |
Bug: 23967648
Change-Id: If91df75e6325b3969dc2351a70af0c160d3eab04
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Bug: 23971926
Change-Id: Ia3c6fb18d38fb7479028191ad3df8389adb830ec
|
|/ /
| |
| |
| |
| | |
Bug: 23970549
Change-Id: Iec1e8ac507268086e0e2935847eda606ea1fb700
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug: 23827042
This reverts commit 0cb50efdc2d3ecaa9f1b2163109e8fff1b23f0e7.
Change-Id: I40251500b2dcf95e63ce39a768e11a50b26fb923
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If the gesture was detected while turning on, the gesture
would not launch.
Bug: 23636271
Change-Id: I166759a55137163be0c3f38fe8d1dc0c18977e11
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fixed b/23727634.
Change-Id: Ie03b26f7b8faee8d61d772041351729995f7088c
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
So we don't end up in a wrong state.
Bug: 23692022
Change-Id: If40eb66499c95b82d86873dbbd6ccc64468373b2
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
With Android M, the system correctly handles camera arbitration
and therefore the secure camera launcher was only adding delay.
Bug: 23713450
Change-Id: Icd5e7883f3560bfd0c9b5f7bd93675847949469b
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Bug: 23596083
Change-Id: Iba88abce317e9d3a9c675a846261f35b1daee22a
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Bug: 23718313
Change-Id: I6c88fbba9ae460594b8e2f1a77c6545b305e5813
|
|\ \ \ \ \
| |/ / / /
| | | / /
| |_|/ /
|/| | | |
|