0

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.estatement 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

Phantômaxx
  • 37,901
  • 21
  • 84
  • 115
LePain
  • 1
  • 1
  • I also like how `mDeviceBusy` has the value opposite of that which was just assigned :) I suspect you have a case of "source code doesn't match the bytecode", maybe you received that warning, but dismissed it? You could double-check by stepping the debugger, and seeing if it does return "false" immediately, or you can check it by trying to step into the `mService.writeDescription()` function, for example. – greeble31 Jan 10 '20 at 14:29
  • Yes, I saw this warning appear at some point. Stepping into ```writeDescription``` makes it jump into the middle of a comment block in BluetoothDevice.java:971. I noticed that [this](https://stackoverflow.com/a/56002147/12688627) answer mentions a solution; extracting .oat files from the device and converting them into jar files. I am however not clean on how to make Android Studio point to custom Android sources for debugging. – LePain Jan 10 '20 at 15:37
  • Maybe see [here](https://stackoverflow.com/questions/51752026/source-code-does-not-match-the-bytecode-for-system-files-on-huawei). Also note that it is quite likely that no exception is taking place; you only thought one was b/c of the breakpoint location, which was, of course, erroneous. – greeble31 Jan 10 '20 at 15:52

1 Answers1

0

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.

LePain
  • 1
  • 1