FotterButton constructor in setupcompat will be deprecated, change to
use builder.
Bug: 120805516
Test: RunSettingsRoboTests
Change-Id: Ic84b0c91205bf3c770bc658e8eaf2626e4d7bddd
1. remove the dependence of setupwizardlib.
2. add to use setupcompat and setupdesign.
3. modify new footer button in following up cl.
Bug: 120805516
Bug: 120872944
Test: RunSettingsRoboTests
Change-Id: I463dd35b799d4250b2aabce0cb0b8102cf9dd7d6
The factory reset page and the reset confirmation page is too old to
follow the style of Setup Wizard design. To change the layout and apply
the style for textviews and header.
Bug: 73738836
Test: make -j SettingsRoboTests RunSettingsRoboTests
Change-Id: I1ee3d09e1ef9cac8e25c60a566363d4f7d537eeb
This means that in some cases RestrictedLockUtils has to be used and in
some RestrictedLockUtilsInternal.
This causes a lot of trivial code changes.
I also updated the ordering of the imports in all affected files.
Bug: 110953302
Test: Built
make -j RunSettingsRoboTests
Change-Id: I9bdf8b89134f853bae4f38c81af436715c73e924
- for fragments that do not implement the preference screen, change them
to inherit from InstrumentedFragment instead.
Change-Id: I791c2634024bd2c248efea955be5c680180d735c
Fixes: 68277111
Test: make RunSettingsRoboTests
1. Move getPreferenceScreenResId() from individual subclass to
InstrumentedPreferenceFragment.
2. Removed InstrumentedPreferenceFragment.getTitle() and let the
preference fragments that do not have preference screen set the activity
title directly instead.
3. Removed OptionsMenuFragment as all it does is call
setHasOptionMenu().
- changed subclasses of OptionsMenuFragment to extend from
InstrumentedPreferenceFragment directly.
- none of the exisitng subclasses actually implements the option menu
related methods to provide any option menu. So, the setHasOptionMenu()
call is not added to the subclasses.
4. Update Languages preference title.
- launch the fragment from the preference controller instead of from the
default handling, as we need the title res id at launch time to get it
work properly when retrieving the title from back stack.
Bug: 64564191
Test: blaze-bin/screenshots/android/i18nscreenshots/i18nscreenshots
Change-Id: Ibecdcab32cbaed8bf604ec5ebe0a926b4e489a7d
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
This CL add a check box for eSIM enabled devices to reset eSIM data
during factory reset of the phone.
Bug: 37255419
Test: Included
Change-Id: Ic98974726a515b0a350b73a33093460a63c1fb8a
Both do the same, ACTION_FACTORY_RESET is the new name.
Test: manual - reset the device
BUG: 33656232
Change-Id: I30cedea600bfcbeffa5d1094a6e0e83326f7ccfc
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
SettingsPreferenceFragment has this already set so that the drawer
layout will work when the menu doesn't exist. However, some fragments
are not preference fragments, and we need to set setHasOptionsMenu
manually.
bug:27879503
Change-Id: I6faadeb56dab00af611ac413109800822038c66d
Also added a utility function for checking provisioning, instead of
repeating code for this check in several places.
bug:26156445
Change-Id: I9f4a280dd0cdf889f892e386dbf6a3fdb2a052ef
Guard against FRP attacks by keeping the persistent data block
intact, if a factory reset has been issued during SUW.
[resolves merge conflicts with ag/808069]
Bug: 25290269
Change-Id: Id26b4c10235ad126632b71875592a4fa70a39b24
If you close and then launch settings before the persistent
data block wipe is finished.
Bug: 20458454
Change-Id: I07bf79f25bcb30ac8932925aa7b77b9a95d16e20
Wiping the PDB effectively starves all other threads from
accessing flash, and freezes the UI. We throw up a dialog
but there's a race between drawing the dialog and starting the
wipe.
Show the dialog in onPreExecute to fix this.
Bug: 20854355
Change-Id: I8462f5ed3ff53ed574ebc1be416a821c2086b4f5
Each time a user adds an account, a challenge gets
stored to the persistent data block service.
If a user factory resets *from Settings*, this is
considered a "secure wipe" and thus we must wipe
the account challenges as well.
No other factory reset mechanism must be permitted
to wipe this data.
Bug: 14288780
Change-Id: Ibe48ccae2d7b5f8d736717a27b7c4f44bed0fba7
