* 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
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
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
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
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 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
Create the obsolete version of the belowing fragments, so we could
flip between old page and new page.
BluetoothSettingsObsolete and DeviceListPreferenceObsoleteFragment
contains all the old logic but:
1. Logic about BluetoothPairingPreferenceController(ag/2239482),
since this preference shouldn't be checked in without the flag :(
This cl also adds logic in MasterSwitchPreferenceController to flip
these two pages.
Following cl will refactor these fragment to make it compatible
to new framework.
Bug: 35877041
Test: RunSettingsRoboTests
Change-Id: I1cc1bc2d49d8a3e11c3127e56f6409fbc84028d8
This preference lives in paired category. When clicked, it will
go to the pairing page.
Bug: 35877041
Test: RunSettingsRoboTests
Change-Id: I64706c49c8d303a494d4c1827e1f86b59effd54c
The implementations have been imported into SettingsLib. Setting's copy
can now be removed, which this change also does.
Test: Manually check battery status, which uses FooterMixin, looks OK.
make RunSettingsLibRobotTests && make RunSettingsRoboTests
&& make RunSettingsGoogleRoboTests
Change-Id: I6539605fdad80d156ff5ff249e68df4a1c412067
Show "Visible as [Device name]". Also remove the menuitem for
changing device name.
This cl creates a preference controller to handle the logic for
device name preference.
Bug: 35876447
Test: RunSettingsRoboTests
Change-Id: I9ab6c9d2df5b053d15b8ff887073ef82616243a4
This mac address means the owned device, not the device
to connect.
Bug: 35875420
Test: RunSettingsRoboTests
Change-Id: I142f49fdca72d8ffbb9b8b2e2666a61aefb80505
RestrictedDashboardFragment has all the same logic coming from
RestrcitedSettingsFragment but extends from DashboardFragment.
As a result, we could use preferenceController in child class of
RestrictedDashboardFragment.
This cl also make DeviceListPreferenceFragment as child of
RestrictedDashboardFragment, which enfluences the bluetooth page.
Bug: 38041586
Test: Build
Change-Id: I01395d506176c5cc584948478f7ca16c1c7c7045
This reverts commit 457c3cbec2.
Revert with fix/test.
The fix is that we removed DevicePickerFragment#initDevicePreference(),
which incorrectly set a useless widget on preference, and removes the
gear icon from preference, preventing bind() call to go through
Change-Id: Ia70cdb51d13cca6035a4e7fe8008d195f7f00c6e
Fix: 36511169
Test: runtest --path tests/app/src/com/android/settings/bluetooth/DevicePickerActivityTest.java
- 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
As a temporary solution to getting the most popular
settings to be the top rank, we have created a white list.
If a prioritized setting shows up somewhere in the results
then it will be given an elevated rank to be at the top.
Bug: 35048659
Test: make RunSettingsRoboTests
Change-Id: I92b563a17b42d8f91d980dd1d8e5f8f29ca5aa9c
Bluetooth is the receiver for the OPEN_RECEIVED_FILES intent, so we
should aim the intent directly at them.
Test: go to BT settings and click "Open Received Files" in the context
Change-Id: I057215f1faf04c8c735a7e9340325716225ad22d
Fix: 35246073
- Add a method in VisibilityLoggerMixin to log visible event using
LogMaker, which allows logging additional FIELD_CONTEXT field.
- In Utils.startFragment, add current page's metricsCategory as an extra
to next page.
- In next page's onResume(), extract the previous page's metricsCategory
and send it to VisibilityLoggerMixin.visible()
- Update all caller with additional paramters
Change-Id: I8e1f2597fa465b7d3aa16fa1d21c052a3219694a
Fix: 35359289
Test: RunSettingsRoboTests
- Add a preference controller for Network & internet->Wi-Fi to control
the preference toggling and summary update.
- Refactor WifiSettings and WifiEnabler to share code between the new
wifi preference controller and the wifi setting.
- Refactor BluetoothSummaryHelper to have a common base class with the
WifiSummaryHelper.
- Rename the summary helper to summary updater.
Bug: 34280769
Test: make RunSettingsRoboTests
Change-Id: I00ebfc161bcef89331bb41ba405ed8cb8232d248
- Add a new preference type that has Title and optional summary on the
left, and a toggle switch on the right. Clicking the left part of the
preference will open a settings screen.
- Update Connected devices->Bluetooth to use this new preference.
- Refactor BluetoothSettings and BluetoothEnabler to share code between
the new bluetooth preference controller and the bluetooth setting.
Bug: 34280769
Test: make RunSettingsRoboTests
Change-Id: I109ecdba640ecdd4748a6e5b2b4f4c47cbf653fd
The text from the empty text view can be any CharSequence. Need to check
the actual type before trying to cast it to Spannable and setting the
text span.
Change-Id: Ib3ead0a0fe0b797e026c0c259591025fc9c94709
Fix: 34075068
Test: make RunSettingsRoboTests
- Refresh connected state before setting summary text.
- Detect inconsistent state (BT manager says connected but doesn't
provide a connected device)
(This basically syncs implementation between settings and QS tile)
Change-Id: Id23138f8432b9aecd194f5016bf2576e33e8ca98
Fixes: 33341275
Test: RunSettingsRoboTests
- Create a new layout for footer prefs.
- Create a new FooterPreference type to use the layout
- Create a Mixin to create and add the pref to screen
- Create a new lifecycle observer type to invoke mixin at right time
- Switch SettingsPreferenceFragment to use footer mixin.
- Switch FingerprintSettings to use the new footer pref.
Bug: 33579394
Test: RunSettingsRoboTests
Change-Id: I548ac39a0d120196a7ffed09b4f98bd9a80bae90
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
Was bug in some code trying to handle preference animations better.
Since those animations are all disabled now, just remove everything
again and re-add it.
Change-Id: If1ce07a8f2b4144d95a95cec6ebb1b423644825a
Fixes: 29314480
Previously, adapter names which tend to be LTR and may appear at the
beginning of the string could cause the detected bidi direction of the whole
string (which would be RTL in RTL locales) to get miscalculated as LTR.
With this fix, not only the detected bidi direction would be correct,
but also odd adapter names would not impact the bidi layout of the
whole string.
Bug: 28816891
Change-Id: I1d25edbeeff7e9c013bb6c741e7f706431e721dc
In the off/turning on state all items were being removed, but never
re-added to the preference screen.
Bug: 27347029
Change-Id: I8f47ee79f428fc8555a0dc6574244c81aa85c6c8
Removing all prefs causes ugly animations, so avoid it at all cost
and cache all the prefs (while still added) as long as possible.
Bug: 26271353
Change-Id: I33b84d751938b460f4b66c0158057407dd45d974
bug: 27324609
Emulator has no bluetooth support at this moment, and settings
should not crash in this case.
Change-Id: I1bfc6c907ac02d4798b6c118291e6a9d1bf23c7c
Issue:
When BT is turned off/on staying in the same BT Settings
screen discoverability was not set again.
Fix:
Handle setting discoverability Bluetooth state change
intents also when BT state is turned ON.
Bug: 21944289
Change-Id: Ic3c8d476c53673b21d40ea2bd9669758d89c2aee
