GitLab

This patch allows BTM inquiry and LE observe to be launched
and overlap each others' occurance by redirecting results
and handling states accordingly.

CRs-Fixed: 579505

Conflicts:
	stack/btm/btm_ble_gap.c
bug 12939764

Change-Id: Ifde73f17f8d40e9ebfff3b49e409591189574ee0

LE: Add status callback function for LE broadcasts

Change-Id: If4342050ce1141a9c2111286e7b3cccdc012a91e

bug:12003067
Change-Id: I74e4921047a27ee79fa1e3cd58056fde2958e60f

* changes:
  DO NOT MERGE BLE stack doesn't handle multiple l2cap_conn_update requests
  DO NOT MERGE sometime the BLE connection parameter isnot updated for the first time

Merge "DO NOT MERGE Remove the device from le backgrond connection whitelist when it's unpaired" into klp-dev

Merge "DO NOT MERGE BLE Secuity manager state machine generate wrong pairing success event." into klp-dev

this is to work around broadcom firmware problem to handle
unsolicited command complete event for HCI_LE_Create_Connection_Cancel
and LE connection complete event with status error code (0x2)
unknown connection identifier from bluetooth controller
the workaround is to release the HCI connection to avoid out of sync
with bluetooth controller, which cause BT can't be turned off.

bug:11614046
Change-Id: Ia5c5ad0c6c9b1a4f03253cac8a7caaf21341c88c

we can define 4 bits as flags:
1. L2C_BLE_CONN_UPDATE_DISABLE:
if set it means disable update connection parameter. otherwise enable
2.L2C_BLE_NEW_CONN_PARAM:
if set, it means we have new connection parameter which is needed to be configured
if possible(after update done or enable).
3.L2C_BLE_UPDATE_PENDING:
if set, it means waiting for connection parameter update finished.
this flag will be cleared in btu_ble_ll_conn_param_upd_evt.
will be set when we call btsnd_hcic_ble_upd_ll_conn_params
4.L2C_BLE_NOT_DEFAULT_PARAM:
if set, it means we don't use the default connection parameter.
so when we disable update,
we need to configure default connection parameter.
with these 4 flags, we can replace all these states:
UPD_ENABLED, UPD_DISABLED, UPD_PENDING and UPD_UPDATED.
so we can cover all the corner cases which aren't handled
by original code.

bug:11450715
Change-Id: I6673d4783a8063bf9e8a213c6669800f86e67945

When we receive the BLE connection parameter update
from remote device after smp_send_pair_req before
start BLE service discovery(bta_gattc_set_discover_st).
We will miss update this BLE connection parameter.
The reason is we call
L2CA_EnableUpdateBleConnParams(p_cb->pairing_bda, FALSE);
in smp_send_pair_req ,We change the state to UPD_DISABLED.

When we receive the new BLE connection parameter from
remote device, we will update the state to UPD_PENDING,
which will update the new connection parameter
when enable the connection parameter update.

when we start BLE service discovery
we call L2CA_EnableUpdateBleConnParams(p_srcb->server_bda, FALSE);
in bta_gattc_set_discover_st, We will update the state back to
 UPD_DISABLED, which will cause we miss updating
the new connection parameter when enable the connection parameter update.

The fix is don't change the state to UPD_DISABLED
when the state is UPD_PENDING for disabling.

bug:11727252
Change-Id: I953b9ca669e3460e18b340e7779cc54e03d6305b

When HID BLE device start encryption, if some other GATT application
already start encryption(but not finished yet) by calling
gatt_security_check_start. The HID BLE device will be failed to start
encryption, which will cause it to disconnect the BLE HID connection.
The solution is to check whether we already started the encryption
, If the encryption is already started, wait until the encryption
finished, then continue to start security check for BLE HID device.
add encrytion complete event to notify all GATT client encryption done.
filter the event just for BTA HH LE GATT client.

bug:11636246
Change-Id: If58e57c623cc8cfa05208587b010bec68c71306c

this is due to we didn't remove the device from the white list before unpair
Which cause a fake pair request from remote device triggered
right after the acl is disconnected.
The fix is to remove the BLE device from whitelist before unpair.
Also fix a problem return wrong device handle from bta_hh_le_add_device.

if bta_hh_le_add_device is called right after reboot, before we connect HID device.
This is normally true for a previous paired device, which we saved in the nvram.
The wrong device handle will cause the removing HID device from while list failed
after unpair the HID device.

bug:11676338
Change-Id: Id5b45b2829da9a990dfd1dbae0c15764b16c2bfb

 we call smp_proc_release_delay to setup a timer.
