Adapter: prevent race condition around sServiceLock
Since get_profile_use_lock, the onServiceConnected callback is running on the binder thread instead of bloating the main thread (use to block main app thread for ~200 ms which is not great). But because it doesn't post the event, it tries to complete its execution while holding some other lock, including sServiceLock during the onBluetoothOn. This lock is also use when getting the adapterService from BluetoothDevice. Prior to this change, both call are mutually exclusive, but both are only trying to access to the service value in read mode and they shouldn't be blocked. In an optimal world, no lock would be necessary, and BluetoothDevice wouldn't need to fetch a static adapterService binder. But this is a too big refactor, using a read/write lock is simple enough for this issue and doesn't change the behavior that much Bug: 373533897 Bug: 370815283 Flag: com.android.bluetooth.flags.get_profile_use_lock Test: m Bluetooth -- There is no race condition test written for Bt Change-Id: Id9bb4aea1a9f1ee4f282cff9fde703646e886585
Loading
Please register or sign in to comment