Also make the new lib only use system-apis.
This allows mainline module to use the new
RestrictedLockUtilsSettingLib.
Unfortunately the whole RestrictedLockUtils would have caused to much
new system-api. Hence it was split into RestrictedLockUtils and
RestrictedLockUtilsInternal. This caused a lot of trivial code changes.
Bug: 110953302
Test: Built
Change-Id: I693b3bf56f3be71f0790776e3aad5694717786ef
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I9acb311ec05f72f0a37f08b0d26785841fe91de5
We check the value of disabledByAdmin state in setEnabled, so update it
first before calling setEnabled.
Bug: 27642236
Change-Id: Ie6c805b85a3afb87ffdaad0b80dbadc172b62d49
In case a RestrictedPreference can also be disabled
for other reasons than device admin, the state
of RestrictedPreferenceHelper may not be up-to-date
with the actual preference state. For example, the
"Android Beam" checkbox can be disabled by device
policy, but it can also be disabled by Settings itself
because NFC was turned off by the user.
To fix that, always update the Preference state.
Bug: 26907006
Change-Id: I27cde70beb82721dd4d423943a9898e022df8862
- Currently, if a preference is disabled by admin, we add a padlock and disable
the preference. And now if the preference is enabled in some other place, the
padlock is not removed. Updated RestrictedPreference to fix this
behavior.
- Made RestrictedPreferenceHelper and
RestrictedPreferenceHelper.onAttachedToHierarchy public so that preferences in
Settings can use these.
- Put a check for null to avoid NullPointerException.
- Removed a redundant statement.
Change-Id: Ie88a761dc38c58a680c62b3703d2081c67462079
