- 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
When an app requests to enable Bluetooth and/or Bluetooth discovery,
we show a dialog for user confirmation. Remove the dialog title,
update the message text and button labels to be more descriptive,
and use the standard dialog layout instead of a custom layout.
Also fixes the button layout on the Bluetooth permission test app so
that the "Discoverable" button doesn't wrap to two lines.
Bug: 6001468
Change-Id: I731e2f31b4c822395fc3f83584a092550d9ae7d3
The dock audio enable setting is not saved if the user
dismisses the dialog without checking or unchecking the check box.
The dialog is then displayed each time the device is docked until the
user checks/unchecks the dialog or goes to sound settings to enable
or disable dock audio.
Bug 7518165.
Change-Id: Ifbc6179e78b64b5b7577ac750acf9846525e47c5
Display a dialog to enable the use of the dock audio connection
when a low end dock is connected for the first time.
Modify DockService to process docked and undocked messages even if
the device indicated is null (meaning the dock is not a bluetooth dock)
only for low end docks.
Bug 7302106.
Change-Id: I331d83a74fecf5f26b24bfc178342df414bd8153
The root cause is normally when change the airplane mode, the bluetooth setting UI
will not be foreground. No listener is setup for bluetooth setting UI when it is
in background. So the onCheckedChanged won't be called and mLocalAdapter.setBluetoothEnabled
won't be called. But for manta, airplane mode setting and bluetooth setting UI both
will show on the foreground due to bigger screen size. When we turn ariplane mode on,
bluetooth manager service will disable bluetooth without changing the persist bluetooth setting.
But bluetooth setting UI will listen to the bluetooth state change intent, it will receive
bluetooth state turn-off intent then it will call mSwitch.setChecked(false) in handleStateChanged,
which cause checked status changed from true to false to trigger the listener (onCheckedChanged)
being called. The listener will call mAdapter.disable() which will call mManagerService.disable(true)
to change bluetooth persist state to OFF. So when we turn back airplane more to OFF,
due to the bluetooth persist state is OFF, we won't turn back bluetooth to ON.
Don't need to consider thread synchronization, because everything is running on the main thread.
bug 7366814
Change-Id: I138d1904df6cb17c7828295caa51a7d80abf99f2
The root cause is normally when change the airplane mode, the bluetooth setting UI
will not be foreground. No listener is setup for bluetooth setting UI when it is
in background. So the onCheckedChanged won't be called and mLocalAdapter.setBluetoothEnabled
won't be called. But for manta, airplane mode setting and bluetooth setting UI both
will show on the foreground due to bigger screen size. When we turn ariplane mode on,
bluetooth manager service will disable bluetooth without changing the persist bluetooth setting.
But bluetooth setting UI will listen to the bluetooth state change intent, it will receive
bluetooth state turn-off intent then it will call mSwitch.setChecked(false) in handleStateChanged,
which cause checked status changed from true to false to trigger the listener (onCheckedChanged)
being called. The listener will call mAdapter.disable() which will call mManagerService.disable(true)
to change bluetooth persist state to OFF. So when we turn back airplane more to OFF,
due to the bluetooth persist state is OFF, we won't turn back bluetooth to ON.
bug 7366814
Change-Id: I07d4a2dfe03fc6775cfeabb28cd3a0cc1fded44e
In the Bluetooth profile list, the checkbox indicates whether the
profile is preferred (we should auto connect). If the profile is
not connected, selecting it will try to connect the profile and set
it to preferred. If the profile can't be connected, then the user
could not turn off the preferred setting for the profile.
Change the behavior so that when a profile is not connected,
but is marked as preferred, selecting the profile will turn off the
preferred setting (no auto connect) instead of trying to connect.
This enables the user to turn off auto connect for a profile when
it can't be connected. Tapping a second time will try to connect
the profile and set it as preferred, as usual.
Also change PanProfile to return the current connection status for
isPreferred() instead of always returning true. Currently, the
PAN profile is always checked, which is confusing because it looks
like PAN is always connected. Also, because of the new behavior
when a profile is selected, it's now necessary to return false for
isPreferred() when PAN isn't connected, so that we will try to
connect when the user selects it, instead of trying to turn off
the preferred setting, which isn't supported for PAN.
Bug: 7007641
Change-Id: Ifb0f51a15379bc254933168c43bdfc8b22f26051
There is no code change, the classname is OK, it was just the
filename that needed a tweak.
Original code was Change-Id: I381ed96f6b57f414bbaccd694f55d2b992e330a4
Change-Id: I14f2009cff186647a736b1183acf815713234dd5
This fixes a NPE by ensuring that cached device list has
a cached device associated with a given BDA before accessing
the cached device
Bug:5964529
Change-Id: Ib2c3596e6e008c78f9f1137134e421ca710e1217
When BT is turned off in mid of a profile connection, sometimes
profile connection status change message with status= DISCONNECTED
does not reach Settings app which results in stale connection status
for the device when BT is enabled next time. Fixed the issue
By explicitly clearing the connection status for all paired devices
when BT is turning OFF
Change-Id: I5d0c158636f3b62eff9094821abe2ef3a7cab16e
Remove profile auto connection specific logic as it is not implemented in
Bluetooth app
Disconnect PBAP server connection when user initiates device level disconnection
Change-Id: I381ed96f6b57f414bbaccd694f55d2b992e330a4
* commit '8756c500a1aa22b9b81eeeb7f25ec7246a1c1464':
Fix for correctly enabling PAN profile in Settings Update the connected profile list in CachedBluetoothDevice correctly if a PANU-NAP connection is already existing but the onUuidChanged() callback doesnt contain the PANU UUID in SDP inquiry. Now, the DeviceProfileSettings screens displays valid 'Internet connection sharing' option when connected as a NAP to remote PANU.
Update the connected profile list in CachedBluetoothDevice correctly
if a PANU-NAP connection is already existing but the onUuidChanged()
callback doesnt contain the PANU UUID in SDP inquiry. Now, the
DeviceProfileSettings screens displays valid 'Internet connection
sharing' option when connected as a NAP to remote PANU.
Change-Id: I35821233e7776fb13f7fb1eb22af992b497202a9
Move the BT settings appliance check after the foreground activity check.
This allows us to pair bt devices if we have a UI hooked up instead of never
allowing it.
TESTED = runs on Nexus Q.
Change-Id: I3c1ea4abb8d05236d91d2525934bec757cc5ca88
