Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Общие системные изображения

Общий системный образ (GSI) - это системный образ с настроенными конфигурациями для устройств Android. Он считается чистой реализацией Android с немодифицированным кодом Android Open Source Project (AOSP), который может успешно работать на любом устройстве Android под управлением Android 8.1 или выше.

GSI используются для проведения тестов VTS и CTS-on-GSI. Системный образ устройства Android заменяется GSI, затем тестируется с помощью Vendor Test Suite (VTS) и Compatibility Test Suite (CTS), чтобы убедиться, что устройство правильно реализует интерфейсы поставщика с последней версией Android.

Чтобы начать работу с GSI , просмотрите следующие разделы для получения подробной информации о конфигурации GSI (и разрешенных отклонениях), типах (Android GSI и Legacy GSI), а также двоичных файлах поставщиков и зависимостях VNDK . Когда вы будете готовы использовать GSI, загрузите и создайте GSI для своего целевого устройства, а затем перенесите GSI на устройство Android.

Конфигурация и отклонения GSI

Текущая версия Android GSI имеет следующую конфигурацию:

  • Высокие частоты. GSI включает полную поддержку архитектурных изменений на основе HIDL (также известных как Treble ), представленных в Android 8.0, включая поддержку интерфейсов HIDL . Вы можете использовать GSI на любом устройстве Android, которое использует интерфейсы поставщика HIDL. (Для получения дополнительной информации см. Архитектурные ресурсы .)
  • Проверьте загрузку. GSI не включает в себя решение для проверки загрузки (например, vboot 1.0 или AVB ). Чтобы прошить GSI на устройство, запускаемое на Android 9 или более ранней версии, устройство должно иметь метод отключения проверки загрузки.
  • Файловая система. GSI использует файловую систему ext4.
  • Разметка разделов. GSI использует схему разделов системы как корень .

Текущий Android GSI включает в себя следующие основные различия:

  • Архитектура процессора. Поддержка различных инструкций ЦП (ARM, x86 и т. Д.) И разрядности ЦП (32-разрядная или 64-разрядная).

GSI цели для испытаний на соответствие тройных

GSI, используемый для тестирования соответствия, определяется версией Android, с которой запускается устройство.

Тип устройства Построить цель
Устройства, запускаемые с Android 10 aosp_$arch-user
Устройства, запускаемые с Android 9 aosp_$arch-userdebug
Устройства, запускаемые с Android 8.0 или Android 8.1 aosp_$arch_ab-userdebug

Все GSI построены на базе кода Android 10, и каждая архитектура ЦП имеет соответствующий двоичный файл GSI (см. Список целей сборки в разделе Создание GSI ).

Android 10 GSI изменения

Устройства, запускаемые с Android 10, должны использовать GSI Android 10 для тестирования соответствия. Это включает в себя следующие основные изменения от более ранних GSI:

  • Сборка пользователя. GSI имеет пользовательскую сборку из Android 10. В Android 10 пользовательская сборка GSI может использоваться при тестировании на соответствие CTS-on-GSI / VTS. Для получения подробной информации обратитесь к разделу «Тестирование VTS с Debug Ramdisk» .
  • Неразбавленный формат. GSI с целями aosp_$arch построены в формате без разбора. Вы можете использовать img2simg чтобы конвертировать неразбавленный GSI в разреженный формат, если это необходимо.
  • Система-а-корень. aosp_$arch_a цель сборки GSI с именем aosp_$arch_a была прекращена. Для устройств, обновленных с Android 8 или 8.1 до Android 10 с aosp_$arch_ab и не-root-системой, используйте устаревшую aosp_$arch_ab GSI aosp_$arch_ab . Обновленный init в ramdisk поддерживает OEM system.img с макетом system-root.

Чтобы протестировать устройства, запускаемые на Android 9 или 10 с CTS-on-GSI, используйте цели сборки Android GSI .

Legacy GSI

Устаревшие GSI, названные с суффиксом _ab (например, aosp_arm64_ab ). Эти GSI построены из дерева исходных кодов Android 10, но содержат следующие обратно совместимые конфигурации для устройств, обновленных с Android 8 или 8.1:

  • 32-битное пользовательское пространство + 32-битный интерфейс связующего. 32-разрядные GSI могут продолжать использовать интерфейс 32-разрядного связующего.
  • 8.1 ВНДК. Устройства могут использовать включенный 8.1 VNDK.
  • Смонтировать каталоги. Некоторые устаревшие устройства используют каталоги в качестве указателей монтирования (например, /bluetooth , /firmware/radio и /persist ).

