Encryption is required when using 'adb backup' on encrypted devices,
but the UI has not been enforcing this. The failure mode is quite
confusing: the user can tap "back up my data" with no encryption
phrase supplied, and the confirmation activity disappears, but
the backup doesn't actually happen.
We now disallow confirming the backup unless a non-empty passphrase
has been entered into the UI.
In addition, tapping "do not back up my data" now finishes
the confirmation activity instead of just leaving it in a
confusing "dead" state.
Bug 19081192
Change-Id: I9ca69a08ff4322fe25129f9ca880b066c31525d0
Ensure that we always show the data icon in both Quick Settings and
the status bar, or in neither, but never one or the other.
The particular inconsistency this is intended to fix is that in some
circumstances, Wi-Fi may be connected, but the cell radio may be still
be used by certain apps, due to new multinetworking APIs in L. In this
case, we should always show the data icon; currently appears in the
status bar, but not Quick Settings, which was unconditionally dropping
the icon if any Wi-Fi connection was up.
Bug: 19112322
Change-Id: I9942f6b24081e061a72804ef47ad4fe719f32ec2
Don't assume the pickup sensor will perform a proximity check before
starting to pulse. This will add some latency, but necessary if
we can't trust the sensor.
Bug: 19083596
Change-Id: I51b7daf5ed76b2780ec5c949a75cc1fca247ddad
A clicked notification is not guaranteed to be removed,
so instead of dropping a clicked HUN notification we have
to release it to the shade.
Bug: 19093631
Change-Id: I73b88af774e49e89c8a601873c48cc5f5eed0224
QSDualTileLabel is no longer a FrameLayout (now a LinearLayout),
so it does not need the top padding based on the caret size
anymore.
Bug: 18725348
Change-Id: Ibd3aaa20e7cdb35ba585cc5c8981c64efb5c66fe
Use startSettingsActivity (QSTileHost) to make sure we use the right flags
and get the keyguard out of the way so the user always sees the
connect dialog for secure networks when they are sent to settings.
Bug: 18987307
Change-Id: I9027393ab8743e6dfe702221cb3bc1bb4e213708
It turns out that sysUI visibility / interactivity is racing with
boot, and it's possible in some circumstances for the user to start
the secure camera swipe gesture before formal boot-completed. Make
sure we only send the camera-related broadcast to registered
receivers in that case, otherwise we'll implicitly be asking to
launch other apps before boot, which is forbidden.
Bug 19060618
Change-Id: I7fcf13b5af7b2edfbb4aac06ef04a0fde2c6a0f7
We can use our normal visibility check to dismiss Recents when the screen is off,
since the system broadcast can occur after the activity is stopped. We should use
the same mechanism we use to test visibility when launching Recents and just see
if it is the top most activity.
Change-Id: Ib9c01e78fd9221c4fb0ffcc80a01a0c58fb96836
Log the following lockscreen gestures:
* Swipe up to unlock
* Swipe down to enter full shade
* Tap in empty area (causing unlock hint)
* Swipe to camera
* Swipe to dialer
* Tap on lock to lock device
* Tap on notification, activating it
For swipe gestures, includes length and velocity where available.
Bug: 18767135
Change-Id: Ib2c535e3a9d2b378f5a2a0a00c2be3fd916554ac
