getPreferenceControllers() -> createPreferenceControllers() for the same
reason as in ag/3647936
Bug: 73668763
Test: robotests
Change-Id: I97670a91a2a38d1c844d1b9d37f4222c5e6f45a0
Updated testContextMock() how it checks the bluetooth_connected string.
Bug: 72317067
Test: Unit test updated:
make ROBOTEST_FILTER=BluetoothDetailsHeaderControllerTest \
RunSettingsRoboTests
Manual: two headsets and switching the active device
Change-Id: I3db178d71543e4dfa437544350c58241860ae703
1. Remove the placeholder summary so it won't show blank summary
2. Update settings_entity_header to make text center_vertical,
so it could align with the icon.
Bug: 71742145
Test: Screenshot
Change-Id: I185114a4e0c8d996f218075a8633e802fabf3c66
Adds dynamic summary getter in relevant BasePreferenceControllers.
Preferece controllers that don't have dynamic summaries or which
are not yet BasePreferenceControllers are not changed right now.
Change-Id: I435ccab7758d90515583fd8ca10a9b1ef0c858b9
Fixes: 71514936
Test: robotests
Then UI won't be janky(as everything slide down a little bit)
Bug: 63910184
Test: RunSettingsRoboTests
Change-Id: Ie4074694f54af92da52f09d2caaab5490fa73647
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
In the new design, bluetooth preference is not MasterSwitchPreference
any more. This cl creates BluetoothSwitchPreference while reuse the
BluetoothEnabler.
Future cl will remove the BluetoothMasterSwitchPreference when P
feature is finalized.
Bug: 69333961
Test: RunSettingsRoboTests
Change-Id: Ie1f934b4e93a6758a1b0cf83bb5098585a635c2a
Get the PreferenceGroup there and add/remove preference
through the callback
Also add ConnectedBluetoothDeviceUpdater which only filter
the connected device.
Bug: 69333961
Test: RunSettingsRoboTests
Change-Id: Ia2ab6b6708329227929d6fe442df3a8d45bf86f5
The core thing is to find out a way to update group when devices
(bt device and usb device)are updated.
The infrastructure contains three parts:
1. ConnectedDeviceController
Normal PreferenceController. Get info from sub controller and update
the preferenceGroup.
2. BluetoothDeviceUpdater
Listen to bluetooth callback, decide whether to add/remove devices
3. DevicePreferenceCallback
Interface to add/remove preference. This interface will be used in
ConntectedDeviceController and future SavedDeviceController
Bug: 69333961
Test: RunsettingsRoboTests
Change-Id: I85a9ef216a801d5f0dd1cf0130d53850a68be4bd
The BluetoothDevicePreference need to know whether to display with an
invalid name. However pass in the whole fragment is over-killing.
This cl decouple it for several reasons:
1. In P, BluetoothDevicePreference will be used in other fragment.
2. In preference lifecycle from end user side, this flag is constant.
Bug: 69333961
Test: RunSettingsRoboTests
Change-Id: I3dbcd2a4aafa3ead74371534250e5e7c3ee221f7
The functional fix for b/62672248 in ag/2856166 removes the device name
from the text near the checkbox in the bluetooth pairing dialog, so we
need to stop checking for it in this robotest. However, that functional
fix needs to be in a separate CL from this fix for the robotest, because
the robotest doesn't exist on some of the older branches where the
functional fix needs to be backported.
Bug: 62672248
Test: RunSettingsRoboTests
Change-Id: I17ff3e4f13c20d58cc4027557f275d296ecccc95
This cl contains the moving about:
1. Several methods in Bluetooth/Utils.java
2. Bluetooth icon drawables
3. Bluetooth strings
4. Tests
Bug: 65488978
Test: RunSettingslibRoboTests
Change-Id: I682daa3eeb5022beb90a95763c70d19d32d54915
The forget button should be left and connect button be right.
Bug: 67915643
Test: RunSettingsRoboTests
Change-Id: I71bb99270c4a3d480346db1ded554ecc9b99e706
* LocalBluetoothAdapter is already a cache of BluetoothAdapter and its
methods should be used directly to obtain states instead of caching them
in BluetoothSummaryUpdater
- Use LocalBluetoothAdapter.isEnabled() to check whether Bluetooth
is enabled
- Use LocalBluetoothAdapter.getBondedDevices() to get list of bonded
devices
* BluetoothDevice is a stable Bluetooth API and its methods should not
incur large latency. We should use API methods as much as possible to
avoid intermediate wrappers
- Use BluetoothDevice.isConnected() to check if a device is connected
* Add more logging messages in error conditions
* Show status as "Not Connected" when there is a state mismatch (i.e.
adapter says it is connected, but no bonded device is connected)
* Updated unit tests to reflect the latest behavior
Bug: 65591907
Test: make, unit test, pair with Bluetooth devices, check Settings UI
Change-Id: I0fa54959c8bed8ac67a935f150785ba8197d0411
In ag/2863892, we add a new parameter to tune the size of battery icon.
This cl use this parameter and update the icon in bluetooth detail page.
Bug: 65397557
Test: RunSettingsLibRoboTests & Screenshots
Change-Id: I6dd26f14b3209101dd39320b3720fbd4f79acf54
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
* Add a developer menu option to allow name-less devices to be shown
when a Bluetooth developer needs it, but hide it for non-developer
users.
* Set BluetoothDevicePreference to invisible when CachedBluetoothDevice
does not have a name besides MAC address and the above developer option
is false.
* This affects BluetoothPairingDetail and DevicePickerFragment, but does
not affect BluetoothSettings. BluetoothSettings will show all paired
devices regardless whether an user friendly name exists.
Bug: 34685932
Test: pair Bluetooth device, send file over Bluetooth, unit tests
Change-Id: Idd7ad4b1671dfdcf3204efb50eddb6dae1065aa5
This cl change util method in bluetooth package to return
drawable instead of resId.
If the bt device has battery level, then method return customized
layerDrawable, otherwise return a simple drawable created from
resId.
Bug: 63393322
Test: RunSettingsRoboTests
Change-Id: Ib21822eafda0e8570212ce5cb070478e4f4876a2
Merged-In: Ib21822eafda0e8570212ce5cb070478e4f4876a2
This cl change util method in bluetooth package to return
drawable instead of resId.
If the bt device has battery level, then method return customized
layerDrawable, otherwise return a simple drawable created from
resId.
Bug: 63393322
Test: RunSettingsRoboTests
Change-Id: Ib21822eafda0e8570212ce5cb070478e4f4876a2
BluetoothPairingDialogFragment has code that makes the OK button on the
dialog disabled until the user has entered at least one character into
the PIN field. However it didn't properly handle the case where the user
had entered some text and then rotated the screen - because it always
marked the OK button as disabled during onShow even if it already had
some content. This CL fixes that by looking at the text content and only
disabling the OK button if the content is empty.
Bug: 36514895
Test: make RunSettingsRoboTests
Change-Id: I4e8e70089a862e67b20ff614bbaa64fc2b641fd4
