This is made necessary by changes to the SystemAPI the lib relies on.
Test: RunSettingsRoboTests
Bug: 116798569
Change-Id: I2812ce9e58e3fb15a5579ddc10cd0edf33d0ed44
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
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
This CL removes the toggle from the bluetooth preference and instead
takes users to a new dedicated screen for toggling bluetooth status.
On this screen we show a different summary text depending on whether
bluetooth and bluetooth scanning are on/off. Also, we were able to
delegate most of the UI/bluetooth handling to already existing
classes.
Test: robotests
Bug: 77543471
Change-Id: I036a3992bbd78896da8364b55ecc51afc4464b6e
This allows Settings to test against the latest framework changes.
Also replaced TestConfig with traditional robolectric.properties.
Bug: 73173204
Bug: 73892008
Test: make -j56 RunSettingsRoboTests
Change-Id: I3135b4fa5f095ba79b282a76f45dd9baa2584bc7
The symptom observed is that the Bluetooth master switch on the
Connected devices page doesn't properly respond to Bluetooth turning off
via quicksettings - either turning on airplane mode or just toggling
Bluetooth.
The root cause was that MasterSwitchPreference's isChecked method would
not return the true value of whether the switch was checked - if the
control is disabled, it always just returns false. This interacts badly
with code in BluetoothEnabler - we disable the switch when the Bluetooth
state is in transition (eg becomes STATE_TURNING_OFF), and we also
attempt to avoid calling setChecked if the switch is already in the
desired state. So the switch would be checked but disabled, and we'd
avoid ever calling setChecked(false) on it.
A thorough fix would be to remove the code from MasterSwitchPreference's
isChecked method that looks at the enabled state, since enabled and
checked really should be treated as separate concerns. But given the
timeframe of MR1, we're opting for a more conservative fix of directly
accessing the switch and checking it's state, to avoid introducing bugs
in other consumers that might be depending on the current
behavior. We'll then do the thorough fix on the master branch which will
give a lot more time for any unexpected issues to be found (I audited
other usages and none seemed likely to be a problem, but it's better to
be safe than sorry).
Change-Id: I19a6c6b71e74595be3ef32a9718a430b67a89d53
Bug: 64940731
Test: make RunSettingsRoboTests
If handleStateChanged() is called after
maybeEnforceRestriction, the disabled switch will be
enabled again, only to be disabled when the user touches it.
Bug: 37737621
Test: make RunSettingsRoboTests -j40 ROBOTEST_FILTER=*BluetoothEnablerTest
Change-Id: I3086806dfd6d911d6d7fca1f1d30fa7d8b8757d1
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
- Add logging when users selects the listed devices to connect or
disconnect, and when connection error is shown
- Update the event for the top level bluetooth master switch toggle to
have its own event.
Change-Id: I58f21256fdd07fad9d733ff987ff38df1148f4f8
Fix: 35065258
Test: make RunSettingsRoboTests
