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

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

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

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

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

Слой Пример Описание
Продукт myProduct, myProduct_eu, myProduct_eu_fr, j2, SDK Уровень продукта определяет спецификацию функций поставляемого продукта, например, модули для сборки, поддерживаемые локали и конфигурацию для различных локалей. Другими словами, это имя общего продукта. Переменные, специфичные для продукта, определены в make-файлах определения продукта. Продукт может наследовать от других определений продукта, что упрощает обслуживание. Распространенным методом является создание базового продукта, который содержит функции, применимые ко всем продуктам, а затем создание вариантов продукта на основе этого базового продукта. Например, два продукта, которые отличаются только своими радиомодулями (CDMA и GSM), могут быть унаследованы от одного и того же базового продукта, который не определяет радиомодуль.
Доска / устройство марлин, синий цвет, коралл Уровень платы / устройства представляет собой физический слой пластика на устройстве (то есть промышленный образец устройства). Этот слой также представляет собой простую схему продукта. К ним относятся периферийные устройства на плате и их конфигурация. Используемые имена - это просто коды для различных конфигураций платы / устройства.
Арка рука, x86, arm64, 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 определяется как пользовательская сборка с включенным корневым доступом, за исключением:
    • приложения только для отладки пользователя, которые запускаются пользователем только по запросу
    • Операции , которые работают только в режиме ожидания обслуживания (на зарядное устройство / полностью заряжена), такие как использование dex2oatd против dex2oat для фона компилирует
  • Не включайте функции, которые включены / отключены по умолчанию в зависимости от типа сборки. Разработчикам не рекомендуется использовать какие-либо формы ведения журнала, влияющие на срок службы батареи, такие как ведение журнала отладки или сброс кучи.
  • Любые функции отладки, которые включены по умолчанию в userdebug, должны быть четко определены и доступны всем разработчикам, работающим над проектом. Вы должны включать функции отладки только на ограниченный период времени, пока проблема, которую вы пытаетесь отладить, не будет решена.

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

Система сборки Android использует наложения ресурсов для настройки продукта во время сборки. Наложения ресурсов определяют файлы ресурсов, которые применяются поверх значений по умолчанию. Для использования наложений ресурсов, изменить Buildfile проекта создания PRODUCT_PACKAGE_OVERLAYS на пути относительно каталога верхнего уровня. Этот путь становится теневым корнем, который ищется вместе с текущим корнем, когда система сборки ищет ресурсы.

Наиболее часто настроены параметры содержатся в файле рамок / базы / ядра / RES / RES / значений / 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. Создать device.mk Makefile , который объявляет файлы и модули , необходимые для устройства. Для примера, см device/google/marlin/device-marlin.mk .
  3. Создайте make-файл определения продукта, чтобы создать конкретный продукт на основе устройства. Следующий 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
    

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

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

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

Переменные, специфичные для продукта, определены в файле makefile продукта. В таблице показаны некоторые переменные, хранящиеся в файле определения продукта.

Переменная Описание Пример
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 , если он еще не установлен.