For the docks, we can set if a device is preferred or not
before pairing process. This was getting overridden when we pair.
This problem doesn't happen with normal headsets.
Dr No: Eastham
Bug: 2318290
1. PRIORITY_OFF is when user unchecks A2DP connection profile box.
2. By default, when you bond, it will be PRIORITY_ON.
3. When the profile gets connected, the priority gets set to
PRIORITY_AUTO_CONNECT. This means that we will connect
automatically to this profile.
4. When the user disconnects, we downgrade the priority to PRIORITY_ON,
which means we won't reconnect automatically.
a) We need to make a similar change to Handsfree profile.
b) We need to rework the profile management design and code which
will fix the 6 second timer that we have for A2DP reconnection.
Add AUTO_CONNECT priority for Headset profile.
Also, don't set priority to ON while disconnecting.
This logic has been pushed up to the Settings app.
Dr No: Eastham
Bug: 2133530
Merge commit '6d95fc0a2ca910212a43c4547c0ef000659b72dc' into eclair
* commit '6d95fc0a2ca910212a43c4547c0ef000659b72dc':
docs for ESR: add docs to bluetooth explainin that discovery should
Merge commit '88427cff609e668185010af2244500be5823595e' into eclair
* commit '88427cff609e668185010af2244500be5823595e':
docs: add more documentation for the bluetooth apis.
Make functions that are meant to be BLUETOOTH_ADMIN really
BLUETOOTH_ADMIN.
Add some missing javadoc for permissions.
The only functional change here is the BLUETOOTH->BLUETOOTH_ADMIN
changes. This is super safe because every system app that uses BT
has both permissions.
Change-Id: Iddc61f9fd5d81fe0171358665a0fa52f2fa02871
DrNo: eastham
Joke: How do you catch a rabbit? Hide behind a tree and make carrott noises.
Sometimes during OPP, we can get stuck in Pairing state when the remote
end, cancels the Pairing process - we will just get onAgentCancel
and thus not set the Pairing state properly.
DrNo: Eastham
Bug:2174874
This is the main entry point to the Bluetooth APIs, and returns the default
local Bluetooth adapter.
It replaces context.getSystemService(Context.BLUETOOTH_SERVICE). This was
never in a public SDK release.
DrNo: eastham
Bug: 2158765
Joke: Why can't you play cards in the jungle? Because there's too many cheetas!
Change-Id: Ieed8be009ee5aba621cb69090ee8c8a9c19c840d
Hide createRfcommSocket(int channel)
Add createRfcommSocketWithServiceRecord(UUID uuid)
Rename listenUsingRfcomm(String,UUID) -> listenUsingRfcommWithServiceRecord(..)
Now we have a complete API for developers to make peer-peer RFCOMM connections
with hard-coding the limited (30) RFCOMM channels, instead using SDP lookup
of an UUID.
This commit addresses two serious bugs:
- Do not throw IOException on accepting an incoming RFCOMM connection with
BluetoothSocket. This was a regression from commit 24bb9b8af4
- Workaround failure of bluez to update SDP cache when channel changes by
trying to use the same RFCOMM channel on the server every time, instead
of picking server channels randomly. This is a pretty ugly workaround,
and we are still trying to fix the caching issue - but with this
workaround we are at least shippable and apps will work at least until
they start colliding on the 30 RFCOMM channels.
DrNo: eastham
Bug: 2158900
Joke: What did the digital watch say to his mom? "Look mom no hands."
Change-Id: Ia4879943b83afac06b6f1a3f2391cf1628afce7d
Hide listenUsingRfcommOn(int channel)
Add listenUsingRfcomm(String name, ParcelUuid uuid)
The new API automatically finds a free RFCOMM channel and registers an SDP
record with the given uuid and name. The SDP record is automatically
removed when the socket is closed, or if the application dies.
Apps are prevented from registering SDP records with the uuid of system
Bluetooth profiles, such as A2DP, HFP and OPP.
Apps are prevented from removing SDP records that they did not create. This is
tracked by pid.
TODO: Provide an API for the connecting app to look up an SDP record.
Bug: 2158900
DrNo: eastham
Joke: "What did the dog say to the tree? bark."
Change-Id: Ia92f51c34615a7270a403255ad2b8faa98c4a3f5
This happens when the the remote headset is in a bad state or is
not accepting connections. Try twice before giving up.
Change-Id: I55e15bad6b72904b8e4ccbca89e17e9bd3ddb61e
Instead add ACTION_REQUEST_DISCOVERABLE for the system to show a dialog to
adjust discoverable mode.
Also remove createBond(), removeBond() and cancelBondProcess(). The Settings
App already handles these automatically when connections require bonding.
Change-Id: I216154cd1b6de410de64ba91b07d7263ac03e8df
Bluez Device implementation is such that when a device
is unpaired, we removes the device and hence there is no
way to interact with it unless you pair again. Remote service
channel call is used to get the rfcomm channel number which
will be used in profiles like OPP which don't require pairing.
Change-Id: I868a6cdfdb1b7d3591dd8b66cd0320f41a9c1b92
Add new API which clients can use to force an SDP query.
The result is broadcast using an intent having the UUIDs.
The intent is broadcast after a timeout, in case of an error.
This timeout is greater than the page timeout.
Change-Id: I61e6db4c05b34c42f679a66987e37e2063a793b6
This keeps consistency with Bluez which uses upper case string address. It's
important to keep the case the same so that .equals() in BluetoothService.java
work.
Change-Id: I6404ca137d0aec3cc2e6e7cb79763d5305a03547
This is to help collect information from Moto QA about delays connecting BT
audio.
Change-Id: I790c65f5b64c85aaffc0e68ebe8b6202f476b39f
http://b/2129464
1) Handle incoming 2.1 pairing requests
2) Modify displaying error messages on bond failures.
3) Add delay while accepting incoming pairing for certain 2.1 devices.
When MITM is on, the link key request might come more than once.
Auto accept with a delay.
4) Handle DisplayPasskey callback for pairing a 2.1 keyboard with
a 2.1 device
This is a large batch, and covers:
-- Bluetooth Device Discovery --
BluetoothAdapter.ACTION_DISCOVERY_STARTED
BluetoothAdapter.ACTION_DISCOVERY_FINISHED
BluetoothAdapter.startDiscovery()
BluetoothAdapter.cancelDiscovery()
BluetoothAdapter.isDiscovering()
-- Bluetooth bonding (pairing) --
BluetoothAdapter.getBondedDevices()
BluetoothDevice.ACTION_BOND_STATE_CHANGED
BluetoothDevice.EXTRA_BOND_STATE
BluetoothDevice.EXTRA_PREVIOUS_BOND_STATE
BluetoothDevice.BOND_NONE
BluetoothDevice.BOND_BONDING
BluetoothDevice.BOND_BONDED
BluetoothDevice.getBondState()
BluetoothDevice.createBond()
BluetoothDevice.cancelBondProcess()
BluetoothDevice.removeBond()
-- BluetoothClass --
BluetoothDevice.ACTION_CLASS_CHANGED
BluetoothDevice.EXTRA_CLASS
BluetoothDevice.getBluetoothClass()
BluetoothClass.Service.*
BluetoothClass.Device.Major.*
BluetoothClass.Device.*
BluetoothClass.getDeviceClass()
BluetoothClass.getMajorDeviceClass()
BluetoothClass.hasService()
-- Misc BluetoothDevice --
BluetoothDevice.ACTION_ACL_CONNECTED
BluetoothDevice.ACTION_ACL_DISCONNECTED_REQUESTED
BluetoothDevice.ACTION_ACL_DISCONNECTED
BluetoothDevice.ACTION_DISCOVERED
BluetoothDevice.ACTION_NAME_CHANGED
BluetoothDevice.EXTRA_DEVICE
BluetoothDevice.EXTRA_NAME
BluetoothDevice.EXTRA_RSSI
-- Misc BluetoothAdapter --
BluetoothAdapter.ACTION_LOCAL_NAME_CHANGED
BluetoothAdapter.EXTRA_LOCAL_NAME
BluetoothAdapter.checkBluetoothAddress()
I deprecated BluetoothIntent and moved each intent into the class it relates
to.
Change-Id: I877b1280428ab46278b2bc25668bb44cda22dc36
Deprecate BluetoothError.java.
I spent a lot of time experimenting with a class BluetoothError to enumerate
the many error codes returned by the Bluetooth API. But at the end of the day
they were never used. The vast majority of method calls only really need a
true/false error value, and often not even that.
Methods which do need more detailed error enumeration (for example, bonding
failures) can have there own enumerated error codes. But there is no need
for a common set of error codes.
Also change the IPC failed warnings in BluetoothA2dp to Log.e. These indicate
a very serious error.
Introduce BluetoothAdapter.ERROR and BluetoothDevice.ERROR as helper sentinel
values.
Unfortunatley, shutdown() on the underlying fd does not actually stop a
listening socket from listening. You need to call close() on the fd to
do this. There is no way around it.
So this means the Java BluetoothSocket code has to call destroyNative() during
BluetoothSocket.close().
Since native methods cannot be called after destroyNative(), add a ReadWrite
lock and mClosed field to protect access to native methods.
This fixes the "resource busy" error when Bluetooth OPP and Bluetooth PBAP
tried to resume listening after turning BT off and then on.
