Google усложнил разработку кастомных прошивок на основе AOSP

Ранее Google объявил, что будет разрабатывать ОС Android полностью в закрытом режиме, чтобы упростить процесс разработки. Сосредоточив свои усилия на одной внутренней ветке, Google стремится оптимизировать работу, которая ранее была разделена. Эта новость сначала напугала некоторых членов сообщества разработчиков Android, но споры быстро утихли. Влияние было минимальным, поскольку Google и так разрабатывал большую часть Android в закрытом режиме и пообещал, что будет продолжать публиковать исходный код. Однако недавние публикации Google вновь разожгли опасения, что компания может прекратить публикацию исходного кода для новых версий Android. Google заявил, что эти опасения беспочвенны, но новые изменения затрудняют публикацию кастомных ROM на устройствах Pixel.

AOSP исчезнет? Google говорит, что нет

Как и обещал, Google опубликовал на этой неделе исходный код Android 16, позволив независимым разработчикам компилировать свои собственные сборки новой операционной системы. Этот исходный код был загружен в Android Open Source Project (AOSP), как обычно, под разрешительной лицензией Apache 2.0.

Однако многие разработчики быстро заметили явное упущение в выпуске исходного кода Android 16: отсутствовало дерево устройств для Pixel. Google также не загрузил новые бинарные файлы драйверов для каждого устройства Pixel и выпустил исходный код ядра с сокращенной историей коммитов. Поскольку Google в течение многих лет делился деревьями устройств, бинарными файлами драйверов и полной историей коммитов исходного кода ядра, их отсутствие в выпуске на этой неделе вызвало беспокойство.

Эти упущения привели некоторых к предположению, что Google делает первый шаг в плане прекращения поддержки AOSP. В ответ на это вице-президент и генеральный директор Google по платформе Android Сэнг Чау опроверг эти утверждения. Он прокомментировал эти предположения в посте на X, заявив, что «AOSP НЕ исчезнет».

Он также подтвердил, что исключение устройств Pixel из дерева устройств является намеренным, заявив, что «AOSP нуждается в эталонной цели, которая была бы гибкой, настраиваемой и доступной — независимой от какого-либо конкретного оборудования, включая оборудование Google». Вместо поддержки сборок AOSP на устройствах Pixel, Google будет поддерживать виртуальное устройство Android «Cuttlefish» в качестве эталонной цели. Cuttlefish работает на ПК, что позволяет Google и разработчикам платформ тестировать новые аппаратные функции. Google также продолжит поддерживать цели GSI, которые представляют собой общие системные образы, которые можно установить практически на любое устройство Android.

С одной стороны, эта логика вполне обоснована. Google хочет отказаться от использования Pixel в качестве эталонного устройства AOSP и вносит соответствующие изменения. Как отмечает Сэнг Чау, «AOSP был создан как открытая платформа для устройств, SoC и наборов инструкций». В этом отношении Cuttlefish является более подходящей эталонной целью, поскольку это не кастомное потребительское оборудование, как телефон Pixel. Однако, поскольку Cuttlefish является виртуальным устройством, оно может только имитировать поведение аппаратных функций, что в некотором смысле делает его несовершенным эталоном.

Как эти изменения повлияют на разработку кастомных ROM?

Однако более значимой проблемой является влияние этого решения на разработчиков, которые создают кастомные прошивки. Нолен Джонсон, давний участник и рецензент проекта LineageOS, говорит, что процесс создания этих ROM для телефонов Pixel станет «болезненным».

Раньше Google упрощал разработчикам создание AOSP для устройств Pixel, но теперь эта поддержка исчезла. Разработчикам просто нужно было «взять конфигурации, созданные Google», добавить свои настройки и затем создать сборку. Теперь же им придется взять старые дерева устройств, выпущенные Google для Android 15, и «вслепую угадывать или проводить реверс инжиниринг из готовых [бинарных файлов], какие изменения необходимы каждый месяц».

Это связано с тем, что для создания полной сборки Android для устройства — а не только GSI — требуется дерево устройств. Это «набор конфигурационных файлов, которые определяют оборудование, периферийные устройства, списки проприетарных файлов и другие детали для конкретного устройства, позволяя системе сборки создать подходящий образ для этого устройства». Раньше Google занималась этой работой, но теперь разработчики должны создавать свои собственные деревья устройств без доступа к необходимому проприетарному исходному коду.

Кроме того, решение Google об уничтожении истории коммитов исходного кода ядра также препятствует кастомной разработке. Исходный код ядра Pixel часто использовался в качестве «ориентира для других устройств, из которого они брали функции, исправления ошибок и патчи безопасности», но теперь, когда история сокращена до одного коммита, это больше невозможно.

Хотя Google не обязан публиковать дерево устройств, предоставлять бинарные файлы драйверов или делиться полной историей коммитов ядра (на самом деле, это один из немногих производителей устройств, который делает это), компания делала это в течение многих лет. Причина, по которой компания так поступала, заключалась в том, что Pixel рассматривался как эталонная платформа для AOSP, поэтому разработчикам нужен был простой способ развертывания Android для него.

Решение Google прекратить использование Pixel в качестве эталонного устройства AOSP является неудачным, поскольку оно подкосило разработчиков, таких как команды LineageOS и GrapheneOS, которые создают Android для устройств Pixel. Эти разработчики по-прежнему смогут создавать AOSP для устройств Pixel, но теперь это будет сложнее и болезненнее, чем раньше, поскольку им придется создавать свои собственные дерева устройств с нуля. Это также ставит Pixel на один уровень с другими устройствами Android, поскольку разработчикам уже давно приходилось создавать свои собственные дерева устройств, извлекать бинарные файлы и иметь дело с сокращенной историей коммитов исходного кода ядра на других устройствах.

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