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
- Remove the old DevelopmentSettings
- Remove references to the feature flag
Fixes: 65522949
Test: make RunSettingsRoboTests -j40
Change-Id: Ie2eb3465127d79a027de6bb58a47bb15e3094f89
* 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
* 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
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
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
Disable animations for all SettingsPreferenceFragments, unless they
explicitly ask for them before creating their preference screens.
Turn it on for all fragments using the cached removal currently.
Bug: 27713314
Change-Id: I1bc14e7aeb3ee5b8ddb4f3547f472305cd312edf
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
SettingsLib has a couple of bluetooth changes to support quick
settings and as a result a few updates are needed in Settings.
Depends on I7f828f0038ad0cf39274986ece6d486d545f0286
Change-Id: I9b207b74abb0175148fd4a3c421d33ab9a861587
Move the non-ui bluetooth control/tracking code to SettingsLib so
that it can be shared with others.
Mostly just move classes to frameworks/base/packages/SettingsLib,
however a few things had to move around.
- Dock handling had to move back to code still in settings
- Local preference related code had to be moved back to settings
- Added an error flow from SettingsLib to Settings
Depends on I69fd888362c6dbb325f6113b32c4b15cc6a23a41
Bug: 19180466
Change-Id: Ie57fe26a27bbb0adc2ef69e042a05c7290c6a52a
- get rid of PreferenceActivity as much as we can and use fragments instead
- add Drawer widget
- add Dashboard high level entry into the Drawer (but this is work in progress and would be done in another CL)
- add bypass of fragment's Header validation when launched from the Drawer but *force* validation if external
call thru an Intent
Be aware that WifiPickerActivity should remain for now a PreferenceActivity. It is used by SetupWizard and should
not trigger running the SettingsActivity's header building code. SetupWizard is a Home during the provisionnig process
and then deactivate itself as a Home but would make the Home header to appear in the Drawer (because momentarily we
would have two Home).
Also, verified that:
- the WiFi settings still work when called from SetupWizard
- when you have multiple Launchers, the Home header will appear in the list of Headers in the Drawer
Change-Id: I407a5e0fdd843ad7615d3d511c416a44e3d97c90
When these screens are locked down with user restrictions,
it should prompt the user for the restrictions pin before allowing
access to the settings screen.
Change-Id: Iadbb087da2d9470b855ea0bea89f2da1ffb9e854
- Change Bluetooth profiles screen to match ICS wireframes
- Remove BluetoothProfilePreference.java (no longer used)
- Remove "Pair with this device" summary below every unpaired device
- Remove "Paired but not connected" summary below unconnected paired devices
- Fix auto connection after pairing (reuse existing CachedBluetoothDevice)
- Add "Connected (no phone/media)" summaries based on ICS wireframes
- Fix visibility timeout strings.
- Fix crash when starting Bluetooth from Settings shortcut widget.
Bug: 5064139
Bug: 5064324
Bug: 5080404
Bug: 5093513
Bug: 5104485
Change-Id: Ie87103e183ce414c86cb1831a38ef0178b1b1292
- Remove BluetoothFindNearby.java (no longer used)
- Show message when Bluetooth is turning off
- Fix case where device name sometimes didn't show when turning BT on
- Disable "Rename device" and "Visibility timeout" menus when BT is off
- Remove "Got onDeviceAdded, but cachedDevice already exists" log message
- Never show "Rename device" in action menu (bug 5064378)
- Show discovery time remaining as "m:ss", not "mm:ss" (bug 5064104)
Bug: 5064378
Bug: 5064104
Change-Id: I79609dfdad61993a28cff64c9e082870ff74d180
Paired devices are listed first (from cache), followed by unpaired ones.
A scan is only started on user request or when there is no paired device
(should it be when there is no paired *connected* device?).
Wrench icon only displayed for paired devices.
Wrench click listener no longer uses mDeviceSettings which is unreliable
with ListView view recycling.
Fixed blinking ProgressCategory when the category was first in the list.
Change-Id: Ie749883426c12bd354da64733bd04b00304bc1f5
Major refactoring of Bluetooth settings classes.
- Moved all functionality from LocalBluetoothManager into new
LocalBluetoothAdapter and LocalBluetoothPreferences, and into
existing classes.
- Refactored functionality from BluetoothEventRedirector into new
BluetoothEventManager class, deleting the original version. New
version uses a HashMap from action Strings to implementers of the
BluetoothEventManager.Handler interface.
- Created new BluetoothDiscoveryReceiver to update shared preferences
timestamp for Bluetooth discovery start/finish. This is the only event
handling we need to do when the settings app is not visible, so it has
its own receiver entry in AndroidManifest.xml. Edits are written using
QueuedWork.singleThreadExecutor(), which BroadcastReceiver knows about
and will wait for completion, eliminating the need for PendingResult.
- Miscellaneous cleanups to code style and logic for readability.
- Pulled some large switch statement code blocks into new methods.
- Changed all Bluetooth state references to the new BluetoothProfile
constants.
- Changed use of deprecated Notification constructor in
BluetoothPairingRequest to use Notification.Builder.
- Moved Utf8ByteLengthFilter helper function from BluetoothNamePreference
into its own class, and moved test cases into the same package.
- Moved all LocalBluetoothProfileManager functionality related to
specific profiles into new top-level classes (A2dpProfile, etc.), all
implementing the LocalBluetoothProfile interface.
- Moved all UI-related methods from CachedBluetoothDevice into the class
that uses the method, or into the static Utils class for shared methods.
Change-Id: I6d49b7f4ae0c7d7dcf62551ee40b51ecb5fe4f47
Close the scan screen after successful pairing, and remove a
device from the list of paired devices after unpairing.
As part of the fix, BluetoothSettings was refactored into a parent
class, DeviceListPreferenceFragment, and three subclasses for each
variant type: BluetoothSettings, BluetoothFindNearby, and
DevicePickerFragment, replacing the checks against mScreenType with
custom logic in the child classes.
Bug: 3325848
Change-Id: If64fddc3ba5b4f1136451491c7d5a1139b696e47
