Ваш Xiaomi греется в кармане и жрёт батарею? Виновник — не железо. Лечится за 15 минут через ADB

Смартфон лежит экраном вниз на столе. Ничего не запущено. Но через час он тёплый, а заряд упал на 18%. Открываешь статистику батареи — и там это: «Система Android», 31%. Не YouTube, не навигация, не игра. Система Android.

Первый инстинкт — сброс настроек. Второй — нести в сервис. Оба неверные. Потому что проблема не в железе и не в прошивке как таковой. Проблема в том, что ваш смартфон буквально не закончил думать после последнего обновления HyperOS. И сейчас покажем, как его дожать.

Что реально происходит внутри: виртуальная машина, которая застряла на полпути

Каждое Android-приложение написано на Java или Kotlin и хранится на устройстве в формате DEX — это не машинный код, который процессор понимает напрямую, а байткод. Чтобы он работал быстро, Android Runtime (ART) должен его заранее скомпилировать в нативные инструкции вашего конкретного процессора.

Этим занимается инструмент dex2oat. Он берёт DEX-файл и на выходе даёт три артефакта:

Вот в чём соль: dex2oat умеет работать в нескольких режимах. И выбор режима — это разница между смартфоном, который работает, и смартфоном, который перерабатывает.

Четыре режима компилятора: от «почти ничего» до «всё и сразу»

На Android 8 и выше официально поддерживаются четыре фильтра компиляции. Важный момент для владельцев HyperOS: режим quicken, о котором пишут в старых гайдах, умер на Android 12. Забудьте про него.

speed-profile — это золотая середина. Система не тратит время на компиляцию кода, который вы никогда не запускаете. Она компилирует только то, что JIT уже «видел» в работе и пометил как часто используемое. Быстро, точно, без лишней работы.

Почему после обновления HyperOS телефон ведёт себя как после бессонной ночи

После установки OTA-обновления HyperOS система намеренно выставляет компиляцию в режим verify. Не speed-profile, не speed — просто верификация. Это сделано специально, чтобы не затягивать первую загрузку после апдейта.

Дефолтные значения ART Service выглядят так:

Фоновая оптимизация (bg-dexopt) с режимом speed-profile запустится сама — но только когда телефон одновременно заряжается и лежит без дела. И только один раз в сутки. Если вы постоянно пользуетесь смартфоном и редко оставляете его на зарядке в покое — эта фоновая задача просто никогда не доберётся до конца.

Итог: после обновления десятки приложений работают через JIT-компиляцию на лету. Процессор постоянно занят. Батарея тает. Телефон греется. И вот вам — «Система Android» в топе потребителей.

Инструментарий: что нам понадобится

Никакого root. Никаких сторонних прошивок. Только ADB — официальный инструмент отладки от Google.

Что установить на ПК:

• Platform Tools — скачать с developer.android.com/tools/releases/platform-tools. Это архив с adb.exe (Windows) или adb (macOS/Linux).

Что включить на смартфоне:

1. Настройки → О телефоне → Версия MIUI/HyperOS — тапнуть 7 раз подряд. Появится пункт «Для разработчиков».
2. Настройки → Дополнительные настройки → Для разработчиков — включить «Отладка по USB».
3. Там же включить «Беспроводную отладку» — пригодится, если хотите работать без кабеля.

Подключаете телефон кабелем, в терминале проверяете связь:

adb devices

Если в ответ видите серийный номер устройства со статусом device — всё готово.

Шаг 1: Принудительная компиляция ART. Дожимаем то, что система не доделала

Перед запуском — два условия. Заряд батареи выше 50%. Телефон не горячий. Потому что команда ниже, в отличие от фоновой задачи, не ждёт покоя — она нагружает CPU прямо сейчас.

adb shell cmd package compile -m speed-profile -a

Флаг -a означает «все установленные приложения». Команда пройдётся по каждому пакету и скомпилирует методы из накопленных JIT-профилей. В зависимости от количества приложений процесс займёт до 30 минут. Телефон будет тёплым — это норма.

Но здесь есть один скользкий момент, о котором не пишут в коротких гайдах.

Подводный камень №1: speed-profile без профиля — это просто verify в маскировке

Если у приложения ещё нет JIT-профиля (только установленное, или данные были очищены) — ART молча понижает фильтр с speed-profile до verify. Без предупреждения, без ошибки в терминале.

Чтобы убедиться, что компиляция реально сработала для конкретного приложения:

adb shell cmd package compile -m speed-profile -f -v com.example.app

Смотрите на поле actualCompilerFilter в выводе:

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

Шаг 2: Отключаем фоновых «шпионов». Аккуратно и обратимо

Два пакета стабильно появляются в топе фоновой активности на устройствах Xiaomi:

