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

Используйте информацию на этой странице для создания 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 . Из этой конфигурации устройства создается продукт с makefile определения продукта, который объявляет специфичную для продукта информацию об устройстве, такую ​​как имя и модель. Вы можете просмотреть каталог device/google/marlin чтобы увидеть, как все это настроено.

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

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

1. Создайте каталог device/ <company-name> / <device-name> для вашего продукта. Например, device/google/marlin . Этот каталог будет содержать исходный код для вашего устройства вместе с makefiles для их сборки.
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 , который указывает на makefile продукта. В этом примере нужен только makefile определения продукта. Пример ниже взят из 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. Создайте файл 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 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 , если он еще не установлен.