| Age | Commit message (Collapse) | Author |
|---|
|
interface.
Change-Id: I893a48d6568a2e3048d754788a7e33f0c5549a0d
|
|
For all kinds of tethering we want to have a single place
where the interface is added to the bridge to avoid multiple
failure points.
Change-Id: I517e6d00e2953bc5ca008492367c48e3fa18a155
|
|
Change-Id: I6a78c16cc55c2e76c76d4135ca4abe82b0915197
|
|
Bug: 2719204
Dr No: Eastham / Jsh
Change-Id: I03d8d6761d8b114e2cdf95ed0fab86c7cb61e469
|
|
There are several problems in liba2dp.c:
1 There is a bug in bluetooth_parse_capabilities(): the capabilities field pointer increment
in the while loop is wrong and in case the first capabilities field is not the one we need
we end up reading undefined data.
2 In the same while loop there is no protection for infinite looping if the length of the
capabilities field is 0.
3 When start or configure fail, we just reset state to A2DP_STATE_INITIALIZED to force a new
configuration attempt. This is bad as we don't close the connection and configure expects a
closed connection. Subsequent configure attempts will fail reading sbc capabilites.
4 When there is a problem executing a command in a2dp_thread() loop, we do not reset current command
which prevents from executing the same command again.
Here is what happens in this issue:
There is an error in the A2DP start request because the headset has been disconnected and we go back to configure.
Because of problem 3, the connection is still opened when we run configure again and the 1st capabilitites
field lock indicator is set. We try to read next field and because of problems 1 & 2 we end up looping here for ever.
As data->mutex is locked, it cannot be acquired by pthread_cond_timedwait() trying to exit in
wait_for_start() and the timeout mechanism fails. We stay locked here with A2dpAudioInterface::A2dpAudioStreamOut::mLock also
locked as we are in A2dpAudioInterface::A2dpAudioStreamOut:write().
When system_server tries to disable bluetooth A2DP, A2dpAudioInterface::A2dpAudioStreamOut::setBluetoothEnabled()
tries to acquire mLock and system_server is also deadlocked.
Change-Id: I785250fe65651ec6fc2ae01a4250a61f2fd43908
|
|
Currently BlueZ is hard-coding the default link policy to include
role switch, hold mode, sniff mode and park state. However, some
device will have problem to maintain the connection or setup SCO
if they are in park state. Making these operation modes configurable
in main.conf improves flexibility so any of these four modes can be
disabled if necessary.
Signed-off-by: Bao Liang <tim.bao@motorola.com>
|
|
This is to reduce the chance of skipping on A2DP sinks that have buffers
larger than 120ms. Changed on advice from BCM.
Change-Id: I3d6574b30b362b43e311991eb3cc41776c5f9b52
|
|
Change-Id: I5abd8fc37e20a7916e84e624f883c7a1987b0587
|
|
Change-Id: I352eaaa2ba844b7c14bce1589156161c050afe34
|
|
Change-Id: I5afca60a75a318e69c543d231c69e3264e0dff12
|
|
uint16_t sco_pkt_type is introduced to struct sockaddr_sco. It allows bitwise
selection of SCO/eSCO packet types. Currently those bits are:
0x0001 HV1 may be used.
0x0002 HV2 may be used.
0x0004 HV3 may be used.
0x0008 EV3 may be used.
0x0010 EV4 may be used.
0x0020 EV5 may be used.
0x0040 2-EV3 may be used.
0x0080 3-EV3 may be used.
0x0100 2-EV5 may be used.
0x0200 3-EV5 may be used.
This is similar to the Packet Type parameter in the HCI Setup Synchronous
Connection Command, except that we are not reversing the logic on the EDR bits.
This makes the use of sco_pkt_tpye forward portable for the use case of
white-listing packet types, which we expect will be the primary use case.
If sco_pkt_type is zero, or userspace uses the old struct sockaddr_sco,
then the default behavior is to allow all packet types.
Packet type selection is just a request made to the Bluetooth chipset, and
it is up to the link manager on the chipset to negiotiate and decide on the
actual packet types used. Furthermore, when a SCO/eSCO connection is eventually
made there is no way for the host stack to determine which packet type was used
(however it is possible to get the link type of SCO or eSCO).
sco_pkt_type is ignored for incoming SCO connections. It is possible
to add this in the future as a parameter to the Accept Synchronous Connection
Command, however its a little trickier because the kernel does not
currently preserve sockaddr_sco data between userspace calls to accept().
The most common use for sco_pkt_type will be to white-list only SCO packets,
which can be done with the hci.h constant SCO_ESCO_MASK.
This patch is motivated by broken Bluetooth carkits such as the Motorola
HF850 (it claims to support eSCO, but will actually reject eSCO connections
after 5 seconds) and the 2007/2008 Infiniti G35/37 (fails to route audio
if a 2-EV5 packet type is negiotiated). With this patch userspace can maintain
a list of compatible packet types to workaround remote devices such as these.
Change-Id: Ie6dc57a6a2d4ec4b42f919070d98d39f225eaf95
|
|
This reverts commit ee7f17f2e9bc434c04fdfe5bfab84a6c48687b7a.
|
|
Signed-off-by: San Mehat <san@google.com>
|
|
Signed-off-by: San Mehat <san@google.com>
|
|
This is to avoid skips when the system time changes.
|
|
falling behind by 200ms, or on poll() timeout.
This allows us to recover more quickly from a situation where an A2DP headset
rejects A2DP packets for a short time. We now reset to regular packet metering
faster.
|
|
Less A2DP drop-outs due to unnecessary flushing.
BCM recommend 120-150ms for lazy flushing.
|
|
|
|
flush timeout.
Remove the (ahead < 0) logic that was designed to skip forwards when streaming
was lagging. This logic was not working properly, and ACL flushing does its
job.
Changes made by: Jaikumar Ganesh for Bluez upgrade to 4.89
Change-Id: Ic9025be657cbea1362b0a7f1d5a30ecf55e6cad2
|
|
Accessed with the debug tool 'hcitool con'
Change-Id: I637d6ac9e2ca63c6e4fc1d24a149f73901704550
|
|
This is to address an A2DP issue seen with the Mazda carkit, where A2DP audio
cannot be played. The MTU size (8200) requested by this carkit is much greater
than the output buffer size (2048) allocated by the Bluez A2DP profile. The
output buffer being full is giving an SBC encode error. This patch checks for
the buffer full condition.
Change-Id: Idded504d085c760baef15cd3cef84fcf57165e4f
Signed-off-by: Yu Kang Ku <kang.ku@motorola.com>
Signed-off-by: Nick Pelly <npelly@google.com>
|
|
Enabled on platforms with BOARD_HAVE_BLUETOOTH_BCM.
Change-Id: Ic223955ac3580e5a9430f96e069f686a7afdbef8
|
|
This change will reduce the occurence rate of A2DP sink suspend resume failures observed in issues 2184627, 2181005 and possibly 2189628.
Avoid lockups in case of BT device disconnection during the A2DP start process by using a timeout when reading from bluetooth command socket.
Correct a typo causing potential deadlock in wait_for_start().
|
|
org.bluez.Adapter.AddRfcommServiceRecord takes a name, uuid and channel
and creates a record like:
Service Name: MyApplication
Service RecHandle: 0x10009
Service Class ID List:
UUID 128: 42999bc0-ac5e-11de-8a39-0800200c9a66
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 26
It returns the integer Record Handle, that can be used with
org.bluez.Adapter.RemoveServiceRecord to remove that record.
Bug: 2158900
DrNo: eastham
Changes to original commit: Jaikumar Ganesh for Bluez upgrade.
Change-Id: Ie375d5ccd24b5faf067a26b8a04a1449b3f56ce2
|
|
This is a cleanup to Ian Kent's preceeding patchset.
Change-Id: I8ff00530fdd337873ff898b7fd9009b0fc13f0b4
|
|
Change-Id: Icef1729957ed55e491e63d74d14a2c0c93984c4d
|
|
The 500 msec write timeout is extremely optimistic, a 1000 msec
timeout is closer to reality.
|
|
When waiting on a condition is is possble to receive spurious
wake ups. Deal with this in wait_for_start().
Change-Id: I678e9d7831333d9b8baa31e9b0ec2597ca9263cd
|
|
On entry to wait_for_start() it's possible we are in state
A2DP_STATE_NONE if a2dp_thread() has not completed bluetooth_init().
Also, we call the pthread_mutex_*() functions more frequently than
we really need to.
Move the mutex locking outside the loop and let condition wait
take care of the locking. Also move the A2DP_STATE_NONE check
below the condition wait so we can be sure the state machine
has been poked before we test it.
Change-Id: I020bea365a623e88cb1a5f7e5fccd8f8aa948518
|
|
Pthread resources may be used by the thread attributes object.
We should destroy this after thread creation.
|
|
The dynamically created pthread mutex and condition variables
consume pthread resources. They should be destroyed prior to
freeing the structure containing them.
|
|
When waiting on a condition is is possble to receive spurious
wake ups. Use the fact that when we poke the state machine the
command must have changed to deal with this.
Change-Id: I0ed2f2a15c15dea30cb1d5cf3b67c8549d6802d4
|
|
Using a worker thread implementation for A2DP means that if we don't
have some way to syncroniize state transitions we can get overlap of
requested command functions or lost signals. In order for the A2DP
state machine to function each command operation must complete before
the next is initiated or we will get errors caused by these out of
sequence commands. And if we signal the thread when it is not waiting
on the condition the signal will be missed.
This could be partly resolved by implementing a queue but then there
is an overhead with also implementing a wait mechamism for state
transitions. It's much easier and simpler to just hold the mutex
during command processing which also deals with the lost signals issue.
This may well not achieve the original goal of the worker thread
implementation but neither would a queue implementation. It looks
like this is just the way things are!
|
|
There is an order of execution assumption made when starting the
a2dp worker thread. Add an additional condition variable to allow
us to make sure we have reached the thread_wait condition wait
before returning from a2dp_init().
|
|
This callback will be called for incoming pairing requests for 2.1
devices only when the remote IO capabilities are NoInputNoOutput
or DisplayOnly and the local IO capability is DisplayYesNo.
Currently, we were silently auto accepting.
|
|
|
|
|
|
We should be having the SDP record in the cache. In the very rare
case, that the remote device's SDP records have changed and if a discovery
is in progress, we would have already updated the cache or if we have not
queried the device yet, we are going to fail anyways.
|
|
We are a AVRCP 1.0 target, not a controller.
This is identical to the change we applied to Bluez 3.x
|
|
Signed-off-by: Mike Lockwood <lockwood@android.com>
|
|
|
|
In bluez4, when a device is unpaired the socket end is freed and
so we will get a EPIPE when we write to it, this causes us to call
bluetooth_close. On the next write, we don't call bluetooth_init.
The logic here is thati, if the state is A2DP_STATE_NONE and we
are waiting for BLUETOOTH_START state, we need to call bluetooth_init.
The ENODEV case is where the other end, doesn't exist, and we are
trying to write repeatedly, which means the problem is elsewhere.
When we start initially (i.e the first time) when a2dp_set_sink is called,
we used to directly set the command to configure and the a2dp_thread used to
call bluetooth_init. This fix makes this a separate state and step.
Tested:
1. A2DP music playing, turn BT off. Turn BT open, A2DP should work.
2. A2DP music playing, disconnect. On reconnection, it should work.
3. A2DP music playing, cause a crash in bluetoothd. On restart, it should
work.
4. A2DP music playing, remote end powers down. On power up, it should work.
5. A2DP music playing, disconnect and unpair. On repair and reconnect,
it should work.
Tested with 2 headsets and with the troublesome HBH-DS790.
|
|
Also increase a2dp_write timeout from 100ms to 500 ms
to avoid losing the first fraction of a second of a song
when streaming starts.
This is a manual integration of commit cb75ad7a5a708a6a1f593cddb745f1c0460676c6
from donut.
Signed-off-by: Mike Lockwood <lockwood@android.com>
|
|
Read the error code in a new recv call. Trying to read more data
than required to cover the error scenario was causing problems
when a NEW STREAM was being started.
|
|
|
|
In Bluez4, the error code has been moved out of the response
structure into a new structure bt_audio_error_t. We were only
reading sizeof(bt_audio_msg_header_t) and hence the 1 extra bytes
gets read on the next call and our state machine gets screwed up.
Fixed some tab / spaces issue.
|
|
As android init.rc doesn't support applying linux capabilities,
add them after starting the bluetooth daemon as root.
Original Change by Nick Pelly. <npelly@google.com>
Moved to Bluez4 by Jaikumar Ganesh. <jaikumar@google.com>
Change-Id: I9406ddc33a6510845b6709b321d828b160ed10ca
|
|
Original Change by Nick Pelly <npelly@google.com>
Change-Id: Id33de250ab501a4d81ee143e6a01fe26abe31d07
|
|
Original author: Nick Pelly <npelly@google.com>
Change-Id: Ia2864eb0e686a71741b8a11ace3f98b63634c3d7
|
|
1)Add support for ro.produce.model/brand/name system properties.
2)Set SBC frequency to 44100.
Original Change by Nick Pelly. <npelly@google.com>
Moved to Bluez-4 by Jaikumar Ganesh. <jaikumar@google.com>
|
