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

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

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

Разберитесь в слоях построения.

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

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

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

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

Это существующие на данный момент варианты сборки.

Рекомендации по отладке пользователя

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

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

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

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

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

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

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

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

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

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

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

Напишите make-файлы для продукта

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

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

   # 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. Создайте файл makefile BoardConfig.mk , содержащий конфигурации, специфичные для конкретной платы. Пример можно найти в файле device/google/marlin/BoardConfig.mk .
6. Только для Android 9 и ниже создайте файл vendorsetup.sh , чтобы добавить ваш продукт («ланч-бокс») в сборку вместе с вариантом сборки, разделенным дефисом. Например:

   add_lunch_combo <product-name>-userdebug
   

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

Задайте переменные определения продукта

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

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

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

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

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

• 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 если она еще не установлена.