- If the "Extend compatibility" preference is not supported, then set to shutdown secondary SAP automatically within the "Turn off hotspot automatically" preference.
Bug: 285914977
Test: manual test
atest -c WifiTetherAutoOffPreferenceControllerTest
Change-Id: I405107a4782a6f023442d196d0fca27515aab00e
Call super.onCreate(savedInstanceState) first to pass the correct userId
in maxFacesEnrolled.
Test: Manual - delete face unlock for work and re-enroll and observe
face unlock can be enrolled successfully
Test: atest FaceEnrollIntroductionTest
Fixes: 284819031
Change-Id: Ic1620c0ca3ca9adc61f5281abd34471f0c1b3f97
Remove the summary method and write the code in AOSP directly instead to
force string consistency. Also refactor a bit after the modification.
Fixes: 276399056
Test: robotests
Change-Id: I76ad740b694363a3cdfb3748e41c840fb678b93d
FingerprintAuthenticationClient wasn't cancelled successfully because cancelletion signal was set to null.
Test: Manual - rename an existing fingerprint and observe fingerprint unlock can be entered again
Test: atest FingerprintSettingsFragmentTest
Fixes: 283926104
Change-Id: Id33cc3d3e8052f5cc39eddac26a75047d3139633
ag/22361082 and ag/22460413 have added a dialog preventing entering
FingerprintEnrollEnrolling. So showing toast and early return in
onCreate() will never be reached. This CL cleans up this obsolete code
block.
Bug: 283244022
Test: N/A
Change-Id: Ifc5f3d909a275c735035146e44f70d2b5d5b51e3
Previously, we show settings's udfps enroll animation view (the fingerprint icon and progress view) once the FingerprintEnrollEnrolling is shown.
However, touch events have to wait for systemui's udfps overlay to be valid. This CL lets settings's udfps enroll view wait for systemui's overlay.
1. Sets udfps enroll animation view's default visibility Gone.
2. Propagates FingerprintManager#onUdfpsOverlayShown to
FingerprintEnrollEnrolling and when it's called, set the enroll view
visible.
Besides, this CL renames onPointerDown() and onPointerUp() with Udfps.
Bug: 280718879
Test: atest FingerprintEnrollEnrollingTest
Change-Id: Ieed3e74c182828918785edcacb021f19a3665f2a
**Root cause**
- When DisplayDataSizeTest was created, it was ignored already due to
b/214161063. That means the test never passed in the beginning.
- The default display's type in Robolectric is TYPE_UNKNOWN. However, in
the constructor of DisplayDensityUtils, we check all the display that is
not TYPE_INTERNAL can't be a default display. Hence the test failed.
- Even if we shadow the DisplayInfo to have TYPE_INTERNAL for default
display, the test still failed, because whenever we tried to get the
default display density we always get 0, and doens't have other diplay
density values. Hence we can't test increasing the display size in
Robolectric Test.
Note: the solution here is a workaround for waiting AsyncTask to finish.
If we ever change the implementation in DisplayDensityUtils to not use
AsyncTask, we'll need to update the test.
Bug: 279082331
Test: atest DisplaySizeDataTest --iterations 20
Change-Id: I3ccee5e7ba4d9399a8b715d84a9d53e106f88762
Note that an NLS that shouldn't be approvable (because its name is too long) but was already approved (either before the max length check was introduced, or through other means) will disappear from the list if the user revokes its access. This might be somewhat confusing, but since this is a very-edge case already it's fine.
Bug: 282932362
Test: manual
Change-Id: I4c9faea68e6d16b1a4ec7f472b5433cac1704c06
By marking the Intent that's being sent to WPP as "launched from
settings", the code in CustomizationPickerActivity can correctly
conclude that the multi-pane wrapper does not need to be applied to the
intent, preventing the odd "disordering" of the back stack in the bug.
Fix: 284809020
Test: manually verified, on a large screen device with a multi-pane
settings configuration, that going to Display > Lock screen > Shortcuts
and then swiping back off the left edge of the display correctly exits
settings instead of revealing an incorrect screen like it did in the
bug.
Test: also manually verified that the long-press on the home screena and
on the lock screen paths both open the right tab in WPP in settings
correctly.
Change-Id: Iac2b4e9fa5bab91b6a5251f1c51b4d21a0824f00
**Root cause**
The test was failing because it was not grabbing the boolean resource
from the values-mc999 folder. I'm not sure what changed in Robolectric
that causes it not able to find the resources based on the
qualifiers.
Bug: 279082331
Test: atest TopLevelAccessibilityPreferenceControllerTest
Change-Id: Ie738d1ada1a87b48f34efb7e0477c691c4d44d1e
metric category
**Root Cause**
The test was written when the metric category is set to 0. After we
update the metric category to FLASH_NOTIFICATION_SETTINGS in the
FlashNotificationsPrefereenceFragment, we forgot to update the test.
Bug: 279082331
Test: atest FlashNotificationsPreferenceFragmentTest
Change-Id: Icd709bd9e571ca264226d0ca860e5c482eae3927
