Телефон сломался после одной ADB-команды — и Gemini починил его, разобрав код на лету

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

Один ADB-командой можно включить невидимый отладочный режим, о котором не знает даже Google. Но когда поиск молчит, а форумы разводят руками, на помощь способен прийти ИИ, который читает машинный код вашего телефона как открытую книгу.

Как одна команда превратила телефон в отладочный стенд

История, которой поделился разработчик и студент-инженер Omar Afifi на платформе dev.to, звучит как типичная ночной кошмар программиста. Работая над Android-проектом через ADB (Android Debug Bridge — утилита для связи телефона с компьютером), он выполнил команду, которая установила системное свойство persist.log.tag в значение V — подробный режим логирования. Команда нужналась для отладки аудиосервиса, и на первый взгляд была совершенно безобидной.

Проснувшись на следующий день, Omar обнаружил, что по всем меню настроек его OnePlus расползлись ярко-красные строки моноширинного текста. Надписи вроде isOverScrolling: false, FlingVY: 15435.0 и AbortVX: 0.0 пересчитывались в реальном времени при каждом касании экрана. Хуже того — телефон начал заметно тормозить: свайпы от края экрана подтормаживали, боковая панель срывала кадры, а плавный 120-герцовый дисплей вдруг стал похож на экран бюджетного устройства образца 2016 года.

Почему стандартные советы не помогут

Первая реакция любого, кто хоть немного знаком с Android-разработкой, — проверить настройки для разработчиков. Указатель местоположения? Выключен. Отображение границ макета? Выключено. Строгий режим? Отключён.

Перезагрузка тоже не помогла — красные цифры вернулись вместе с системой.

Здесь начинается самая интересная часть. Omar прогнал через Google десятки запросов — от «red text on android screen» до точных строк из оверлея вроде isOverScrolling и AbortVX. Результат: абсолютный ноль. Ни XDA Forums, ни Reddit, ни OnePlus Community — никто никогда не сталкивался с подобным. Когда в эпоху мгновенного поиска не находится ни единого упоминания проблемы, это обычно означает одно: можно запускать сброс к заводским настройкам и прощаться с данными.

Gemini берёт управление на себя

Вместо того чтобы следовать этому печальному сценарию, Omar подключил телефон к ноутбуку и обратился к Gemini — ИИ-ассистенту, встроенному в его среду разработки Antigravity IDE. Суть запроса была примерно такой: «Ты запускал ADB-команды на моём телефоне, а теперь на экране красный текст и тормоза. Исправь.»

Стандартный чат-бот в такой ситуации обычно выдаёт шаблонный ответ: проверьте настройки разработчика, попробуйте сброс. Когда пользователь говорит, что всё это уже перепробовано, бот заходит в тупик.

Gemini повёл себя иначе — как системный инженер, а не как справочник. Он начал методично диагностировать проблему изнутри.

Диагностика: от интерфейса до машинного кода

Шаг первый: исключить очевидное

Gemini запросил у устройства текущие настройки через ADB — pointer_location и show_touches оба вернули ноль. Стандартные Android-датчики касаний были отключены, значит, красный текст генерировался чем-то другим.

Затем ИИ выгрузил полную иерархию интерфейса приложения «Настройки» в XML и поискал в нём ключевое слово isOverScrolling. Результат — пусто. Это сразу указывало на то, что текст не является обычным элементом интерфейса. Он отрисовывался напрямую в буфер экрана на уровне аппаратного Canvas — то есть рисовался «поверх» всего остального, как цифровая краска на холсте.

Шаг второй: разобрать код телефона без root-доступа

Поскольку текст появлялся в меню OnePlus, Gemini предположил, что он относится к проприетарному UI-фреймворку COUI (ColorOS UI), который OnePlus наследует от OPPO. Документации по этому фреймворку в открытом доступе нет.

Тогда ИИ сделал нечто впечатляющее: он скачал стандартное приложение «Калькулятор» прямо с телефона (adb pull), поскольку это приложение использует те же UI-компоненты, что и системные настройки. Затем, прямо в терминале, Gemini написал и выполнил Python-скрипты для парсинга бинарных DEX-файлов (Dalvik Executable — формат скомпилированного Android-приложения).

Через несколько секунд поиск по строковому пулу DEX выявил точные идентификаторы:

• Строка #2600 — 'AbortVX:'
• Строка #37919 — 'isOverScrolling: '

Обе относились к классу androidx.recyclerview.widget.COUIRecyclerView — внутреннему расширению OnePlus для прокручиваемых списков. Методом, рисующим красный текст, оказался dispatchDraw с байткодом, который буквально говорил: «Если флаг COUI_DEBUG истинен — нарисуй красным всё, что движется.»

