android/hal-bluetooth.c: In function ‘set_adapter_property’:
android/hal-bluetooth.c:659:46: error: taking address of packed member of ‘struct hal_cmd_set_adapter_prop’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
659 | adapter_prop_from_hal(property, &cmd->type, &cmd->len, cmd->val);
| ^~~~~~~~~
Android 5.0 uses service name (sic!) for defining instance ID and
supported message types. Name passed is in format of "XXYYname"
where XX is hex coded instance and YY is hex coded message types
mask.
This patch adds new mode for Socket HAL in which daemon tries to
extract instance ID and message types from service name.
When doing the HAL cleanup the callbacks should be reset to NULL
after calling hal_ipc_unregister otherwise an handler may be called
leading to invalid reads:
BlueZ D: android/hal-a2dp.c:cleanup()
bluetoothd[2624]: android/avdtp.c:connection_lost() Disconnected: Input/output error (5)
bluetoothd[2624]: android/avdtp.c:avdtp_ref() 0x5841900: ref=2
bluetoothd[2624]: android/a2dp.c:bt_a2dp_notify_state() device 00:AA:01:01:00:00 state 0
==2564== Thread 3:
==2564== Invalid read of size 8
==2564== at 0x6B66B47: handle_conn_state (hal-a2dp.c:38)
==2564== by 0x6B6CDB3: notification_handler (hal-ipc.c:125)
==2564== by 0x5368EE4: start_thread (in /usr/lib64/libpthread-2.18.so)
==2564== by 0x5672B8C: clone (in /usr/lib64/libc-2.18.so)
==2564== Address 0x8 is not stack'd, malloc'd or (recently) free'd
This role was introduced with some devices in Android 5. The same set
of IPC structs and defines is used as in Sink as it uses the same HAL
API as Source does, but just yet another instance of HAL.
Add parameter to create_bond following new bluetooth.h HAL, transport is
defined in bluedroid include/bt_types.h. Bluetooth daemon shall check
transport parameter and make needed decisions, by default parameter is
unknown and this is the way bluedroid manage it itself.
HAL was sending extra byte at the end of command. Refactor code to
use pointer + offset and avoid less intuitive pointers subtraction.
Syscall param sendmsg(msg.msg_iov[1]) points to uninitialised byte(s)
at 0x53529BD: ??? (syscall-template.S:81)
by 0x6D96197: hal_ipc_cmd (hal-ipc.c:369)
by 0x6D8D41E: send_configuration (hal-bluetooth.c:453)
by 0x6D8EC16: init (hal-bluetooth.c:489)
by 0x412B20: setup (tester-main.c:1411)
by 0x40CE05: setup_callback (tester.c:394)
by 0x5083CE4: g_main_context_dispatch (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.4000.0)
by 0x5084047: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
by 0x5084309: g_main_loop_run (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.4000.0)
by 0x40DB4C: tester_run (tester.c:815)
by 0x40259E: main (tester-main.c:2335)
Address 0xffefffe31 is on thread 1's stack
This patch also introduce BLUEZ_EXTENSIONS flag which is used for not
Android AOSP features like HF Client in this case.
Idea is that BfA for PC is always build with this flag and it is added
to Makefile.am
For Android there is need to set this flag as described in README
This fix following Valgrind report:
Syscall param sendmsg(msg.msg_iov[1]) points to uninitialised byte(s)
at 0x534823D: ??? (syscall-template.S:81)
by 0x5F68689: hal_ipc_cmd (hal-ipc.c:357)
by 0x5F6240B: init (hal-bluetooth.c:437)
by 0x4128C0: setup_base (android-tester.c:2594)
by 0x40DDE5: setup_callback (tester.c:380)
by 0x50803B5: g_main_context_dispatch (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x5080707: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
by 0x5080B09: g_main_loop_run (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x40EA0C: tester_run (tester.c:798)
by 0x404475: main (android-tester.c:4864)
Address 0x7ff0002b1 is on thread 1's stack
This header contains IPC specific structures and code not related to
BT and audio HAL protocols. This allows to fully decouple IPC from
HAL messages.
This is first step to make HAL part of IPC unit-testable and reusable
between BT HAL and audio HAL.
This removes compatibility with Android 4.3 and older. Android 4.4 is
current target. Due to bug in Audio HAL in 4.2 build was failing on
that version anyway.
This allows to correctly handle remote version info property. Although
this property is marked as get/set in HAL only get is implemented as
I fail to see how this property could be settable.
