在源方法中调试时无法检查 catch 子句中的变量

Question

While debugging in Android Studio 3.5.3 I usually don't have problems. However I stumbled onto a problem while debugging inside the Android source, specifically the file Sdk\\sources\\android-28\\android\\bluetooth\\BluetoothGatt.java

Once suspended at the breakpoint indicated below, the variable e is not listed in the Variables tab. Am not sure if this is by design and if so, what is the cause of it? What causes some variables to be available, while some are not? Various local variables are available, but not the e variable.

My breakpoint is here, at line 1259:

    try {
        mService.writeDescriptor(mClientIf, device.getAddress(), descriptor.getInstanceId(),
                AUTHENTICATION_NONE, descriptor.getValue());
    } catch (RemoteException e) {
        Log.e(TAG, "", e); // <-- HERE (breakpoint)
        mDeviceBusy = false;
        return false;
    }

Systems used:

OS: Win 10
Android Studio: 3.5.3
Build Tools: 29.0.2
SDK Tools: 26.1.1
Platform Tools: 29.0.5
Gradle: 3.5.3

Devices tested:
Huawei P20 Pro (Android 9)
Huawei Mate 9 (Android 9)

PS The Log.e statement should print the stacktrace contained in the e variable to LogCat, however it is nowhere to be found after thorough inspection. Therefore I am very interested in the contents of the exception variable.

Screenshot demonstrating the aforementioned issue with the debugger

Answer 1

As a commenter pointed out, the debugger was not actually suspending on the line it indicated. Based on this information and on the return value of the method it clicked: the method is very likely returning false on the mDeviceBusy check which happens earlier in that method.

Moreover, the issues I was experiencing with the Bluetooth framework (BLE specifically) seem to be caused by calling API methods while an operation is still running. This can break the Android Bluetooth API, causing the mDeviceBusy field to remain true.

After I disabled some GATT/BLE operations which my app does right after connecting, the problem disappears. The solution is making sure only one command is active at a time, and possibly even adding additional time between commands.