问题点4：Android BLE具体连接flow 并问询DB的API flow 之第一阶段问询；

当前确认原生BT当作为GATT Client 连接上GATT Server时，在连接上后会有自动启动问询的动作(以下Tracing 基于Android 9(P), 测试 8.1的代码和Android 8.0有差异；部分log在Android9中出现，但部分又在8中出现，所以8.1算是一个过渡版本)：

-->BlueDroid中，当BLE callback连接上时，触发的API 是bta_gattc_conn；

 

 -->执行到API bta_gattc_start_discover；

 -->执行启动第一阶段的第一包主服务问询动作，API 是：bta_gattc_discover_pri_service；

对应Sniffe Log中的“Read By Group Type Request +Attribute Type: Primary Service”

这里确认其实第一包的原因是：可以看到其设置的起始Handle值是1，最大值是0xffff;

 

-->最终调用API GATTC_Discover, API内部调用API gatt_act_discovery；

 

 -->执行API gatt_act_discovery，API内部此时填充opcode和attribute Type(即UUID)：

 

 -->因基于“问询-->收到回复-->启动下一次问询…”形式，

因此当执行gatt_act_discovery后，收到Remote GATT Server回复时，API

gatt_client_handle_server_rsp被触发；

因第一阶段问询使用的opcode是“Read By Group Type Request”，

在原生中的表示是GATT_REQ_READ_BY_GRP_TYPE；

所以response的opcode是：GATT_RSP_READ_BY_GRP_TYPE

 -->执行API gatt_process_read_by_type_rsp，在此函数里面最终执行“p_disc_res_cb”和“p_disc_cmpl_cb(在API gatt_end_operation中执行)”，

/***********************************************************************************/

GATT client在BlueDroid中的callback通过API GATT_Register注册 bta_gattc_cl_cback实现；

 /***********************************************************************************/

最终callback bta_gattc_disc_res_cback 和bta_gattc_disc_cmpl_cback被触发；

此时问询得到的DB通过API bta_gattc_add_srvc_to_list写入到缓存中；

 Attention：API gatt_process_read_by_type_rsp不止发送response callback那么简单，其还负责同一阶段的自动后续问询：

 如当前Sample第一阶段，从Sniffer Log中可以看到其问询了4次，但Code显示其只提供执行第一包问询的API bta_gattc_start_discover，后续3次的自动执行都是由

gatt_process_read_by_type_rsp中的API gatt_act_discovery完成；

小结：第一阶段问询，对应的启动API 是bta_gattc_start_discover，启动后自动问询在gatt_process_read_by_type_rsp中进行，当最后问询结束触发的API是：

bta_gattc_disc_cmpl_cback；

---其结束时将触发第二阶段的问询动作：bta_gattc_explore_srvc；