The wifi service already handles turning off tethering if
multi-interface is/isn't supported. We don't need to do tie wifi
and tethering stuff together in the UI.
Test: robotests still pass
Bug: 79213401
Change-Id: I699dfe2d7646f248a54faa5a8429176697614cdf
Even though onStopJob is called, the service may still exist, so
we need to reset the mIsJobCanceled in onStartJob
Also remove the batteryStats since we don't need it anymore.
Change-Id: I6d48efecb750ad4e464569cac426d87014a8db90
Fixes: 77968649
Test: RunSettingsRoboTests
- Add connected hearing aid device to MediaOutputPreferenceController
and HandsFreeProfileOutputPreferenceController
- Set active device to different profile depend on HisyncId
Bug: 78142719
Test: make RunSettingsRoboTests ROBOTEST_FILTER="MediaOutputPreferenceControllerTest" -j28
Test: make RunSettingsRoboTests ROBOTEST_FILTER="HandsFreeProfileOutputPreferenceControllerTest" -j28
Test: make RunSettingsRoboTests ROBOTEST_FILTER="AudioOutputSwitchPreferenceControllerTest" -j28
Change-Id: Ib8fe4f06f8564572dffdce6fcc3f29578bf91bd9
Distinguish between settings which are permanently unavailable on
the device, and temporarily unavailable. This enables us to restrict
which setting slices are exposed in onSliceGetDescendants.
The primary changes in this CL are renaming:
"DISABLED_UNSUPPORTED" -> "UNSUPPORTED_ON_DEVICE"
to be more clear the the setting will cannot be accessed on the device, and,
adding a new enum to encapsulate settings which are currently unavailable, but
could be enabled in the future.
Also remove UNAVAILABLE_UNKNOWN. Devs should never need this enum.
Bug: 78910582
Fixes: 79245656
Test: robotests
Change-Id: I42c2cedab66be2d76999795f46470a079cc1ec71
Merged-In: I58821a6cfd6134b3b351657b6edf5f74ead00643
The keywords used for settings search are good when we are highly
confident the user is searching for as setting (settings search),
but not effective in a more general search setting (launcher,
an assistant). Thus, we should not index these keywords as Slice
keywords, and rely on the setting title and screen title as baseline
keywords.
Change-Id: I99e44834454b5949c4883f877e02be47498e06e2
Fixes: 78911847
Test: robotests
Distinguish between settings which are permanently unavailable on
the device, and temporarily unavailable. This enables us to restrict
which setting slices are exposed in onSliceGetDescendants.
The primary changes in this CL are renaming:
"DISABLED_UNSUPPORTED" -> "UNSUPPORTED_ON_DEVICE"
to be more clear the the setting will cannot be accessed on the device, and,
adding a new enum to encapsulate settings which are currently unavailable, but
could be enabled in the future.
Also remove UNAVAILABLE_UNKNOWN. Devs should never need this enum.
Bug: 78910582
Bug: 79245656
Test: robotests
Change-Id: I58821a6cfd6134b3b351657b6edf5f74ead00643
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
Merged-In: Id168911b082fffac193cd7c7a658ab92d6ce2c15
Change-Id: I0a3a4ec4dda78e28ee88a11d383eda49e9cf50a6
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
onGetSliceDescendants would return empty results if
the call was made before the database was indexed.
This CL checks the index before building the list.
Change-Id: I2e0f88893138a048dbd529d465d68fa4b1a3dc12
Fixes: 78196823
Test: robotests
Replace all SettingsLib/PackageManagerWrapper in Settings,
by PackageManager,
Remove ShadowPackageManagerWrapper.
Bug: 62067063
Test: make RunSettingsRoboTests
Change-Id: I6d1af55c13d80c1907b98b21e0207cc903cd9b1f
- Remove dummy preference from trust_agent_setting.xml.
- Build a controller to generate/manage a list of preferences.
- Move some logics to the controller and add tests.
Bug: 73899467
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.security
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.core
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.search
Test: atest SettingsGatewayTest UniquePreferenceTest
Change-Id: Ideae0c1e7311d7647cf522e01592822e565a0ff7
Attach the keywords used for Settings search to Slices.
Their primary use is helping match synonyms for presenters
which display slices without explicit Uri requests, like a launcher.
This changes:
- Updates database scheme
- Adds to SliceData object
- Grab keywords in the SliceDataConverter
- Set keywords on all slices
Test: robotests
Change-Id: I16c40d2380ffddaf0a87fb1b9cd58e95573b308f
Fixes: 78306195
Managed profiles cannot completely hide notifications, so
this setting should be treated as always "true" for them.
Change-Id: I9808c1e9736d83efccb0e947d9097379bda59ebb
Fixes: 78194020
Test: atest RedactionInterstitialTest
- Build a controller to generate a list of preferences and add to screen.
- Move some logic to controller.
- Add some test cases for controller.
Test: manual
Test: make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.inputmethod
make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.core
make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.dashboard
atest UniquePreferenceTest
Change-Id: I4ebe486ade3439b9814b11866c402dcf881f21a7
- Remove isWiredHeadsetOn() and isBluetoothA2dpOn()
in MediaOutputPreferenceController.
- Remove isWiredHeadsetOn() and isBluetoothScoOn()
in HandsFreeProfileOutputPreferenceController.
- Replace with AudioManager.getDevicesForStream().
- Update test cases.
Bug: 78141441
Test: make RunSettingsRoboTests ROBOTEST_FILTER="MediaOutputPreferenceControllerTest" -j40
Test: make RunSettingsRoboTests ROBOTEST_FILTER="HandsFreeProfileOutputPreferenceControllerTest" -j40
Test: make RunSettingsRoboTests ROBOTEST_FILTER="AudioOutputSwitchPreferenceControllerTest" -j40
Change-Id: Ic57c40badf0fd5633f1b7412d63a0b5417d0f47a
When a slice becomes unavailable, it should not update the
underlying data even if the view has not changed.
When we receive a change from an unavailable slice, notifychange
on the Uri and do not change the underlying data.
Change-Id: I91851ab668e4aece669fd65c14e0dc4ec2edefdf
Fixes: 77980406
Test: robotests
- Build two controller to control list preferences.
- MediaOutputPreferenceController which allows switching
the media output between current device and connected
BT device supporting A2DP. It also controls disabling
media output switching during a call or cast mode.
- HandsFreeProfilePreferenceController which allows
switching between HFP-connected BT devices while in
on-call state.
- Add test cases for controllers.
Bug: 74130772
Test: make RunSettingsRoboTests ROBOTEST_FILTER="MediaOutputPreferenceControllerTest" -j56
Test: make RunSettingsRoboTests ROBOTEST_FILTER="HandsFreeProfileOutputPreferenceControllerTest" -j56
Test: make RunSettingsRoboTests ROBOTEST_FILTER="AudioOutputSwitchPreferenceControllerTest" -j56
Change-Id: I37f5418442ce77e72cdff07f071ea519ab1047f3
* Implement available media devices group
* Add AvailableMediaDeviceGroupController to realize UI, the user can see the all device that can be activated in this group.
* ConnectedDeviceGroupController change to show the device that cannot be activated but is connected.
* Refactoring the below class, implement the controller in connected_devices.xml.
ConnectedDeviceGroupController.java
SavedDeviceGroupController.java
ConnectedDeviceDashboardFragment.java
connected_devices.xml
* Add AvailableMediaBluetoothDeviceUpdaterTest to verify the add/remove preference behavior when connectedStateChanged or profileAudioStateChanged
* Add test that used to verify device is connected or not in BluetoothDeviceUpdaterTest.
* Add test that used to verify the add/remove preference behavior when connectedStateChanged or profileAudioStateChanged in ConnectedBluetoothDeviceUpdaterTest.
* Add AvailableMediaDeviceGroupControllerTest to verify bluetooth feature is supported or not and test register callback.
* Add test that used to verify bluetooth feature is supported or not and test register callback in ConnectedDeviceGroupControllerTest.
* Add test that used to verify bluetooth feature is supported or not and test register callback in SavedDeviceGroupControllerTest
Bug: 74134939
Test: make -j40 RunSettingsRoboTests
Change-Id: I54d03c2ddadc6a4be7519dd74cdbcb5055d44083
PendingIntents were being cached because they had the same
targets and would not differentiate on extras - thus all Slice
intents would go to the same destination as the first intent fired.
Adding the data stops the system from caching the intents.
Change-Id: Ifccab72ed482e22750422c5c36aa6d205c20ae3d
Fixes: 77650727
Test: robotests
In the change to mark disabled_dependent as available,
it did not change the check in SliceBuilderUtils for the
unavailable Slices. In the case of DISABLED_DEPENDENT, the
setting is available but the Slice is not.
Though it is a simple change, we can now properly test the contents
of Slices, so this change includes tests which should have been in
place earlier and would have caught this bug - duh.
Bug: 71640747
Test: Robotests
Change-Id: I8db5bc80edb337cbf907ce3669aa2bfd9c72f74a
- earlier changes were made to the intent flags when creating new
settings shortcut to ensure that it is launching a new task. However,
ShortcutManager is actually caching existing shortcut info, and it will
continue to use the existing shortcut info unless we explicitly update
the info.
- when rebooting from build upgrade, we will go through all existing
shortcut to update the launch intent flags to ensure that the shortcut
info is update to date.
Change-Id: Iee2365d9aec64a47b193e3c9be443c252504815b
Fixes: 76395879
Test: make RunSettingsRoboTests
For obvious bootstrapping reasons, DNS settings have always used
IP address string literals in input fields.
However, since we can use the network-assigned nameservers to bootstrap
our way to multiple IP addresses of multiple families (!), hostnames
provide a clear simplicity and future-proofing advantage.
Permitting IP address literals means not only making sure that we can
validate X.509v3 certificates for IP addresses, but coping with the
inevitable broken configurations where users may have configured IPv4
addresses but no IPv6 addresses. This will unnecessarily complicate
life on IPv6-only networks.
=)
Test: as follows
- built
- flashed
- booted
- tried to enter IP string literals
- make -j50 RunSettingsRoboTests ROBOTEST_FILTER=PrivateDnsModeDialogPreferenceTest
Bug: 34953048
Bug: 64133961
Bug: 73641539
Change-Id: I7a58e86ed640ff5600906fb3d8cb9a2c75598831
