The canonical location of certain parts of the source tree live in
AOSP, and should not be changed internally to avoid merge conflicts.

WARNING only: The PREUPLOAD script warns developer if the change is
not uploaded on AOSP.

Test: create a CL in master and upload
Change-Id: I9a100d86d31ef35d1f4617c75d523724acf8ae60

am: 083f0667

Change-Id: I5c7cc270f7eec0db9113c9e0a553717efc80ed0b

am: 49959855

Change-Id: I9190e34e891c25029053bf58cc670e5294d08d5d

am: de9b8ce8

Change-Id: I83a997cf14a05c7dd3fbfae39ec5d5f3e5e1c491

am: b74a643f

Change-Id: I2a7c1b6b5a407bc9bb4416f091e8fc530cc61008

am: 315dcd4f

Change-Id: I1b56c78e07e5bdf8f2f7b5f440be6c32aecbbc72

am: f4111d66

Change-Id: Ia5eec4b42696be63342ad1836316e55e126fdeb7

am: 118e1771

Change-Id: Id261b2d0886d9be5bd409bd96e6126000b7b13cf

Bug: 112164711
Test: Run native test net_test_avrcp
Change-Id: Iace287bb716b28eda62a8a0500deb99cc46ae485

am: 017c7e02

Change-Id: I340a9f20348fb588fa9feac2cc327e1b8f649387

am: 08720ac7

Change-Id: Ie00925ac157fc98280eb2e519f357ebc22b9f12b

Trying to get the Browsing MTU before the Browsing channel is opened
returns the minimum MTU. This leads to smaller browsing messages than
expected.

Bug: 113160447
Test: Connect to device and see that Avrcp Browse packets are the
correct size

Change-Id: Iefda855d0a777439a8a6829619bc4c5543b62eaf

am: 19c5aeef

Change-Id: I2ef3b1f3acba41af7c369366ca5b1b54162901d1

am: ee0b1a1f

Change-Id: Ibcaa788024472424d5121b26239e2281ede6209c

am: 7fc931a4

Change-Id: I9e48df80f044f702c8819d1f7ebe3e62a78f2655

* Rename threads:
  - module_wrapper -> bt_module_lifecycle_thread
  - btif_a2dp_sink_worker_thread -> bt_a2dp_sink_worker_thread
  - btif_a2dp_source_thread -> bt_a2dp_source_worker_thread
  - bt_jni_workqueue -> bt_jni_thread
  - stack_manager -> bt_stack_manager_thread
  - hci_thread -> bt_hci_thread
  - bt_workqueue -> bt_startup_thread
  - btu_message_loop -> bt_main_thread
* Rename functions:
  - do_in_bta_thread -> do_in_main_thread
  - get_message_loop -> get_main_message_loop
  - post_to_hci_message_loop -> post_to_main_message_loop
* Refactored bta_sys_sendmsg

Bug: 110303473
Test: make, unit test, stream music
Change-Id: I3051f6ea2d33db37af8eebafba7db4d1e113f611

* std::promise and std::future are able to achieve the same
  functionalities of ExecutionBarrier with extra flexibility
* Replace "_barrier" with "_promise" in system/bt/common

Bug: 110303473
Fixes: 112159657
Test: mm -j40, unit test
Change-Id: I2a420bbf16bf92e4b3dd256d9f23480fc2be7be1

am: 766833df

Change-Id: If4c583a52011e30ccf623ef74a50bdbc1b5910a9

am: ce44a08d

Change-Id: I3c5e817905d2e05403d0a43a3f35231fd19e367e

am: 34bd633f

Change-Id: I95f2f701a2ebb3c5f28e8f2bbae06e553a8dbd55

am: a6c50189

Change-Id: Id894b30247945a89841ec2303830c7de87d15112

am: f09a6618

Change-Id: I16309df0ce191c429359470b52c4ac099f8884ea

am: 967a15bb

Change-Id: I8aeac160d9b537ecdcd92836d7c36f1e26b215e1

All JNI callbacks must be on the JNI thread, otherwise this could
impact the threads' operation.

Bug: 111277984
Test: A2DP streaming
Change-Id: I94fa4500aea62a574c80749e904434e46eb4e942

* libbt-osi is being deprecated and libbt-common will replace it
* Move recently implemented metrics library to libbt-common
* Move time library from libbt-osi to libbt-common and renamed as time_util
  to avoid potention name collision with system time libraries
* Need to keep time library for now because we need to use
  CLOCK_BOOTTIME that include system suspension time for A2DP encoding
* Use libchrome logging methods in metrics library
* Put both metrics and time_util into bluetooth::common namespace
* Return uint64_t for time_get_os_boottime_ms and update various
  receiver types
* Remove tBTM_CB.max_collision_delay and use the constant
  BTM_SEC_MAX_COLLISION_DELAY instead

Bug: 111568640
Test: mm -j40, unit test, stream music
Change-Id: I8c384a810d592bb6b9eb322134e947d066489ba4

am: e2f042d0

Change-Id: I1d5881e37683cc58454e0712dfe5b706376f78a0

am: 7de7fc52

Change-Id: I6d1c17c7dd6721cb7ed541b1b26b9816789a120a

am: 60d81a55

Change-Id: I62c000ac87b56b2d59f4054e57c12126ad653abc

Test: compiles
Bug: 112146072
Change-Id: Ie9e10d727edc652865458298cb59a24ac5732c98

am: 3810c829

Change-Id: Icca9f5dd7a10772204ec08c5c464b4426725e18b

am: 9b1f6264

Change-Id: I67c0eb42639400c6c2c11bfad91e84a3b8515b35

am: 197aeea2

Change-Id: Ia77d3021fc07af620abd706d9fdd83dbd3754424

am: bb45e8fa

Change-Id: Ib7d281fa6e50e0ee7cf75b552d829e2e8d4134ba

am: 42bbbc66

Change-Id: If4ab0c796fb4812e44f2b24df5d513f2195d06fc

am: c319c30f

Change-Id: Ia60a75778714b48f038c2de77f239f16e3149255

Precondition:
1. DUT acts as GATT server.
2. Remote acts as Gatt Client

Use case:
1. Remote device starts BLE scan
2. Remote device connects to DUT
3. Remote device keeps on sending notifications to DUT

Expected result:
Connection should be active after 18 hours

Observed Result:
Connection is dropped after 18 hours due to l2c_link_timeout.

Root Cause:
L2CAP is not properly handling no idle timeout(0xFFFF) and 65535000 ms
timer gets started after BLE connection, leading to connection getting dropped
after 18 hours.

Fix:
If there is no L2CAP dynamic ccb and no idle timeout is configured for
GATT or any other fixed  channel, then cancel existing LCB timer.

Test: No BLE disconnection seen after 18 hours

Bug: 112249120
Change-Id: I58766564cf62efb7af0869035115459bae37c558

For the hearing aid profile and when we get disconnection
while there is a pending connection update, then clear the flag so that
the next connection update can proceed.

Bug: 112050972
Test: Manual test to check for regressions
Change-Id: I54635a680cf276cf6c9f94520943c3efa97e77ec