Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Se usó la API de Cloud Translation para traducir esta página.

HIDL

El lenguaje de definición de interfaz HAL o HIDL (pronunciado "hide-l") es un lenguaje de descripción de interfaz (IDL) para especificar la interfaz entre una HAL y sus usuarios. Permite especificar tipos y llamadas a métodos, recopilados en interfaces y paquetes. En términos más generales, HIDL es un sistema para comunicarse entre bases de código que pueden compilarse de forma independiente. A partir de Android 10, HIDL está obsoleto y Android está migrando para usar AIDL en todas partes.

HIDL está destinado a ser utilizado para la comunicación entre procesos (IPC). La comunicación entre procesos se conoce como Binderized . Para las bibliotecas que deben estar vinculadas a un proceso, también está disponible un modo de transferencia (no compatible con Java).

HIDL especifica estructuras de datos y firmas de métodos, organizados en interfaces (similares a una clase) que se recopilan en paquetes. La sintaxis de HIDL resultará familiar para los programadores de C++ y Java, aunque con un conjunto diferente de palabras clave. HIDL también usa anotaciones de estilo Java.

diseño HIDL

El objetivo de HIDL es que el marco se pueda reemplazar sin tener que reconstruir HAL. Los proveedores o creadores de SOC crearán las HAL y las colocarán en una partición /vendor en el dispositivo, lo que permitirá que el marco, en su propia partición, se reemplace con una OTA sin volver a compilar las HAL.

El diseño de HIDL equilibra las siguientes preocupaciones:

Interoperabilidad . Cree interfaces interoperables confiables entre procesos que pueden compilarse con varias arquitecturas, cadenas de herramientas y configuraciones de compilación. Las interfaces HIDL están versionadas y no se pueden cambiar después de su publicación.
Eficiencia HIDL intenta minimizar el número de operaciones de copia. Los datos definidos por HIDL se entregan al código C++ en estructuras de datos de diseño estándar de C++ que se pueden usar sin desempaquetar. HIDL también proporciona interfaces de memoria compartida y, dado que las RPC son inherentemente algo lentas, HIDL admite dos formas de transferir datos sin usar una llamada RPC: memoria compartida y Fast Message Queue (FMQ).
intuitivo HIDL evita problemas espinosos de propiedad de la memoria al usar solo parámetros in RPC (consulte Lenguaje de definición de interfaz de Android (AIDL) ); los valores que no se pueden devolver de manera eficiente desde los métodos se devuelven a través de funciones de devolución de llamada. Ni pasar datos a HIDL para su transferencia ni recibir datos de HIDL cambia la propiedad de los datos; la propiedad siempre permanece en la función de llamada. Los datos deben persistir solo durante la duración de la función llamada y pueden destruirse inmediatamente después de que regrese la función llamada.

Uso del modo de transferencia

Para actualizar los dispositivos que ejecutan versiones anteriores de Android a Android O, puede encapsular las HAL convencionales (y heredadas) en una nueva interfaz HIDL que sirve a la HAL en modos vinculados y del mismo proceso (transferencia). Este envoltorio es transparente tanto para HAL como para el marco de trabajo de Android.

El modo de transferencia solo está disponible para clientes e implementaciones de C++. Los dispositivos que ejecutan versiones anteriores de Android no tienen HAL escritas en Java, por lo que las HAL de Java están vinculadas de forma inherente.

Cuando se compila un archivo .hal , hidl-gen produce un archivo de encabezado de transferencia adicional BsFoo.h además de los encabezados utilizados para la comunicación del enlazador; este encabezado define las funciones que se dlopen a abrir. Dado que las HAL de transferencia se ejecutan en el mismo proceso en el que se llaman, en la mayoría de los casos, los métodos de transferencia se invocan mediante una llamada de función directa (mismo subproceso). Los métodos oneway se ejecutan en su propio subproceso, ya que no están destinados a esperar a que HAL los procese (esto significa que cualquier HAL que utilice métodos oneway en modo de transferencia debe ser seguro para subprocesos).

