Remove MY_PACKAGE_REPLACED and MY_PACKAGE_SUSPEND action since Settings
is not store updatable, and it will reboot every time while updating. Originally, it is used on the store updatable extension engine.
Test: presubmit
Bug: 258576047
Change-Id: I9f2d58e3a822c4e4ebe182b03ace1b30f97d2340
Add configChanges to avoid the battery settings main page is recreated while rotating the device to improve rotation performance, but we still need to investigate the PowerUsageAdvanced re-create case
Bug: 271380711
Test: presubmit & manual
Change-Id: I7629de89d9d23b08fc82369e1f9f79081e99625a
This page will no longer be there in U, all these entries will be in
More Security Privacy page.
Removes the xml, and redirects the intent to the new More Security
Privacy page.
Bug: 263038547
Test: manually tested
Change-Id: Ib6dad47f79cdaadeff94c640e2001c59a0d8e233
Apps > Special App Access > Manage Full Screen Intents > App Specific page
Follows new Settings Platform Architecture that the Settings team
is migrating to for UDC.
Bug: 243421660
Test: make SettingsGoogle -j40
adb install -r out/target/product/$TARGET_PRODUCT/system_ext/priv-app/SettingsGoogle/SettingsGoogle.apk
Change-Id: Id2ca18480ddf788bee18b67a3689ef9593059a24
The activity which instructs the user to set up face or fingerprint unlock before setting the watch unlock
Bug: 264813445
Bug: 264962961
Test: make RunSettingsRoboTests ROBOTEST_FILTER=ActiveUnlockRequireBiometricSetupTest
Change-Id: I556c62b6b8102f6e15045a37cf506c0c0eedf733
Created a new MoreSecurityPrivacyFragment, a new
more_security_privacy_settings xml.
This more_security_privacy_settings xml is a created by merging
privacy_advanced_settings.xml and security_advanced_settings.xml and the
MoreSecurityPrivacyFragment is created by merging
PrivacyDashboardFragment and SecurityAdvancedSettings fragments.
Test: adb shell am start -a com.android.settings.security.MORE_SECURITY_PRIVACY_SETTINGS
Bug: b/261557620
Change-Id: I8729f4eaf25a31f91354383e7b6cb5e0fc7df976
This was previously added in I875fa6d112db23273026dbc39b5d32748d7e99f1 to match boot animation orientation. But the first system orientation after boot is no longer influenced by FallbackHome and instead is influenced by the default rotation in DisplayRotation#readDefaultDisplayRotation so it should be safe to remove this restriction.
On the other side, if we keep this restriction it can lead to orientation flickering on devices that have ignoreOrientationRequest enabled since "nosensor" is respected on them unlike other orientations so it's possible that FallbackHome and launcher orientations won't match.
Fix: 264329911
Test: manual
Change-Id: I688a4ba3d81c1fe908b9f88c3d601aaccc4f2119
The entry should be hidden if the RUN_LONG_JOBS can't be toggled.
Bug: 255821578
Test: atest AppFilterRegistryTest
Test: make -j RunSettingsRoboTests \
ROBOTTEST_FILTER="LongBackgroundTasksDetailsTest|
LongBackgroundTasksDetailsPreferenceControllerTest"
Test: Manually check the Settings page
Change-Id: Ib1c58d93b40afefdf3ca666c661e213d01c542c6
Root cause: The IT admin dialog cannot be launched by framework features.
Solution: Allow framework features can launch the IT admin dialog to align the setting preference experience.
Bug: 254223085
Test: atest AccessibilityShortcutChooserActivityTest
Change-Id: I1c0ce8244d874049cc2799c580b2f79ece85d32d
KeyguardQuickAffordanceProvider has started to be used for more than
just lock screen shortcuts. This collection of CLs updates its name,
authority, and table schema to become more generically about "system UI
customization".
Fix: 262879277
Test: manually verified Settings > Display > Lock screen shows the
"shortcuts" item
Test: manually verified that the Wallpaper picker properly renders the
preview and can change the quick affordances
Test: manually verified that system UI displays the right lock screen
shortcuts
Change-Id: Idc0765a8c3fe50c82689d2ca7f9d19b41a62baf2
Merged-In: Idc0765a8c3fe50c82689d2ca7f9d19b41a62baf2
KeyguardQuickAffordanceProvider has started to be used for more than
just lock screen shortcuts. This collection of CLs updates its name,
authority, and table schema to become more generically about "system UI
customization".
Fix: 262879277
Test: manually verified Settings > Display > Lock screen shows the
"shortcuts" item
Test: manually verified that the Wallpaper picker properly renders the
preview and can change the quick affordances
Test: manually verified that system UI displays the right lock screen
shortcuts
Change-Id: Idc0765a8c3fe50c82689d2ca7f9d19b41a62baf2
This requires the user to pass into the package name, which enabling
the feature of navigating to app info pages.
Bug: 263553430
Test: Manually with Settings
Change-Id: I9405e3732d99f78cd87e62d73b0c9519a8e2d71f
- Move TetherSettings to network/tether folder
- Refine unit tests
Bug: 237273138
Test: manual test
make RunSettingsRoboTests ROBOTEST_FILTER=TetherSettingsTest
Change-Id: I1eb79780df824c575e79047bdeb3a9276f061fe9
This reverts commit 7a231eaba0.
Reason for revert: Adding in fix for issue that caused initial revert
Change-Id: I395c13fb46fc570a6b8a663d4b4e5537866325ce
Autofill is evolving into CredMan which means we need
to update the settings to have CredMan providers.
This CL adds CredMan equivalent classes to list the
Credential Manager providers and allow the user
to select a number of providers.
Test: Manual & atest SettingsUnitTests & make RunSettingsRoboTests -j
Bug: 253157366
Change-Id: Ice76187cfee91d844d211205b44b661acf2f6a44
Support for Full Disk Encryption was removed in Android 13, since now
File Based Encryption is always used instead. It turns out that I
missed a fairly large chunk of obsolete code: EncryptionInterstitial,
which is the screen that asks whether the device will require the
primary user's lockscreen credential when it starts up. This used to be
shown when setting the primary user's lockscreen credential, to
determine whether the full-disk encryption key would be tied to that
lockscreen credential or not. But now it's unused code.
This CL removes all this unused code.
This should not change any behavior, with one very minor exception:
Settings will no longer explicitly set the REQUIRE_PASSWORD_TO_DECRYPT
setting to 0 whenever the primary user's lockscreen credential is
changed. (This happened in SaveChosenLockWorkerBase.) This setting is
a @SystemApi, but it no longer has any meaning, since it is never set to
1 anymore. If there is a reason to keep it explicitly set to 0, instead
of unset, we should make LockSettingsService in system_server set it.
Test: Went through SUW, set a PIN, cleared the PIN, set a PIN again (all
using the UI). Nothing unusual seen.
Bug: 208476087
Change-Id: I039cc7a284e3f43e1e284970a5869958c909d1b7
This is not a design which could resolve the issue, but try to improve
it through reducing the time blocking on BroadcastReceiver and reducing
the happening of ANR.
Bug: 262209170
Test: local and auto
Change-Id: Idec4da3d1deaffb121a5c7a73aeb84b4b0331374
This is in Display > Lock screen. It reads "Buttons" and the summary
text below it is a comma delimited list of the names of the
currently-selected quick affordances.
Fix: 256662519
Test: Manual verification that the lock screen and wallet
items are gone and the new item is visible and clicking it opens the
Wallpaper & style settings screen
Change-Id: If3746b5d0eb8c61edb9378cdb217ca248b999944
