After too many incorrect attempts at entering the user credential (PIN,
password, or pattern) for the work profile, a timeout will be triggered
to limit the rate of retries. At the same time, fingerprint should no
longer be allowed to unlock the work profile, until the user unlocks it
with the correct user credential.
Previously, fingerprint was not banned from unlocking the work profile
during and after the said timeout. (Pattern lock screen only had a
partial fix which removed the fingerprint UI, but still allowed
fingerprint to unlock.)
This CL fixes the issue. It also replaces the following fields with
equivalent getter methods:
- mIsStrongAuthRequired,
- mAllowFpAuthentication.
Otherwise, we would have to rely on these internal states being always
up-to-date, which is less maintainable.
Test: make SettingsGoogle and manually enter incorrect PINs/patterns
Bug: 36912481
Change-Id: Id6ac6b5c78bdc19078ce8dd7acb4ec41329e57c3
As per storage discussions, the best way to calculate storage for the
System is to just take all known data and subtract it from the used
bytes. There is more to the system than just the /system partition and,
even if we ignore the partitions and use the underlying block device
method of calculating it, we run into the problem of it not adding up to
the actual device size.
Change-Id: I6e1f775ea3f3b8b2cc78d734623934651e2fb7b4
Fixes: 37166310
Test: Robotests
Settings thought the default for "Allow from lock screen" was
on. It's really off.
Bug: 37158451
Test: Manually confirmed that a fresh device now shows off.
Change-Id: I38dc4f6d2bfec5e0c8562c0d2c6e034db461aa98
The Master Clear dialog lists the accounts whose data will be lost by
a factory reset. The list contains the headings "Personal" and "Work"
to distinguish accounts in the main user and the work profile. When
there is no work profile, the header (only "Personal" would be shown in
this case) is superfluous and misleading (as the user may be using the
device for work).
Bug: 30132270
Test: Manual :(
Change-Id: Id493652fc331d4500c4d772a9abcc716995565b3
Wasn't checking if the user actually agreed. Whoops.
Bug: 37123004
Test: Manually verified that canceling leaves the selection
unchanged.
Change-Id: I48a052eb74733d3d0105fc1e72c4bf77ce8be0c5
This addresses jank issues when first showing the WifiSettings. Given
the new loading bar, animated transitions seem less relevant. Based on
user feedback, animations may be readded after a delay in ODR.
Bug: b/37429702
Test: Visual
Change-Id: I9a44820bb354885d0ef31d50278aee6a47727701
Disable selectable when adding ipv6 addresses to the
WifiNetworkDetailsPage.
Bug: b/37351354
Test: make RunSettingsRoboTests
Change-Id: I79bc3dcab7339df96598aa1a6505f0148f8844b0
If a user tells a device to forget a storage volume and then
goes back to the PrivateVolumeForget activity from their Recents, it
attempts to re-initialize itself with a volume that it forgot.
And this makes Settings crash.
By gracefully killing the activity when we try to open
PrivateVolumeForget for a forgotten volume, we avoid this crash.
Change-Id: Ib4e881c10f0c872ce6b268b16a573960230ef99b
Fixes: 34856304
Test: Settings unit test
- add content observer for brightness relates changes, and update the
brightness preference summary when changes occur.
- also check for VR mode and auto brightness mode when reading the
current brightness value.
Merged-In: I895d251e1dc12cb114ef00328eb8aa0075d77ab1
Change-Id: Ice549ffd708c2dad311a87b6a92bf1c8db426456
Fix: 37227609
Test: make RunSettingsRoboTests
