Exploración en profundidad de Android HAL (1): descripción general de la arquitectura

En este artículo conoceremos en profundidad las diferentes formas y arquitecturas de Android HAL, así como las diferencias y conexiones entre ellas. Comenzará con el HAL heredado más antiguo y luego introducirá el nuevo método de definición de HAL a partir de Android 8.0 (Oreo): HIDL (lenguaje de definición de interfaz de hardware). Se compararán dos modos de HIDL: el modo Passthrough y el modo Binderized, y se analizarán sus respectivas ventajas y desventajas. Finalmente, resumiremos el papel y la importancia de HAL y esperaremos la dirección del desarrollo futuro. La estructura del código se basa en el ejemplo personalizado de SystemGpio (Legacy HAL).

Serie de artículos:
Exploración en profundidad de Android HAL (1): descripción general de la arquitectura
Exploración en profundidad de Android HAL (2): HAL tradicional y simulación de cifrado y descifrado de archivos
Exploración en profundidad de Android HAL (3): modo HIDL Passthrough y puerto serie simulación de devolución de llamada de datos
Exploración en profundidad de Android HAL (4): modo enlazado HIDL y simulación de devolución de llamada de datos CAN
Exploración en profundidad de Android HAL (5): depuración de informes y soluciones de errores de HAL

0.Aprendizaje de referencia

Descripción general de la capa de abstracción de hardware (HAL)
HIDL C++ | Proyecto de código abierto de Android
Tipo HAL | Proyecto de código abierto de Android
HIDL Explicación detallada: Android10.0 Principio de comunicación HwBinder (2)
Parte de hardware de interfaz GPIO personalizada de la serie Rockchip (3)

1. HAL heredado

Antes de HIDL, Android usaba HAL tradicional, que estaba escrito en lenguaje C. Este HAL define una serie de estructuras y punteros de función, uno de los cuales hw_module_trepresenta un módulo de hardware. Este estilo de HAL suele estar ubicado /hardware/libhardware/include/hardware/en un directorio.

modo interactivo

HAL tradicional necesita interactuar con el marco de Android para proporcionar funciones y servicios relacionados con el hardware. Para lograr esto, HAL tradicional debe pasar por los siguientes niveles:

• Interfaz de marco de Java : esta es una clase o interfaz de Java definida en el marco de Android, que se utiliza para proporcionar API para aplicaciones o servicios. Por ejemplo, android.os.SystemGpioes una clase Java utilizada para controlar el puerto GPIO (entrada/salida de propósito general).
• Interfaz AIDL : este es un archivo AIDL (lenguaje de definición de interfaz de Android) definido en el marco de Android, que se utiliza para describir los tipos de datos y firmas de métodos que deben pasarse o devolverse durante la comunicación entre procesos. android.os.IGpioService.aidlEs un archivo AIDL que se utiliza para definir la interfaz que el servicio GPIO debe implementar.
• Implementación de servicios en Java : esta es una clase Java en el marco de Android que implementa la interfaz AIDL, se utiliza para ejecutarse en segundo plano como un servicio y manejar solicitudes de otros procesos o aplicaciones. com.android.server.GpioServiceEs una clase Java utilizada para implementar servicios GPIO.
• Capa JNI : este es el código C/C++ en el marco de Android que utiliza JNI (interfaz nativa de Java) para unir la interacción entre la capa Java y la capa C. La capa JNI es responsable de convertir los parámetros pasados ​​por la capa Java en tipos de datos que puedan ser reconocidos por la capa C y de llamar a las funciones C correspondientes. viceversa. com_android_server_GpioService.cppEs un archivo de capa JNI que se utiliza para llamar a funciones relacionadas con GPIO HAL.
• Encabezado HAL : este es un archivo de encabezado C en HAL tradicional que define especificaciones de interfaz como estructuras y punteros de función. Estos archivos de encabezado generalmente se encuentran hardware/libhardware/include/hardware/en directorios y _hal.hterminan en . gpio_hal.hEs un archivo de encabezado HAL que se utiliza para definir interfaces relacionadas con GPIO HAL.
• Implementación de HAL : este es el código C que implementa la especificación de interfaz definida en el archivo de encabezado HAL en HAL tradicional. Estos códigos suelen estar ubicados hardware/libhardware/modules/en directorios y _hal.cterminan en . gpio_hal.cEs un archivo de implementación HAL que se utiliza para implementar funciones relacionadas con GPIO HAL.
• Controlador del kernel : este es el código de la capa del controlador que interactúa directamente con el hardware y generalmente forma parte del kernel del sistema operativo. Estos códigos suelen estar ubicados kernel/drivers/en directorios y terminan con .co .h. gpio.cEs un archivo de capa de controlador que se utiliza para controlar el estado de entrada y salida del puerto GPIO.