We will send a pair failure message to uplayer after the time expired.
Right before the time expire, the l2cap connection is disconnected
from remote device, we receive L2C_DISC, which will call smp_delay_terminate,
 smp_delay_terminate will send a pair success message to uplayer.
The fix is not to change the status if the remote device disconnect the link

bug:11716967
Change-Id: I8ca63599a170ec86913785aafea552301cec37df

When bluetooth is initialized which call gki_buffer_init,
the buffer pool is allocated by GKI_os_malloc which is
to call libc malloc function.
When bluetooth is cleanup which call GKI_shutdown,
the buffer pool will be  freed by GKI_os_free
which is to call libc free function.
So if we access the buffer, after the whole buffer pool is freed,
we will get this native crash.
if we call cleanup during bluetooth disabling:
the state is still BTIF_CORE_STATE_DISABLING,
then GKI_shutdown will call before bte_main_disable
( bt_hc_if->cleanup();), which is  before userial thread exit.
Then we may trigger this native crash.

bug:11793775
Change-Id: Ic8ced12848d25f918a28f4d5ba29b803d6ac5bd7

the HID device state is out of sync between java layer and bluedroid stack after upair.
This will cause the HID device can't be connected after repair.
YOu can find the following error message
E/HidService( 1452): Hid Device not disconnected: 00:15:9E:20:29:41

bug:11718702
Change-Id: I271bb77a2cc205c5a0ef396db86b87902d29966b

The follwoing code cause this problem:
BTA_HH_LE_RPT_INST_ID_MAP(s,c)=(UINT8)(((s)<<4)||(c))
The code use || instead of |, this cause we can only generate
two instance HID report 0 and 1(false and true).

bug:12213520
Change-Id: If6b7cfd9633255401aef12aafd918ee147f256b6

report array out of boundary when read HID report reference
descriptor for BLE HID device.

bug:12208657
Change-Id: Ic60fd7555045f367b4fcd606510f52f60e36995e

The Mat mouse have more than 10 report (11),
which exceed our limitation

bug:12214036
Change-Id: Id578bf7959f73dc3bd57664eccf49ab5580ec76b

BLE Scan needs to clean up the bt_config.xml periodically so that
new entries could be added to bt_config.xml. Also, there is no
need to add BLE Random bd_addr to the bt_config.xml

Change-Id: I00ba2e50dd39a021099052cb569786f6cb2cc8b9

b/12912008
(cherry picked from commit 377cb140)

Change-Id: I3fa0286c96782822a8fdac14b05bbb6f98636e50

Add support for UUIDs and custom service data in the advertising and
scan response records.

Cherry picking ble advertising changes from master to KLP MR2.
b/13137996

Change-Id: I6470427ad194871488cc90f3ab384b9ecf326b15

Currently the maximum number of parallel connections is 4. This patch
increases the limit to allow for more devices.
bug 11571899
Change-Id: I42b77e6b67f59d7d430d879a5fb0eb80982160b5

the root cause of the problem is:
In BLE GATT client state machine, When It is in discovery state,
any command to access the service, characteristic and descriptor
will be queued, these commands will be executed after BLE service
discovery complete. When we queue the command, we will copy these
message. The problem is we didn't copy these message correctly.
We didn't deep copy these messages. There are pointers inside
these messages. These pointers are still point to the old message
which are already freed. When the messages are reused, the original
content will lost. The queued commands will be corrupted.
This is very serious issue, which can cause a lot of stability problem.

bug:11620252
Change-Id: I93082a9dbcc3a676f5f791c2b1ea98e49b165813

bug 11591406

Change-Id: Ibb9c6b3865e6d757236f1c5896775bb6f28e47be

Ensure that the remote device type is set correctly by reading the
device information from non-volatile storage and (re-)adding it to
the inquiry database before connecting to a remote GATT device.
bug 11573208
Change-Id: Ifa69da3d5871aed5293ea5e611144874b67afe72

bug:11562902
Change-Id: I16ba8cfb727d05e5d324c6301ba0ab23e729232b

Host starts encryption twice when the remote device is
already paired. The host sends disconnect when the
second encryption attempt returns failure. This fix
avoids duplicate encryption attempt.

bug:11450719
Change-Id: I8ec5c4a953180ec17585aece757810421bc44aae

We are blacklisting all the devices that are not in whitelist
instead of blacklisting known bad devices.
bug 11124170

Change-Id: I044970df611d2a800d7698d4a63331644ab107ce