- 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
This patch removes incorrect condition.
(to not use LocalBluetoothProfile#isPreferred())
This condition uses the priority that already disconnected profile,
so this codition always returns false.
To verify this issue:
1. Turn on Bluetooth.
2. Pair and connect to BTH(A2DP/HFP)
3. The display now says "Connected"
3. Disconnect HFP profile
4. The display still says "Connected" but it should say "Connected (no phone)"
Change-Id: I9e2bfa6d23bf1be7587c9556b4b05459d02c4817
- add a new boolean parameter to ask for Index rebuilding:
passing "true" will delete first all the data corresponding to the
"className" and then apply the update.
Change-Id: Ifc42fc560a14f5470b466cf6982915d9207fa3c7
We were indexing the remembered device names but we were missing the
informations for launching the correct Activity from the Search result.
- add the missing information: className and iconResId
Change-Id: Ib6781d4c492c296e822da1b5a8a2a76c92ecd586
- 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
- remembered devices name were only indexed when BT was turned on/off
- allow the same when they are paired
- remove device name from the Index if it is un-paired
Change-Id: I1206a591b0132789c3b003e52c7ffac630e80758
- 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
During bluetooth pairing, HTML injection is possible via the device name displayed to the user. This escapes the device name, before creating HTML from it, so it will preserve things like < and > but will not affect rendering of HTML
Bug: 12976386
Change-Id: I8a02d3be8c1a779dc9ed1c9ef8083a1159ab3f2b
Cancel the pairing notification on bond state change happens from
BOND_BONDING to BOND_NONE. Otherwise it will present in the
notification area until it gets cancelled by opening it and press
cancel on pairing dialog.
Change-Id: I96f673e29e612cd748165a1323a5b4a4276a843c
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
- remove the call to PreferencesActivity as we are no more using the PreferencesActivity
Also set correct activity title with the new selected BT name for the device.
Change-Id: I03497187e0410ff2bba87bdb04a197938d1ea967
- remove the PreferenceActivity related code as we are no more using PreferenceActivity (and Settings is a derive of
SettingsActivity)
Change-Id: I3c650c03cd205d9c06679974ae4d832ced25459b
- 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
Changing the discoverable timer from 2min to infinity before the 2min timer
has passed will not clear the 2min timer.
This fix handles this case.
Bug: 12220031
Change-Id: I8794eda353c74e46b09e15ee9a7a491658e7b5cd
remember how many time the user choose the "no",
if user choose "no" twice, we will make it persist.
bug:11176511
Change-Id: I7234e7b4ba4586065dea462029e2da5ddaf53316
We can remember it as a non persist global value when user click no.
This value won't be saved when power down.
We will restore the permission choice
when we are disconnected with the remote device.
So the "no" choice selected by user will only take effect
until we are disconnected with the remote device.
bug:11176511
Change-Id: Ic0c0829587cf7a812b5fa96fbd381921f67c186f
- Fixes to the issues found during review.
- added support for BluetoothProfile ProfileService Classes
- Added new MapProfile.java to comply with new structure
- changed ORDINAL to use BluetoothProfile.MAP directly
- Moved construction of MapProfile to LocalBluetoothProfileManager constructor
- Added support for multiple concurent permission activities and/or multiple notifications (i.e. pbap and map permission request right after each other)
- cleanup
- changed settings to use Notification.Builder
- made the notifications for map/pbab more informative
- added handling of back button + "clear all notifications"
Bug:10692365
Change-Id: I9803c9658a96b1a9c1d4734d2fdd22f1421d2827
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 BluetoothSettings is entered via QuickSettings while an A2DP
device is connected, we aren't showing the device connection
status in the UI, because the device list is created before we've
connected to the A2DP and Headset profile services, and we weren't
refreshing the device list UI after getting the callback for
onServiceConnected() and retrieving the list of connected devices.
Add a line to HeadsetServiceListener.onServiceConnected() to call
device.refresh() after we call device.onProfileStateChanged() to
refresh the device list UI. Also copy the logic into A2dpProfile's
onServiceConnected() callback so it will refresh the UI for any
connected A2DP devices.
The reason this bug doesn't show up when entering BT settings
from the main Settings screen is because the onServiceConnected()
callbacks happen before the device list is initialized, so the
UI items are created with the correct connection status. For the
same reason, the bug doesn't occur if the Settings app is already
running and we re-enter it via Bluetooth QuickSettings.
Bug: 8724247
Change-Id: I1a993636ecab18dd6e980e3b4d2485bbed256d74
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
