All search results are now refreshed when resuming the
search fragment, to prevent crashes from results that
no longer exist.
Bug: 34817357
Test: make RunSettingsRoboTests
Change-Id: I96a0cbfee711ab9dee49d56bfdc4e885202d9ecd
Change preference keys of duplicate settings between
display and battery to avoid duplication in search.
Bug: 33701673
Test: make RunSettingsRoboTests
Change-Id: I56c82e9e7f163d345065ca478849de9b14c173fe
On older devices, the activation warning dialog would show upon the
switchbar changing to On. This was occurring when the page opens
because the status was changing onResume. By shuffling the switchbar
changes into the ASMSwitchBarController, we can register our listener
after the initialization of the switch bar's first status.
Change-Id: I3610d07345684d1e66444981a8059d1c2965e955
Fixes: 37472724
Test: Settings robotests
Previously, the PersistentDataBlockService but that is only one possible
implementation of the OEM lock. The new service abstracts the
implementation so is the API that should be used.
Test: Manual
Bug: 34766843
Change-Id: I5f9cb94996f84c4c082d152f05cd8aef566edc66
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
