Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

HIDL C ++

Android O реструктурирует ОС Android, чтобы определить четкие интерфейсы между независимой от устройства платформой Android и кодом, специфичным для устройства и поставщика. Android уже определяет многие такие интерфейсы в форме интерфейсов HAL, определенных как заголовки C в hardware/libhardware . HIDL заменяет эти интерфейсы HAL стабильными версионными интерфейсами, которые могут быть интерфейсами HIDL на стороне клиента и на стороне сервера в C ++ (описано ниже) или Java .

Страницы в этом разделе описывают C ++ реализаций HIDL интерфейсов, включая информацию о файлах автоматически сгенерированных из HIDL .hal файлов по hidl-gen компилятору, как эти файлы упакованы, и как интегрировать эти файлы с C ++ код, использует их.

Клиент и сервер реализации

Интерфейсы HIDL имеют реализации клиента и сервера:

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

При переходе от libhardware HAL к HIDL HAL реализация HAL становится сервером, а процесс, вызывающий HAL, становится клиентом. Реализации по умолчанию могут обслуживать как промежуточные, так и раздельные HAL, и могут меняться со временем:

Рисунок 1. Ход разработки для устаревших HAL.

Создание клиента HAL

Начните с включения библиотек HAL в make-файл:

  • Сделать: LOCAL_SHARED_LIBRARIES += android.hardware.nfc@1.0
  • shared_libs: [ …, android.hardware.nfc@1.0 ] : shared_libs: [ …, android.hardware.nfc@1.0 ]

Далее, включите заголовочные файлы HAL:

#include <android/hardware/nfc/1.0/IFoo.h>
…
// in code:
sp<IFoo> client = IFoo::getService();
client->doThing();

Создание сервера HAL

Чтобы создать реализацию HAL, вы должны иметь файлы .hal которые представляют ваш HAL, и уже сгенерировали make-файлы для вашего HAL, используя -Lmakefile или -Landroidbp в hidl-gen ( ./hardware/interfaces/update-makefiles.sh делает это для внутренние файлы HAL и является хорошей ссылкой). При передаче через HALs из libhardware вы можете легко выполнить большую часть этой работы с помощью c2hal.

Чтобы создать необходимые файлы для реализации вашего HAL:

PACKAGE=android.hardware.nfc@1.0
LOC=hardware/interfaces/nfc/1.0/default/
m -j hidl-gen
hidl-gen -o $LOC -Lc++-impl -randroid.hardware:hardware/interfaces \
    -randroid.hidl:system/libhidl/transport $PACKAGE
hidl-gen -o $LOC -Landroidbp-impl -randroid.hardware:hardware/interfaces \
    -randroid.hidl:system/libhidl/transport $PACKAGE

Для HAL на работу в проходном режими, вы должны иметь функцию HIDL_FETCH_IModuleName проживающую в /(system|vendor|...)/lib(64)?/hw/android.hardware.package@3.0-impl( OPTIONAL_IDENTIFIER ).so где OPTIONAL_IDENTIFIER - строка, идентифицирующая реализацию passthrough. Требования режима прохода выполняются автоматически с помощью вышеуказанных команд, которые также создают цель android.hardware.nfc@1.0-impl , но можно использовать любое расширение. Например, android.hardware.nfc@1.0-impl-foo использует -foo для дифференциации себя.

Если HAL является младшей версией или расширением другого HAL, базовый HAL должен использоваться для именования этого двоичного файла. Например, реализации android.hardware.graphics.mapper@2.1 прежнему должны находиться в двоичном android.hardware.graphics.mapper@2.0-impl( OPTIONAL_IDENTIFIER ) именем android.hardware.graphics.mapper@2.0-impl( OPTIONAL_IDENTIFIER ) . Обычно OPTIONAL_IDENTIFIER здесь включает в себя актуальную версию HAL. Назвав двоичный файл подобным образом, клиенты 2.0 могут получить его напрямую, а клиенты 2.1 могут отклонить реализацию.

Затем заполните функциональные заглушки и настройте демон. Пример кода демона (с поддержкой passthrough):

#include <hidl/LegacySupport.h>

int main(int /* argc */, char* /* argv */ []) {
    return defaultPassthroughServiceImplementation<INfc>("nfc");
}

defaultPassthroughServiceImplementation -impl dlopen() предоставленную библиотеку -impl и предоставит ее в виде бинарной службы. Пример кода демона (для чистого бандеризованного сервиса):

int main(int /* argc */, char* /* argv */ []) {
    // This function must be called before you join to ensure the proper
    // number of threads are created. The threadpool will never exceed
    // size one because of this call.
    ::android::hardware::configureRpcThreadpool(1 /*threads*/, true /*willJoin*/);

    sp<INfc> nfc = new Nfc();
    const status_t status = nfc->registerAsService();
    if (status != ::android::OK) {
        return 1; // or handle error
    }

    // Adds this thread to the threadpool, resulting in one total
    // thread in the threadpool. We could also do other things, but
    // would have to specify 'false' to willJoin in configureRpcThreadpool.
    ::android::hardware::joinRpcThreadpool();
    return 1; // joinRpcThreadpool should never return
}

Этот демон обычно находится в $PACKAGE + "-service-suffix" (например, android.hardware.nfc@1.0-service ), но это может быть где угодно. Разделительной политикой для определенного класса HAL является атрибут hal_<module> (например, hal_nfc) . Этот атрибут должен применяться к демону, который запускает определенный HAL (если один и тот же процесс обслуживает несколько HAL, к нему можно применить несколько атрибутов).