When an app uses KeyguardManager.createConfirmDeviceCredentialIntent to ask
the user to confirm credentials, it first goes into ConfirmDeviceCredentialActivity
and then goes into ConfirmLockPattern/ConfirmLockPassword, that incorporates
a derivative of ConfirmDeviceCredentialBaseFragment to deal with the actual credential
and fingerprint checking.
There are two bits of logic that are changed:
1) ConfirmDeviceCredentialBaseFragment gets target user id from the intent,
then uses UserManager.getCredentialOwnerProfile to find the credential owner
user id. If the target user is a work profile with unified challenge,
profile owner will be primary user, otherwise it will be the same user.
When credential confirmation dialog is invoked via
KeyguardManager.createConfirmDeviceCredentialIntent, mUserId will already
correspond to credential owner because ConfirmDeviceCredentialActivity already
calls getCredentialOwnerUserId(), so real target user is not available.
With this CL ConfirmDeviceCredentialActivity doesn't query credential owner because
it will be handled later anyway.
2) Currently when confirming credentials for work profile with unified challenge
we use mEffectiveUserId (credential owner) for fingerprints, which is incorrect,
since fingerprints are per-user and primary profile fingerprints cannot unlock
work profile apps' auth-bound keys. With this CL work profile user is used for
fingerprints.
Bug: 111821299
Test: manual, tried ConfirmCredential sample app in both profiles
Test: manual, tried CA certificate installation in both profiles
Test: manual, tried separate work challenge
Change-Id: I074f773de1bd6207b01664f259bdd04766f32d41
- Dialog needs to use AppCompat theme.
- Activity needs to finish itself when user closed AlertDialog.
If we don't fix it, you can see a window after AlertDialog was dismissed.
Change-Id: Idfbd6b68bcdd3b577f1459657b635b7af9397276
Fixes: 112018696
Test: robo test, manual test
LocalBluetoothAdapter is obsolete, use BluetoothAdapter instead.
Bug: 111810977
Test: make -j50 RunSettingsRoboTests
Change-Id: I5109a0296c1006a3c2e346bf966ef8901c101e30
Since we are moving conditionals/suggestions to a different place, there
is no need to use DashboardSummary to display top level settings any
more. We can simplify a lot of code for top level settings and reduce it
to a standard DashboardFragment.
- Create a new DashboardFragment + xml for all top level internal items
- Add a PreferenceController to provide summary for Network & internet
item.
- Mark a bunch of things deprecated for future work.
Bug: 110405144
Test: robotests
Change-Id: I9f778777131c28eb836b722e089e026a59f5ddc6
Previously, there was no way to change the autofill service of the
personal and managed profile independently. After 'uncloning' the
setting in ag/4666330, we now introduce a separate UI control
for each profile.
BUG: 38033559
Test: Tested manually by setting up a work profile and verifying that
the setting can be changed independently. Also verified that the
additional UI does not show without a managed profile.
Change-Id: I1c42fc4335bc319ca7f6fd1b7b10c781343ca248
The underlying Dialog API changed when it returns true for isShowing()
in a way that broke our profile photo chooser, but it turns out it was
an intended change and we were depending on it in a way we shouldn't
have been. Instead we'll just keep track of whether we were showing the
dialog by using an already existing boolean flag that gets set before we
start the photo collection activity.
Fixes: 110101157
Test: make -j RunSettingsRoboTests
Change-Id: I166230e85142c348b6760e436324261f2a41f1e0
Bug: 80507279
Test: inspected hprof before and after fix
Change-Id: I6ea2925695deb6261263649e858484e1667ec522
Merged-In: I6ea2925695deb6261263649e858484e1667ec522
If a device doesn't support NFC then
android.settings.NFCSHARING_SETTINGS and
android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT intents shouldn't
do anything and gracefully exit.
Test: Manual; Emulate a non-NFC device and test with apks sending intents
Bug: 80094104
Bug: 80092438
Change-Id: I5b3c3fdd582679e2cb16f474ef3331bc246b0d42
When the device is not yet provisioned and settings is launched:
- disable the entry point for changing device lock
- remove the search panel from settings home page
- remove the search menu
Bug: 110034419
Test: make RunSettingsRoboTests
Change-Id: Ieb7eb0e8699229ec0824ccc19d7b958ac44965a2
Merged-In: Ieb7eb0e8699229ec0824ccc19d7b958ac44965a2
When the device is not yet provisioned and settings is launched:
- disable the entry point for changing device lock
- remove the search panel from settings home page
- remove the search menu
Bug: 110034419
Test: make RunSettingsRoboTests
Change-Id: Ieb7eb0e8699229ec0824ccc19d7b958ac44965a2
Use isFilterMatched() to decide the prefernce should be added
or removed when receive onProfileConnectionStateChanged()
Bug: 80161203
Test: make -j42 RunSettingsRoboTests
Change-Id: Icccdb9007b587d3f481a23856edd7b2f7c9b04e0
ZenModeScheduleRuleSettings creates an DaysDialog when user clicked
Days option.
If Activity was destroyed suddenly, WindowsManager throws a windows leaked exception.
And then DaysDialog try to do something(dismiss), settings app will crash.
So, we need to dismiss dialog when activity was destroyed.
Test: robo test, change code to recover symptom, manual test
Change-Id: I8d5370fe9673573581d613da91c7ab9be55d8199
Fixes: 111841375
