HID: Fix forced disconnection flow.
In some cases, we end up in a state where we can neither connect nor forcefully end connection, and will require disabling the Bluetooth adapter to fix this state. When a device is taking too long to connect (or out of range), the user may want to cancel the connection by calling disconnect method, which will be ignored in any state other than BTA_HD_CONN_ST. It is a lot better to immediately cease the connection process at this point, so: - BTA_HD_API_DISCONNECT_EVT is now not ignored in BTA_HD_IDLE_ST; - bta_hd_disconnect_act now reports a correct MAC address during disconnection (it used to send 00:00:00:00:00:00 before); - HidDevDisconnect now allows to forcefully end the connection, and does it in exactly the same way we handle the errors. When L2CAP connection fails, both hidd_l2cif_config_ind and hidd_l2cif_config_cfm set conn_state to HID_CONN_STATE_UNUSED, which is immediately overwritten by the hidd_conn_disconnect call (it will set conn_state to HID_CONN_STATE_DISCONNECTING, because ctrl_cid != 0 in both cases), thus making any subsequent calls to connect failing with "already connecting" error. More than that, all functions send the HID_DHOST_EVT_CLOSE event when failing, which is, again, ignored in the BTA_HD_IDLE_ST state. So: - BTA_HD_INT_CLOSE_EVT is now not ignored in BTA_HD_IDLE_ST; - conn_state is set to HID_CONN_STATE_UNUSED after the call to hidd_conn_disconnect, but before sending the close event. Test: Build, run, connect/disconnect multiple times. Change-Id: I85bb03f760bb9a6fd4c1b944d515232c1be12300
Showing
- system/bta/hd/bta_hd_act.cc 4 additions, 4 deletionssystem/bta/hd/bta_hd_act.cc
- system/bta/hd/bta_hd_main.cc 2 additions, 2 deletionssystem/bta/hd/bta_hd_main.cc
- system/stack/hid/hidd_api.cc 8 additions, 0 deletionssystem/stack/hid/hidd_api.cc
- system/stack/hid/hidd_conn.cc 2 additions, 2 deletionssystem/stack/hid/hidd_conn.cc
Loading
Please register or sign in to comment