Создание и развертывание пакетов услуг

После создания промежуточного ПО и написания собственного кода вы можете развернуть пакеты сервисов в виде файлов APEX.

  1. Создайте конфигурационные файлы SDV:

    Ржавчина

    1. Сгенерируйте конфигурационные файлы SDV, выполнив следующую команду:

      vsidlc -c /path/to/catalog -o /path/to/output --apex

      Запуск vsidlc с флагом --apex автоматически генерирует все необходимые конфигурационные файлы, включая:

      • Манифест APEX ( apex_manifest.json )
      • Манифест метаданных SDV ( sdv_service_bundles_manifest.textproto )
      • Конфигурация компоновщика ( linker.config.json )
      • Контексты файлов SELinux ( file_contexts )
      • Открытые и закрытые ключи ( .avbpubkey и .pem )
      • Объявления о правах доступа и конфигурации оркестровки
      • Файл Android.bp , определяющий все необходимые модули Soong.

      Сгенерированные конфигурации можно найти по следующему адресу:

      /path/to/output/apex/

      и,

      /path/to/output/configs/

    C++

    1. Создайте файл манифеста метаданных SDV, service_bundle.manifest.textproto , содержащий следующие важные поля метаданных выполнения:

      • Название сервиса в соответствии с принятыми правилами именования.
      • Целочисленное и строковое представление версии пакета сервиса.
      • Путь к созданной ранее библиотеке

      Подготовка необходимых метаданных для пакетов услуг является обязательной для их упаковки и развертывания.

      # proto-file: //system/software_defined_vehicle/core_services/service_bundles_registry/proto/sdv_service_bundles_manifest.proto
# proto-message: SdvServiceBundleManifestEntry

# SDV service bundle metadata definition with mandatory fields.
sdv_service_bundle_metadata {
  # Service bundle name.
  name: "ServiceBundleName"
  # Service bundle integer version.
  version_number: 42
  # Service bundle version as a string.
  version_name: "42.alpha"
  # Service bundle library path.
  native_library_path: "lib64/libservice_bundle.so"
}

    2. Создайте новый файл конфигурации компоновщика , linker.config.json :

      { "visible": true }

    3. Создайте новый файл apex_manifest.json со следующими полями:

      • Уникальное имя пакета SDV
      • Версия APEX
      • Зависимость от библиотек связи SDV.
      {
  "name": "com.sdv.oem.apex_and_module_name",
  "version": 1,
  "requireNativeLibs": [
      "libsdv_comms_ctx_ffi.so",
      "libsdv_comms_dt_ffi.so",
      "libsdv_comms_id_ffi.so",
      "libsdv_comms_sd_ffi.so"
  ]
}

    4. Создайте открытый ключ apex_name.apex_key .avbpubkey и закрытый ключ apex_name.apex_key .pem .

    5. Создайте новый контекст файла SELinux apex_file_contexts .

      (/.*)?    u:object_r:system_file:s0

      Для получения более подробной информации см. раздел «Контекст и категории безопасности» .

    6. Создавайте предварительно собранные цели в новом или существующем файле Android.bp :

      // SDV manifest file prebuilt.
prebuilt_etc {
    name: "com.sdv.oem.apex_and_module_name.service_bundles_manifest",
    // The source filename of the manifest file.
    src: "service_bundle.manifest.textproto",
    // The name of the installed file needs be `sdv_service_bundles_manifest.textproto`.
    filename: "sdv_service_bundles_manifest.textproto",
    // Disable direct installation of the prebuilt to one of the partitions.
    // The manifest is used only inside of an apex.
    installable: false,
}
// The linker config to allow libraries for the apex to be linkable.
linker_config {
    name: "com.sdv.oem.apex_and_module_name. linker_config",
    src: "linker.config.json",
    // Disable direct installation of the prebuilt to one of the partitions.
    // The linker configuration is used only inside of an apex.
    installable: false,
}
// Key to be used for signing the apex.
apex_key {
    name: "apex_name.apex_key",
    public_key: "apex_name.apex_key.avbpubkey",
    private_key: "apex_name.apex_key.pem",
}

    7. Создайте новый модуль APEX в новом или существующем файле Android.bp . Используйте имя пакета SDV в качестве имени модуля APEX.

      apex {
    name: "com.sdv.oem.apex_and_module_name",
    // The service bundle(s) to be included in the apex.
    native_shared_libs: [
        "libservice_bundle",
    ],
    prebuilts: [
        // SDV service bundles manifest file.
        "com.sdv.oem.apex_and_module_name.service_bundles_manifest",
        // Linker configuration to enable loading library from apex.
        "com.sdv.oem.apex_and_module_name.linker_config",
    ],
    // Json manifest file describes metadata of the APEX package.
    // The 'name' field from the JSON is used as a mounting point.
    manifest: "apex_manifest.json",
    // Setting the security contexts to files in this APEX bundle.
    file_contexts: "apex_file_contexts",
    // Name of the apex_key module that provides the private key to sign the APEX bundle.
    key: "apex_name.apex_key",
    // Mark apex as non-updatable for now, this might be revisited going forward.
    updatable: false,
    // Service bundle package is installed into /product partition.
    product_specific: true,
}

  2. Чтобы включить новый makefile в образ SDV, добавьте новый модуль APEX в раздел PRODUCT_PACKAGES в makefile продукта . Например, см. sdv_samples_core_services.mk .

  3. Если вы используете Cuttlefish, выполните следующую команду для запуска устройства: 

    sdv-cf create --instance_name=instance1

  4. Запустите пакет служб при загрузке системы: 

    # Grant root access.
adb root
# Launch the new service bundle.
adb shell sdv_service_bundle start \
  local-vm:com.sdv.oem.apex_and_module_name.ServiceBundleName/instance-1

управление зависимостями пакетов сервисов

В некоторых сценариях статическая компоновка зависимостей пакетов служб может помочь уменьшить размер APEX-файлов и объем памяти, занимаемый пакетами служб, а также сократить время запуска пакетов служб. К таким сценариям относятся APEX-файлы со следующими характеристиками:

  • Пакеты отдельных услуг
  • Несколько пакетов сервисов, которые не имеют много общих зависимостей.

Для включения статической компоновки добавьте следующие свойства в определение библиотеки пакета служб: 

// Service bundle library.
rust_ffi_shared {
  // See rust_ffi_shared basic template.
  ...
  // uses static linking for the dependencies
  prefer_rlib: true,
  // needed to correctly resolve commstack deps
  ld_flags: ["-Wl,--no-as-needed"],
}

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

Отладка (dumpsys)

Менеджер жизненного цикла реализует интерфейс dumpsys . Этот интерфейс отображает пользователю список пакетов служб, находящихся в состоянии created или started . Интерфейс также отображает полный квалифицированный идентификатор (FQIN) или уникальный идентификатор (UID) процесса пакета служб.

Чтобы просмотреть текущее состояние и идентификаторы ваших пакетов служб, выполните следующую команду: 

# Grant root access.
adb root

# Execute dumpsys to see service bundles state
adb shell dumpsys google.sdv.lifecycle.ILifecycleManager/default

Что дальше?

Для автоматического запуска vsidlc и обеспечения работы плагина IDE с зависимостями см. раздел «Автоматическое обновление каталога и интеграция LSP» .