Загрузка свежесобранного GSI-образа заканчивается бутлупом на логотипе — типичный симптом, с которым сталкиваются и начинающие портеры, и опытные разработчики при несовпадении архитектуры раздела system с бинарниками vendor. Причина почти всегда кроется не в самом образе, а в несоответствии версии VNDK, отсутствии поддержки Project Treble на уровне vendor-раздела или неправильно выбранном варианте сборки (ARM64 вместо ARM32_binder64 и наоборот).
Эта статья разбирает полный цикл работы с Generic System Image: от подготовки среды сборки исходников AOSP до диагностики типичных ошибок при портировании на конкретное устройство. Материал ориентирован на тех, кто уже знаком с ADB и fastboot, но хочет систематизировать процесс разработки и портирования GSI.
Что такое GSI и зачем его портируют
Generic System Image — это «чистый» образ системного раздела Android, собранный из исходного кода AOSP без привязки к конкретному производителю. Технология появилась вместе с Project Treble в Android 8.0: Google стандартизировал интерфейс между системой и vendor-разделом, благодаря чему один и тот же system-образ теоретически может загружаться на любом Treble-совместимом устройстве.
Практические задачи, которые решает портирование GSI:
- 🧪 Тестирование приложений на «чистом» Android без оболочек производителя
- 🔓 Установка актуальной версии системы на устройства, заброшенные вендором
- 🛠️ Разработка и отладка собственных сборок AOSP на реальном железе
- 🔍 Исследование совместимости HAL-интерфейсов и VNDK между версиями Android
Стоит понимать границу применимости: GSI заменяет только раздел system. Ядро, vendor-раздел, прошивки модема и загрузчик остаются родными. Именно поэтому полноценное «обновление Android» через GSI ограничено возможностями старого vendor — камера, модем или датчики могут работать некорректно, если их HAL-интерфейсы не совпадают с ожиданиями новой системы.
Проверка совместимости устройства перед портированием
Прежде чем собирать или скачивать образ, убедитесь, что устройство вообще поддерживает Treble и GSI. Это делается через ADB при загруженной стоковой системе:
adb shell getprop ro.treble.enabled
adb shell getprop ro.product.cpu.abi
adb shell getprop ro.vendor.build.version.sdk
Значение ro.treble.enabled=true подтверждает базовую поддержку. ABI процессора определяет вариант образа: для arm64-v8a нужен ARM64 GSI, при этом часть устройств с 64-битным ядром использует 32-битную систему — тогда потребуется вариант arm32_binder64. Несовпадение именно здесь — одна из самых частых причин мгновенного бутлупа после прошивки.
⚠️ Внимание: прошивка GSI требует разблокированного загрузчика. Разблокировка стирает все данные на устройстве и на части моделей аннулирует гарантию или отключает сертифицированные сервисы (банковские приложения, DRM-контент). Порядок разблокировки зависит от производителя — сверяйтесь с официальной документацией конкретной модели.
☑️ Проверка устройства перед портированием GSI
Варианты GSI: официальные, кастомные и собственные сборки
Работать можно с тремя источниками образов, и выбор зависит от цели. Официальные GSI от Google публикуются на странице для разработчиков и подходят для тестирования совместимости, но не содержат сервисов Google в базовых вариантах. Кастомные GSI от независимых разработчиков включают патчи для конкретных семейств устройств — их качество и безопасность зависят от автора, проверяйте источник и контрольные суммы. Собственная сборка из AOSP даёт полный контроль, но требует мощной машины и времени.
| Источник GSI | Контроль над сборкой | Порог входа | Типичное применение |
|---|---|---|---|
| Официальный GSI Google | Нет | Низкий | Тестирование Treble-совместимости |
| Кастомный GSI сообщества | Ограниченный | Низкий-средний | Обновление заброшенных устройств |
| Собственная сборка AOSP | Полный | Высокий | Разработка, исследования, форки |
| GSI с патчами (phh-подобные) | Средний | Средний | Запуск на проблемном железе |
Сборка GSI из исходников AOSP
Для собственной сборки потребуется Linux-машина (обычно Ubuntu LTS), значительный объём свободного места на диске и оперативной памяти — точные требования зависят от версии Android и указаны в официальной документации AOSP. Общий порядок выглядит так: установка зависимостей, загрузка дерева исходников через repo, выбор цели и запуск компиляции.
repo init -u https://android.googlesource.com/platform/manifest -b <ветка>
repo sync -c -j$(nproc)
source build/envsetup.sh
lunch <цель_gsi>
make -j$(nproc) systemimage
Ключевой момент — выбор правильной цели через lunch. Для GSI существуют отдельные варианты целей (например, семейство aosp_arm64 и связанные GSI-цели), и их названия меняются между версиями Android. Актуальный список всегда смотрите в документации соответствующей ветки AOSP или выводом команды lunch без аргументов.
Результатом будет файл system.img в выходном каталоге. Перед прошивкой его полезно упаковать и сверить контрольную сумму — при последующей отладке это избавит от сомнений, не повредился ли образ при переносе.
Прошивка и первый запуск портированного образа
Процедура прошивки зависит от схемы разделов устройства. На устройствах со схемой A/B (seamless updates) system-раздел прошивается через fastboot напрямую, на старых A-only устройствах может потребоваться перепаковка или прошивка через кастомное рекавери. Универсальной команды не существует — сверяйтесь с инструкцией для вашей модели.
fastboot flash system system.img
fastboot -w
Команда fastboot -w очищает userdata — при смене системы это почти всегда необходимо, иначе старые данные приложений конфликтуют с новой системой и вызывают циклические падения. После прошивки первая загрузка занимает заметно больше времени, чем обычно: система оптимизирует приложения и инициализирует разделы.
⚠️ Внимание: перед прошивкой сохраните стоковый boot- и system-образ вашего устройства (или убедитесь, что официальный пакет прошивки доступен для скачивания). Без проверенного пути отката неудачный эксперимент с GSI может превратить устройство в нерабочее состояние, из которого придётся выходить через низкоуровневые режимы прошивки производителя.
Диагностика типичных проблем после портирования
Что делать, если устройство не загружается или работает нестабильно? Порядок диагностики идёт от простого к сложному. Сначала снимите логи: если система хотя бы частично стартует, доступен adb logcat; при раннем зависании помогает fastboot get_staged и анализ последних строк ядра через dmesg в рекавери, если оно это позволяет.
- 🔄 Бутлуп на логотипе — чаще всего несовпадение ABI/binder-варианта или несовместимость VNDK-версий
- 📶 Нет сети и модема — vendor HAL радиомодуля не соответствует ожиданиям новой системы
- 📷 Не работает камера — проприетарные камера-HAL производителя не покрываются generic-образом
- 🔐 Запрос PIN/пароля при загрузке — шифрование userdata несовместимо с новой системой, помогает форматирование данных
Наиболее коварная категория проблем — частично работающие функции: устройство загружается, но отваливается конкретный датчик или аудиотракт. Такие дефекты не видны в общих логах загрузки и требуют точечного сравнения HAL-манифестов (lshal в работающей системе) между стоком и GSI. Именно здесь кастомные GSI с патчами под конкретные платформы часто выигрывают у чистого AOSP.
Что такое VNDK и почему он важен
VNDK (Vendor Native Development Kit) — набор библиотек, через которые system взаимодействует с vendor. Версия VNDK жёстко привязана к версии Android, под которую собран vendor-раздел. GSI, собранный под существенно более новую версию системы, может требовать VNDK-интерфейсы, которых нет в старом vendor — отсюда падения системных служб. Проверить версию можно через ro.vndk.version в стоковой системе.
Разработка собственных модификаций GSI
Когда базовый образ загружается, начинается собственно разработка: внесение патчей, добавление приложений, настройка оверлеев. Для точечной адаптации под железо используются runtime resource overlays (RRO) и механизм phh-трелей — набор хуков, позволяющих включать вендор-специфичные обходные пути без пересборки всего образа.
Практический совет: ведите изменения в отдельных коммитах поверх чистого дерева AOSP, а не правьте всё скопом. Когда после очередной правки устройство перестаёт грузиться, бинарный поиск по истории git найдёт проблемный коммит за несколько итераций, тогда как отладка «большого бага» без истории может занять дни.
FAQ: частые вопросы о разработке и портировании GSI
Загрузится ли GSI на любом Android-смартфоне?
Нет. Необходима поддержка Project Treble, разблокированный загрузчик и совпадение архитектуры образа с ABI устройства. Устройства без Treble (выпущенные до Android 8 и не получившие порт Treble от сообщества) с GSI несовместимы.
Можно ли прошить GSI без разблокировки загрузчика?
Нет. Загрузчик проверяет подпись разделов, и неподписанный производителем system-образ не пройдёт верификацию. Исключений в виде «обходных» методов для массовых моделей не существует.
Почему после прошивки GSI не работает камера или мобильная сеть?
Возможная причина — несовместимость проприетарных HAL производителя с новой системой. GSI содержит только generic-компоненты, а vendor-часть остаётся старой. Проверьте через lshal, какие интерфейсы реально поднялись, и рассмотрите GSI с патчами под вашу платформу.
Сколько ресурсов нужно для сборки AOSP с нуля?
Требования зависят от версии Android и описаны в официальной документации AOSP. Ориентируйтесь на многоядерный процессор, десятки гигабайт ОЗУ и сотни гигабайт свободного дискового пространства; точные цифры сверяйте с документацией вашей ветки.
Безопасно ли использовать кастомные GSI из интернета?
Риск зависит от источника. Образы от известных разработчиков с открытыми патчами и публичной историей сборки вызывают меньше вопросов, чем анонимные файлы. Проверяйте контрольные суммы, читайте списки изменений и не устанавливайте образы без информации об авторе.