1. Change to FooterBarMixin
2. Move FooterButton to the same package with FooterBarMixin
Bug: 120805516
Test: RunSettingsRoboTests
Change-Id: Ic6937e3cbc515dd7bf877c9193932cd5800ac801
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
Properties accessed across partitions are now schematized and will
become APIs to make explicit interfaces among partitions.
Bug: 117924132
Test: m -j
Change-Id: Id2a696c621015d46015d5de0e7aef987e9e01b54
(cherry picked from commit 64af0081cc1a8babe19b0552122e35211fc84c9d)
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
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
For make this method usage more clear,
setTitle(charSequence) rename as setTitleText,
add java doc: it is only for user generated string
setTitle(int) rename as setTitleRes.
Change-Id: I972cb6a8ff90873dfdc25c23f6dc3d68103c8e4e
Fixes: 78347436
Test: make RunSettingsRoboTests
This CL update following UI of eSIM:
1. update title of eSIM reset checkbox under network reset and FDR screens.
2. update eSIM reset checkbox to default is checked.
3. Show eSIM reset checkbox in FDR when user is under developer mode.
Bug: 74083169
Bug: 74085673
Bug: 74771900
Bug: 74122440
Test: E2E & make RunSettingsRoboTests
Change-Id: Ia49fdae98d6ef541398b1dfb36c54beea1f2ba39
- When doing factory reset, we will launch the account credential
confirmation. If this fails, the settings page is re-initialized.
This steps might trigger multiple layout changes for the scrollview
before it is finalized. However, we are removing the global layout
listener once we receive the first update, which could result in the
reset button being disabled incorrectly, as the scroll state is
calculated based on wrong view heights. Remove the call that remove
the layout listener, so that we can still receive further updates.
- also remove the scroll listener once we enable the reset button
from scroll, as no more action is really needed on suceeding scroll.
Change-Id: I6ec1f592991629c15e5ad2bcb29fdd679d598f70
Fixes: 73298075
Test: make RunSettingsRoboTests
- for fragments that do not implement the preference screen, change them
to inherit from InstrumentedFragment instead.
Change-Id: I791c2634024bd2c248efea955be5c680180d735c
Fixes: 68277111
Test: make RunSettingsRoboTests
Tested manually by:
(1) Setting up a gmail account.
(2) Setting up a screen pattern.
(3) Going to Settings > System > Reset Options > Factory Wipe
(4) Hit the Erase button.
(5) Enter pattern into the Screenlock prompt.
(6) Notice the Google credential confirmation screen.
Prior to this change we would skip (5) if there was a Google account on
the device.
Test: make RunSettingsRoboTests ROBOTEST_FILTER=andorid.settings.MasterClear
Bug: 72694056
Change-Id: Ie07c678ecbc8361e8e1792f82efdfb1261db49fb
Due to issues with an Intent filter not being configured with a category. We
needed to move to launching the confirmation activity via Component targeting
Intent. Hopefully this can be addressed post IC.
Manual Testing:
Start by navigating in Settings to:
Settings > System > Reset Options > Erase
Then click on "Reset Phone." At this point the behavior depends on the state of
GmsCore.
With forthcoming GmsCore changes (and accompanying SettingsGoogle changes), the user will see a prompt telling them that
they can confirm their credentials. Regardless of whether the user successfully
confirms or hits back, they will end up in the MasterClearConfirm UX. As per the
feature spec.
Test: make RunSettingsRoboTests -j40
Bug: 6393703
Change-Id: Idca02bda1fa2e388d612bd2014e16e2b6665fe70
Chase list bug. Accidentally bailed on true effectively.
Manual tested by going to Settings > System > Erase All Data
And then hitting then successfully wiping and reseting.
Test: make RunSettingsRoboTests -j40
Bug: 72324059
Change-Id: Ib2a155820811f0ec62a45c1312475c24646ede76
This CL add a check box for eSIM enabled devices to reset eSIM data
during factory reset of the phone.
Bug: 67500470
Test: make RunSettingsRoboTests
Change-Id: I5a81d43f23ae55f8549a5b807fdf41f36c9d3acd
The basic AOSP settings infrastrucutre. Will add the Google specific
resources and tests to GoogleSettings in the next AR/FR change.
Test: make DEBUG_ROBOLECTRIC=1 RunSettingsRoboTests -j40
ROBOTEST_FILTER=com.android.settings.MasterClearTest.java
Change-Id: I7278b5c6d2a72e71d81c7fa5f937a2313d6c322c
- remove all code that check for the feature flag, and use the new logic
by default.
Change-Id: I7fbe60da84c1c0f35e7241402a71d2bc4cd300e6
Fixes: 64564191
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
- Add missing title to preference screen xml so that they will be used to
set the activity title when the fragment is launched.
- Also updated some incorrect preference screen titles.
- Overrides getTitle() in preference fragments that do not use the
preference screen xml.
Bug: 64564191
Test: blaze-bin/screenshots/android/i18nscreenshots/i18nscreenshots
Change-Id: Id72d5ddf18f0962bc484de8bbd847a2e55d6371e
Due to substantial risk in landing the "retain profiles" flow that
would otherwise occur if the user elected not to wipe eSIM profiles
during a factory reset, we no longer expose this option to users
through the UI. Instead, we show affected users messaging indicating
that their eSIM will be wiped unconditionally.
The underlying plumbing is retained to keep the change small and to
make it easier to revert back to a checkbox when the rest of the
platform supports it.
Change-Id: Ida7df14d81ffc4cb6b4b414928d3ce7e5c78594b
Fixes: 64081853
Test: TreeHugger
Per UX review feedback, it doesn't make sense to show this just
because someone has developer options turned on. So only show it if
the user has ever downloaded an eSIM profile.
Change-Id: If474451dddcaa75bce1e57ce2f1751ef3adf45ee
Test: TreeHugger
Fixes: 63147904
If a user never downloaded a profile onto their eUICC, there's no
reason to offer the wipe option, and it would only cause confusion.
But show the option nonetheless if developer options are enabled.
Bug: 38460669
Test: TreeHugger / Unit test / Manual verification
Change-Id: I51fb7b9e75c4f9a46ee0b24e64bddfafcbd48b14
Consolidated the many variants of ChooseLock*.createIntent, so that
it will take the same set of arguments.
Also modified SetupChooseLock*.createIntent to modifyIntentForSetup,
which will take the intent created by ChooseLock* and modify it for
use with setup.
Test: cd tests/robotests && mma
Change-Id: I5ff033f459c33ec9980872a536b3996d89f2bbbb
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
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
- Add a method in VisibilityLoggerMixin to log visible event using
LogMaker, which allows logging additional FIELD_CONTEXT field.
- In Utils.startFragment, add current page's metricsCategory as an extra
to next page.
- In next page's onResume(), extract the previous page's metricsCategory
and send it to VisibilityLoggerMixin.visible()
- Update all caller with additional paramters
Change-Id: I8e1f2597fa465b7d3aa16fa1d21c052a3219694a
Fix: 35359289
Test: RunSettingsRoboTests
Bug: 34341567
Test: manual - password is not required for regular user factory
resets and is required in carrier demo mode.
Change-Id: Ic594ebafdac02fc467dc6b2e46dfbd520db3ce9f
Bug: 34341567
Test: manual - in carrier demo mode, go to Settings > Backup and
Reset > Factory data reset > Reset phone > Erase everything and
this entire path is viewable.
Change-Id: Ia5491765241adad97ecdb0a5bfd86a8371b8e4fe
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
