Use different source metric categories to distinguish different launch sources of the BluetoothPairingDetail page.
Bug: 237344016
Test: manual
Change-Id: If762e87414055f3e497f99ea6885f7736b7193cd
At the media device, it only shows the active LE device which is
connected.
Bug: 232892046
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AvailableMediaBluetoothDeviceUpdaterTest
make RunSettingsRoboTests ROBOTEST_FILTER=ConnectedBluetoothDeviceUpdaterTest
make RunSettingsRoboTests ROBOTEST_FILTER=SavedBluetoothDeviceUpdaterTest
Change-Id: Iac661206def4d43bc40ab9bb1938f084926899c2
The provided uri doesn't contain the formatted string, so just append
the width at the end
Bug: 229048602
Test: make -j64 RunSettingsRoboTests
Change-Id: Idadbb4d725c8ca65bac31fbead8ac1d429ebcea9
The "phone calls" uses the Headset profile, not HFP profile. The ui
uses the wrong profile. It causes the "phone calls" is always enabled
when LE is enabled.
Bug: 231511825
Test: build pass
Change-Id: Ib507352107c0d825b8c7a9605713bc9083259fbd
Merged-In: Ib507352107c0d825b8c7a9605713bc9083259fbd
The "phone calls" uses the Headset profile, not HFP profile. The ui
uses the wrong profile. It causes the "phone calls" is always enabled
when LE is enabled.
Bug: 231511825
Test: build pass
Change-Id: Ib507352107c0d825b8c7a9605713bc9083259fbd
* Pop up dialog in 'Connected deivce' page and 'Accessibility -> Hearing
aids' page
Bug: 225117454
Bug: 226511985
Test: make RunSettingsRoboTests ROBOTEST_FILTER=HearingAidPairingDialogFragmentTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AvailableMediaDeviceGroupControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AccessibilityHearingAidPreferenceControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=HearingAidUtils
Change-Id: I34a1e3ac680a7efe97dc501bfbe93f840ad16364
* changes:
Add 'Live Caption' preference for hearing aids device in Device details page
Update summary in Accessibility -> Hearing aids
Header for hearing aids now listed in one summary
If the sink device has connected the broadcast source, then the device
should initialize the sourceId and create the sourceId's preference UI.
Bug: 231576575
Test: manually test
Change-Id: I24d9e6d4c78dc4e583c5253e552456a68b1114c3
Systemui memory regression, so we have to move the qr code activity back to Settings
Bug: 228031398
Test: manual
Change-Id: Ic30291e6d752c6c770c40e1329d9f95ceec8cca6
aosp/2093046 cancels bonding unconditionally in onDestroy(), this
results in the user not being able to pair when the pair button is
pressed because onDestroy() is also called in that case.
Only cancel bonding if the user did not press the pair button.
Bug: 231554812
Test: Changed settings app is able to scan after dismissing the dialog
and is also able to pair when the pair button is pressed
Change-Id: I868af9b795f1bb0766656e4619bd06dc8028008a
Merged-In: I868af9b795f1bb0766656e4619bd06dc8028008a
aosp/2093046 cancels bonding unconditionally in onDestroy(), this
results in the user not being able to pair when the pair button is
pressed because onDestroy() is also called in that case.
Only cancel bonding if the user did not press the pair button.
Bug: 231554812
Test: Changed settings app is able to scan after dismissing the dialog
and is also able to pair when the pair button is pressed
Change-Id: I868af9b795f1bb0766656e4619bd06dc8028008a
When pairing dialog is dismissed using the back gesture, we do not call
cancelBondProcess() for the remote device. Since bonding is not
cancelled and the dialog is dismissed, when the user tries to pair again
and scans for devices, nothing shows up. This is because in case of a
pending bond or pending SDP, the request to search for new devices is
queued.
The correct behavior is to cancel bonding if the pairing dialog is
dismissed using the back gesture. This is similar to what
happens when the pairing dialog is dismissed using the cancel button.
Bug: 231554812
Test: Changed settings app is able to scan after dismissing the dialog
Change-Id: Ia790e345be811be1b60762ff819544d03c5a18fd
Merged-In: Ia790e345be811be1b60762ff819544d03c5a18fd
When pairing dialog is dismissed using the back gesture, we do not call
cancelBondProcess() for the remote device. Since bonding is not
cancelled and the dialog is dismissed, when the user tries to pair again
and scans for devices, nothing shows up. This is because in case of a
pending bond or pending SDP, the request to search for new devices is
queued.
The correct behavior is to cancel bonding if the pairing dialog is
dismissed using the back gesture. This is similar to what
happens when the pairing dialog is dismissed using the cancel button.
Bug: 231554812
Test: Changed settings app is able to scan after dismissing the dialog
Change-Id: Ia790e345be811be1b60762ff819544d03c5a18fd
