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

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

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

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

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

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

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

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

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

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

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

• userdebug определяется как пользовательская сборка с включенным корневым доступом, за исключением:
  • приложения только для отладки пользователя, которые запускаются пользователем только по запросу
  • Операции, которые выполняются только во время простоя обслуживания (на зарядке/полностью заряжен), например, использование 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-файлов продукта

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

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

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

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

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

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