Добавить новое устройство

Используйте информацию на этой странице для создания make-файлов для вашего устройства и продукта.

Каждый новый модуль Android должен иметь файл конфигурации, управляющий системой сборки, содержащий метаданные модуля, зависимости времени компиляции и инструкции по упаковке. Android использует систему сборки Soong . Подробнее о системе сборки Android см. в разделе «Сборка Android».

Понимание слоев сборки

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

Использовать варианты сборки

При сборке для конкретного продукта полезно иметь небольшие изменения в финальной сборке. В определении модуля можно указать теги LOCAL_MODULE_TAGS , которые могут принимать одно или несколько значений: optional (по умолчанию), debug и eng .

Если у модуля не указан тег (с помощью LOCAL_MODULE_TAGS ), его тег по умолчанию — optional . Дополнительный модуль устанавливается только в том случае, если это требуется конфигурацией продукта с помощью PRODUCT_PACKAGES .

Это текущие определенные варианты сборки.

Руководство по отладке пользователя

Запуск сборок userdebug в процессе тестирования помогает разработчикам устройств оценить производительность и возможности разрабатываемых версий. Чтобы обеспечить согласованность между сборками userdebug и userdebug, а также получить достоверные показатели в сборках, используемых для отладки, разработчикам устройств следует следовать следующим рекомендациям:

• userdebug определяется как пользовательская сборка с включенным доступом root, за исключением:
  • приложения, доступные только для отладки пользователем, которые запускаются только по требованию пользователя
  • Операции, которые выполняются только во время простоя (при зарядке/полной зарядке), например, использование dex2oatd вместо dex2oat для фоновой компиляции
• Не включайте функции, которые включены/отключены по умолчанию в зависимости от типа сборки. Разработчикам не рекомендуется использовать любые формы журналирования, влияющие на время работы от батареи, например, журналирование отладки или дамп кучи.
• Все функции отладки, включённые по умолчанию в userdebug, должны быть чётко определены и предоставлены всем разработчикам, работающим над проектом. Функции отладки следует включать только на ограниченное время, пока не будет решена проблема, которую вы пытаетесь отладить.

Настройте сборку с помощью наложений ресурсов

Система сборки Android использует наложения ресурсов для настройки продукта во время сборки. Наложения ресурсов определяют файлы ресурсов, которые применяются поверх файлов по умолчанию. Чтобы использовать наложения ресурсов, измените файл сборки проекта, указав в параметре PRODUCT_PACKAGE_OVERLAYS путь относительно каталога верхнего уровня. Этот путь станет теневым корневым каталогом, который будет просматриваться вместе с текущим корневым каталогом при поиске ресурсов системой сборки.

Наиболее часто настраиваемые параметры содержатся в файле frameworks/base/core/res/res/values/config.xml .

Чтобы настроить наложение ресурсов на этот файл, добавьте каталог наложения в файл сборки проекта, используя один из следующих способов:

PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay

или

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

Затем добавьте в каталог файл наложения, например:

vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml

Любые строки или массивы строк, найденные в файле наложения config.xml заменяют те, что находятся в исходном файле.

Создайте продукт

Вы можете организовать исходные файлы для своего устройства различными способами. Вот краткое описание одного из способов организации реализации для Pixel.

Pixel реализован с помощью основной конфигурации устройства marlin . На основе этой конфигурации устройства создаётся продукт с помощью make-файла определения продукта, который объявляет специфичную для продукта информацию об устройстве, такую ​​как название и модель. Вы можете просмотреть каталог device/google/marlin чтобы увидеть, как всё это настроено.

Написать make-файлы продукта

Следующие шаги описывают, как настроить make-файлы продукта аналогично линейке продуктов Pixel:

1. Создайте каталог device/ <company-name> / <device-name> для вашего продукта. Например, device/google/marlin . Этот каталог будет содержать исходный код вашего устройства, а также файлы makefile для его сборки.
2. Создайте make-файл device.mk , в котором указаны файлы и модули, необходимые для устройства. Пример см. в device/google/marlin/device-marlin.mk .
3. Создайте make-файл определения продукта для создания конкретного продукта на основе устройства. Следующий make-файл взят из device/google/marlin/aosp_marlin.mk в качестве примера. Обратите внимание, что продукт наследует файлы device/google/marlin/device-marlin.mk и vendor/google/marlin/device-vendor-marlin.mk через make-файл, а также объявляет специфичную для продукта информацию, такую ​​как название, марка и модель.

   # Inherit from the common Open Source product configuration
   $(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
   $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk)
   
   PRODUCT_NAME := aosp_marlin
   PRODUCT_DEVICE := marlin
   PRODUCT_BRAND := Android
   PRODUCT_MODEL := AOSP on msm8996
   PRODUCT_MANUFACTURER := Google
   PRODUCT_RESTRICT_VENDOR_FILES := true
   
   PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin
   
   $(call inherit-product, device/google/marlin/device-marlin.mk)
   $(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk)
   
   PRODUCT_PACKAGES += \
       Launcher3QuickStep \
       WallpaperPicker
   

   Дополнительные переменные, специфичные для продукта, которые можно добавить в make-файлы, см. в разделе Настройка переменных определения продукта .

