This patch refactor a bit select_device_bearer function so we can get
debug log out of it. This log might be very useful in dual mode devices
scenarios
In a case get_app(), get_device(), get_channel() fail prevent
dereference of NULL pointer. Fixes clang warnings:
...
android/health.c:1980:15: warning: Access to field 'dev' results in a
dereference of a null pointer (loaded from variable 'channel')
queue_remove(channel->dev->channels, channel);
^~~~~~~~~~~~
1 warning generated.
...
So far BfA updates android bond state after link key(s) are
distributed. With LE pairing it might happen that no keys are
distributed e.g remote device has Initiator Key Distribution and
Responder Key Distribution set to 0. In such case link is encrypted
with STK and after its disconnected, pairing needs to be done again.
With this patch Android will get update about pairing complete just
after BfA gets pairing complete from the kernel. It solve issue withnot
updated Android settings application, which is hanging on "Pairing", in
case when no keys are distributed.
However, bacause Android does not see the difference between bonded /
paired devices and because Android does not allow to update its bond
state if FSM it is not in 'pending' state, BfA updates Android with
BONDED state on pair_complete with success. This is how we are doing
so far for bonding and non-bonding pairing.
Note: BfA will update its bonded state after link key(s) are
distribiuted.
Previously used connection procedure was to slow for remotes preforming
directed advertising. This issue is no longer valid on the latest kernel
and auto connection support added recently to the daemon.
If device is dual mode and can be seen on both LE and BREDR, then
bdaddr_type in device struct keeps LE address type of that device.
During discovery, we should take current bdaddr_type to decide about
passing that device up to application or not. Using dev->braddr_type might
be misleading
This patch fix scenario when remote device is known as LE device and
recently has been found on inquiry seesion as DUAL mode device. In such
case, based on braddr_type and eir flags we could incorectly skip
new device notification for Android framework.
When trying to reconnect to HDP device, BfA tries to connect MDL even
MCL is not connected.
D/BlueZ ( 2218): external/bluetooth/bluez/android/hal-health.c:connect_channel()
I/bluetoothd( 2220): bluetoothd[2221]: external/bluetooth/bluez/android/health.c:bt_health_connect_channel()
I/bluetoothd( 2220): bluetoothd[2221]: external/bluetooth/bluez/android/health.c:create_channel() mdep 1
D/BlueZ ( 2218): external/bluetooth/bluez/android/hal-bluetooth.c:handle_acl_state_changed() state 0
I/bluetoothd( 2220): bluetoothd[2221]: external/bluetooth/bluez/android/mcap-lib.c:mcap_create_mdl()
I/bluetoothd( 2220): bluetoothd[2221]: health: error creating mdl MCL is not connected
This patch makes sure that MCL is connected before trying to connect
MDL.
Fix typo not initializing variable. Silence warnings:
...
/android/tester-hdp.c: 71 in create_app()
/android/tester-hdp.c: 97 in create_app()
...
>>> Using uninitialized value "mdep2". Field
>>> "mdep2.mdep_description" is uninitialized.
71 reg->mdep_cfg[1] = mdep2;
...
>>> Using uninitialized value "mdep2". Field
>>> "mdep2.mdep_description" is uninitialized.
97 reg->mdep_cfg[1] = mdep2;
...
