libGDX перестает ставить контрольные точки после нескольких часов работы с устройством Android - PullRequest
0 голосов
/ 10 июня 2018

Во время исследования этого я писал ответ на IntelliJ IDEA: точка останова не была достигнута и показывается без галочки, просто красная точка , пока я не понял, что это совершенно другой вопрос.У меня была эта проблема дважды за последние 4 недели, но мой вариант использования - IntelliJ больше не ставит красные контрольные точки.Я просто смотрел, как клещи исчезают у меня на глазах.

Первый раз, когда это произошло, произошло после бесцеремонного отрыва USB-кабеля в спешке.Я не ценю необходимость церемонии здесь.Этот сломанный проект так и остался.

Я пытался все исправить, и разочаровался в этом конкретном проекте;это было в основном завершено.Я попробовал adb kill-server и общее семейство решений «потом снова безрезультатно».

Перенесемся через пару недель, я забыл об этом и был в восторге (я лгу, япринимал это как должное), чтобы иметь возможность проверить мой новый протокол с точками останова на устройстве Android.Первым симптомом было то, что мои иконки испортились (я думал, что где-то в IDE был захваченный поток, но мне трудно поверить, что я не заметил бы этого только при отладке одного процесса).Затем отметка точки останова просто исчезла, и у меня появилось синее сообщение в консоли IDE, что-то о GDX и слишком много времени с графикой (аналогичное сообщение добавлено внизу поста).Глупо я перезапустил апк.

Что я не пробовал?Я думаю, что что-то радикальное, например, настойчивость в разработке только для настольных компьютеров или отказ от Windows.Я думал об обновлении (заключении контракта) Gradle, но мой другой проект был совершенно новым и недавно был диагностирован с специфическими зависимостями версии Gradle .

dead red breakpoint

Я могу запустить приложение с моей машины разработчика, но даже пауза не может найти то, что оно делает, потому что оно выберет (случайный) поток из контекста с моим приложением.

Pausing no longer intercepts my code

Я также могу нажимать точки останова из приложения Desktop:

working breakpoint

Полагаю, мне следует попробовать Android Studio с этимпроект, но знаю, что это не будет легко исправить.Я использую Win10 Pro и на фирменном ноутбуке и телефоне (ничего особенного).Я использую Gradle 2.1 (IIRC, я получаю ежедневную надбавку за обновление до 4.1), но мой другой аналогичный проект имеет определенные зависимости от версий Gradle , поэтому я хочу оставить достаточно хорошо в покое.

Я не знаю, ответ это или нет, но, похоже, он отлично работает с эмулятором, который может показаться более универсальным решением, чем что-то столь же сложное, как, вы знаете, поддержка нескольких аппаратных средств.Я запустил его снова и перехватил определенную строку, наблюдал те же артефакты экрана, что и раньше, но убил его прежде, чем смог потерять и мой эмулятор.

Это последнее, что она напечатала:

W/zygote: Long monitor contention with owner GLThread 260 (8155) at boolean com.mygame.game.screens.Menu$4.keyDown(int)(Menu.java:128) waiters=0 in boolean com.badlogic.gdx.backends.android.AndroidInput.onKey(android.view.View, int, android.view.KeyEvent) for 9.799s

Он был пойман в ловушку другим способом, но суть в том, что я заблокировал GLThread.

...