Android BLE GATT Status Diagnosis

Step 1: Frame the failure without naming a cause

1. DEFINE initial direct-connect failure | auto-connect stall | disconnect after connection | service-discovery failure | operation status failure | timeout | stale callback | retry storm | OEM-only issue | persistent system-wide failure.
2. CAPTURE exact callback/API stage, decimal/hex status, newState, submission result, attempt ID, connection epoch, elapsed time, Android/API/OEM/device/peripheral firmware matrix, app/process state, adapter/permission/bond state, scan observation freshness/connectability/RSSI, and reproduction rate.
3. TREAT status == 133 (0x85) as a legacy raw/opaque status. Current public API 37/37.1 has no GATT_ERROR or 133 constant; do not infer RF, cache, resource leak, or stack corruption from that number alone.
4. EVALUATE callback status before accepting newState. Only GATT_SUCCESS plus STATE_CONNECTED establishes a usable connection.
5. READ references/status-semantics.md and exact current BluetoothGatt/BluetoothGattCallback symbols before classifying a status.
6. READ references/article-audit.md before copying the supplied retry, close, delay, address, auto-connect, or adapter-reset examples.
7. ROUTE ADB executable/device selection/shell/logcat/dumpsys/bugreport mechanics to android-debug-bridge, ordinary BLE lifecycle changes to android-ble, client operation serialization to android-ble-gatt-queue, local server failures to android-ble-gatt-server, and inspector UI to android-ble-inspector.

Completion: the failure is an observed stage/status/state/timeline/matrix, not “status 133 means X.”

Step 2: Inspect connection and retry code