4. Создайте файл AndroidProducts.mk , указывающий на make-файлы продукта. В этом примере требуется только make-файл определения продукта. Пример ниже взят из файла device/google/marlin/AndroidProducts.mk (который содержит как marlin (Pixel), так и sailfish (Pixel XL), которые имеют практически одинаковую конфигурацию):

   PRODUCT_MAKEFILES := \
   	$(LOCAL_DIR)/aosp_marlin.mk \
   	$(LOCAL_DIR)/aosp_sailfish.mk
   
   COMMON_LUNCH_CHOICES := \
   	aosp_marlin-userdebug \
   	aosp_sailfish-userdebug
   

5. Создайте make-файл BoardConfig.mk , содержащий конфигурации, специфичные для конкретной платы. Пример см. в файле device/google/marlin/BoardConfig.mk .
6. Только для Android 9 и ниже : создайте файл vendorsetup.sh , чтобы добавить свой продукт («комбинацию обедов») в сборку вместе с вариантом сборки, разделённым тире. Например:

   add_lunch_combo <product-name>-userdebug
   

7. На этом этапе вы можете создать больше вариантов продукта на основе одного и того же устройства.

Установить переменные определения продукта

Переменные, специфичные для продукта, определены в make-файле продукта. В таблице представлены некоторые переменные, хранящиеся в файле определения продукта.

Настройте язык системы по умолчанию и фильтр локали

Используйте эту информацию для настройки фильтра языка по умолчанию и региональных параметров системы, затем включите фильтр региональных параметров для нового типа устройства.

Характеристики

Настройте язык по умолчанию и фильтр региональных параметров системы с помощью специальных системных свойств:

• ro.product.locale : для установки локали по умолчанию. Изначально задана первая локаль в переменной PRODUCT_LOCALES ; это значение можно переопределить. (Подробнее см. в таблице « Установка переменных определения продукта» .)
• ro.localization.locale_filter : для настройки фильтра локали с использованием регулярного выражения, применяемого к названиям локалей. Например:
  • Включающий фильтр: ^(de-AT|de-DE|en|uk).* — допускает только немецкий язык (варианты Австрии и Германии), все английские варианты английского языка и украинский язык.
  • Эксклюзивный фильтр: ^(?!de-IT|es).* — исключает немецкий язык (итальянский вариант) и все варианты испанского языка.

Включить фильтр локали

Чтобы включить фильтр, задайте строковое значение системного свойства ro.localization.locale_filter .

Установив значение свойства фильтра и язык по умолчанию через oem/oem.prop во время заводской калибровки, вы можете настроить ограничения, не встраивая фильтр в образ системы. Чтобы гарантировать получение этих свойств из OEM-раздела, добавьте их в переменную PRODUCT_OEM_PROPERTIES , как указано ниже:

# Delegation for OEM customization
PRODUCT_OEM_PROPERTIES += \
    ro.product.locale \
    ro.localization.locale_filter

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

Настройте ADB_VENDOR_KEYS для подключения по USB

Переменная окружения ADB_VENDOR_KEYS позволяет производителям устройств получать доступ к отлаживаемым сборкам (-userdebug и -eng, но не -user) через adb без ручной авторизации. Обычно adb генерирует уникальный ключ аутентификации RSA для каждого клиентского компьютера, который отправляется на любое подключенное устройство. Этот ключ RSA отображается в диалоговом окне авторизации adb. В качестве альтернативы вы можете встроить известные ключи в образ системы и поделиться ими с клиентом adb. Это полезно для разработки ОС и, особенно, для тестирования, поскольку исключает необходимость ручного взаимодействия с диалоговым окном авторизации adb.

Чтобы создать ключи поставщика, один человек (обычно менеджер по выпуску) должен:

1. Сгенерируйте пару ключей с помощью adb keygen . Для устройств Google компания генерирует новую пару ключей для каждой новой версии ОС.
2. Проверьте пары ключей где-нибудь в исходном дереве. Google хранит их, например, в vendor/google/security/adb/ .
3. Установите переменную сборки PRODUCT_ADB_KEYS так, чтобы она указывала на ваш каталог ключей. Google делает это, добавляя в каталог ключей файл Android.mk со следующим текстом: PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub . Это помогает нам не забыть сгенерировать новую пару ключей для каждой версии ОС.

Вот makefile, который Google использует в каталоге, где мы храним наши зарегистрированные пары ключей для каждого выпуска:

PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub

ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),)
  $(warning ========================)
  $(warning The adb key for this release)
  $(warning )
  $(warning   $(PRODUCT_ADB_KEYS))
  $(warning )
  $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk)
  $(warning has changed and a new adb key needs to be generated.)
  $(warning )
  $(warning Please run the following commands to create a new key:)
  $(warning )
  $(warning   make -j8 adb)
  $(warning   LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS)))
  $(warning )
  $(warning and upload/review/submit the changes)
  $(warning ========================)
  $(error done)
endif

Чтобы использовать эти ключи поставщика, инженеру достаточно настроить переменную окружения ADB_VENDOR_KEYS так, чтобы она указывала на каталог, в котором хранятся пары ключей. Это предписывает adb сначала попробовать эти канонические ключи, прежде чем переходить к сгенерированному ключу хоста, требующему ручной авторизации. Если adb не может подключиться к неавторизованному устройству, сообщение об ошибке предложит вам установить ADB_VENDOR_KEYS если она ещё не установлена.