Чтобы протестировать устройства, запускаемые на Android 8 или 8.1 с CTS-on-GSI, используйте цели сборки Legacy GSI .

Android 9 GSI изменения

Android 9 GSI включают в себя следующие основные изменения по сравнению с более ранними GSI:

  • Объединяет GSI и эмулятор. GSI создаются на основе системных образов продуктов эмулятора, например, aosp_arm64 и aosp_x86 .
  • Система-а-корень. В предыдущих версиях Android устройства, которые не поддерживали обновления A / B, могли монтировать образ /system каталоге /system . В Android 9 корень образа системы монтируется как корень устройства.
  • 64-битный интерфейс связующего. В Android 8.x 32-битные GSI использовали 32-битный интерфейс связывания. Android 9 не поддерживает 32-битный интерфейс связывания, поэтому как 32-битные GSI, так и 64-битные GSI используют 64-битный интерфейс связывания.
  • ВНДК исполнения. В Android 8.1 VNDK был необязательным. Начиная с Android 9, VNDK является обязательным, поэтому необходимо установить BOARD_VNDK_VERSION .
  • Совместимое системное свойство. Android 9 включает проверку доступа для совместимого системного свойства ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Android 9 Keymaster изменения

В более ранних версиях Android устройства, реализующие Keymaster 3 или ниже, должны были проверять, чтобы информация о версии ( ro.build.version.release и ro.build.version.security_patch ), сообщаемая работающей системой, соответствовала информации о версии, сообщаемой загрузчиком. Такая информация обычно получалась из заголовка загрузочного образа.

В Android 9 и выше это требование изменилось, чтобы позволить производителям загружать GSI. В частности, Keymaster не должен выполнять проверку, поскольку информация о версии, сообщаемая GSI, может не соответствовать информации о версии, сообщаемой загрузчиком поставщика. Для устройств, реализующих Keymaster 3 или ниже, поставщики должны изменить реализацию Keymaster, чтобы пропустить проверку (или обновить до Keymaster 4). Для получения подробной информации о Keymaster см. Аппаратное хранилище ключей .

Двоичные файлы поставщика и зависимости VNDK

Устройства, обновляющиеся до Android 10, имеют разные пути обновления в зависимости от версии двоичных файлов поставщиков, используемых на устройстве, и конфигураций, связанных с VNDK, используемых для создания устройства. В следующей таблице приводится сводная информация об устаревшей поддержке GSI для обновленных устройств.

Случай использования продавец
двоичные файлы
версия
BOARD_VNDK_VERSION Legacy GSI
версия системных двоичных файлов
Поддержка Legacy GSI
0 8,0 (любой) 10 нет
1 8,1 (Пусто) 10 нет
2 8,1 current 10 да
3 10 current 10 да

Наиболее распространенным поддерживаемым вариантом использования является № 2, где устаревшие GSI поддерживают устройства под управлением Android 8.1, которые были созданы с установленным current BOARD_VNDK_VERSION .

Случай № 1 не поддерживается. В этом случае устаревшие GSI НЕ поддерживают устройства под управлением Android 8.1, где BOARD_VNDK_VERSION опущено в сборке. Эти устройства не могут поддерживаться, потому что их двоичные файлы поставщиков зависят от общих библиотек Android 8.1 без VNDK, которые не включены в устаревшие GSI. Чтобы сделать эти устройства совместимыми с устаревшей GSI, вы должны выполнить одно из следующих действий:

  • Включить BOARD_VNDK_VERSION без BOARD_VNDK_RUNTIME_DISABLE ( BOARD_VNDK_RUNTIME_DISABLE использования № 2).

    ИЛИ

  • Портируйте / обновляйте двоичные файлы вендоров, чтобы они зависели от общих библиотек из Android 10 (вариант использования № 3).

Загрузка GSI

Вы можете скачать готовые GSI с веб-сайта непрерывной интеграции AOSP по адресу ci.android.com . Если тип GSI для вашей аппаратной платформы недоступен для загрузки, обратитесь к следующему разделу для получения подробной информации о создании GSI для конкретных целей.

Создание GSI

Начиная с Android 9, каждая версия Android имеет ветку GSI с именем DESSERT -gsi на AOSP (например, android10-gsi - это ветвь GSI на Android 10). В ветви GSI входит содержимое Android со всеми исправлениями безопасности и исправлениями GSI .

Чтобы создать GSI, настройте дерево исходников Android, загрузив его из ветви GSI и выбрав цель сборки GSI . Используйте приведенные ниже таблицы целей сборки, чтобы определить правильную версию GSI для вашего устройства. После завершения сборки GSI является образом системы (то есть system.img ) и появляется в выходной папке out/target/product/ generic_arm64 . vbmeta.img также выводит vbmeta.img , который можно использовать для отключения проверки загрузки на устройствах с помощью Android Verified Boot .

