Эта страница переведена с помощью Cloud Translation API.

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

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

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

Общие сведения о слоях сборки

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

Слой	Пример	Описание
Товар	мой продукт, myProduct_eu, myProduct_eu_fr, j2, SDK	Уровень продукта определяет спецификацию функций поставляемого продукта, например модули для сборки, поддерживаемые локали и конфигурацию для различных локалей. Другими словами, это название всего продукта. Переменные, специфичные для продукта, определяются в make-файлах определения продукта. Продукт может наследовать определения других продуктов, что упрощает обслуживание. Распространенный метод заключается в создании базового продукта, содержащего функции, применимые ко всем продуктам, а затем создании вариантов продукта на основе этого базового продукта. Например, два продукта, которые отличаются только своими радиомодулями (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` включен по умолчанию.

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

Система сборки 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:

Создайте каталог device/ <company-name> / <device-name> для вашего продукта. Например, device/google/marlin . Этот каталог будет содержать исходный код для вашего устройства вместе с make-файлами для их сборки.
Создайте make-файл device.mk , в котором объявляются файлы и модули, необходимые для устройства. Пример см. на device/google/marlin/device-marlin.mk .
Создайте 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-файлы, см. в разделе Установка переменных определения продукта.
Создайте файл AndroidProducts.mk , указывающий на make-файлы продукта. В этом примере нужен только 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
```
Создайте make-файл BoardConfig.mk , содержащий конфигурации для конкретной платы. Пример см. в разделе device/google/marlin/BoardConfig.mk .
Только для Android 9 и более ранних версий: создайте файл vendorsetup.sh , чтобы добавить в сборку ваш продукт («комбинация обедов») вместе с вариантом сборки, разделенными дефисом. Например:
```
add_lunch_combo <product-name>-userdebug
```
На этом этапе вы можете создать больше вариантов продукта на основе одного и того же устройства.

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

Переменные, специфичные для продукта, определены в 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.

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

Сгенерируйте пару ключей с помощью adb keygen . Для устройств Google Google создает новую пару ключей для каждой новой версии ОС.
Проверьте пары ключей где-нибудь в исходном дереве. Google хранит их, например, в vendor/google/security/adb/ .
Установите переменную сборки 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 , если он еще не установлен.