Info is now stored for all devices and bond state depends on file.
Based on that devices loaded from storage are put either to cache
or to bonded_devices list.
Bonded devices are permament until unbondedn. Non-bonded devices will
be held in (size limited) cache based on timestamp property so split
list to ease separation.
Elements on list are struct device not bdaddr_t so make comparing
function use proper types. This was working so far only due to
bdaddr_t being first element in struct device.
JNI code in Android is mapping returned code to boolean value. Only
SUCCESS status is mapped to true and that value is returned to Java
code. This could result in faultyly triggering error path in Java
when returning DONE in command reply.
Print command opcode in handle_le_test_mode_cmd and
handle_dut_mode_send_cmd. This is valuable information on what kind
of HCI command the Java layer tries to send.
This allows to enable and disable DUT mode. This is special mode so
adding more info from related kernel commit:
"The Device Under Test (DUT) mode is useful for doing certification
testing and so expose this as debugfs option.
This mode is actually special since you can only enter it. Restoring
normal operation means that a HCI Reset is required. The current mode
value gets tracked as a new device flag and when disabling it, the
correct command to reset the controller is sent."
Groups and key file were not free on function return. This fix
following valgrind reports:
34 (16 direct, 18 indirect) bytes in 1 blocks are definitely lost in
loss record 33 of 77
at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
amd64-linux.so)
by 0x4E81DD0: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so
.0.3800.1)
by 0x4E74BF1: g_key_file_get_groups (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x40CDFA: read_info_complete (bluetooth.c:1672)
by 0x40827C: request_complete (mgmt.c:221)
by 0x4085E9: received_data (mgmt.c:319)
by 0x4E7C3B5: g_main_context_dispatch (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x4E7C707: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
by 0x4E7CB09: g_main_loop_run (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x403B15: main (main.c:439)
1,633 (72 direct, 1,561 indirect) bytes in 1 blocks are definitely lost
in loss record 75 of 77
at 0x4C2A2DB: malloc (in /usr/lib/valgrind/
vgpreload_memcheck-amd64-linux.so)
by 0x4E81DD0: g_malloc (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x4E9796D: g_slice_alloc (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x4E97EAD: g_slice_alloc0 (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x4E746DA: g_key_file_new (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x40CDD4: read_info_complete (bluetooth.c:1667)
by 0x40827C: request_complete (mgmt.c:221)
by 0x4085E9: received_data (mgmt.c:319)
by 0x4E7C3B5: g_main_context_dispatch (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x4E7C707: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
by 0x4E7CB09: g_main_loop_run (in /lib/x86_64-linux-gnu/
libglib-2.0.so.0.3800.1)
by 0x403B15: main (main.c:439)
This allows to store information about remote device. For now this is
stored only for bonded devices. Currently stored data includes devices
ddress, type, name, friendly name, class and uuids.
This patch adds initial support for storing adapter configuration.
Currently stored data is address, name and discoverable timeout.
Since Android daemon storage format is to be simpler than Linux check
if correct adapter is used before going operational. This is
a precaution to avoid e.g. using linkkeys generated for different
controller.
Adapter property notification are send from multiple places so it make
sense to have helper for that. This is especially usefull for 'simple'
properties.
Remote device property notification will be send from multiple places
so it make sense to have helper for that. This will be especially
usefull for 'simple' properties.
Rename send_remote_device_name_prop to get_device_name and make it
accept struct device as parameter. Also return HAL status code.
This will allow to use this function also in get device property
command handler.
This match adapter properties handling functions with properties names.
Will make code easier to understand and avoid clashes with remote
device properties functions.
Currently eir_parse always return 0 but it is checked throughout the code
(in android/bluetooth code as well in src/adapteri, etc) for return value
(err < 0) which never happens. Make function eir_parse return void. This
fixes warnings from static analyzer tools.
There is no need to sending set_discoverable command if new settings
are not connectable as clearing connectable also clear discoverable.
Sending set_discoverable when not connectable result in 'rejected'
mgmt response.
This fix issue with sending invalid success response from several
places where ipc_send_rsp was used for reporting success. Instead of
using using ipc_send for success response, make helper handle that.
This makes function flow easier to follow and understand. Besides that
it also fix issue with sending to many bytes if some prop were not
present in EIR.
Before sending any ssp request or pin code request up to HAL library we
need to send bond state change with bonding state. Otherwise incoming
bonding is not correctly handled by Bluetooth.apk.
In this patch also device list has been added in order to e.g track
bonding state.
Note: For incoming paring (security mode 3) there is a need to send
HAL_EVE_REMOTE_DEVICE_PROPS before HAL_EV_PIN_REQUEST.
It is because Android will crash due to bug in pinRequestCallback
function in java. Android checks if device is already in HashMap and if
not then creates device, but forget to use that one, but instead do
operations on NULL. By sending HAL_BOND_STATE_BONDING event it works
better but we have race issue. It is because new device is added to
HashMap not in callback context but later after BONDING msg will be
received by BondStateMachine. If it happens before pin_request_cb hits
java then we are fine, otherwise not. So for that reason we send
HAL_EV_REMOTE_DEVICE_PROPS so in the java handler class new device will
be added to HashMap in the callback context.
In ssp case we don't have this problem as we send device found once acl
is created.
