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

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

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

Понимание слоев построения

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

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

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

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

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

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

Запуск сборок 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-файлов продукта

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

1. Создайте каталог device/ <company-name> / <device-name> для вашего продукта. Например, device/google/marlin . Этот каталог будет содержать исходный код вашего устройства, а также файлы make-файлов для его сборки.
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-файл определения продукта. Пример ниже взят из device/google/marlin/AndroidProducts.mk (который содержит как Marlin, Pixel, так и парусник, 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 Google генерирует новую пару ключей для каждой новой версии ОС.
2. Проверьте пары ключей где-нибудь в дереве исходного кода. Google хранит их, например, в vendor/google/security/adb/ .
3. Установите переменную сборки PRODUCT_ADB_KEYS , чтобы она указывала на ваш каталог ключей. Google делает это, добавляя файл Android.mk в каталог ключей с именем PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub , что помогает гарантировать, что мы не забудем сгенерировать новую пару ключей для каждой версии ОС.

Вот make-файл, который 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 если он еще не установлен.