Dado un IFoo.hal , BsFoo.h envuelve los métodos generados por HIDL para proporcionar funciones adicionales (como hacer que las transacciones oneway se ejecuten en otro subproceso). Este archivo es similar a BpFoo.h , sin embargo, en lugar de pasar las llamadas IPC usando Binder, las funciones deseadas se invocan directamente. Las futuras implementaciones de HAL pueden proporcionar múltiples implementaciones, como FooFast HAL y FooAccurate HAL. En tales casos, se crearía un archivo para cada implementación adicional (p. ej., PTFooFast.cpp y PTFooAccurate.cpp ).

HAL de transferencia de encuadernación

Puede enlazar las implementaciones de HAL que admiten el modo de transferencia. Dada una interfaz HAL abcd@MN::IFoo , se crean dos paquetes:

abcd@MN::IFoo-impl . Contiene la implementación de HAL y expone la función IFoo* HIDL_FETCH_IFoo(const char* name) . En dispositivos heredados, este paquete se dlopen y la implementación se instancia mediante HIDL_FETCH_IFoo . Puede generar el código base usando hidl-gen y -Lc++-impl impl y -Landroidbp-impl .
abcd@MN::IFoo-service . Abre la HAL de transferencia y se registra como un servicio enlazado, lo que permite usar la misma implementación de HAL como transferencia y enlazada.

Dado el tipo IFoo , puede llamar a sp<IFoo> IFoo::getService(string name, bool getStub) para obtener acceso a una instancia de IFoo . Si getStub es verdadero, getService intenta abrir la HAL solo en modo de transferencia. Si getStub es falso, getService intenta encontrar un servicio enlazado; si eso falla, entonces intenta encontrar el servicio de transferencia. El parámetro getStub nunca debe usarse, excepto en defaultPassthroughServiceImplementation . (Los dispositivos que se inician con Android O son dispositivos completamente vinculados, por lo que no se permite abrir un servicio en modo de transferencia).

gramática HIDL

Por diseño, el lenguaje HIDL es similar a C (pero no usa el preprocesador C). Toda la puntuación no descrita a continuación (aparte del uso obvio de = y | ) es parte de la gramática.

Nota: Para obtener detalles sobre el estilo de código HIDL, consulte la Guía de estilo de código .

/** */ indica un comentario de documentación. Estos solo se pueden aplicar a declaraciones de tipo, método, campo y valor de enumeración.
/* */ indica un comentario de varias líneas.
// indica un comentario al final de la línea. Aparte de // , las nuevas líneas son las mismas que cualquier otro espacio en blanco.
En el ejemplo de gramática a continuación, el texto desde // hasta el final de la línea no es parte de la gramática, sino un comentario sobre la gramática.
[empty] significa que el término puede estar vacío.
? después de un literal o término significa que es opcional.
... indica secuencia que contiene cero o más elementos con puntuación de separación como se indica. No hay argumentos variados en HIDL.
Las comas separan los elementos de la secuencia.
Los puntos y comas terminan cada elemento, incluido el último elemento.
MAYÚSCULAS es un no terminal.
la italics es una familia de tokens, como integer o un identifier (reglas de análisis C estándar).
constexpr es una expresión constante de estilo C (como 1 + 1 y 1L << 3 ).
import_name es un paquete o nombre de interfaz, calificado como se describe en Control de versiones de HIDL .
Las words en minúsculas son tokens literales.

Ejemplo:

ROOT =
    PACKAGE IMPORTS PREAMBLE { ITEM ITEM ... }  // not for types.hal
  | PACKAGE IMPORTS ITEM ITEM...  // only for types.hal; no method definitions

ITEM =
    ANNOTATIONS? oneway? identifier(FIELD, FIELD ...) GENERATES?;
  |  safe_union identifier { UFIELD; UFIELD; ...};
  |  struct identifier { SFIELD; SFIELD; ...};  // Note - no forward declarations
  |  union identifier { UFIELD; UFIELD; ...};
  |  enum identifier: TYPE { ENUM_ENTRY, ENUM_ENTRY ... }; // TYPE = enum or scalar
  |  typedef TYPE identifier;

VERSION = integer.integer;

PACKAGE = package android.hardware.identifier[.identifier[...]]@VERSION;

PREAMBLE = interface identifier EXTENDS

EXTENDS = <empty> | extends import_name  // must be interface, not package

GENERATES = generates (FIELD, FIELD ...)

