- remove duplicate index preference
- default set searchable = false when the preference has fragment
- make some fragments indexable
Bug: 143057584
Test: robotest & manual
Change-Id: I4d64f6106d2f92f0a45e8c7e26388677f593f412
This CL before, the lambda callback is different it cause
callback didn't unregister.
If you re-enter bluetooth detail page many times,
onDeviceAttributesChanged() will be called many times cause UI not
smooth.
This CL remove the lambda callback and show the UI when device
connected.
Fixes: 141583252
Test: Manual
Change-Id: Icd3e84b2d461d9b949f080269dfa2bb5b5d5cb73
This CL uses onProfileConnectionStateChanged() to handle
the case that bonded device is connected in pairing list.
1. Finish BluetoothPairingDetail page if the bonded device is connected
and selected.
2. Remove the devices in BluetoothPairingDetail page if the device is
connected.
Bug: 142519901
Test: make -j42 RunSettingsRoboTests
Change-Id: I51a9f2ebc0b491edb8ea026ff62ec20ae91eee1d
Finish the activity after call super.onAttach().
Bug: 143187915
Test: make -j42 RunSettingsRoboTests
Change-Id: I8f205ef60797bd9eb96617d413f554613008f65b
The issue happens when users are toggling slices. Sometimes the toggle
doesn't work as expected because the pending intent of the toggle action
seems to be canceled for some reasons.
Hence, we replace FLAG_CANCEL_CURRENT with FLAG_UPDATE_CURRENT to prevent from
getting PendingIntent.CancelExcpetion from SliceActionView when toggling
slices.
Note that this change would only apply on Wifi, MobileData, Flashlight
and Bluetooth Slices.
Bug: 140719905
Test: rebuild and switch toggles
Change-Id: Iddbb16ddcbcf97b6f6e680b43645c04fbc061f39
- Use SettingsLib Indexable
- Directly use resource id in getPreferenceScreenResId
Bug: 135053028
Test: roboletric
Change-Id: I05f493b55e8b6e2091301e9231ba5615215618e6
This CL added null check for the case that dialog
is started from adb command.
Bug: 129783237
Test: manually
Change-Id: I47d47cb5ddfe3487e2d616d1cf2ed08bd11d215d
Fixes: 124129485
Test: manual test
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.core
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.SettingsPreferenceFragmentTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.bluetooth
Change-Id: I920d0de403b9c7109de0e2e53be7ed99bc8e7390
- If first summary is unavailable, not to show second summary.
Bug: 132409181
Test: make -j42 RunSettingsRoboTests
Change-Id: I0d2e426b15dae8ed38e0a1b5a9219209e1a0026c
Before this CL, we didn't consider the case of two
preferences timestamp are the same.
If 2 preferences timestamp are the same, the second preference
will first out. it will cause test case will fail some times.
In this CL, if two BluetoothDevicePreference's timestamp are the same,
The first BluetoothDevicePreference is first out.
Bug: 138547532
Test: make -j42 RunSettingsRoboTests
Change-Id: I7366275e8edf615c582481a570ea0c25b8d37a66
- Removed the FooterPreferenceMixin from the BluetoothDetailsMacAddressController.
- Added the common api addFooterPreference.
Fixes: 139104386
Test: manual test
Test: make RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.bluetooth
Change-Id: Iab40fa4c5be674290b1dc6d372c84609ccc2ea49
Add two type SortType.TYPE_DEFAULT and SortType.TYPE_FIFO in BluetoothDevicePreference.
It needs to decide the sort type when you create the BluetoothDevicePreference.
TYPE_DEFAULT - According to the CacheBluetoothDevice state to sort
TYPE_FIFO - According to the timestamp to sort
Bug: 112546918
Test: make -j42 RunSettingsRoboTests
Change-Id: Icd25d9b76a44d5a105f8daf64e5bc1f9ead8cd92
- Move PreferenceGroup init method out of isAvailable() condition,
then PreferenceGroup will not be null.
- Update getAvailabilityStatus(), since the controller now may have usb
and dock.
Bug: 110712414
Test: make -j42 RunSettingsRoboTests
Change-Id: I4d85a42c26fb20d319e7321177b271933be3fdb0
The issue is happened when BT is disabled then navigate to
"Connected devices". BluetoothDeviceUpdater didn't update
UI when BT is disabled. Remove all device from preference when
BT is disabled.
Bug: 80090956
Test: make -j42 RunSettingsRoboTests
Change-Id: Ia1fd8cfbcf95d712a1a702fdf101ff98186b76cd
* Align with the changes of Bluetooth metadata APIs.
* Move metadata utils from Settings to SettingsLib.
Bug: 124448651
Test: make RunSettingsRoboTests
Change-Id: Ic9ad91536ef3ff6807a08bbffa3dd796ef1ad523
If we recycle it in OnStop() and this page isn't destoried,
it will crash when we revisit it.
Fixes: 130185099
Test: RunSettingsRoboTests
Change-Id: I4d3c1c12debcccb1ee7d676a1c5accece0b42e09
Usecase:
1. Start advertising from DUT (using BLE Smartertooth app).
2. Scan and connect from central device.
3. Now initiate bond from central and accept pairing request.
(Consent Pairing Dialog will be shown on DUT)
4. Notification will be received for PASSKEY CONFIRMATION Dialog.
Do not open notification and let it timeout.
5. Repeat steps 2 and 3. At step 3, Passkey Confirmation pairing
dialog is show instead of Consent pairing dialog.
Issue:
Wrong Pairing Popup is shown. Passkey Confirmation pairing
dialog is show instead of Consent pairing dialog.
Reproducible Rate: 100%
Root Cause:
PendingIntent created for showing pairing notification are getting
reused as only FLAG_ONE_SHOT is used. This flag is not updating new
extra's in the pending intent.
Fix:
Use flag FLAG_UPDATE_CURRENT in pending Intent.
Test: Tested above mentioned testcase and pairing scenarios.
Fix: 129479787
Bug: 129456113
Change-Id: I46813f355cd796cee1b472774b494c8580b39784
