Snapshot 09118679ff7861de0fe2b742591e5d6aadba3fcc

Change-Id: I35cdb320673d847d8122bc03b9832d13673ea208
Snapshot 9fd57cbacd95e89602f430244c35bbc67f08b6d2

Change-Id: Ibc3a4bf4161d286c7cfab89a19c676eb5cc9224f
fixed rfc resouce leaking and multi-session issue

also added more debug messages
bug 7486080

Change-Id: Ic21e9d2df5f651b51ea2126a3cac25811808dcfb
fix too small buffer

property_get must be called with a buffer of at least
PROPERTY_VALUE_MAX len. The supplied buffer is too small.
Fixed.

Change-Id: I6c6b3050b30f6aa5ece69888263394e572551aff
fix bt_hc_worker_thread() sometimes transmit more than num_hci_cmd_pkts

bt_hc_worker_thread() checks the controller's outstanding HCI
command credits (maintained in num_hci_cmd_pkts) and skips the rest
of the tx queue after it has used up the credits. But the skip
condition is not correct in the loop:

      if ((tx_cmd_pkts_pending == TRUE) || (num_hci_cmd_pkts <= 0))
      {
          tx_cmd_pkts_pending = TRUE;
          // skip the rest of the packets in the tx queue
          ...
      }

Since num_hci_cmd_pkts doesn't change during the loop, this condition
never becomes true. As a result, all the HCI commands in the tx queue
are sent if num_hci_cmd_pkts > 0. That is why sometimes more than
num_hck_cmd_pkts are sent.

To check a correct skip condition, we should count how many HCI
command packets are being sent:

      if ((tx_cmd_pkts_pending == TRUE) ||
          (sending_hci_cmd_pkts_count >= num_hci_cmd_pkts))

sending_hci_cmd_pkts_count is incremented every time a HCI command is
pushed for sending. It should never go beyond num_hci_cmd_pkts.

Change-Id: I58101b2785fc3ab4171cdf22497ca97a3ae3124a
Signed-off-by: Toshi Kikuchi <toshik@google.com>
am 6ff9944c: fix bt_hc_worker_thread() sometimes transmit more than num_hci_cmd_pkts

# Via Toshi Kikuchi
* commit '6ff9944c9dda368fd79ebdf8d6748fc4922eafec':
  fix bt_hc_worker_thread() sometimes transmit more than num_hci_cmd_pkts
Resolved partial uipc channel read issue

When partial data is read the previously read size wasn't
compensated for.  Ensure we don't transmit empty a2dp frames in case
of underrun
Bug 8026551

Change-Id: I4195ed798008378b93343bf7cd266c6e2f11b094
Fixed unpair and reconnect issue with certain non-pointing hid devices

Hid info would not be removed from storage if COD is
NON_KEYBOARD_NON_POINTING. Due to this the device will
be added to stack even if it is unpaired and subsequent connections
will fail.
bug 8055549

Change-Id: Ib493fc165120de3c71398f5fe24b17f31fa5fc3e
Cancel device search before starting SDP

Also update bonding state when acl link goes down during bonding
b/8120036
Change-Id: I28e4cb6f35e4c524b7a67281e78a196ba1fce0cb
Initial version of BLE support for Bluedroid

Change-Id: I9825a5cef9be2559c34c2a529b211b7d471147cf
bluedroid: use correct header file.

Change-Id: Ia536e42e24fcc0491a16b160cd5b00189024e0f0
Merge "bluedroid: use correct header file."
am 6c1b8172: Merge "bluedroid: use correct header file."

* commit '6c1b8172756dc99348bf87b8d19e44e88bb1c57e':
  bluedroid: use correct header file.
am 93a2edbf: am 6c1b8172: Merge "bluedroid: use correct header file."

* commit '93a2edbfe42df2dbeb436e0a2a5278367f6d5381':
  bluedroid: use correct header file.
Remove bluedroid configuration warning

This warning is fired on every full-eng build.  It seems excessive
given that there are very few other warning fired on a full-eng build
and 0 seems like a reasonable goal to shoot for.

Change-Id: I2fb2b5342dee35b3ed05343466309f6c335022ef
Merge "Remove bluedroid configuration warning"
am c30f9355: Merge "Remove bluedroid configuration warning"

* commit 'c30f9355997082a7a3479e8b21f0440bb822c4ac':
  Remove bluedroid configuration warning
am 04c1c088: am c30f9355: Merge "Remove bluedroid configuration warning"

* commit '04c1c0883c0833f5cd1190446baa58d6c04018da':
  Remove bluedroid configuration warning
LE fixes

- Null pointer exception check added.

An exception occurs at the memcpy in the bta_dm_gatt_disc_result.
User removed the battery on Ble device(Smart Nudge) during bonding
and connection. This exception occurs sometimes.
I used Broadcom LE Explorer to reproduce it.

- Fixed disconnect and encryption behaviour

Disconnect will now disconnect the physical link immediately when no
other application is interested in the device anymore. Also, the
connection to a remote device is now dropped if encryption fails.

- Deep copy buffers when transfering context

Certain BTA server event types require a deep copy of the request
data buffers when transfering context. Shallow copy of the pointers
involved may cause a crash when overlapping read and write requests
are received.

- 2nd encryption has not started

need to send encryption complete callback
when the encryption fail due to link drop without a complete event.
Otherwise BTA layer would not be able to clean up the status,
and no further encryption can be started.

Change-Id: If93e0a188e8779830c8991e4193b96dc95e23e5d
Initial version of Stack for AVRCP 1.3

BTIF and stack changes for supporting AVRCP 1.3

Change-Id: Id02eb7b6a385683cedc41c62b6f829f5d7620bd4