This reverts commit 08f2a58459.
Reason for revert: design changed, we decide to take the user to
the entry after clicking on a search result.
It's opposite with what we did, so we revert related CL first.
Test: robotest
Change-Id: Iadb9a94a7ef7838be34a54499e2d934d6396c336
- 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 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
- Use SettingsLib Indexable
- Directly use resource id in getPreferenceScreenResId
Bug: 135053028
Test: roboletric
Change-Id: I05f493b55e8b6e2091301e9231ba5615215618e6
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
Some users forgot they had paired devices and couldn't see their BT device
when they search device in "Pair new device". (b/80382940, b/80133137).
Need to change the behavior to let paired devices can be shown on "Available devices".
Bug: 111738593
Test: Bluetooth Pairing Test
Change-Id: Ib499785abaa8e4efc1875be113ac87bdbe0c89ba
LocalBluetoothAdapter only has a few APIs that is not supported
by BluetoothAdapter, and lots of LocalBluetoothAdapter function
pass parameter to BluetoothAdapter directly.
Do the refactor in Settings, use BluetoothAdapter instead of
LocalBluetoothAdapter.
Bug: 111769754
Test: make -j42 RunSettingsRoboTests
Change-Id: I88e5a8377b5d1106c7679e6a8c3fd1ca1a80ea6f
* Shown "Bluetooth turned on" toast only when BT turned on in "Pair new device"
* Add test to verify shown toast function can be called when BT turned on.
Bug: 79383997
Test: make -j42 RunSettingsRoboTests ROBOTEST_FILTER=BluetoothPairingDetailTest
Change-Id: I25f75aaa04063d9ef8a0df4bb06aeaa70d7ac146
* Add BluetoothDeviceRenamePreferenceController in bluetooth_screen.xml
* Refactor BluetoothDeviceRenamePreferenceController and BluetoothDeviceNamePreferenceController.
Let these controllers can be init in xml.
Bug: 78247352
Test: make -j50 RunSettingsRoboTests
Change-Id: Iddd0cac1e973bbd82cb30fe4c18e8b359ba4ba2b
Only disable the controllers not the whole fragment because
user might need to have entry for other features.
Fixes: 73664409
Merged-In: I98ed248cf33d11715dd523e711cbc68ebf128ef8
Change-Id: I98ed248cf33d11715dd523e711cbc68ebf128ef8
Signed-off-by: Weilun Du <wdu@google.com>
(cherry picked from commit 68a195ae93)
getPreferenceControllers() -> createPreferenceControllers() for the same
reason as in ag/3647936
Bug: 73668763
Test: robotests
Change-Id: I97670a91a2a38d1c844d1b9d37f4222c5e6f45a0
Also refactor the preference controller
1. Extend from BasePreferenceController.
2. pass in the preference key. Then it could be reused in different
places with different key.
Bug: 69333961
Test: Screenshot | RunSettingsRoboTests
Change-Id: I773ca022baa326481045c1659565c9a21111200a
This is a clean up to action bar menu item pattern, we will use the same
pattern to build search icon on all pages in a later change.
Bug: 68814716
Test: robotests
Change-Id: Iedd3ec263e8ccb63ed75ec7a95b28c00878b1de4
There are two problems with the Bluetooth settings and pairing pages
that are fixed by this CL:
(1) We advertise on the page that the local device is visible to other
devices, but that only lasts for the length of the default timeout (120
seconds) for the local adapter being in discoverable mode.
(2) Both the BluetoothSettings and BluetoothPairingDetail fragments
enter discoverable mode in their onStart handler and exit it in their
onStop handler. Unfortunately when doing a fragment navigation the
onStart and onStop events interleave in a non-intuitive manner. When you
go from BluetoothSettings to BluetoothPairingDetail, we see the onStop
event for BluetoothSettings *after* the onStart event for
BluetoothPairingDetail, and similarly when going back from
BluetoothSettings to BluetoothPairingDetail. What this means in practice
is that if you go to the BluetoothSettings page, the device will be
discoverable, but once you navigate to BluetoothPairingDetail or back
again you won't be discoverable again until you go somewhere else or end
the settings activity.
This CL adds a new object called AlwaysDiscoverable which can be used to
start and stop a mode of "always being discoverable". While started, it
will listen for changes to the discoverable state, and return to
discoverable mode. This fixes (1) by returning to discoverable mode
whenever the normal timeout expires, and (2) similary by returning to
discoverable mode when we accidentally exit it due to the onStop/onStart
mismatch.
A better fix for (2) would be to avoid the "glitch" of briefly exiting
discoverable mode only to re-enter it, but the implementation of that is
a little more complicated so that's being left as future work in order
to keep this CL as small as possible.
Bug: 64130265
Test: make RunSettingsRoboTests
Change-Id: I559dd8187263ea6a0008be1a8abdfffac97cb87a
- xml layout clean up
- add "Device name" preference, tapping will bring up rename dialog
- Remove tap target from original device_name pref
Merged-In: I6e9764dbb6c51f94be6d6a61d5a6401141407409
Change-Id: I9cb67cc557a9b932d7cf795a8d4a6fb5215c4365
Fix: 62890841
Fix: 62891178
Test: robotests
- xml layout clean up
- add "Device name" preference, tapping will bring up rename dialog
- Remove tap target from original device_name pref
Change-Id: I6e9764dbb6c51f94be6d6a61d5a6401141407409
Bug: 62890841
Bug: 62891178
Test: robotests
* mLocalAdapter should never be null
* We should crash if it is ever null
Bug: 63442969
Test: make, pair Bluetooth device
Change-Id: If98f9ea0762927eb57d00224b62abf24bbec69ba
* Modified DeviceListPreferenceFragment to have enable/disable scanning
methods. In ENABLE state, each onScanningStateChanged(false) will
restart another round of scanning
* Subclasses of DeviceListPreferenceFragment should call enable/disable
scanning when scanning is needed for long period of time
* Currently, BluetoothPairingDetail and DevicePickerFragment call
enableScanning() when Bluetooth is turned ON and call disableScanning
when some device is picked in their lists
* Both BluetoothPairingDetail and DevicePickerFragment will re-enable
scanning if pairing failed for selected device
* Added associated unit tests as well
Bug: 32172815
Test: make, pair Bluetooth device, send file over Bluetooth Opp
Change-Id: I99325e06aadd7b00e7a7ba6d6c282a6831859d8b
This cl splits the BluetoothSettings into paired device page and
pairing page, including small changes about:
1. Refactor the pages so they could get as much as static preference
from xml file rather than dynamically add/remove them everytime.
2. Remove creating method in BluetoothDeviceNamePreferenceController
and add it in xml file
3. Create BluetoothPairingDetail page, basically move the logic from
BluetoothSettings.
4. Make pairing preference clickable and jump to BluetoothPairingDetail
5. Add and update bunch of tests
Bug: 35877041
Test: RunSettingsRoboTests
Change-Id: Ief9e9690c612f7b46c58e866e5cecc511af642c8
