Невозможно проверить переменные в предложении catch при отладке внутри метода источника - PullRequest
Новая
       13

Невозможно проверить переменные в предложении catch при отладке внутри метода источника

0 голосов
/ 10 января 2020

При отладке в Android Studio 3.5.3 у меня обычно проблем нет. Однако я наткнулся на проблему при отладке внутри источника Android, в частности файла Sdk\sources\android-28\android\bluetooth\BluetoothGatt.java

После приостановки в точке останова, указанной ниже, переменная e не отображается на вкладке Переменные. Не уверен, что это по замыслу, и если да, то какова причина этого? Что делает некоторые переменные доступными, а некоторые нет? Доступны различные локальные переменные, но не переменная e.

Моя точка останова здесь, в строке 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;
    }

Используемые системы:

ОС: Win 10
Android Studio: 3.5.3
Инструменты сборки: 29.0.2
Инструменты SDK: 26.1.1
Инструменты платформы: 29.0.5
Gradle: 3.5.3

Проверенные устройства:
Huawei P20 Pro (Android 9)
Huawei Mate 9 (Android 9)

PS The Log.e инструкция должна выводить трассировку стека, содержащуюся в переменной e, в LogCat, однако ее нигде не найти после тщательной проверки. Поэтому меня очень интересует содержимое переменной исключения.

Снимок экрана, демонстрирующий вышеупомянутую проблему с отладчиком

1 Ответ

0 голосов
/ 13 января 2020

Как отметил комментатор, отладчик фактически не приостанавливался на указанной строке. На основании этой информации и возвращаемого значения метода, по которому он щелкнул: метод, скорее всего, возвращает ложь при проверке mDeviceBusy, которая происходит ранее в этом методе.

Кроме того, проблемы, с которыми я столкнулся при Структура Bluetooth (в частности, BLE), по-видимому, вызвана вызовом методов API, когда операция еще выполняется. Это может нарушить Android Bluetooth API, в результате чего поле mDeviceBusy останется истинным.

После того, как я отключил некоторые операции GATT / BLE, которые мое приложение выполняет сразу после подключения, проблема исчезает. Решение состоит в том, чтобы убедиться, что одновременно активна только одна команда, и, возможно, даже добавить дополнительное время между командами.

...