- 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
Update various places in Settings to use "admin" ueser flag
instead of checking user id "0". This should be no-op in
single user mode since the only admin user would be user 0.
In split system user mode, this will correctly ACL admin
user instead of non-interactive system user.
Bug: 19913735
Change-Id: Ida4d59c5f689ea0dc34b3b3ff0822b087fa0afd6
Catch Resources.NotFoundException which should cover all parsing
errors from loadDrawables(); also substitute a default icon if
parsing returns null.
Bug: 17760671
Change-Id: Ia0ec25e34974ed85b6ffe6882d5bce003d64e9d6
- New strings in the screen.
- New layout/style.
- Clean up internal API's around it.
- Add fingerprint support if launched from externally
- Separate theme if launched from externally
- If launched from above Keyguard, use SHOW_WHEN_LOCKED flag
Change-Id: Icdf9bf9e0506841f24e8aab5f0f1d1f4b688951f
List both primary profile's and managed profile's accounts. Also notify the user
if there are other users present on the device.
Bug: 17899181
Change-Id: I5401722e65305861edeed60cfe926fca5c81a418
Search in Settings makes it possible to find the factory reset screen.
Disable the search index in PrivacySettings so that backup and reset
keywords don't get indexed for secondary users.
Also add additional safeguards for other entry points such as public
intents, so that the backup/reset screen does not show any options.
Bug: 18076086
Change-Id: Ie5135fbf4084038c99947a1a107ab4758f0c15a9
Explicit null theme is passed when using Resources.getDrawable() and
no theme is available, e.g. when using getResourcesForApplication().
This fixes an issue with ic_text_dot theming and helps avoid similar
issues in the future.
BUG: 17648301
Change-Id: I3e97c3490b6f2a55744f567b21284f2935ae9af7
- get rid of PreferenceActivity as much as we can and use fragments instead
- add Drawer widget
- add Dashboard high level entry into the Drawer (but this is work in progress and would be done in another CL)
- add bypass of fragment's Header validation when launched from the Drawer but *force* validation if external
call thru an Intent
Be aware that WifiPickerActivity should remain for now a PreferenceActivity. It is used by SetupWizard and should
not trigger running the SettingsActivity's header building code. SetupWizard is a Home during the provisionnig process
and then deactivate itself as a Home but would make the Home header to appear in the Drawer (because momentarily we
would have two Home).
Also, verified that:
- the WiFi settings still work when called from SetupWizard
- when you have multiple Launchers, the Home header will appear in the list of Headers in the Drawer
Change-Id: I407a5e0fdd843ad7615d3d511c416a44e3d97c90