arquitectura de código

El HAL tradicional es el primer diseño de capa de abstracción de hardware del sistema Android. Su objetivo principal es proporcionar una interfaz unificada para el marco de Android, de modo que el marco pueda interactuar con el hardware subyacente sin preocuparse por la implementación específica del hardware.

• Interfaz de marco de Java :

  • frameworks/base/core/java/android/os/SystemGpio.java: Esta es la interfaz Java en el marco de Android a través de la cual las aplicaciones y los servicios del sistema interactúan con el hardware GPIO.

• Interfaz AIDL :

  • frameworks/base/core/java/android/os/IGpioService.aidl: AIDL (Lenguaje de definición de interfaz de Android) define una interfaz entre procesos que permite que las aplicaciones se comuniquen con los servicios GPIO que se ejecutan en otro proceso.

• Implementación de servicios en Java :

  • frameworks/base/services/core/java/com/android/server/GpioService.java: Esta es una implementación Java de un servicio GPIO que maneja solicitudes de aplicaciones e interactúa con el hardware subyacente a través de JNI.

• Capa JNI :

  • frameworks/base/services/core/jni/com_android_server_GpioService.cpp: La capa JNI (Java Native Interface) permite que el código Java interactúe con el código nativo C/C++. El código JNI aquí es para unir la comunicación entre el servicio Java y HAL.

• Encabezado HAL :

  • hardware/libhardware/include/hardware/gpio_hal.h: Este es el archivo de encabezado de HAL, que define la interfaz y las estructuras de datos necesarias para interactuar con el hardware.

• Implementación HAL :

  • hardware/libhardware/modules/gpio/gpio_hal.c: Esta es una implementación C de HAL, que interactúa con el controlador de hardware subyacente.

• Controlador del núcleo :

  • kernel/drivers/misc/gpio/gpio.c: Este es el controlador GPIO en el kernel de Linux, que interactúa directamente con el hardware.

Diagrama de arquitectura

La arquitectura HAL tradicional se muestra en la siguiente figura:

La ventaja del HAL tradicional es que es simple y directo, fácil de entender e implementar. Pero también tiene algunas deficiencias, principalmente las siguientes:

• Falta de control de versiones y compatibilidad con versiones anteriores : HAL tradicional no tiene un número de versión claro ni un mecanismo de cambio de interfaz. Si el proveedor de hardware o el sistema Android necesita modificar o ampliar la interfaz HAL, entonces todos los códigos relacionados deben modificarse al mismo tiempo, incluida la capa JNI, la capa de marco y la capa de aplicación . Esto hace que mantener y actualizar el código sea difícil y requiera mucho tiempo.
• Falta de seguridad y estabilidad : el HAL tradicional está directamente vinculado al proceso del cliente como una biblioteca, lo que significa que las llamadas entre el cliente y HAL son dentro del proceso, sin la sobrecarga de la comunicación entre procesos. Pero esto también significa que si hay un error o falla en HAL, afectará el proceso del cliente e incluso provocará que todo el sistema falle. HAL tradicional no tiene mecanismo de zona de pruebas ni control de permisos. Cualquier proceso puede acceder a cualquier módulo , lo que puede generar riesgos de seguridad.

Para resolver las deficiencias del HAL tradicional, Android ha introducido un nuevo método de definición de HAL: HIDL a partir de 8.0 (Oreo).

HIDL (lenguaje de definición de interfaz de hardware) es un lenguaje utilizado para definir la interfaz de HAL. HIDL proporciona un mejor control de versiones y compatibilidad con versiones anteriores que HAL tradicional. HIDL también admite dos modos diferentes: modo Passthrough y modo Binderized. Estos dos modos corresponden a diferentes métodos y arquitecturas de comunicación.

