Используйте информацию на этой странице для создания файлов 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 | Это вкус по умолчанию.
|
user | Вариант должен был стать финальной версией.
|
userdebug | То же, что и user , за следующими исключениями:
|
Рекомендации по пользовательской отладке
Запуск сборок 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:
- Создайте каталог
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-файл определения продукта. Пример ниже взят из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
если он еще не установлен.