Эта страница переведена с помощью Cloud Translation API.

HIDL С++

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

На страницах этого раздела описываются реализации интерфейсов HIDL на C++, включая сведения о файлах, автоматически сгенерированных из файлов 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 ]

Затем подключите заголовочные файлы 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 и является хорошим справочником). При переносе через HAL из 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 — строка, идентифицирующая сквозную реализацию. Требования сквозного режима автоматически выполняются приведенными выше командами, которые также создают цель 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 ) . Обычно OPTIONAL_IDENTIFIER здесь включает актуальную версию HAL. Присвоив бинарному файлу такое имя, клиенты версии 2.0 могут получить его напрямую, а клиенты версии 2.1 могут воспроизвести реализацию.

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

#include <hidl/LegacySupport.h>

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

defaultPassthroughServiceImplementation вызовет 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, к нему можно применить несколько атрибутов).