2. Modo de paso HIDL

modo interactivo

En el modo Passthrough, el servicio HAL se ejecuta como una biblioteca en el proceso del cliente. Esto significa que las llamadas entre el cliente y HAL están en proceso, sin la sobrecarga de la comunicación entre procesos. Este modo es similar al HAL tradicional, pero tiene las siguientes diferencias:

• Utilice C++ en lugar de C : HIDL HAL en modo Passthrough está escrito en C++. Esto permite a HAL utilizar características de C++ como clases, herencia, polimorfismo, etc.
• Utilice .hal en lugar de .h : HIDL HAL en modo Passthrough utiliza .halarchivos para definir las especificaciones de la interfaz, no .harchivos. .halArchivo es una sintaxis especial que se utiliza para describir los tipos de datos y firmas de métodos que deben pasarse o devolverse en la interfaz HAL. .halLos archivos suelen estar ubicados hardware/interfaces/en directorios y .halterminan en . Por ejemplo, IGpio.hales un .halarchivo utilizado para definir interfaces relacionadas con GPIO HAL.
• Utilice hidl-gen en lugar de escribir código manualmente : HIDL HAL en modo Passthrough utiliza una herramienta para generar código C++ y Java hidl-gena partir de archivos. .halEstos códigos incluyen implementación de interfaz, proxy de cliente, registro de servicio y otras funciones. Esto evita escribir manualmente código repetitivo y tedioso y garantiza que el código sea coherente con la especificación de la interfaz.
• Utilice Android.bp en lugar de Android.mk : HIDL HAL en modo Passthrough utiliza un nuevo sistema de compilación: Soong para compilar el código. Soong utiliza .bparchivos para describir los tipos de datos y firmas de métodos que deben pasarse o devolverse en la interfaz HAL. .halLos archivos suelen estar ubicados hardware/interfaces/en directorios y .halterminan en . IGpio.halEs un .halarchivo utilizado para definir interfaces relacionadas con GPIO HAL.
• Utilice Android.bp en lugar de Android.mk : HIDL HAL en modo Passthrough utiliza un nuevo sistema de compilación: Soong para compilar el código. Soong utiliza .bparchivos en lugar de archivos para describir reglas de construcción y dependencias .mk. .bpLos archivos suelen estar ubicados en el mismo directorio que el código de implementación HAL y .bpterminan en . Gpio.bpEs un .bparchivo utilizado para compilar código relacionado con GPIO HAL.

La ventaja del modo Passthrough es el alto rendimiento y la ausencia de sobrecarga de comunicación entre procesos. Pero también tiene algunas deficiencias, principalmente las siguientes:

• Falta de seguridad y estabilidad : el modo Passthrough todavía tiene los problemas de seguridad y estabilidad del HAL tradicional. Debido a que el servicio HAL se ejecuta como una biblioteca en el proceso del cliente, si ocurre un error o falla en HAL, afectará el proceso del cliente e incluso provocará que todo el sistema falle. El modo Passthrough tampoco tiene mecanismo de zona de pruebas ni control de permisos. Cualquier proceso puede acceder a cualquier módulo HAL, lo que puede conllevar riesgos de seguridad.
• Falta de flexibilidad y escalabilidad : HIDL HAL en modo Passthrough solo se puede vincular al proceso del cliente como una biblioteca, lo que significa que el cliente debe ser un servicio o aplicación nativa de C++. Si el cliente es una aplicación o servicio de capa Java, entonces la capa JNI aún es necesaria para unir la interacción entre Java y C++. Esto aumenta la complejidad del código y los costos de mantenimiento. El modo Passthrough tampoco admite que varios clientes accedan al mismo servicio HAL al mismo tiempo, lo que limitará la escalabilidad del servicio HAL.

Para resolver las deficiencias del modo Passthrough, Android también proporciona otro modo HIDL: el modo enlazado.

arquitectura de código

HIDL (lenguaje de definición de interfaz de hardware) es un nuevo mecanismo de abstracción de hardware introducido en Android Oreo (8.0). El modo Passthrough es uno de los modos que permite que HAL se ejecute de forma tradicional pero interactúe con el marco de Android a través de la interfaz HIDL.

