- remove the content description in Keyguard
- only show virtual views when pattern is in progress
- add a content description when the pattern is not in progress
Bug: 22646748
Change-Id: Id32a37c4c74c82b547cee8861b2856fa0a08c41c
We check for the presence of energy data when determining whether to use
the WiFiPowerCalculator or WiFiPowerEstimator. Since we can receive this data
later, we need to switch to the WiFiPowerCalculator if we weren't using it before.
We can't ask the hardware if it supports energy data because that would involve a call into
WiFiManagerService, which can cause a deadlock if we are holding the BatteryStatsService lock
while using this class.
Bug:22776010
Change-Id: Id685d487c56595eab1d382f49da9417a423bb517
- Add callback to inform SysUI when the screen has been unblocked
and turned on.
- Cleanup inconsistent messaging about device interactive/screen on
and off.
- Add callbacks to inform SysUI about screen states
- Implement a quick fade for the scrim after touch, wake, and unlock.
First, start with a black scrim on top of everything, and then fade
it out.
- Make sure we play the normal unlock animation when device is pulsing
- Override navigation bar animations for touch, wake and unlock: Fade
in the same manner as the scrim.
Bug: 22571198
Bug: 21855614
Change-Id: I8ff08d72cced1e0f03c78d71ff710d8a4f6b848c
The main change here is to not allow the dialog to go in to its "focus
on the last app the user selected" when running in voice interaction mode,
instead just always giving a simple list.
This also fixes some problems with cleaning up active commands when
an activity finishes and not forcing the current session to go away
when the screen is turned off.
Also added some debug help, having activity print the state of the
voice interactor.
Change-Id: Ifebee9c74d78398a730a280bb4970f47789dadf5
Running status was being parsed incorrectly.
This could cause stuck notes or exceptions when sending running
status messages to a Bluetooth MIDI device.
Bug: 22689606
Change-Id: I9f7abce9758927be587eead9614617d5b0076353
Signed-off-by: Phil Burk <philburk@google.com>
There was a mistake in the code that was supposed to recover from the
initial time on a new device being bad until the real time ultimately
gets set, which was causing us to update the start clock time every time
there was a time change (instead of just when the original start time
appears bad).
Rework all of this, so we now count the start time as bad if it is more
than one year before the current time, only modifying it in that case.
Also when modifying it, adjust the time we set it to take in to account
how much realtime has actually elapsed so far in the battery stats.
Change-Id: If74bd711d9b7618c8f6148a9935c452aaaa7e257
Previously we tried to read /d/wakeup_sources to gather kernel wakelock data. If that
fails we used the older sys file /proc/wakelocks.
N7 has both /proc/wakelocks and /d/wakeup_sources, but /proc/wakelocks
has the actual data we need. All other devices are using /d/wakeup_sources, so
only N7 experienced a loss of kernel wakelock data.
The original regression was introduced here: ag/659258
Bug:22556242
Change-Id: I51ec68e957f587bc1466e24f0a1dbc8cd7753ac6
- Add onFingerprintAcquired, so Keyguard can grab a wakelock to prevent
the device from sleeping.
- If we get a successful fingerprint, wake the device up, immediately
dismiss the keyguard and tell PWM that we kicked off our frame that
will represent the correct state.
- PWM then waits for this frame to be drawn, and then turns on the
screen, which results in unlocking directly to the previsouly
opened app.
Bug: 21855614
Change-Id: I5f43df17fa5e4e9c6a6392eef4a4590b07df4f96
...context and/or screenshot
Added new API to find out what contextual data has been globally disabled.
Also updated various documentation to make it clear what kind of contextual
data you will get (and when it will be null).
Also added a new Activity.showAssist() API because... well, I was already
in there, it was easy to do, it is safe, and maybe people will build cool
things with it.
Change-Id: Ia553d6bcdd098dc0fce4b9237fbfaca9652fc74b
Simplify ChooserTarget handling by requiring a target component and an
extras bundle instead of a full PendingIntent/IntentSender. This
simplifies the handling of URI grants from sending apps.
Prune ChooserTargets that point at ComponentNames that don't share a
package with the original matching Activity target or that aren't
exported so that we don't show the user something they can't launch.
Bug 22516282
Change-Id: I3439c0910b4fa4f95c7a881b529942c96ffc953e