Например, чтобы создать цель сборки GSI aosp_arm64-userdebug в ветви GSI android10-gsi , выполните следующие команды.

$ repo init -u https://android.googlesource.com/platform/manifest -b android10-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch aosp_arm64-userdebug
$ make -j4

Android GSI строить цели

Следующие цели сборки GSI предназначены для устройств, запускаемых на Android 9 или выше. Из-за уменьшения различий между архитектурами Android 10 включает в себя только четыре продукта GSI.

Имя GSI Арка процессора Биндер интерфейса битность Система-а-корень Построить цель
aosp_arm РУКА 64 Y aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 Y aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 x86 64 Y aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 Y aosp_x86_64-user
aosp_x86_64-userdebug

Legacy GSI строить цели

Следующие устаревшие цели сборки GSI предназначены для обновления устройств с Android 8.0 или 8.1 до Android 10. _ab имена GSI включают суффикс _ab чтобы отличать их от имен Android 10 GSI.

Имя GSI Арка процессора Биндер интерфейса битность Система-а-корень Построить цель
aosp_arm_ab РУКА 32 Y aosp_arm_ab-userdebug
aosp_arm_64b_ab РУКА 64 Y aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 Y aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 Y aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 Y aosp_x86_64_ab-userdebug

Требования к прошивке GSI

Устройства Android могут иметь различную конструкцию, поэтому нет общей команды или набора инструкций для перепрограммирования GSI, применяемого ко всем устройствам. Уточните у производителя устройства Android явные инструкции по перепрошивке. Используйте следующие шаги в качестве общего руководства:

  1. Убедитесь, что устройство имеет следующее:
    • Treblized
    • Способ разблокировки устройств (чтобы их можно было прошить с помощью fastboot )
    • Метод отключения проверки загрузки (например, vboot 1.0 или AVB )
    • Разблокированное состояние, чтобы сделать его доступным через fastboot (чтобы у вас была последняя версия fastboot , fastboot ее из дерева исходников Android).
  2. Отключить проверку загрузки.
  3. Сотрите текущий системный раздел, затем перенесите GSI в системный раздел.
  4. Сотрите пользовательские данные и удалите данные из других необходимых разделов (например, пользовательских данных и системных разделов).
  5. Перезагрузите устройство.

Например, чтобы прошить GSI на любое устройство Pixel:

  1. Загрузитесь в режим fastboot и разблокируйте загрузчик . Устройства, поддерживающие fastbootd также должны загрузиться в fastbootd :
    $ fastboot reboot fastboot
  2. Отключите проверку загрузки (AVB), перепрошив vbmeta.img :
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  3. Сотрите и прошейте GSI в системный раздел:
    $ fastboot erase system
    $ fastboot flash system system.img
    
  4. Сотрите пользовательские данные и удалите данные из других необходимых разделов (например, пользовательских данных и системных разделов):
    $ fastboot -w
  5. Перезагрузка:
    $ fastboot reboot
На устройствах Android 10 с небольшими системными разделами может появиться следующее сообщение об ошибке при перепрошивке GSI:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Используйте следующую команду, чтобы удалить раздел продукта и освободить место для системного раздела. Это обеспечивает дополнительное пространство для прошивки GSI:
$ fastboot delete-logical-partition product_a
Постфикс _a должен соответствовать идентификатору слота системного раздела, например, system_a в этом примере.

Содействие GSIs

Android приветствует ваш вклад в развитие GSI. Вы можете принять участие и помочь улучшить GSI:

  • Создание патча GSI. DESSERT -gsi не является веткой разработки и принимает только черриков из основной ветки AOSP, поэтому для отправки патча GSI вы должны:
    1. Отправьте патч в master ветку AOSP .
    2. Cherrypick патч для DESSERT -gsi .
    3. Отправьте сообщение об ошибке, чтобы получить отзыв о вишенке.
  • Сообщение об ошибках GSI или внесение других предложений. Просмотрите инструкции в разделе « Отчеты об ошибках» , затем просмотрите или зарегистрируйте ошибки GSI .

подсказки

Изменение режима панели навигации с помощью adb

При загрузке с GSI режим панели навигации настраивается переопределением поставщика. Вы можете изменить режим панели навигации, выполнив следующую команду adb во время выполнения.

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar. mode

Где mode может быть threebutton , twobutton , gestural и т. Д.