• Interfaz de marco de Java :

  • frameworks/base/core/java/android/os/SystemGpio.java: Esta es la interfaz Java en el marco de Android a través de la cual las aplicaciones y los servicios del sistema interactúan con el hardware GPIO.

• Definición de interfaz HIDL :

  • hardware/interfaces/gpio/1.0/IGpio.hal: Esta es una interfaz definida por HIDL que describe cómo interactuar con el hardware GPIO.

• Implementación de servicios nativos :

  • frameworks/base/services/core/jni/com_android_server_GpioService.cpp: Si la capa Java necesita acceder al hardware directamente, interactuará con la interfaz HIDL a través de esta capa JNI.

• Implementación HAL :

  • hardware/interfaces/gpio/1.0/default/Gpio.cpp: Esta es la implementación de HIDL HAL, que interactúa con el controlador de hardware subyacente.

• Controlador del núcleo :

  • kernel/drivers/misc/gpio/gpio.c: Este es el controlador GPIO en el kernel de Linux, que interactúa directamente con el hardware.

Diagrama de arquitectura

La arquitectura de HIDL HAL en modo Passthrough se muestra en la siguiente figura:

3. Modo enlazado HIDL:

modo interactivo

En modo enlazado, el servicio HAL se ejecuta como un proceso independiente. La comunicación entre el cliente y HAL se realiza a través de Binder IPC. Este modo es diferente del modo Passthrough, pero tiene los siguientes puntos en común:

• Utilice C++ en lugar de C : HIDL HAL en modo enlazado también está escrito en C++.
• Utilice .hal en lugar de .h : HIDL HAL en modo enlazado también utiliza .halarchivos para definir las especificaciones de la interfaz.
• Utilice hidl-gen en lugar de escribir código manualmente : HIDL HAL en modo enlazado también se utiliza hidl-genpara generar código C++ y Java a partir de .halarchivos.
• Utilice Android.bp en lugar de Android.mk : HIDL HAL en modo Binderized también utiliza Soong para compilar el código.

La ventaja del modo Binderized es la alta seguridad y estabilidad, porque el servicio HAL se ejecuta en su propio entorno sandbox y puede obtener permisos a través de SELinux. El modo Binderized también admite que varios clientes accedan al mismo servicio HAL al mismo tiempo, lo que mejora la escalabilidad del servicio HAL. Pero también tiene algunas deficiencias, principalmente las siguientes:

• Bajo rendimiento : HIDL HAL en modo Binderizado requiere comunicación entre procesos a través de Binder IPC, lo que genera sobrecarga y latencia adicionales. Especialmente para algunos servicios de hardware con requisitos de alta frecuencia o baja latencia, como audio, video, sensores, etc., Binder IPC puede afectar su rendimiento y experiencia.
• Alta complejidad : HIDL HAL en modo Binderized necesita implementar un proceso de servicio independiente, lo que aumentará la complejidad del código y los costos de mantenimiento. Especialmente para algunos servicios de hardware simples o de uso poco frecuente, como GPIO, LED, etc., puede que no sea necesario implementar un proceso de servicio independiente.

arquitectura de código

El modo enlazado es otro modo de HIDL donde HAL se ejecuta como un proceso separado e interactúa con el marco de Android a través de Binder IPC.

• Interfaz de marco de Java :

  • frameworks/base/core/java/android/os/SystemGpio.java: Esta es la interfaz Java en el marco de Android a través de la cual las aplicaciones y los servicios del sistema interactúan con el hardware GPIO.

• Definición de interfaz HIDL :

  • hardware/interfaces/gpio/1.0/IGpio.hal: Esta es una interfaz definida por HIDL que describe cómo interactuar con el hardware GPIO.

• Implementación del servicio HAL :

  • hardware/interfaces/gpio/1.0/service/GpioService.cpp: Esta es la implementación del servicio HAL en modo Binderized, que se ejecuta como un proceso independiente e interactúa con el marco de Android a través de Binder IPC.

• Controlador del núcleo :

  • kernel/drivers/misc/gpio/gpio.c: Este es el controlador GPIO en el kernel de Linux, que interactúa directamente con el hardware.

Diagrama de arquitectura

La arquitectura de HIDL HAL en modo enlazado se muestra en la siguiente figura:

