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
This makes the lifecycle simpler to fix a crash after rotation.
Also do some adjusting of alignment while here.
Bug: 21444336
Bug: 21205689
Change-Id: I67eccf4833f53b5e5088ae5e6038d041e8653565
Tint icons properly
Bug: 21077770
Show better icons for wifi and bt (remove the old ones)
Bug: 21172936
Also add a way to show fake items in power list for testing.
Change-Id: I6b6804673a68190ebc3f2ea32802e30811a7f5b2
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
+ Now when a user goes to Settings->Bluetooth and turns on Bluetooth,
the device will be discoverable.
Bug: 17368189
Change-Id: Ia0d8000ddf7e3c3b43172c08ee28e7305d205462
+ Fixed a crash when selecting On/Off multiple times on an input device.
+ Fixed a crash when visiting different Bluetooth Settings after
disabling an input device.
Bug: 17402421
Change-Id: I23efa3a36ba8cf0df02cf41397586a10dae9e08c
+ Also updated padding around Available Devices.
+ Also updated opacity on Bluetooth's "your device is visible" message.
Bug: 17398966
Change-Id: Id9631334ee0f3a01e40b00470d6debf6a31abe47
+ When refreshing Bluetooth devices, sometimes it took awhile for some
devices to come back up. This is a fix.
Bug: 17049458
Change-Id: Id6233b38585e003e0432707663af4d06b0ce98c2
+ After renaming your Bluetooth device, the title of the Bluetooth
Activity stays "Bluetooth" instead of changing to the new name.
+ After renaming the device, the status at the bottom Bluetooth Settings
is correctly displayed.
Bug: 16463239
Change-Id: Ifb12df2004fe1f89bd6f918e23c2c64ae08a0191
+ Replace the “Paired bluetooth device” screen with a “Pair device” dialog
+ Add device name text field at the top
+ Replace “Unpair” list item with a “Forget" button at bottom of dialog
+ Change “Profiles” section header to “Use for”
+ Remove status under profile titles
+ Move checkboxes to left side of labels
Bug: 15719219
Change-Id: I3b0e8c82c761fae98f16508b9fd9c58aff651f80
+ Remove top "this device" item from the list
+ Upon opening Bluetooth settings, cue a search for available, pair-ready devices
+ Upon opening Bluetooth settings, make the phone/tablet visible to other devices
+ Keep phone/tablet visible as long Bluetooth settings is open and screen is on
+ Filter this list so that only pair-ready devices are displayed
+ Add non-interactive text “<Device name> is now visible to nearby devices” at the bottom of the available devices list
Overflow menu:
- Remove “visibility timeout”
+ Replace “Search for devices” with “Refresh”
Bug: 15716927
Change-Id: I7c5225784af9bfb48dde511e05503ddc59be2b2b
+ List available email accounts
+ Allow for turning each account on/off with switches--making the message content available to bluetooth devices that can read emails (like cars)
Bug: 15720425
Change-Id: Ia0c91c1e74a2644fc99a8b902c42212453d8f86e
- change the way the SwitchBar is shown and hidden
- save its state
- remove the delay transition code
Change-Id: I07260430e6709b42517ca011f6d3c3446a626731
- follow up CL to 4193776698
Related to bug #14898161 On/Off switches must move down from Action Bar
Change-Id: Ic04de39599c91388cba8510bfd46d96e7bc30260
- the EXTRA_NO_HEADERS flag as no more meaning as we are showing
the Tiles (previously named "Headers") only in the Dashboard
(which is the main Settings screen)
Change-Id: I55656de0d28ca9c84adbe6647d870838b4ac230b
- getNonIndexableKeys(Context) allow a SearchIndexProvider to tell which data
he does not want to index by providing a list of the data keys
- use this new API for SoundSettings and removing KEY_EMERGENCY_TONE related
settings if the device is not CDMA
- add a BaseSearchIndexProvider for code simplification
Change-Id: I23633ace1d7e390ee05fac0a5458a33e04e72d8d
- follow the UX spec by no more using a Drawer
- the Dashboard is now a Fragment that contains the list of Headers
- the search results are also put into a Fragment that is replacing
the initial one (Dashboard or other) when expanding the SearchView
- use a SearchView for query input
- when tapping on a Header or a Search Result, re-launch Settings as
an Activity so that we are benefiting from the Activity stack for
UP affordance and BACK button
- manage UP affordance to show it only when needed
- move some Actions to the Menu in the ActionBar for allowing space
to the Search action and removing some clutter
- fix an issue with the Index and WiFiEnabler and their cached Context
that was not updated when there was a Configuration change
- simplify the SettingsActivity code by extracting some inner classes
Change-Id: I50b5f77bb44a7fade1886114dbbc820609a5e63d
- change the Index SQL model. Add a new "enabled" column.
- use that column for issuing a more restrictive search query
- change the SearchIndexProvider API to pass the "enable" state
- apply it to Bluetooth settings
- refactor the list of indexable resources (SearchIndexableResources)
Change-Id: Ic900fb27cb12a285a80d953aa1aa88f0070cd986
- comply to the SEARCH_INDEX_DATA_PROVIDER
- add to the Index the name of previously paired BT devices
(this will work for now only and only if BT has been on during
the indexing)
Change-Id: I00065db0f4e9657cca3578a2fafa0ec39cfaa432
There was a fundamental flow in the BT code. Basically BluetoothSettings is using
a singleton BluetoothDiscoverableEnabler.
BluetoothDiscoverableEnabler is keeping (thru its constructor) a reference on a Context
for registering/unregistering some broadcast receiver. BUMMER! When you change orientation
(or more generally the device Configuration), your Context is no more the same!
Hence the crash as we were trying to unregister a Receiver on a Context that is no more valid.
Fix that issue by passing an updated Context to the BluetoothDiscoverableEnabler.resume() API.
Bug #12991455
Change-Id: I77db15d2b59b6dd973907e26f9e6bb022202a8b5
- 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
When a user has the user restriction DISALLOW_CONFIG_BLUETOOTH
- Remove all the menu items for searching and other config
- Hide "available" but non-paired devices
- Remove settings button from paired devices
- Remove ability to make the device visible to others
Change-Id: Icaebf29d3cce55d924fdd65449447b5b7a438bbe
