In order to keep the settings list up to date
we are listening to package manager broadcasts
so when an app is installed, etc it will trigger
a refresh
Bug: 264420106
Test: ondevice & atest
Change-Id: I83be80e88dd03ebce1cb97a66fb759e1ef2537e8
According to Activity#isInMultiWindowMode() API design,
When the Task is in fullscreen windowing mode, and the app is in
ActivityEmbedding split (two activities split left and right),
Activity.isInMultiWindowMode() == true.
With the reason, we should consider additional condidion for
foldable device in unfolded mode, while settings activities
config to embedded activity, we can't only count on
isInMultiWindowMode() for split-screen mode
Bug: 278176550
Bug: 276938441
Test: atest CombinedBiometricProfileSettingsTest
Test: atest FingerprintSettingsFragmentTest
Test: manaul go to split screen mode and try to enroll face
Test: manual unfold device and enroll finger or face
Change-Id: I02bd223f27889e74e67b73051531a5b4554f3de1
Legacy choose lock options was hard coded description.
1. In T-QPR when device do not support Face enroll in SUW flow,
We should remove "Face" from the description.
2. Use BidiFormatter to handle RTL string combination.
3. Define a new string for "Fingerprint"
4. Add workaround crash in ChooseLockGenericTest/SetupChooseLockGenericTest
Test: Manual login corp, and observe the UI in Choose screen lock
Test: adb shell settings put system system_locales ar check RTL
Test: m RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.password
Bug: 269786629
Bug: 277361320
Change-Id: I2b26b7cc229f66300bb23ca190bb21f86f1caa01
redundant face unlock header.
1. Change the FaceSettings theme style to avoid an action bar
appearing.
2. In AndroidManifest.xml to apply configChanges attribute for
handling device orientation.
Bug: 262497152
Test: manually to do reproduced steps:
Pre-Condition:
1. enroll face
2. enable auto rotate
Procedure:
1.go to settings > security > face & fingerprint unlock
2.enter screen lock
3.click face unlock
4.rotate device into landscape mode and then back to portrait mode
5.check the UI
Test: make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings
.biometrics.face.FaceSettingsActivityTest"
Change-Id: I4ee1bb4f061ea2d141043405213ba6e60bacd92f
This preference was updated in
commit 6c3805288b
to use "%s" summary and remove the controller's getSummary()
implementation so the old test that checked the controller summary
was failing.
This new version checks the preference's summary directly, but that
seems to require running using the robotest runner instead of unit test
so this test was moved there and now follows patterns used by other
similar tests there.
Fix: 278110568
Test: SelectLongPressTimeoutPreferenceControllerTest
Change-Id: Ib65c823a568ad200ebeae74ad443f32441e5cb73
Context:
The legacy architecture UdfpsEnrollView was shown by SysUI
which has higher z-order that encounter lots of overlap issue.
Besides, IPC impact the latency of show/hide enroll view in
legacy architecture.
We used to upload ag/19699461 to cancel enrollment due to
above limitation.
With the new architecture ag/20582186 the UdfpsEnrollView
migrate to Settings and controlled by Settings process.
And ag/21149538 config SETTINGS_SHOW_UDFPS_ENROLL_IN_SETTINGS flag
to ture by default.
It's the time to improve the enroll UX by removing cancel
signle when onWindowFocusChanged() invoked.
Bug: 262680438
Test: m RunSettingsRoboTests -j30 ROBOTEST_FILTER=FingerprintEnrollEnrollingTest
Test: manual Security Settings > Enroll fingerprint > enroll
Swipe Notify Shade , Heads-up, Power menu interrupt should
not stop the enroll flow.
Change-Id: I60d88d5edd80e6eed70e2fbf288357e949abcae3
CP from ag/22598718 due to conflicts in downstream branch.
Bug: 276432652
Test: ForceEnableNotesRolePreferenceControllerTest
Change-Id: Ic0fa7f33dcb6509908008774c725eec386d0608b
Restricting merge due to conflicts; will manually CP this to master.
Bug: 276432652
Test: ForceEnableNotesRolePreferenceControllerTest
Change-Id: Ic0fa7f33dcb6509908008774c725eec386d0608b
When FaceSettings or FingerprintSettings are closed because of onStop(),
this information can't been passed back to previous Preference screen,
CombinedBiometricSettings, because handlePreferenceTreeClick() from
AbstractPreferenceController class only can launchActivity() throguh
preference's Context.
In order to recevice the activity result code from FaceSettings or
FingerprintSettings, add handleBiometricPreferenceTreeClick() method in
BiometricStatusPreferenceController. Then CombinedBiometricSettings uses
this method to show FaceSettings or FingerprintSettings through
launchActivityForResult().
Bug: 263057093
Test: atest BiometricNavigationUtilsTest
Test: Manually open camera through double-click power key on different
pages inside "Face & Fingerprint Unlock"
Change-Id: I99167739766ad5ea5f204b0f0543ba6ad18fac31
There are few corner cases and new updates that need to be incorporated:
1. Apps that declare USE_EXACT_ALARM, do not need SCHEDULE_EXACT_ALARM.
So these should be filtered out, regardless of whather they declared
the latter.
2. Apps that are in the power allowlist do not need either of the
permission, and so these should be filtered out as well.
In either case, if the user somehow ends up in the app detail page for
this setting, the switch should get disabled based on existing logic.
Test: make -j RunSettingsRoboTests
Test: Manually by UI inspection:
Settings -> Apps -> Special App access -> Alarms and Reminders
or by running:
adb shell am start -a android.settings.REQUEST_SCHEDULE_EXACT_ALARM
Bug: 232460265
Change-Id: I5aeab49f95260218878bc36f5a4d73a49e5082e4
Remove the plug/unplug condition checking for the incompatible
notification based on the feedback from:
https://b.corp.google.com/issues/276403405#comment3
Bug: 276403405
Test: make -j64 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.fuelgauge.batterytip"
Change-Id: Iec177ed33a3cc8cf5a5747b6f65440d31120823c
When the screen rotates, currently the startActivityForResult() within
RequestPermissionActivity could be called multiple times, so the
multiple RequestPermissionHelperActivity will be created, which caused
the issue.
Replace RequestPermissionHelperActivity with AlertDialog (as an
unfinished TODO of RequestPermissionHelperActivity) can fix this issue.
Fix: 243601277
Test: Manually with adb shell commands
Test: Unit test
Change-Id: If1e2b2807b69a87bbcfffa543ee0da134d4c4312