Шаг третий: найти корень проблемы

Оставалось выяснить, почему этот отладочный флаг вдруг включился. Gemini проанализировал инициализатор класса и обнаружил, что COUI_DEBUG устанавливается через стандартный Android-механизм Log.isLoggable(). Этот механизм сначала ищет свойство для конкретного тега, а если не находит — смотрит на глобальное свойство persist.log.tag.

Запросив это свойство у телефона, Gemini получил одну букву: V — режим подробного логирования для всего и сразу.

Именно сюда вела цепочка. Команда, которую Omar запустил ночью для отладки аудиосервиса, установила persist.log.tag в V. Свойства с префиксом persist. сохраняются во флеш-память и переживают перезагрузку. При загрузке любого приложения со списками COUIRecyclerView проверял, включён ли подробный логгинг — и, обнаружив глобальный режим Verbose, активировал отладочный оверлей. Одновременно система начинала записывать сотни строк лога в секунду на каждое касание, что и объясняло тормоза.

Лечение: две команды и перезагрузка

Установив точную причину, Gemini выполнил три действия:

1. Сбросил глобальное свойство логирования: adb shell setprop persist.log.tag ""

2. Добавил защиту на будущее: adb shell setprop persist.log.tag.COUIRecyclerView SUPPRESS — даже если подробный логгинг будет включён снова, конкретно этот компонент больше не будет показывать отладочную информацию.

3. Перезагрузил устройство: Поскольку статические переменные в Android загружаются в память при старте процесса и не обновляются до перезагрузки, одного сброса свойства было недостаточно — нужно было «вытряхнуть» кешированные значения из всех работающих сервисов.

После перезагрузки красный текст исчез полностью, жесты от края экрана снова работали плавно, а 120-герцовый дисплей вернулся к жизни. Ни одного байта личных данных не было затронуто.

Что это значит на практике

Для обычного пользователя

Если вы никогда не подключали телефон к компьютеру через ADB, эта история вас не касается напрямую. Свойство persist.log.tag невозможно установить через интерфейс телефона — только через терминал. Но сам случай хорошо иллюстрирует важный принцип: одна неосторожная команда может создать проблему, которую ни один поисковик не опишет, потому что до вас с ней сталкивалось, возможно, всего несколько десятков человек на планете.

Для разработчиков

История полезна как пример того, как непредсказуемо могут вести себя проприетарные OEM-фреймворки. OnePlus, OPPO и другие производители добавляют в Android собственные отладочные инструменты, которые не документированы нигде — ни в AOSP, ни в публичных руководствах. COUIRecyclerView — один из таких «скелетов в шкафу». Знать, что глобальный persist.log.tag может активировать скрытые оверлеи в чужих компонентах, — полезный опыт для любого, кто работает с ADB на ежедневной основе.

Стоит ли верить в «волшебные способности» Gemini

Здесь нужна честная оговорка. Omar работал с Gemini не как с обычным чат-ботом, а как с инструментом, интегрированным в IDE с прямым доступом к терминалу и файловой системе. Это не ситуация «открыл браузер и спросил» — это среда, где ИИ может в реальном времени запускать команды, анализировать вывод, писать скрипты и итеративно продвигаться к решению.

Тем не менее, способность Gemini пройти путь от «красный текст на экране» до разбора Dalvik-байткода конкретного OEM-класса — впечатляет. Стандартный LLM в таком случае остановился бы на первом шаге и посоветовал сброс. Здесь же ИИ действовал как квалифицированный системный инженер: отсекал слои один за другим, пока не добрался до корня.

Грустная правда о документации

Этот случай — хороший напоминатель о том, в каком состоянии находится экосистема Android-разработки. Огромная часть кода, который работает на ваших телефонах, принадлежит OEM-производителям и не имеет никакой публичной документации. Проприетарные расширения вроде COUI, MIUI, One UI живут в параллельной вселенной от AOSP, и когда что-то идёт не так, стандартные каналы помощи молчат.

Именно в таких ситуациях ИИ-ассистенты с доступом к системе начинают демонстрировать практическую ценность — не как генераторы текстов, а как инструменты для работы с бинарными данными, которые человеку пришлось бы разбирать вручную часами.

Для Omar эта история закончилась хорошо. Но основной урок, пожалуй, в другом: прежде чем запускать ADB-команду с persist.-свойством, лучше дважды подумать — или хотя бы сохранить точное значение, которое было до вмешательства. Потому что когда форумы молчат, а Google молчит, надеяться остаётся только на то, что у вас под рукой есть достаточно умный инструмент, чтобы разобрать ваш телефон на молекулы.