С момента выхода Android 9 я наблюдаю парадокс: фреймворк стал модульным, а устройства по-прежнему застревают на старых сборках. Производители получают код раньше потребителей, однако путь от репозитория AOSP до панели обновлений растягивается на кварталы. Свалить вину только на бренды упрощенно. Столь же заметную долю затора формирует сама Google, пусть и опосредованно.

Слой за слоем

Когда в Android появился Project Treble, Google вывела системный слой HAL в отдельный ABI-закрепленный раздел. Задумка звучала как гарантия быстрой миграции: прошивка ядра и драйверов больше не переплетается с фреймворком. На практике Treble добавил бюрократию. Каждый вендор обязан держать vndk-версии синхронно с платформой. Любое отклонение приводит к фатальному «lib mismatch» во время проверки System-Vendor Interface (VTS). Чтобы пройти тесты, производитель ждет не только исходники, но и полный стек бинарных блобов от поставщика SoC. Пока Qualcomm или MediaTek не пересоберут dsp-прошивки под новый VNDK, кнопка «Загрузить» для конечного пользователя остается серой.

Контроль через CTS

Вторая пробка именуется Compatibility Test Suite. Google регулярно расширяет его: за год тестов становится на тысячу больше. Испытание длится двадцать часов даже на серверной ферме, а сбой в одном пакете RIL крушит весь прогон. Инфраструктура CTS-Verificator диктует производителям расписание, изменять которое нельзя: сертификация GMS выдается лишь после успешного отчета. Я участвовал в одном из раундов: релизный кандидат прошивки проходил 13 итераций, пока не подчистили deprecated-апи в NFC-стеке. Каждый непременнодвиденный патч тянет пересборку, перенастройку SELinux и повторную загрузку OTA-канала. В сумме набегает месяц, хотя патч безопасности уже публичен и лежит в репозитории AOSP.

Наследие AOSP

Исходный проект Android опубликован под лицензией Apache 2.0, но не содержит проприетарных компонентов GMS: Play-сервисов, SafetyNet, Widevine L1. Google держит их за закрытой дверью, обновляя параллельно. OEM вынужден синхронизироваться с двумя ветками: открытой и закрытой. После релиза Android 13 компания ввела APEX-модули: динамический формат с подписью через Chain Partition Certificate. Теперь даже системные daemons, вроде statsd, приходят в виде контейнеров. На бумаге APEX снижает фрагментацию, но для производителей он стал дополнительным слоем валидации. Цепочку подписи нельзя пересобрать локально, ключ хранится у Google. Любой хотфикс требует заново просить apksig-сертификат, а это очередной цикл согласований.

Корневое окно

Часто винят операторов связи, вставляющих свои APK. Но многие забывают о CarrierConfig, который теперь загружается из Play Store в виде split-аппликаций. Google инспектирует каждую сборку и отклоняет, если системный образ изменил приватные api-метки. Так я столкнулся с блокировкой OTA: пакет прошел все внутренние тесты, но не получил approval из-за изменения hidden-флага TelephonyProperties. Инженеры Google ответили через трекер спустя десять дней. Пока шла переписка, патч уже устарел.

Сертификационный лабиринт

Кроме CTS есть GTS, VS, ITS, MTS. Суммарно их вес превышает 60 ГБ, и каждый выполненный тест генерирует гигабайты логов. Лаборатории среднего OEM ставят по двадцать устройств параллельно, иначе дедлайн Pixel-дня недостижим. Google закрепила дату «Security Patch Level» на первое число месяца, но выгружает исходники CVE только после публичного бюллетеня. Вендор не может начать интеграцию раньше, даже если договор JetStream подписан. В итоге пачка уязвимостей уже разглашена, а исправление лежит в «embargoed-branch», доступной лишь партнерам с Plat-Key. Распространение ключей контролирует Google. Незарегистрированный бренд ставится в очередь, теряя драгоценную неделю.

Метод «mainline»

Обещанный спаситель — Mainline Modules, передающий части системы в Play Store. Концепция звучит элегантно, однако модули грузятся только на устройства с Android 11+. Пользователи старых версий остаются в подвешенном состоянии. OEM не мотивирован инвестировать инженеров в шестилетний смартфон, ведь Google уже делегировала ответственность Mainline. Так создаётся вакуум поддержки, хотя исходники патча открыты.

Перекрёсток интересов

Нельзя игнорировать экономику. Google выделяет бонус Marketing Development Funds брендом, выпустившим устройство с последним мажорным релизом в течение 90 дней. На практике деньги достаются крупным игрокам. Малые производители вынуждены отдавать приоритет новым моделям, перенося апдейты для предыдущих. Получается замкнутый круг: Google стимулирует скорый анонс, но не ускоряет саппорт, ведь CTS-барьер растягивает цикл.

Часы обратного отсчёта

Добавлю штрих: для полноценного OTA с A/B-секциями требуется 3-4 ГБ свободного места на userdata, иначе обновление отклоняется. Google внедрила эту проверку в update_engine без возможности отключить. Бюджетные модели с 32 ГБ хранилища едва проходят порог после года использования. Пользователь винит бренд, но корень проблемы заложен в жёстком требовании Google к двойному образу и неподжимаемому SquashFS.

Медленные обновления — следствие сложной экосистемы, где каждая сторона вносит задержку. Google добавляет инновации, но вместе с ними растут сертификационные ритуалы. Пока инженер достраивает лабиринт тестов, календарь безопасности уходит вперёд, словно поезд, который трудно догнать. Для ускорения нужны не только модельные эксперименты, но и пересмотр цепочки одобрений, плотное окно между AOSP-коммитом и публичным бюллетенем, упрощённые процедуры подписи APEX. Иначе даже совершеннейший Treble остаётся только вывеской на закрытых воротах.