蓝牙连接是使用蓝牙的基础，那蓝牙断开可能就不完全是我们能够控制的。也就是说蓝牙链路的断开可能因为各种各样的原因，那本篇就带大家详解蓝牙断开的原因。
蓝牙链路也就是蓝牙专业人士说的ACL链路，所有的蓝牙操作都是在此基础上进行的，一旦ACL断开，那蓝牙功能必定无法使用。但蓝牙断开的原因很多，具体是啥原因？我们从何获取？带着这些疑问我们开始吧。
BluetoothDevice类中定义了ACL断开的广播为：
<code>/**
* Broadcast Action: Indicates a low level (ACL) disconnection from a
* remote device.
*Always contains the extra field {@link #EXTRA_DEVICE}.
*ACL connections are managed automatically by the Android Bluetooth
* stack.
*Requires {@link android.Manifest.permission#BLUETOOTH} to receive.
/<code>
*/
@SdkConstant(SdkConstantType.BROADCAST_INTENT_ACTION)
public static final String ACTION_ACL_DISCONNECTED =
\t\t\t "android.bluetooth.device.action.ACL_DISCONNECTED"；
广播里的内容只包含了远端设备BluetoothDevice，无法知道ACL断开的具体原因，那就让我们从底层到上层梳理下ACL断开完成事件上报流程中是否有reason这个参数。
查看蓝牙协议Core_v5.0.pdf里Vol 2, Part E中的7.7.5的HCI事件Disconnection Complete Event:
协议里详细规定了上报ACL断开完成事件时是必须带有断开原因的参数，所有我们跟着ACL断开完成事件的上报流程来追踪reason参数存储在何处，下图为详细的上报时序图：
ACL断开完成事件的处理在bluedroid中有将reason保存，但最后回调上报JNI时却没带上该参数，导致蓝牙服务层没法知道断开原因。
到这里我们大致清楚ACL断开的reason还被保存在bluedroid中，没有上报给服务层，只需在合适的地方将该参数通过回调的方式上报给蓝牙服务即可。蓝牙服务广播ACL断开时添加reason参数就可被应用获取到断开原因，应用根据不同的断开原因采取不同的操作来完善蓝牙功能。
閱讀更多 Connectivity 的文章
