If RFCOMM is disabled on the kernel, headset_server_probe() fails.
Relevant log messages:
audio/manager.c:headset_server_probe() path /org/bluez/499/hci0
src/adapter.c:btd_adapter_ref() 0x4bb4f78: ref=6
audio/manager.c:audio_adapter_ref() 0x4ca3010: ref=1
socket(STREAM, RFCOMM): Protocol not supported (93)
audio/manager.c:audio_adapter_unref() 0x4ca3010: ref=0
src/adapter.c:btd_adapter_unref() 0x4bb4f78: ref=5
audio-headset: Operation not permitted (1)
The powered callback should only be registered if adapter driver probe
was successful. The callback unregister was moved to the beginning of
headset_server_remove() for consistency.
This fixes this memory leak:
==499== 8 bytes in 1 blocks are definitely lost in loss record 44 of 182
==499== at 0x4826444: malloc (vg_replace_malloc.c:263)
==499== by 0x4877243: g_malloc (gmem.c:132)
==499== by 0x488D088: g_slice_alloc (gslice.c:836)
==499== by 0x488E8A5: g_slist_append (gslist.c:230)
==499== by 0x18AEEE: btd_adapter_register_powered_callback
(adapter.c:3416)
==499== by 0x11AF61: headset_server_probe (manager.c:919)
==499== by 0x18B67B: probe_driver (adapter.c:2033)
==499== by 0x1908F5: adapter_init (adapter.c:2048)
==499== by 0x189D20: btd_manager_register_adapter (manager.c:397)
==499== by 0x1649AF: mgmt_cmd_complete (mgmtops.c:1075)
==499== by 0x16665E: mgmt_event (mgmtops.c:1780)
==499== by 0x48B2EFA: g_io_unix_dispatch (giounix.c:162)
This patch fix the very first incoming connection from a GSM device
(playing the gateway role), when 'device->gateway' is NULL (when we
didn't perform a SDP browse request yet)
we add the service with 'btd_device_add_uuid(device->btd_dev,
remote_uuid)' but we provide HFP_HS_UUID as remote_uuid. Consequently,
the HFP headset service is activated instead the gateway service.
Fix response for any vendor commands when there are no players
registered. According to the specification responses should be
REJECTED with error code.
"For error response PDU the response parameter is always the
error code independent of the response format defined for
ACCEPTED PDU response for the corresponding PDU command."
(source: section 4.7.9 of AVRCP 1.3 specification)
In some situations, a connect callback is created, but
this callback is not added to media_owner. Thus when the owner
is destroyed and at rfcomm disconnect, the callback is executed
with an invalid pointer.
Failure on BlueZ-initiated SCO requests should not drop the RFCOMM
connection to the gateway. Instead, considering the stream as suspended
should be enough.
With both sink and sources disabled, the A2DP server is not even
registered in audio_manager_init. When trying to register the endpoint,
this should result in the same error as if the server existed but the
profile was disabled.
Calling gateway_unlock seems safer in gateway_suspend_complete, in
combination with the update of transport->in_use. This avoids the
transitional state of having the gateway unlocked but the transport
still in use.
This approach is also more consistent with the way headset and a2dp
handle it.
If get_setting is called before set_setting, mp->settings would be
NULL resulting in GLib assertion. Hashmap is now allocated in
media_player_create instead of on-demand allocation in set_setting.
external/bluetooth/bluez/audio/media.c:get_setting() Equalizer
CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed
The users of btio should not expect that btio will set the security
level to medium if it wasn't specified. Now, all the users specfify
the security level needed.
If HF has already requested for the Extended Error result code
reporting, then send the same in certain failure cases. Earlier in this
case we were sending normal error.
If pending connection will stay after state has been changed to
HEADSET_STATE_DISCONNECTED, then crash may happen (e.g. when hs_connect
will be called quickly again after that) To avoid that kind of problems
using headset_shutdown, which does necessary cleanup first (finalizes
pending connections) and after that changes state to
HEADSET_STATE_DISCONNECTED.
In gst_avdtp_sink_start(), if bt_audio_service_open() failed, there was
an attempt to close an invalid file descriptor (through
bt_audio_service_close()).
Variables which are assigned to the errno variable (usually called
"err") should be negative, and "-err" should be used where a positive
value is needed.
Variables which are assigned to the errno variable (usually called
"err") should be negative, and "-err" should be used where a positive
value is needed.
Variables which are assigned to the errno variable (usually called
"err") should be negative, and "-err" should be used where a positive
value is needed.
This commit also changes places where errno can be replaced with -err
(for consistency) and one perror() usage error.
Variables which are assigned to the errno variable (usually called
"err") should be negative, and "-err" should be used where a positive
value is needed.
Variables which are assigned to the errno variable (usually called
"err") should be negative, and "-err" should be used where a positive
value is needed.
This patch also fixes a bug related to not using an "err" variable to
store the errno value before calling external library code.
Currently, +CIEV indicator after AT+CHLD=0 command for one active call,
one held call, one incoming call scenario is incorrect. callheld=2
according to HFP 1.5 spec., p.70, means 'Call on hold, no active call'.
Hence, value 2 cannot be provided in +CIEV if there is an active call.
This happens in the following circumstance:
bluetoothd[30869]: audio/manager.c:hf_io_cb() Authorization denied!
(bluetoothd:30869): GLib-WARNING **: Invalid file descriptor.
Reported by Daniel Wagner <wagi@monom.org>
audio/avrcp.c: In function 'avrcp_unregister':
audio/avrcp.c:1253: error: implicit declaration of function 'g_slist_free_full'
thermometer/thermometer.c: In function 'destroy_char':
thermometer/thermometer.c:79: error: implicit declaration of function 'g_slist_free_full'
Section 5.4.1 of AVRCP 1.3 spec says:
If TG does not support SongLength And SongPosition on TG, then TG shall
return 0xFFFFFFFF.
SongPosition is always available, but song length depends on user to
provied it.
When registering for TRACK_CHANGED event, CT expects the track's UID in
the INTERIM and CHANGED responses. According to AVRCP 1.3 spec, there
are only 2 possible values:
1) 0: there's a track selected
2) UINT32_MAX: there's no track selected
AVRCP 1.4 reserves the value UINT64_MAX for the second case. Since this
later value is the one used in certification process for best IOP
we return UINT64_MAX instead of the former.
This implementation allows to pass PTS test TP/NFY/BV-05-C.
If we use the same hash table to set the new metadata, we have 2
undesired behaviors:
1) New track may contain fields from previous track if it didn't set all
the fields
2) If we fail on parsing the signal, we will still change some of the
fields
This fixes the same issue as in 8a6119ea1c685fc61419ee444a5967596f524c1c
but for CSD_CALL_STATUS_COMING. Call status change sequence in csd is
IDLE to COMING, COMING to PROCEEDING, and PROCEEDING to WAITING.
Returned 'state of the call' value after CSD_CALL_STATUS_COMING, as well
as after CSD_CALL_STATUS_PROCEEDING, in +CLCC shall be 5 (waiting, MT
call) instead of 4 (incoming, MT call) in maemo6 telephony driver for the
second incoming call.
Refactor code when we are 'listing selected attributes' to share code
with 'listing all attributes'. This way we always keep the list of
attributes in a GList, and call player_get_media_attribute() in only one
place.
When remote side requests all available metadata (i.e. it gives number
attributes equals to 0) do not return zero-length strings for
unavailable items. The only exception is title, that must be always present.
If list current calls is requested when there is second incoming call
and csd call status is CSD_CALL_STATUS_PROCEEDING, then returned 'state
of the call' value in +CLCC is 4 (incoming, MT call), which is incorrect.
Indication than proceeds from incoming to waiting state.
This patch sets the corresponding value to 5 (waiting, MT call) in
maemo6 telephony driver for the second call.
This fixes the following compilation error with GLib on 32-bit sytems:
audio/media.c: In function 'get_setting':
audio/media.c:1109:44: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
audio/media.c: In function 'set_setting':
audio/media.c:1132:41: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
Crash is caused by not removed freed player from the list:
Invalid read of size 8
at 0x13E7B5: media_adapter_find_player (media.c:861)
by 0x13FEBC: register_player (media.c:1561)
by 0x120DFE: process_message (object.c:224)
by 0x4F6E9A0: ??? (in /lib64/libdbus-1.so.3.5.6)
by 0x4F6092F: dbus_connection_dispatch (in /lib64/libdbus-1.so.3.5.6)
by 0x11F787: message_dispatch (mainloop.c:80)
by 0x4C762CA: ??? (in /lib64/libglib-2.0.so.0.3000.0)
by 0x4C74ADC: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.3000.0)
by 0x4C752D7: ??? (in /lib64/libglib-2.0.so.0.3000.0)
by 0x4C75824: g_main_loop_run (in /lib64/libglib-2.0.so.0.3000.0)
by 0x11EE4B: main (main.c:485)
Address 0x642ef30 is 16 bytes inside a block of size 80 free'd
at 0x4A0662E: free (vg_replace_malloc.c:366)
by 0x4C7B7F2: g_free (in /lib64/libglib-2.0.so.0.3000.0)
by 0x12D292: player_destroy (avrcp.c:1099)
by 0x120C38: service_filter (watch.c:477)
by 0x120950: message_filter (watch.c:527)
by 0x4F608E5: dbus_connection_dispatch (in /lib64/libdbus-1.so.3.5.6)
by 0x11F787: message_dispatch (mainloop.c:80)
by 0x4C762CA: ??? (in /lib64/libglib-2.0.so.0.3000.0)
by 0x4C74ADC: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.3000.0)
by 0x4C752D7: ??? (in /lib64/libglib-2.0.so.0.3000.0)
by 0x4C75824: g_main_loop_run (in /lib64/libglib-2.0.so.0.3000.0)
by 0x11EE4B: main (main.c:485)
Device object may exist but control wont be initialized causing the
following crash:
Invalid read of size 8
at 0x12B510: state_changed (control.c:90)
by 0x12BA20: avctp_set_state (avctp.c:367)
by 0x12C0DC: avctp_confirm_cb (avctp.c:733)
by 0x166481: server_cb (btio.c:200)
by 0x4E75ADC: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.3000.0)
by 0x4E762D7: ??? (in /lib64/libglib-2.0.so.0.3000.0)
by 0x4E76824: g_main_loop_run (in /lib64/libglib-2.0.so.0.3000.0)
by 0x11ED19: main (main.c:473)
Address 0x8 is not stack'd, malloc'd or (recently) free'd
If CT tries to change an Application Setting providing only one
setting, the size of the PDU will be 3 bytes. Therefore we should check
if the PDU is shorter than or equal 3, not only shorter.
If media attribute is not available for a certain media file, return an
empty string instead of rejecting the request. The spec is not so clear
if only the title should be handled as an empty string when not present,
but this is the only alternative to rejecting the request.
IOP tests showed that some CT devices don't like reject messages: they
never ask for an attribute again if they previously received a REJECTED
message for that attribute. They consider REJECTED as "TG doesn't
implement it these optional attributes" as opposed to what we had
before, "this attribute is currently not available".
Check on active call is added for playing of DTMF feedback tones to
notify user. Network DTMF tones are handled by modem, and therefore
there is no need in special check for those.
