During a new lock setup for profile whose credential is shareable with
its parent first the user is authenticated with device lock after which
an activity having options of Pin/Pattern/Password with fingerprint and
face combinations is shown.
On choosing any option which has combination to set LSFK and biometric
it is expected that after setting LSKF the Biometric enroll activity is
started but currently this does not work as expected as the
ChooseLockGeneric activity is finished after adding LSKF and it does not
start the biometric enrollment for the profile.
The issue also exists with non-profile users using this workflow through
SET_NEW_PASSWORD intent and if already have LSKF assigned.
This change adds a new boolean which takes care to not finish the
activity till the Biometric enrollment is started.
Below conditions are taken care with this change
- For new lock setup when device lock already exists then after
authentication of current device lock make sure the activity is not
finished untill the biometrics enrollment activity is started.
- On choosing continue without fingerprint or face option the biometrics
enrollment is not started
screen recordings uploaded to buganizer - b/316109077
Bug: 316109077
Test: Manual
Change-Id: Ifcbaa7d89195d87d432fc848092f2301752c3c22
Update the battery status of incompatible charging on settings home page
Bug: 315748218
Test: Manual Test
Flag: NA
Change-Id: I4e729a5c45a0d2f8c8bcd82c40b776d9e9900dca
Clean up the legacy anomaly detection mechanism in the Settings, which is implemented in the 2017-2018. The will be replaced by the new anomaly detection mechanism.
Bug: n/a
Test: make -j64 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.fuelgauge"
Change-Id: I12ee6c8b3cbdb5073e4d46f18b90f8de228be8a8
- from batteryDiffEntry to batteryUsageDiff
Bug: 320358970
Test: make RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.fuelgauge.batteryusage.*"
Change-Id: Ibc5ee2f14ede066bef3fb1c832ef54941fc59ebf
Clean up the legacy anomaly detection mechanism in the Settings, which is implemented in the 2017-2018. The will be replaced by the new anomaly detection mechanism.
Bug: n/a
Test: make -j64 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.fuelgauge"
Change-Id: Id5b5f4987c205c45698b6aa25aeb9604479e79c6
Some of the hearing aids support both ASHA + MFi, however, they only
advertise MFi service uuid in advertisement packets.
We can filter the devices with MFi uuid while scanning and then connect
gatt to discover the remote services before pairing to make sure if the
devices are compatible with Android or not. Only devices that support
ASHA/HAP will be shown.
Bug: 307890347
Test: atest HearingDevicePairingFragmentTest
Change-Id: Ie1f4eedddd4c43fad0fcbcd35f436dea5ab06925
Rewrite a new hearing device pairing page with update UI for "See more
devices".
Bug: 307473972
Test: atest HearingDevicePairingFragmentTest
Test: flip the flag com.android.settings.flags.new_hearing_device_pairing_page && atest HearingAidPairingDialogFragmentTest AddDevicePreferenceControllerTest
Change-Id: Ic60601905e3d0d7d7c5b1ef9733652118a211f1d
When the app is restoring the button's text will be constantly updated
until the app is restored.
Test: manual
Bug: 304255818
Change-Id: Id5da0923e5f9f3e45889e10c017a3f3dc3f8bd95
- replace the string for charging on hold in settings main page and
battery status in battery settings page
Bug: 315748218
Test: Manual Test
Flag: NA
Change-Id: I130d377912e150d593f6480e2bbdf43048b6916e
Update the setOverrideDeadline based on the suggestion in the b/319721625, and remove the legacy anomaly detection mechanism from the main entry BroadcastReceiver
Fix: 319721625
Test: make -j64 RunSettingsRoboTests ROBOTEST_FILTER="com.android.settings.fuelgauge.batterytip"
Change-Id: I1276bfc95d9cf36a60e28612ebb8a295fd58083b
if the value of carrier config and current SIM's carrier is matched, then the pSIM conversion menu will show
Bug: b/319527964
Test: manual test (b/319527964#comment3)
Change-Id: I82025447f43c0151ba58edd77c6f8b7e8aff660d
This contains fix for PS biometrics issue in Pixel devices without
face hardware support.
In private space separate lock settings page
- without face support only fingerprint unlock controller is shown
- with face support controller for both face and fingerprint is shown.
Screenshot:
-Without Face support
go/ss/qhDqdyqYLCTYaJq.png
go/ss/4Jw54XKJPNYm4R6.png
go/ss/5LPjRQ76cVPZy7j.png
-if without Fingerprint
go/ss/ACGqKU7j24G3Q9Q.png
-With Face support
go/ss/7jV385WCFsXajZM.png
go/ss/ZrGTdiYUN5MFY3r.png
go/ss/6QNKqaFuZvuMJZ9.png
go/ss/9ZcSvXULHuPK2ps.png
go/ss/7GfABcYE4h8BkCo.png
Bug: 319794904
Test: Manual
Change-Id: I053e8584d036ca0d6e3d8157d0fdef6d465492aa
Prevent the disabling of specified apps, avoiding cases
where disabling the app may result in an unusable system.
Bug: 200043113
Test: make RunSettingsRoboTests ROBOTEST_FILTER=ApplicationFeatureProviderImplTest
Change-Id: I0b298af76cec20e4f31ec7411bbf3200a2869035
Merged-In: I0b298af76cec20e4f31ec7411bbf3200a2869035
