title: BLE stack repeatedly reconnects to peripheral after connection is closed and app terminated
body: <p>I have an app that opens a short-lived connection to a BLE device, does some characteristic read and writes, and then disconnects and closes the connection. The app uses autoReconnect=false, and the device is not paired or bonded.</p>
  
  <p>I am seeing some very weird behavior by Android, which seems to repeatedly and unexpectedly reconnect to the peripheral, even after the connection is close()d, the app killed or even uninstalled.</p>
  
  <p>This issue has been previously linked to Spotify triggering the reconnects (see: <a href="https://stackoverflow.com/questions/43160195/android-ble-unexpectedly-and-repeatedly-reconnects-to-peripheral">Android BLE unexpectedly and repeatedly reconnects to peripheral</a>), but in my case, this happens even <strong>without Spotify being installed</strong>.</p>
  
  <p>The devices on which this can reliably reproduced are:</p>
  
  <ul>
  <li>Google Pixel, Android 8.1</li>
  <li>LG Nexus 5X, Android 7.1.2</li>
  <li>Samsung Galaxy S7, Android 7.0</li>
  <li>Samsung Galaxy S6, Andorid 6.0</li>
  </ul>
  
  <p>Connections are short-lived and last around 3 seconds. I can verify that connections are made because the peripheral provides visual indications and log outputs of its connections.</p>
  
  <p>I'm pretty stumped as to what might cause the repeated reconnects, as the logcat of the BLE stack does not give a hint as to who or what caused the connection. The logcat output of the Bluetooth service (com.android.bluetooth) for one connect/disconnect cycle on the Nexus 5X running 7.1.2 looks as follows:</p>
  
  <pre><code>05-15 10:36:55.428  6397  7029 W bt_smp  : smp_br_connect_callback is called on unexpected transport 2
  05-15 10:36:55.428  6397  7029 W bt_btif : bta_dm_acl_change info: 0x0
  05-15 10:36:55.428  6397  7029 E bt_btif : bta_gattc_cache_load: can't open GATT cache file /data/misc/bluetooth/gatt_cache_c4be844851e9 for reading, error: No such file or directory
  05-15 10:36:55.428  6397  6526 D bt_btif_dm: remote version info [c4:be:84:48:51:e9]: 0, 0, 0
  05-15 10:36:55.432  6397  6526 E BluetoothRemoteDevices: state12newState0
  05-15 10:36:56.141  6397  7029 W bt_bta_gattc: bta_gattc_explore_srvc no more services found
  05-15 10:36:56.141  6397  7029 I bt_bta_dm: bta_dm_gatt_disc_result service_id_uuid_len=2 
  05-15 10:36:56.141  6397  7029 I bt_bta_dm: bta_dm_gatt_disc_result service_id_uuid_len=2 
  05-15 10:36:56.142  6397  7029 I bt_bta_dm: bta_dm_gatt_disc_result service_id_uuid_len=2 
  05-15 10:36:58.185  6397  7029 W bt_btif : bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016
  05-15 10:36:58.185  6397  7029 W bt_btif : bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016
  05-15 10:36:58.185  6397  7029 W bt_btif : bta_gattc_conn_cback() - cif=5 connected=0 conn_id=5 reason=0x0016
  05-15 10:36:58.185  6397  7029 W bt_btif : bta_gattc_conn_cback() - cif=6 connected=0 conn_id=6 reason=0x0016
  05-15 10:36:58.185  6397  7029 I bt_btm_sec: btm_sec_disconnected clearing pending flag handle:5 reason:22
  05-15 10:36:58.187  6397  6526 E BluetoothRemoteDevices: state12newState1
  05-15 10:36:58.199  6397  6397 D BluetoothMapService: onReceive
  05-15 10:36:58.200  6397  6397 D BluetoothMapService: onReceive: android.bluetooth.device.action.ACL_DISCONNECTED
  </code></pre>
  
  <p>My main avenue of debugging currently is flashing AOSP on the Pixel and adding extra log statements to the BT stack. So far the problem has not appeared on AOSP though (of course), which leads me to believe that some 3rd-party or Google service may be responsible.</p>
  
  <p>Any idea how to trace this down? Currently only cycling Bluetooth helps. </p>