- 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
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
When doing Bluetooth pairing and the dialog reqesting a PIN comes up, we
want the PIN field to be focused and the keyboard to be shown. This fixes
a regression from N.
Bug: 62857671
Test: make RunSettingsRoboTests
Change-Id: I00dabfda737b6ac61b50518e11f21e5f9a5a1be1
- 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
BluetoothProgressCategory will add a no device preference if it is
not scanning and no device is added to the list. Since
DeviceListFragment doesn't report its scanning status correctly, it will
show "No nearby device" even though it is scanning.
This cl add control code for BluetoothProgressCategory in
DeviceListFragment, which avoid the unnecessary no device preference.
Bug: 62492822
Test: RunSettingsRoboTests
Change-Id: Ic49f21cb58a80dcd37c5737800181263ae876ebc
Bluetooth settings screen has two categories. Each category should call
removeAll() method to unregister a callback from CachedBluetoothDevice.
But the method is not called for mPairedDevicesCategory.
Bug: 30004142
Test: manual - connect to Bluetooth device and then
open and close Bluetooth settings screen repeatedly
Change-Id: I5a72994473ee2bb5fc3ad00176d9a930b4839099
1. Remove BluetoothSettingsObsolete
2. Remove DeviceListPreferenceObsoleteFragment
3. Update master swtich, now constantly point to new page
4. Update the tests
Future cl will remove the page switch API in BluetoothFeatureProvider
Bug: 63444548
Test: Test still pass
Change-Id: I24fb5cd03cf30044edb7201426e11e0a818f0a7f
Merged-In: I24fb5cd03cf30044edb7201426e11e0a818f0a7f
1. Remove BluetoothSettingsObsolete
2. Remove DeviceListPreferenceObsoleteFragment
3. Update master swtich, now constantly point to new page
4. Update the tests
Future cl will remove the page switch API in BluetoothFeatureProvider
Bug: 63444548
Test: Test still pass
Change-Id: I24fb5cd03cf30044edb7201426e11e0a818f0a7f
* mLocalAdapter should never be null
* We should crash if it is ever null
Bug: 63442969
Test: make, pair Bluetooth device
Change-Id: If98f9ea0762927eb57d00224b62abf24bbec69ba
The problem is that we were calling done() on the EntityHeaderController
and passing false for whether to rebind the action buttons, which means
we were getting the default behavior including a visible gear
icon. Passing true to request rebinding causes that icon to be hidden.
Bug: 63405635
Test: make RunSettingsRoboTests
Change-Id: I031f4a2d176ff3be025cc2675d7026a679936b03
This adds a confirmation dialog for when you hit the "Forget" button to
unpair with a device from the Bluetooth device details page.
Bug: 37955181
Test: make RunSettingsRoboTests
Change-Id: I7643ed09bf363c48078d6de8a47583bf91fc7729
* Use String in connected device summary instead of resource id
* This allows dynamic strings to be built by CachedBluetoothDevice
such as ones involve battery level percentages
Bug: 35874078
Test: make, unit test, test with Bluetooth devices
Change-Id: I583eac73280ca17387b215a4e7095e27de399998
We were getting the following exception when you rotated the Bluetooth
device details screen:
java.lang.RuntimeException: Unable to start activity
ComponentInfo{com.android.settings/com.android.settings.SubSettings}:
java.lang.IllegalStateException: This Activity already has an action bar
supplied by the window decor. Do not request Window.FEATURE_ACTION_BAR
and set android:windowActionBar to false in your theme to use a Toolbar
instead.
It turns out that allowing EntityHeaderController to inflate the
settings_entity_header.xml view seems to cause this - if you instead
manually include a LayoutPreference and hand that to
EntityHeaderController, you don't have the problem.
The rotation failure couldn't be tested with Robolectric because our
version doesn't support using FragmentTestUtil.startFragment for
fragments which use PreferenceScreen's ("sorry, not yet
implemented"). So instead this includes an app test.
Bug: 62447414
Test: runtest --path=BluetoothDeviceDetailsRotationTest.java
Change-Id: I8d052d1f4ab6e2b0ca5c0e513ec366bdcc382d99
This adds an icon to the paired device details page which users can
click on to bring up a dialog for changing the display name for that
device.
We already had a dialog for changing the advertised name of the local
Bluetooth adapter that's used on the main Bluetooth settings page, so
I've made that abstract and created two new subclasses to encapsulate
the slight differences for this use case.
Bug: 62535241
Test: make RunSettingsRoboTests
Change-Id: I1c407f276e12aedf066a336e24b4ccd16d67c4df
This will prevent them from showing up on external devices where they
would be less than useful.
Test: connect to watch and pair a device
Bug: 34612389
Change-Id: I8b02c20200ce78a73967b8121cf7d5653b68f356
(cherry picked from commit 426903d155)
This will prevent them from showing up on external devices where they
would be less than useful.
Test: connect to watch and pair a device
Bug: 34612389
Change-Id: I8b02c20200ce78a73967b8121cf7d5653b68f356
Move it from menu to preference
Also clean up the code about menu since there is no menu anymore
in BluetoothSettings
Bug: 35876447
Test: RunSettingsRoboTests
Change-Id: I4a3821595a0cc75382f1cf74bcafb3ecc44cc178
* 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
Bug: 35877479
Test: make RunSettingsRoboTests
The existing behavior is to bring up a dialog with Bluetooth device
details with checkboxes for each supported profile. This adds a new page
that serves the same purpose with a switch for each profile and a footer
containing the MAC address.
Whether to use the new page or old dialog is controlled by a flag
accessible via BluetoothFeatureProvider.
Change-Id: I026c363d4cd33932a84017a67cbef51c258bad10
This flag will be used to control whether we use a new, separate page
for Bluetooth device details, or the existing dialog.
Bug: 35877479
Test: make RunSettingsGoogleRoboTests
Change-Id: I2bda77493695ebe3b3bb824657a1422a68918256
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
