A large update for search keywords collected from logging
and individual feedback.
At the moment, we don't have a great way to test that a keyword
matches to a search result. It's a bit akin to testing that the
wifi title is Wifi.
Fixes: 36983488
Fixes: 36622889
Fixes: 76115241
Test: Manual audit of keywords surfacing the proper results.
Change-Id: Ia1031b7f6ec1edfcc28c07e6b55049b8dac7c685
getPreferenceControllers() -> createPreferenceControllers() for the same
reason as in ag/3647936
Bug: 73668763
Test: robotests
Change-Id: I97670a91a2a38d1c844d1b9d37f4222c5e6f45a0
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
This is a clean up to action bar menu item pattern, we will use the same
pattern to build search icon on all pages in a later change.
Bug: 68814716
Test: robotests
Change-Id: Iedd3ec263e8ccb63ed75ec7a95b28c00878b1de4
* 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
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
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
