This was made implicit which is confusing for the user so this CL
adds a preference to make the user manually choose their security
type.
Test: robotests
Fixes: 79435112
Change-Id: Ie78806e8952b52e1b7cd21f0b87c9d064acaff64
Merged-In: Ie78806e8952b52e1b7cd21f0b87c9d064acaff64
Add a switch to make logical camera as default camera (with smaller
camera id) for 3rd party app.
Test: Manually using Settings app, RunSettingsRoboTests
Bug: 77600932
Change-Id: I86c7f3b9830fb376b324621feb31cdfac59faee5
Merged-In: I86c7f3b9830fb376b324621feb31cdfac59faee5
This was made implicit which is confusing for the user so this CL
adds a preference to make the user manually choose their security
type.
Test: robotests
Bug: 79435112
Change-Id: Ie78806e8952b52e1b7cd21f0b87c9d064acaff64
The cache in ApplicationsState is causing a lot of damage because AS
object is not smart enough to invalidate the cache in all conditions. So
we end up having bugs like stale app label or icon in weird cases.
This change stops using the cache when loading app icon in entity
headres. This is only a stop gap solution to fix most visible (and most
frequently complained) parts of the page. We still need to address the
cache in ApplicationsState eventually.
Change-Id: Iea88ad99d4069d678d09943cfb0b0e5c94eb3326
Fixes: 79881693
Test: robotests
Add a switch to make logical camera as default camera (with smaller
camera id) for 3rd party app.
Test: Manually using Settings app, RunSettingsRoboTests
Bug: 77600932
Change-Id: I86c7f3b9830fb376b324621feb31cdfac59faee5
When restrict tip update, we should also update app list unless it goes
from NEW to INVISIBLE. After that it won't show "0 apps been
restricted".
Change-Id: Iedf4288fcddfe632a9ba8c16afdfb5bc044bce2e
Fix: 79890132
Test: RunSettingsRoboTests
* For fix the "Automatic merge failed" in pi-dev, cherry pick the ag/4036738 in
master. Change android.support.* to androidx.*
* Add AdvancedConnectedDeviceController that used to show which component is available
* Add getConnectedDevices Summary Resource Id() to decide which string should be shown.
Here have 4 cases to shown the string.
case 1: driving mode available and NFC is availalbe, show "Bluetooth, driving mode, NFC"
case 2: driving mode available and NFC is not availalbe, show "Bluetooth, driving mode"
case 3: driving mode not available and NFC is availalbe, show "Bluetooth, NFC"
case 4: driving mode not available and NFC not availalbe, show "Bluetooth"
* Add test to verify the summary string is correct in each condition
* Add test to verify getAvailabilityStatus() is AVAILABLE.
Bug: 79299421
Test: make -j50 RunSettingsRoboTests ROBOTEST_FILTER=AdvancedConnectedDeviceControllerTest
Change-Id: I1048355bbd344db3ab645dd1537b4259eff57f38
* Add AdvancedConnectedDeviceController that used to show which component is available
* Add getConnectedDevices Summary Resource Id() to decide which string should be shown.
Here have 4 cases to shown the string.
case 1: driving mode available and NFC is availalbe, show "Bluetooth, driving mode, NFC"
case 2: driving mode available and NFC is not availalbe, show "Bluetooth, driving mode"
case 3: driving mode not available and NFC is availalbe, show "Bluetooth, NFC"
case 4: driving mode not available and NFC not availalbe, show "Bluetooth"
* Add test to verify the summary string is correct in each condition
* Add test to verify getAvailabilityStatus() is AVAILABLE.
Bug: 79299421
Test: make -j50 RunSettingsRoboTests ROBOTEST_FILTER=AdvancedConnectedDeviceControllerTest
Change-Id: I1048355bbd344db3ab645dd1537b4259eff57f38
Merged-In: I1048355bbd344db3ab645dd1537b4259eff57f38
For settings which can change in the framework, outside of
the settings app and a slice, a Slice needs to be able to
register a listener for these changes.
Adding a getter for an IntentFilter in BasePreferenceControllers
allows us to use the SliceBroadcastRelay in SysUi to listen for
these changes.
Test: robotests
Fixes: 78138654
Change-Id: I579375069ca98fd21b60cd3a69c1a122cabf96e2
Merged-In: Ifa05b651aaa3458c54866f71469964b1a070e458
For settings which can change in the framework, outside of
the settings app and a slice, a Slice needs to be able to
register a listener for these changes.
Adding a getter for an IntentFilter in BasePreferenceControllers
allows us to use the SliceBroadcastRelay in SysUi to listen for
these changes.
Test: robotests
Bug: 78138654
Change-Id: Ifa05b651aaa3458c54866f71469964b1a070e458
* Add PreviouslyConnectedDevicePreferenceController to handle the preference should be
enable or disable.
Example: If there are no previously connected devices disable the preference otherwise
enable it.
* Add PreviouslyConnectedDevicePreferenceControllerTest
1. Verify the callback can be registered and unregistered
2. Verify the preference is enable when there
have more than 1 previously connected device
3. Verify the preference is disable when there
have no previously connected device
Bug: 78250052
Test: make -j50 RunSettingsRoboTests
Change-Id: I31b5d416aaf907c3bbf1cb61de6e7401463e3df7
Merged-In: I31b5d416aaf907c3bbf1cb61de6e7401463e3df7
Add DND Slice as a special case, since there is an existing
inheritance structures in the zen mode preference controllers which
would be too risky to change at this point in the release.
Change-Id: If4b7013be35c89695786af2dbbea2edcf7a189f3
Merged-In: Ice608b9a7bd6f38b73e581eb3723f0a2fae96f2b
Test: make RunSettingsRoboTests
Fixes: 67997377
Add DND Slice as a special case, since there is an existing
inheritance structures in the zen mode preference controllers which
would be too risky to change at this point in the release.
Test: make RunSettingsRoboTests
Bug: 67997377
Change-Id: Ice608b9a7bd6f38b73e581eb3723f0a2fae96f2b
Before this CL, we will drop log for excessive bg anomaly that
target O or higher. This CL doesn't drop it however merge it to
ACTION_ANOMALY_IGNORED
Bug: 79944380
Test: RunSettingsRoboTests
Change-Id: I46d0bdb1191d8843ba373e59afb1b0ba16057661
When airplane mode is off, fall back to default summary
(tether off summary). It should be fine because once tether
state get updated again, it will go through original listener
to update the summary.
Change-Id: Iba9b56f452e72365ea964d841ee156a2625c0ae1
Fixes: 79721162
Test: RunSettingsRoboTests
Add a custom Wifi Slice to the Settings Slice Provider.
It needs a custom Slice because of the complicated listener logic
in the MasterSwitchPreferenceController, which makes it hard to
work-in synchronous set/get logic.
The one-off Slice requires extra changes, including:
- Including it in getDescendants
- Handling changes to wifi by the framework
This is the first change that uses SettingsLib's broadcast relay,
which allows settings to (un)register IntentFilters to a Uri,
allowing Settings Slices affected by the framework (quicksettings,
connectivity related, volume, etc) to be updated without action
on the Slice.
Bug: 70622039
Bug: 67997332
Test: robotests
Change-Id: Ibfe4736beecb833e3f6bb871b2eb5228a5fd3a34
Add a custom Wifi Slice to the Settings Slice Provider.
It needs a custom Slice because of the complicated listener logic
in the MasterSwitchPreferenceController, which makes it hard to
work-in synchronous set/get logic.
The one-off Slice requires extra changes, including:
- Including it in getDescendants
- Handling changes to wifi by the framework
This is the first change that uses SettingsLib's broadcast relay,
which allows settings to (un)register IntentFilters to a Uri,
allowing Settings Slices affected by the framework (quicksettings,
connectivity related, volume, etc) to be updated without action
on the Slice.
Fixes: 70622039
Fixes: 67997332
Test: robotests
Change-Id: Ia76738dd6baacd5522d52df2c61ebad86a600282
Merged-In: Ibfe4736beecb833e3f6bb871b2eb5228a5fd3a34
