IssueTracker

Environment:

1. An Android phone running an app that acts as GATT a client.

   • Reproduced mostly on lower-spec phones, e.g. Samsung Galaxy A15, Android 14.

2. A BLE peripheral device that acts as GATT server.

Steps to reproduce

1. Setup the BLE peripheral to have a GATT service with two characteristics:
   • char_0101, properties: indicate
   • char_0102, properties: read
2. Setup an app on the Android phone to act as a GATT client.
3. Connect the Android phone as a central to the peripheral device and discover services on it.
4. Send a read request of char_0102 from the Android app to the peripheral device.
5. Send a read response of char_0102 from the peripheral device with payload_1.
6. Send an indication of char_0101 from the peripheral device with payload_2 immediately after sending the read response. Make sure both the read response and the indication are sent out within 10ms or less.

Expected result The Android app received the onCharacteristicRead() callback with payload_1, and then onCharacteristicChanged() with payload_2. So that the app received payloads in the same order as the remote device sent them.

Actual result The Android app received onCharacteristicChanged() callback with payload_2 first, and then onCharacteristicRead() with payload_1. Which effectively swapped the order of payloads as they came to the app. The phone HCI log (see phone-hci-log.png attached) shows that the read response and the indication came to the phone in the correct, intended order. See actual-behavior-diagram.png for a visual explanation.

Probability of occurrence: 1-10%.