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

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

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

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

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

Слой Пример Описание
Продукт myProduct, myProduct_eu, myProduct_eu_fr, j2, SDK Уровень продукта определяет характеристики поставляемого продукта, такие как модули для сборки, поддерживаемые локали и настройки для различных локалей. Другими словами, это название всего продукта. Переменные, специфичные для продукта, определяются в файлах сборки определения продукта. Продукт может наследовать определения других продуктов, что упрощает обслуживание. Распространенный метод — создать базовый продукт, содержащий функции, применимые ко всем продуктам, а затем создать варианты продукта на основе этого базового продукта. Например, два продукта, которые отличаются только радиомодулями (CDMA и GSM), могут наследовать один и тот же базовый продукт, который не определяет радиомодуль.
Плата/устройство марлин, голубая линия, коралл Слой платы/устройства представляет собой физический слой пластика на устройстве (то есть промышленный образец устройства). Этот слой также представляет собой схему продукта. К ним относятся периферийные устройства на плате и их конфигурация. Используемые имена представляют собой просто коды для различных конфигураций плат/устройств.
Арка рука, x86, рука64, x86_64 Уровень архитектуры описывает конфигурацию процессора и бинарный интерфейс приложений (ABI), работающий на плате.

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

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

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

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

Вариант Описание
eng Это вкус по умолчанию.
  • Устанавливает модули с тегами eng или debug .
  • Устанавливает модули в соответствии с файлами определения продукта в дополнение к отмеченным модулям.
  • ro.secure=0
  • ro.debuggable=1
  • ro.kernel.android.checkjni=1
  • adb включен по умолчанию.
user Вариант должен был стать финальной версией.
  • Устанавливает модули с тегом user .
  • Устанавливает модули в соответствии с файлами определения продукта в дополнение к отмеченным модулям.
  • ro.secure=1
  • ro.debuggable=0
  • adb по умолчанию отключен.
userdebug То же, что и user , за следующими исключениями:
  • Также устанавливает модули с тегом debug .
  • ro.debuggable=1
  • adb включен по умолчанию.

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

Запуск сборок 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-файле продукта. В таблице показаны некоторые переменные, хранящиеся в файле определения продукта.

Переменная Описание Пример
PRODUCT_AAPT_CONFIG Конфигурации aapt , которые будут использоваться при создании пакетов.
PRODUCT_BRAND Бренд (например, оператор связи), для которого настроено программное обеспечение.
PRODUCT_CHARACTERISTICS Характеристики aapt , позволяющие добавлять в пакет ресурсы, специфичные для варианта. tablet , nosdcard
PRODUCT_COPY_FILES Список таких слов, как source_path:destination_path . Файл по исходному пути должен быть скопирован в целевой путь при сборке этого продукта. Правила для шагов копирования определены в config/makefile .
PRODUCT_DEVICE Название промышленного образца. Это также имя платы, и система сборки использует его для поиска BoardConfig.mk . tuna
PRODUCT_LOCALES Разделенный пробелами список двухбуквенных кодов языка и пар двухбуквенных кодов стран, описывающих несколько настроек пользователя, таких как язык пользовательского интерфейса, время, дата и формат валюты. Первый языковой стандарт, указанный в PRODUCT_LOCALES , используется в качестве языкового стандарта продукта по умолчанию. en_GB , de_DE , es_ES , fr_CA
PRODUCT_MANUFACTURER Название производителя. acme
PRODUCT_MODEL Видимое конечному пользователю имя конечного продукта.
PRODUCT_NAME Видимое конечному пользователю имя всего продукта. Отображается на экране «Настройки» > «О программе» .
PRODUCT_OTA_PUBLIC_KEYS Список открытых ключей для продукта по беспроводной сети (OTA).
PRODUCT_PACKAGES Список APK и модулей для установки. Контакты календаря
PRODUCT_PACKAGE_OVERLAYS Указывает, следует ли использовать ресурсы по умолчанию или добавлять какие-либо наложения, специфичные для продукта. vendor/acme/overlay
PRODUCT_SYSTEM_PROPERTIES Список назначений системных свойств в формате "key=value" для системного раздела. Системные свойства для других разделов можно установить с помощью PRODUCT_<PARTITION>_PROPERTIES , как в PRODUCT_VENDOR_PROPERTIES для раздела поставщика. Поддерживаемые имена разделов: SYSTEM , VENDOR , ODM , SYSTEM_EXT и PRODUCT .

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

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

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

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

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