Cause: with unified screenlock, ConfirmDeviceCredentialActivity didn't
forward result with FLAG_ACTIVITY_FORWARD_RESULT
Also, fixed that ConfirmDeviceCredentialActivity didn't allow fingerprint
authenication in unified screenlock after keystore unlocked.
In ChooseLockSettingsHelper, add one new util function to allow
extra option to set returnCredentials to false while external to true.
Set StrongAuth to "not required" when it has been successfully unlocked.
Test:
1. PO Unified Screenlock/Work Challenge x fingerprint -> ok to trust cert
(Also, no credential is returned in intent)
2. WorkMode off -> Reboot -> turn on Work mode
-> no fingerprint option, PIN unlock successful to turn work mode on
Bug: 28752364
Change-Id: I6dc8865e8f005545f8577d7731afb4495647062b
Since it grabs a lock that can be slow on the main thread, don't use
ApplicationsState in any of the summaries, instead load the information
directly from the PM.
Change-Id: Ibefe867810d2a9926177a8de4e23a7faea4b1c3b
Fixes: 28435146
am: 3c2bd1a442
* commit '3c2bd1a44238c5844b4ec06018857f9dcb0cc7f2':
Handle return value when Bluetooth is enabled
Change-Id: Ibbba45ce3ea8401e2eeec75369e18047091b7044
am: 63ddec0756
* commit '63ddec075623cbe9d6a09dec75c3be205fa56d81':
Handle return value when Bluetooth is enabled
Change-Id: I712a01b1931400e92bc692d2730e22160bdb296d
am: 77ad3c2531
* commit '77ad3c2531c00c7b654162be826e93abb5e4dc75':
Handle return value when Bluetooth is enabled
Change-Id: I65d2d0b20ed3474f0c8b40a5cd17d12c00283c15
am: 77ad3c2531
* commit '77ad3c2531c00c7b654162be826e93abb5e4dc75':
Handle return value when Bluetooth is enabled
Change-Id: I5db74292d85d6a8795b2b25afd3c89c3731bd533
If the Bluetooth enable(true) returns false currently we are waiting for
a broadcast (which may not happen if enable returns false). We mark the
toggle to have failed (i.e. it is clickable and in OFF state) and the
switch bar text is appropriately shown.
Bug: b/28318203
Change-Id: I09ba46d2e102e7f2c4ef9a72bf38dedc1346364f
am: b09ecc6b8f
* commit 'b09ecc6b8fba4800cf4f1e819b063986245a121a':
Don't show app in deletion helper if it was installed recently.
Change-Id: I73924851d445159a521d35d50a398f30754d518b
am: 0772471119
* commit '07724711199a78720f4b1d9bdf365633e085b333':
Don't show app in deletion helper if it was installed recently.
Change-Id: I442adc220e730aca333eb49041cd2955a8f2e106
This adds a custom preference group which has both a checkbox
and collapse/expand behavior. This is intended to be used in
the deletion helper for apps deletion and downloads folder
deletion.
This patch implements the apps deletion integration.
Bug: 28769691
Change-Id: I9fb28a1baa4067841742b5dbeaf2083728c16144
This solves several problems. The first is that if a user installs
a large app which triggers the deletion helper, the deletion helper
may clear out the recently installed large app to free up space.
The second is that it appears that the usage stats may not be
synced from device to device currently using Backup and Restore.
By considering the installation to be a use for deletion helper
filtering, this should avoid the problem for 60 days (and if the
user hasn't used the app at that point, it should be fair game
to clear).
Bug: 28800057
Change-Id: Idb8545aa45a42e45dc673dc5c179c0197204edfd
After a manual clear, the user will be prompted to turn
on the storage manager, if it is turned off. The prompt
will only show up after certain defined delay times and
stop showing up entirely if denied enough times.
Currently, the dialog does not actually turn on the storage
manager because the storage manager is not yet landed.
Bug: 28801159
Change-Id: I3c221786d08a7102b3b5357416ab12692d1894cf
