Commit Graph

4 Commits

Author SHA1 Message Date
Antony Sargent
c86440538f Stay discoverable in Bluetooth settings and pairing pages
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
2017-08-09 22:10:40 -07:00
Andrew Sapperstein
9f1e911759 Refactor test runner to use static list of resource paths
Previously everything lived in an inner class method of
SettingsRobolectricTestRunner. That method has now been turned into
a static method so that it can be called by other runners.

Bug: 62460102
Test: robotests
Change-Id: I6612b1f26404587301c534c8ba60e39d59d6c840
2017-06-09 09:21:26 -07:00
Jack He
c11af01481 Bluetooth: Always scan while on pairing or DevicePicker page
* 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
2017-06-05 12:13:46 -07:00
jackqdyulei
52ccb49fbe Split BluetoothSettings into two pages
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
2017-05-22 16:57:37 -07:00