Создание интерфейса HAL

Вы должны использовать HIDL для описания всех флагов сборки, используемых для условной компиляции фреймворка. Соответствующие флаги сборки должны быть сгруппированы и включены в один файл .hal . Использование HIDL для указания элементов конфигурации дает следующие преимущества:

  • Поддержка версий (для добавления новых элементов конфигурации поставщики / OEM-производители должны явно расширить HAL)
  • Хорошо задокументированы
  • Контроль доступа с помощью SELinux
  • Проверка работоспособности элементов конфигурации с помощью Vendor Test Suite (проверка диапазона, проверка взаимозависимостей между элементами и т. Д.)
  • Автоматически сгенерированные API на C ++ и Java

Определение флагов сборки, используемых фреймворком

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

  • TARGET_USES_HWC2
  • TARGET_BOARD_PLATFORM
  • TARGET_DISABLE_TRIPLE_BUFFERING
  • TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
  • NUM_FRAMEBUFFER_SURFACE_BUFFERS
  • TARGET_RUNNING_WITHOUT_SYNC_FRAMEWORK
  • VSYNC_EVENT_PHASE_OFFSET_NS
  • SF_VSYNC_EVENT_PHASE_OFFSET_NS
  • PRESENT_TIME_OFFSET_FROM_VSYNC_NS
  • MAX_VIRTUAL_DISPLAY_DIMENSION

Создание интерфейса HAL

Доступ к конфигурациям сборки для подсистемы осуществляется через интерфейс HAL, в то время как интерфейсы для предоставления значений конфигурации сгруппированы в пакете HAL android.hardware.configstore (в настоящее время версия 1.0). Например, чтобы создать файл интерфейса HAL для surfaceflinger , в hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal :

package android.hardware.configstore@1.0;

interface ISurfaceFlingerConfigs {
    // TO-BE-FILLED-BELOW
};

После создания файла .hal запустите hardware/interfaces/update-makefiles.sh чтобы добавить новый файл .hal файлы Android.bp и Android.mk .

Добавление функций для флагов сборки

Для каждого флага сборки добавьте новую функцию в интерфейс. Например, в hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal :

interface ISurfaceFlingerConfigs {
    disableTripleBuffering() generates(OptionalBool ret);
    forceHwcForVirtualDisplays() generates(OptionalBool ret);
    enum NumBuffers: uint8_t {
        USE_DEFAULT = 0,
        TWO = 2,
        THREE = 3,
    };
    numFramebufferSurfaceBuffers() generates(NumBuffers ret);
    runWithoutSyncFramework() generates(OptionalBool ret);
    vsyncEventPhaseOffsetNs generates (OptionalUInt64 ret);
    presentTimeOffsetFromSyncNs generates (OptionalUInt64 ret);
    maxVirtualDisplayDimension() generates(OptionalInt32 ret);
};

При добавлении функции:

  • Будьте краткими с именами. Избегайте преобразования имен переменных make-файла в имена функций и помните, что TARGET_ и BOARD_ больше не нужны.
  • Добавляйте комментарии. Помогите разработчикам понять назначение элемента конфигурации, то, как он изменяет поведение платформы, допустимые значения и другую важную информацию.

Типы возвращаемых функций могут быть Optional[Bool|String|Int32|UInt32|Int64|UInt64] . Типы определены в types.hal в том же каталоге и types.hal в себя примитивные значения с полем, которое указывает, задано ли значение HAL; в противном случае используется значение по умолчанию.

struct OptionalString {
    bool specified;
    string value;
};

При необходимости определите перечисление, которое наилучшим образом представляет тип элемента конфигурации, и используйте это перечисление в качестве возвращаемого типа. В приведенном выше NumBuffers перечисление NumBuffers определено для ограничения количества допустимых значений. При определении таких настраиваемых типов данных добавьте поле или значение перечисления (например, USE_DEFAULT ) для обозначения того, указано ли значение / не указано HAL.

Необязательно, чтобы один флаг сборки стал отдельной функцией в HIDL. В качестве альтернативы владельцы модулей могут агрегировать тесно связанные флаги сборки в структуру и иметь функцию, которая возвращает эту структуру (это может уменьшить количество вызовов функций).

Например, вариант объединения двух флагов сборки в одну структуру в hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal :

 interface ISurfaceFlingerConfigs {
    // other functions here
    struct SyncConfigs {
        OptionalInt64 vsyncEventPhaseoffsetNs;
        OptionalInt64 presentTimeoffsetFromSyncNs;
    };
    getSyncConfigs() generates (SyncConfigs ret);
    // other functions here
};

Альтернативы одной функции HAL

В качестве альтернативы использованию одной функции HAL для всех флагов сборки интерфейс HAL также предоставляет простые функции, такие как getBoolean(string key) и getInteger(string key) . Фактические пары key=value хранятся в отдельных файлах, и служба HAL предоставляет значения путем чтения / анализа этих файлов.

Хотя этот подход легко определить, он не включает преимуществ, предоставляемых HIDL (принудительное управление версиями, простота документации, контроль доступа), и поэтому не рекомендуется.

Один и несколько интерфейсов

Дизайн интерфейса HAL для элементов конфигурации предлагает два варианта:

  • Единый интерфейс, охватывающий все элементы конфигурации
  • Несколько интерфейсов, каждый из которых охватывает набор связанных элементов конфигурации

Единый интерфейс проще, но может стать недоступным для обслуживания по мере добавления дополнительных элементов конфигурации в один файл. Кроме того, управление доступом не является детализированным, поэтому процесс, которому предоставлен доступ к интерфейсу, может читать все элементы конфигурации (доступ к частичному набору элементов конфигурации не может быть предоставлен). В качестве альтернативы, если доступ не предоставлен, элементы конфигурации не могут быть прочитаны.

Из-за этих проблем Android использует несколько интерфейсов с одним интерфейсом HAL для группы связанных элементов конфигурации. Например, ISurfaceflingerConfigs для surfaceflinger о связанных конфигурации элементов и IBluetoothConfigs для Bluetooth-связанных элементов конфигурации.