Xperia Z Ultra на Android 13

Xperia Z Ultra C6833 построен на Snapdragon 800, оснащён 2 ГБ RAM и GPU Adreno 330. Физический дисплей работает в режиме MIPI-DSI video с разрешением 1080 × 1920 при 60 Гц. Следовательно, новый кадр должен быть подготовлен примерно за 16,67 мс.

LineageOS 20 переносит на аппарат современный SurfaceFlinger, WindowManager и SystemUI. Но vendor-часть остаётся наследием msm8974. Между ними работает совместимый HWC-слой, который решает, какие поверхности можно отдать аппаратным плоскостям MDP, а какие нужно предварительно собрать GPU в единый client target.

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

Экран блокировки Sony 5.1 использовал старые private API, ODEX, signature-разрешения и механизм Runtime Skinning. Прямая установка такого SystemUI.apk на Android 13 привела бы к циклическому падению интерфейса. Вместо этого крупные двухъярусные часы Xperia были реализованы внутри современного Keyguard, сохранив актуальные механизмы PIN, уведомлений и системной безопасности.

Геометрия рассчитывалась не по физической диагонали, а по фактической плотности и доступной области экрана. В портрете часы занимают визуальный центр верхней половины. В landscape отдельная раскладка учитывает системную навигационную полосу: в финальной ветке центр замка задан по ширине content area 1824 px, то есть x = 912 px.

Xperia Home и меню приложений

Оригинальный Home 5.1 также нельзя было переносить побайтово. В основу взят более новый Xperia Home, совместимый с Android 13. В нём сохранена логика рабочего стола и локальная миграция настроек, отключены необязательные аналитические точки запуска, а визуальные ресурсы меню приложений заменены материалами C6833.

Стоковый набор использовал 56dp-иконки и 15sp-подписи для профиля sw360dp. Но итоговая сетка вычисляется современным launcher-кодом для текущей плотности. Это визуальная реконструкция, а не запуск бинарного Sony Home из прошивки 14.6.A.1.236.

Стоковый набор обоев и медиа

Из эталонной прошивки C6833 14.6.A.1.236 извлечены полноразмерные обои, миниатюры, UI-звуки и загрузочная анимация 1080 × 1920. Источником FTF было стороннее зеркало, поэтому корректная формулировка здесь важна: совпадают модель и номер сборки, но принадлежность ресурсов прежнему региональному пакету не доказана официальной подписью Sony.

На 60-герцовом дисплее один период развёртки составляет 16,67 мс. Интервал свыше 33 мс уже означает пропуск как минимум одного периода. Но gfxinfo описывает работу приложения, а временная шкала SurfaceFlinger отражает вывод композиции на дисплей. Поэтому эти метрики нельзя механически складывать или подменять одной другой.

Каждая гипотеза проверялась повторяемым жестом, очисткой статистики перед серией, снимком HWC-состава во время проблемного состояния и кадрами, захваченными непосредственно в переходе. После теста отдельно проверялись ANR, crash и FATAL-события.

Первые попытки лечить мигающий угол полным переводом сцены в GLES устраняли часть повреждённых кадров, но резко увеличивали время рендеринга. Обратная крайность, принудительный MDP для любой поверхности, ломала эффекты, которые аппаратные плоскости не могли корректно представить.

Рабочая политика появилась после разделения слоёв по назначению. Обычные непрозрачные окна, рабочий стол и закрывающаяся шторка оставались на MDP. Только эффектные и dim-слои получали GLES fallback. При смене ориентации HWC-кэш обновлялся, а формат поверхности SystemUI не менялся в терминальном кадре закрытия.

В v71 подложка шторки стала непрозрачной, но живой launcher под ней сохранился. Это убрало чёрный полноэкранный буфер при закрытии и не уничтожило параллакс обоев. В проверке v72 шесть последовательных кадров закрытия не содержали ни чёрного, ни белого промежуточного экрана.

Passenger Control 1.40.0-beta13 открывает большое дополнительное окно с полупрозрачным системным затемнением позади. На msm8974 один HWC2 solid-color dim effect между двумя buffered windows переводил весь дисплей в legacy GLES client target. В v71 прокрутка настроек давала p50 около 300 мс и p95 около 483 мс. Одновременно появлялся белый или чёрный угол.

Глобальное отключение dim было бы неправильным: оно изменило бы поведение всех приложений. В v72 условие помещено в WindowState.applyDims() и ограничено пакетом ru.monjaro.passengercontrol.client. Для остальных окон Android логика затемнения не меняется.

Исходный дефект заключался в гонке: приложение успевало восстановить обработку ввода, но уже подготовленное сообщение о показе ANR-диалога оставалось в очереди UI Handler. В framework введён токен конкретного ANR-события. Когда input dispatch возобновляется, токен, отложенное сообщение и видимый диалог очищаются атомарно. Устаревшее сообщение больше не может воскресить завершившийся ANR.