По com.xiaomi.joyose — честное предупреждение. Официальной документации Xiaomi на этот сервис не существует. Всё, что известно о его поведении — результат реверс-инжиниринга сообщества XDA. Xiaomi официально рекомендует его не трогать, ссылаясь на возможный тепловой дисбаланс. При этом именно обновления Joyose исторически вызывали аномальный нагрев. Парадокс, но факт. Решение — за вами.

Есть два метода отключения. Выбирайте осознанно:

Метод A — стандартный (рекомендуется опытным пользователям):

adb shell pm uninstall -k --user 0 com.miui.analytics
adb shell pm uninstall -k --user 0 com.xiaomi.joyose

Метод B — безопаснее для первого раза (полностью обратим одной командой):

adb shell pm disable-user --user 0 com.miui.analytics
adb shell pm disable-user --user 0 com.xiaomi.joyose

Если что-то пошло не так — откат:

# Для метода A
adb shell cmd package install-existing com.miui.analytics

# Для метода B
adb shell pm enable --user 0 com.miui.analytics

Подводный камень №2: OTA-обновление всё вернёт обратно

Оба метода не переживают крупные обновления HyperOS. После каждого системного апдейта пакеты восстанавливаются. Это не баг — это архитектурное решение: pm uninstall -k --user 0 и disable-user работают только в пространстве пользователя, не трогая /system.

Практическое решение: сохраните команды из Шага 2 в текстовый файл. После каждого обновления HyperOS — 2 минуты на повторный запуск.

Подводный камень №3: не трогайте com.miui.personalassistant

Этот пакет отвечает за App Vault («экран -1») и одновременно за работу виджетов на рабочем столе. Его удаление ломает систему виджетов — долгое нажатие на рабочий стол перестаёт открывать меню редактирования. Зафиксировано в сообществе, воспроизводится стабильно.

В список пакетов для отключения он не входит.

Шаг 3: Замеряем результат. CPU Throttling Test — единственный честный судья

Утилита CPU Throttling Test (есть в Google Play) запускает синтетическую 15-минутную нагрузку на процессор и в конце выдаёт два числа: пиковая производительность и средняя. Отношение среднего к пиковому — процент стабильности.

Для понимания, что является нормой, а что — провалом:

Запустите тест до процедуры, запишите цифры. Запустите после — сравните. Если стабильность выросла на 5–15% — вы сделали всё правильно.

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

Полный список команд: копируй и используй

# ── ДИАГНОСТИКА ──────────────────────────────────────────
# Проверка подключения
adb devices

# ── ART: ПРИНУДИТЕЛЬНАЯ КОМПИЛЯЦИЯ ───────────────────────
# Запустить speed-profile для всех приложений (заряд >50%!)
adb shell cmd package compile -m speed-profile -a

# Проверить результат для конкретного пакета
adb shell cmd package compile -m speed-profile -f -v com.example.app
# Смотреть: actualCompilerFilter=speed-profile (✅) или =verify (⚠️ нет профиля)

# ── ТЕЛЕМЕТРИЯ: ОТКЛЮЧЕНИЕ ────────────────────────────────
# Метод A — удаление из пространства пользователя
adb shell pm uninstall -k --user 0 com.miui.analytics
adb shell pm uninstall -k --user 0 com.xiaomi.joyose

# Метод B — мягкое отключение (безопаснее)
adb shell pm disable-user --user 0 com.miui.analytics
adb shell pm disable-user --user 0 com.xiaomi.joyose

# ── ОТКАТ ─────────────────────────────────────────────────
# Восстановление после метода A
adb shell cmd package install-existing com.miui.analytics
adb shell cmd package install-existing com.xiaomi.joyose

# Восстановление после метода B
adb shell pm enable --user 0 com.miui.analytics
adb shell pm enable --user 0 com.xiaomi.joyose

Совместимость: какая версия Android, такой и движок

Синтаксис команд одинаков для всех версий, но внутри работает разный движок:

Практического значения для пользователя это не имеет — команды работают одинаково. Но если вдруг захотите углубиться в кастомизацию через системные свойства (pm.dexopt.*) — знайте, что на Android 14+ вы работаете уже с ART Service API.

Что в итоге

После прохождения всех трёх шагов у вас будет:

• Скомпилированный в нативный машинный код пул «горячих» методов всех приложений
• Отключена фоновая отправка телеметрии в Xiaomi
• Понимание того, что происходит под капотом после каждого обновления прошивки

Никакой магии. Только то, что система должна была сделать сама, но не успела — или не торопилась.

И да: после следующего OTA-обновления HyperOS не удивляйтесь, когда пункт «Система Android» снова окажется в топе батарейной статистики. Это не регресс прошивки. Это boot-after-ota=verify делает свою работу. Теперь вы знаете, что с этим делать.