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
The device name is reflected in three places: A Settings.Global flag
which can be read by third party apps, the Bluetooth device name, and
the Wi-Fi tethering hotspot name.
The Bluetooth and Wi-Fi names can be changed independently of the device
name, but if the user sets the device name, they are all changed in
parallel.
Due to the naming restrictions of Bluetooth devices and SSIDs, the SSID
naming restrictions apply to the device name.
Bug: 63819909
Test: Robotest
Change-Id: I3a81535fc07d183557a6fa5d54baef3c7868499c
To add bluetooth as a valid slice requires adding
support for Context-only preference controller
constructors, which was already planned work.
Fixes: 67997327
Test: robotests
Change-Id: I7efd20a05d5796c3327a26b1fc535d5436d1070f
They are already removed from first 14 days category, now removing
permanently.
Change-Id: I1740d3bff59ff56142c10cce3b9617009c58f47d
Fixes: 72224790
Test: robotests
Applications typically use this action to ask the user to revert the
"Do not ask again" status of directory access requested made by
StorageVolume.createAccessIntent(directory).
Test: adb shell am start -a android.settings.DIRECTORY_ACCESS_SETTINGS
Test: atest CtsAppSecurityHostTestCases:ScopedDirectoryAccessTest#testResetDoNotAskAgain
Bug: 63720392
Change-Id: Ib9007c2c08a75e2e54df6d6b5f465f9c3ccc82be
This adds one flag:
config_show_system_update_settings
Which when set to false will hide "System update" from System page. This
is useful for devices that controls its system update elsewhere.
Bug: 69813881
Test: make RunSettingsRoboTests
ROBOTEST_FILTER=com.android.settings.deviceinfo
Change-Id: Ibd1291ffd8948419e8aa06d0721842246a069378
SystemUpdatePrefenceControllerTest had some logic that seemed irrelevant
to its testing class, which seems to have moved to
AdditionalSystemUpdatePreferenceController. Removed the irrelevant
test cases and added additional test coverage on
AdditionalSystemUpdatePreferenceController.
Bug: None
Test: RunSettingsRoboTests
Change-Id: I5224900bc3449a9f329a1d02ee3cb597b4748d91
Previously ApnPrefence starts an intent with URI content://telephony/carrier/filtered/id,
this URI is only implemented in telephony provider for query(), but not
for delete() or update(). This caused the crash when user tries to
update or delete an APN through this URI.
We should let ApnPrefence starts an intent with URI content://telephony/carrier/id, which
is a general telephony URI and all of query() add() delete() update() are implemented for
non-DPC mode. And let ApnPrefence starts an intent with URI content://telephony/carrier/filtered/id
in DPC mode(as the general URI can't access DPC-owned APN), when only DPC-owned APNs are
presented to user. In the DPC mode, user can't update, add or delete an APN, they can
only view(query) the APN, so it won't crash with URI_FILTERED.
Bug: 72387301
Test: manual. Tried update, delete, and add action in Access Point Name page, no crash occurs. Instrumentation test will be added in b/72154761.
Change-Id: I9979cbffcc94a37b2bd96db766ececd0ac7b20e2
use preference_app to make sure the app icon is 24dp.
Bug: 71502850
Test: Screenshot | RunSettingsRoboTests
Change-Id: I0d7704246299201e72b991f199f9ddd2f224a8a3
This adds in the preferences from the Device Info page into the Me Card
page. By overriding the expanded children count, these preferences
appear in the the overflow (reflecting their more power user-y status).
Bug: 63819909
Test: Manual & Robotest
Change-Id: Ic342babfb34db6343b11300eadb30b09a69f56f1