Дополнительный root-сценарий служит ограниченной страховкой. Он подписывается на am_anr, открывает 75-секундное окно частых проверок и выбирает только кнопку Wait по resource id aerr_wait. Принудительное закрытие, очистка данных и изменение пакета не выполняются.

После прошивки выяснилось, что Magisk исполнял не только основной файл, но и три резервные копии .bak-*, оставленные внутри /data/adb/service.d. В результате появилось 12 лишних процессов, а две старые копии вызывали дорогой dumpsys window каждую секунду. Binder-нагрузка system_server достигала примерно 31%.

Исправление

Резервные копии были обратимо перенесены в /data/adb/togari-script-backups/20260827-anr-autowait, завершены только процессы с точным совпадением командной строки, а основной скрипт получил singleton-lock через атомарное создание каталога. После этого доля CPU у system_server снизилась примерно до 3,1%.

Финальный стресс-тест включал 30 быстрых перелистываний Xperia Home. gfxinfo показал 701 кадр, 0 modern jank и 0 legacy jank; p50, p90, p95 и p99 составили 9, 9, 10 и 11 мс. SurfaceFlinger при этом зарегистрировал три интервала свыше 33 мс из 125, поэтому корректный вывод звучит как устранение регулярного launcher-лага, а не обещание математически идеального вывода.

Google Play: восстановление системного контракта

В исходном состоянии Play Store завершался с ошибкой Failed to load configurations for FinskyApp. В журнале отсутствовал provider com.google.android.gsf.gservices. Это указывало не на сетевой сбой и не на повреждение пользовательских данных, а на отсутствие Google Services Framework и согласованного привилегированного окружения для Play Services и Phonesky.

Для частного устройства собран Magisk-модуль togari_minimal_gapps v1.3. Он монтирует Google Services Framework в system_ext/priv-app, GmsCore и Phonesky в product/priv-app, а также добавляет соответствующие privapp-permissions, default-permissions и sysconfig. После перезагрузки PackageManager распознал все три пакета как SYSTEM и PRIVILEGED; разрешения MANAGE_USERS, INTERACT_ACROSS_USERS и READ_DEVICE_CONFIG выданы. Контрольный запуск дошёл до AssetBrowserActivity, а в окне проверки не было FATAL, crash или ANR для Play Store.

Почему нулевая анимация оказалась медленнее

В проверяемой конфигурации Sony Home был default launcher, но экран недавних приложений обслуживал com.android.launcher3/com.android.quickstep.RecentsActivity. При значениях window_animation_scale=0 и transition_animation_scale=0 визуальная часть перехода исчезала, однако recents animation input consumer и связанные поверхности иногда оставались активными уже после возврата Home. В таком состоянии SurfaceFlinger продолжал занимать примерно 80-118% одного CPU, поэтому последующие переходы выглядели всё тяжелее.

Все три коэффициента анимации установлены в 0,5. Это не декоративная мера, а восстановление времени, необходимого WindowManager и Quickstep для штатного завершения протокола перехода. После закрытия Recents рабочий стол снова становится resumed activity, а нагрузка SurfaceFlinger через несколько секунд возвращается к 0%. Прямые прогретые запуски дали 91 и 83 мс; первый запуск уже поднятого сервиса занял 292 мс.

Фоновая нагрузка как независимый фактор

Отдельный эксперимент локализовал ещё один источник деградации. При активном Яндекс Диске его три процесса занимали около 300 МБ resident memory, основной процесс потреблял примерно 25-85% CPU, а доступная память снижалась примерно до 86 МБ. В журналах одновременно наблюдались запуск Activity за 5,239 с, pause timeout и обработка focus event продолжительностью 3096 мс. После обратимого force-stop SurfaceFlinger вернулся к 0% в покое, а свободная память выросла примерно до 195 МБ.

Автосинхронизация Яндекс Диска не отключалась и фоновые ограничения пакета не менялись. Поэтому повторное открытие приложения может снова создать нагрузку. Этот фактор нельзя смешивать с исправлением Quickstep: он подтверждает, что на устройстве с 2 ГБ RAM один тяжёлый клиент способен исчерпать запас памяти и пропускной способности всей графической системы.

Патч v72 изменил services.jar и соответствующие AOT-артефакты. Новый services.art оказался ровно на один блок 4096 байт больше прежнего extent. Обычная замена файла нарушила бы размещение следующих данных или метаданные файловой системы.

Скрипт v72-extend-services-art.py использовал debugfs fallocate, сопоставил логический блок 515 со свободным физическим блоком 408246, обновил ext4 metadata и добавил соответствующий RAW-chunk в sparse-поток. После упаковки проверены SELinux xattr, e2fsck -fn и точное совпадение sparse-to-raw round trip.