Resumen: HIDL proporciona dos modos diferentes: modo de paso y modo enlazado. Estos dos modos corresponden a diferentes métodos y arquitecturas de comunicación. El modo Passthrough tiene un alto rendimiento, pero poca seguridad y estabilidad. El modo enlazado tiene alta seguridad y estabilidad, pero bajo rendimiento. Puede elegir el modo apropiado según las necesidades y servicios de hardware específicos.

El papel y la importancia de HAL

HAL es un puente entre el sistema Android y el hardware. Proporciona una interfaz estándar para el marco de Android, lo que permite que el marco de Android interactúe con una variedad de hardware sin conocer los detalles de implementación específicos del hardware. Las funciones y el significado de HAL incluyen principalmente los siguientes puntos:

• Compatibilidad mejorada entre los proveedores de hardware y el sistema Android : a través de HAL, los proveedores de hardware pueden proporcionar a su hardware una interfaz que cumpla con las especificaciones de Android sin tener que modificar sus controladores o el sistema Android. Esto facilita que los proveedores de hardware adapten su hardware a la plataforma Android y actualicen sus controladores más rápido.
• Abstracción mejorada entre el sistema Android y las aplicaciones : a través de HAL, el sistema y las aplicaciones Android pueden utilizar una API unificada para acceder a los servicios de hardware sin tener que preocuparse por los detalles de implementación específicos del hardware. Esto facilita que los sistemas y aplicaciones Android admitan múltiples plataformas de hardware y dispositivos, y amplíen y optimicen sus funciones de manera más flexible.
• Seguridad y estabilidad mejoradas entre sistemas y aplicaciones Android : A través de HAL, los sistemas y aplicaciones Android pueden restringir el acceso a los servicios de hardware a través de mecanismos sandbox y control de permisos, evitando que operaciones maliciosas o erróneas causen daños al hardware o los sistemas. A través de HAL, el sistema y las aplicaciones de Android también pueden aislar o recuperar problemas causados ​​por errores o fallas en los servicios de hardware para garantizar el funcionamiento normal del sistema y las aplicaciones.

dirección de desarrollo futuro

A medida que el sistema Android y la plataforma de hardware continúen desarrollándose e innovando, HAL también cambiará y evolucionará en consecuencia. Posibles direcciones de desarrollo:

• Más HIDLización : HIDL es una nueva forma de definir HAL, que proporciona un mejor control de versiones y compatibilidad con versiones anteriores. Actualmente, HIDL ha cubierto la mayoría de los servicios de hardware, como audio, vídeo, sensores, cámaras, etc. Pero todavía hay algunos HAL tradicionales que no han sido HIDLizados, como la administración de energía, la administración de memoria, etc. En el futuro, es posible que veamos HAL más tradicionales HIDLizados para mejorar su compatibilidad y mantenibilidad.
• Más enlazado : el modo enlazado es un nuevo método de comunicación HAL que proporciona mayor seguridad y estabilidad. Actualmente, el modo Binderized es aplicable a la mayoría de HIDL HAL, como audio, video, sensores, cámaras, etc. Pero todavía hay algunos modos Passthrough que no se han vinculado, como GPIO, LED, etc. Es posible ver que se vinculan más patrones de paso a través para mejorar su seguridad y escalabilidad.
• Más VTS : VTS (Vendor Test Suite) es una nueva herramienta de prueba de HAL que puede realizar automáticamente pruebas funcionales, de compatibilidad, seguridad y rendimiento de HAL. Actualmente, VTS admite la mayoría de HIDL HAL, como audio, video, sensores, cámaras, etc. Pero todavía hay algunos HAL que no han sido dimensionados como VTS, como administración de energía, administración de memoria, etc. Es posible que veamos más HAL con tamaño VTS para mejorar su calidad y confiabilidad.

Resumir

Android HAL es un componente importante que proporciona una interfaz estándar entre el sistema Android y el hardware. Los diferentes métodos y arquitecturas de HAL reflejan el continuo desarrollo e innovación de los sistemas y plataformas de hardware Android. En este artículo, exploramos en profundidad los conceptos básicos de tres formas de aprender Android HAL: Legacy HAL, modo HIDL Passthrough y modo HIDL Binderized, y analizamos las diferencias y conexiones entre ellos. También resume el papel y la importancia de HAL y espera con interés la dirección del desarrollo futuro.