// allows the Binder interface to be used as a type
// (similar to typedef'ing the final identifier)
IMPORTS =
   [empty]
  |  IMPORTS import import_name;

TYPE =
  uint8_t | int8_t | uint16_t | int16_t | uint32_t | int32_t | uint64_t | int64_t |
 float | double | bool | string
|  identifier  // must be defined as a typedef, struct, union, enum or import
               // including those defined later in the file
|  memory
|  pointer
|  vec<TYPE>
|  bitfield<TYPE>  // TYPE is user-defined enum
|  fmq_sync<TYPE>
|  fmq_unsync<TYPE>
|  TYPE[SIZE]

FIELD =
   TYPE identifier

UFIELD =
   TYPE identifier
  |  safe_union identifier { FIELD; FIELD; ...} identifier;
  |  struct identifier { FIELD; FIELD; ...} identifier;
  |  union identifier { FIELD; FIELD; ...} identifier;

SFIELD =
   TYPE identifier
  |  safe_union identifier { FIELD; FIELD; ...};
  |  struct identifier { FIELD; FIELD; ...};
  |  union identifier { FIELD; FIELD; ...};
  |  safe_union identifier { FIELD; FIELD; ...} identifier;
  |  struct identifier { FIELD; FIELD; ...} identifier;
  |  union identifier { FIELD; FIELD; ...} identifier;

SIZE =  // Must be greater than zero
     constexpr

ANNOTATIONS =
     [empty]
  |  ANNOTATIONS ANNOTATION

ANNOTATION =
  |  @identifier
  |  @identifier(VALUE)
  |  @identifier(ANNO_ENTRY, ANNO_ENTRY  ...)

ANNO_ENTRY =
     identifier=VALUE

VALUE =
     "any text including \" and other escapes"
  |  constexpr
  |  {VALUE, VALUE ...}  // only in annotations

ENUM_ENTRY =
     identifier
  |  identifier = constexpr

Terminología

Esta sección utiliza los siguientes términos relacionados con HIDL:

encuadernado	Indica que HIDL se está utilizando para llamadas a procedimientos remotos entre procesos, implementado a través de un mecanismo similar a Binder. Véase también transferencia .
devolución de llamada, asíncrono	Interfaz atendida por un usuario de HAL, pasada a HAL (a través de un método HIDL) y llamada por HAL para devolver datos en cualquier momento.
devolución de llamada, síncrono	Devuelve datos de la implementación del método HIDL de un servidor al cliente. No se usa para métodos que devuelven vacío o un solo valor primitivo.
cliente	Proceso que llama a métodos de una interfaz particular. Un proceso HAL o framework puede ser un cliente de una interfaz y un servidor de otra. Véase también transferencia .
extiende	Indica una interfaz que agrega métodos y/o tipos a otra interfaz. Una interfaz puede extender solo otra interfaz. Se puede usar para un incremento de versión menor en el mismo nombre de paquete o para un paquete nuevo (por ejemplo, una extensión de proveedor) para construir sobre un paquete anterior.
genera	Indica un método de interfaz que devuelve valores al cliente. Para devolver un valor no primitivo o más de un valor, se genera una función de devolución de llamada síncrona.
interfaz	Colección de métodos y tipos. Traducido a una clase en C++ o Java. Todos los métodos de una interfaz se llaman en la misma dirección: un proceso de cliente invoca métodos implementados por un proceso de servidor.
de una sola mano	Cuando se aplica a un método HIDL, indica que el método no devuelve valores y no se bloquea.
paquete	Colección de interfaces y tipos de datos que comparten una versión.
pasar por	Modo de HIDL en el que el servidor es una biblioteca compartida, `dlopen` por el cliente. En el modo de transferencia, el cliente y el servidor son el mismo proceso pero con bases de código separadas. Se usa solo para incorporar bases de código heredadas al modelo HIDL. Véase también Encuadernado .
servidor	Proceso que implementa métodos de una interfaz. Véase también transferencia .
transporte	Infraestructura HIDL que mueve datos entre el servidor y el cliente.
versión	Versión de un paquete. Consta de dos números enteros, mayor y menor. Los incrementos de versiones menores pueden agregar (pero no cambiar) tipos y métodos.