- Keep launching notification settings in the Settings task. This is not
the expected behavior, but only a workaround until b/72420153 is
fixed.
Bug: 72420153
Test: Enter PIP, go to app > notifications > additional settings, ensure
that it doesn't start in the PIP task
Change-Id: I73e704a283285462d4884db21923818cfb6deead
- Added a footer in feature flags, displaying "Experimental" during
onStart.
- Ui test to verify the text shows correctly.
Change-Id: Ibf4f79cb3c12e460384e83201a16005a18d6437d
Fixes: 78887450
Test: atest
- Add null check for the package info when trying to retrieve the
install app state. During package update, the package info might becomes
null. The App info activity will finish in that case, but this method
might be called before the activity actually finishes.
Change-Id: I18ff448666dfb403bb6693fccd3e54276db36f37
Fixes: 78257414
Test: make RunSettingsRoboTests
- Move preference related logic to controllers.
- Add some test cases for controllers.
Test: manual
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.nfc
make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.core
atest SettingsGatewayTest UniquePreferenceTest
Change-Id: I061a194c170f63fab51974f26c24be43d67d6f6f
Developer options page crash for restricted users because the page
removes all preferences while DashboardFeatureProvider tries to
manipulate preferences on screen.
Added a null check to skip changin prefs in DashboardFeatureProvider
because the pref is going to be removed either way.
Change-Id: Ic83fd0dfb2a906605fb1d992d7b36c2163630e89
Fixes: 78655710
Test: robotests
As of ag/3932176 the slice indexer now queries getSummary() for each
controller. So we need to create all necessary objects before
getSummary(). In this case, the PSCD object.
Change-Id: I0162996be37d740f1e450880bf4698acd94ca0ad
Fixes: 78897071
Test: atest
Rather than check for the state of the work profile in
LockScreenNotificationPreferenceController#handlePreferenceTreeClick, do so in
the RestrictedListPreference#performClick.
The drawback of checking the state in handlePreferenceTreeClick is that the
preferences are displayed first and then the requirement to unlock/enable the
work profile is displayed on top of it.
This is rather poor UX, so switch to doing the check in performClick and
returning early if the work profile needs to be unlocked/enabled.
This is similar to Patchset 1 from ag/3805482.
The main difference is that the user is returned to the settings screen
both after enabling the work profile and unlocking it.
Test: Manually with TestDPC
Test: atest SettingsRoboTests:RestrictedListPreferenceTest
Bug: 77408805
Change-Id: Id168911b082fffac193cd7c7a658ab92d6ce2c15
- Build a controller to generate/manage a list of preferences.
- Move some logics to the controller and add tests.
- Rename to ChooseAccountFragment.
Bug: 73899467
Test: make RunSettingsRoboTests -j
atest UniquePreferenceTest SettingsGatewayTest
Change-Id: Id2906c4b922ef159d08c803b976671264c54665f
* For fix the conflicts in pi-dev, cherry pick the ag/3944480 in
master and merge the conflict.
* Remove the gear icon in "currently connected" section.
* Change the tapping event in "currently connected" section.
When tapping device in this section, take user to device detail page.
* Add test to verify when ConnectedBluetoothDeviceUpdater add preference
the shouldHideSecondTarget() is return true.
Bug: 78490845
Test: make -j40 RunSettingsRoboTests
Change-Id: I25f8455def3c38e24dea9af9e9e29ba37c250f67
