Capa de abstracción de la plataforma de HAR

Usa el renderizador de alta disponibilidad (HAR) para mostrar la información del vehículo que Android no puede mostrar. Esto puede ocurrir debido a problemas como el inicio, la disponibilidad, la seguridad o las reglamentaciones. HAR es una app portátil integrada escrita en Rust.

HAR, también llamado marco de trabajo de HAR, incluye código que usas para compilar apps. Una app creada con HAR es una app basada en HAR. El framework de HAR tiene secciones de código para diferentes plataformas. Por ejemplo, en un sistema Linux, usas bibliotecas como tinyalsa para los sonidos. QNX tiene sus propias bibliotecas de audio únicas.

Una plataforma incluye hardware, un sistema operativo, bibliotecas del sistema y otros factores. El código específico de la plataforma tiene partes llamadas subsistemas. Cada subsistema controla una función de la plataforma, como el audio, las cámaras del EVS o los datos del vehículo. Para admitir una plataforma, el framework de HAR necesita que se implementen todos sus subsistemas.

El código del subsistema específico de la plataforma puede ejecutarse en el mismo proceso que la app basada en HAR o en uno independiente. Cuando está separado, este código controla la comunicación entre procesos (IPC) para ayudar a verificar que la plataforma admita la app. Los mecanismos complejos de IPC deben formar parte del código específico de la plataforma.

El paquete de pruebas de HAR ejecuta pruebas en todos los subsistemas implementados para una plataforma. Usa este conjunto de herramientas para verificar si las plataformas cumplen con los requisitos de HAR y para encontrar problemas nuevos.

Terminología

Estos términos se encuentran en esta página:

App basada en HAR

Es una app específica para el OEM o la función creada con el framework de HAR. Las apps difieren en el estado de la app y otros aspectos personalizables.

Framework de HAR

Proporciona un conjunto principal de herramientas que se usan para compilar apps.

Abstracción de la plataforma HAR

Es parte del framework de HAR que proporciona una API conocida que todas las plataformas de destino deben implementar.

Paquete de pruebas de HAR

Una serie de pruebas conocidas sobre las implementaciones de la plataforma, que ayudan a verificar que las implementaciones de la plataforma admitan el framework de HAR en una plataforma determinada.

Fuera de alcance

El HAR no aborda lo siguiente:

• Implementaciones individuales para todos los objetivos de la plataforma: Son las implementaciones para las plataformas objetivo. En cambio, en esta página, se describen las interfaces que deben cumplir las implementaciones de la plataforma y que debe satisfacer un paquete de pruebas.

• Casos de prueba: Casos de prueba específicos para todas las interfaces. En cambio, esta página describe funciones individuales para interfaces, incluidos argumentos, valores de devolución, comportamientos esperados y efectos secundarios esperados. En esta página, se describe el conjunto de pruebas en el que puedes implementar y ejecutar casos de prueba.

Estructura de crate de alto nivel de abstracción de la plataforma

Los proyectos de Rust constan de crates. En la figura 1, se muestra la estructura de la caja para la capa de abstracción de la plataforma de HAR. La capa de abstracción de la plataforma afecta a dos o más crates de Rust:

• Las abstracciones (descripciones de trait de Rust) se encuentran en el crate del framework de HAR.

• Las implementaciones para una plataforma se realizan con un crate har-platform-x independiente. Por ejemplo, har-platform-linux o har-platform-android.

No puedes compilar ni probar el crate HAR sin una implementación de plataforma especificada. Esto es intencional, ya que el framework de HAR es un framework.

Una app que especifica una plataforma debe compilarse con este framework para funcionar y probarse. En este diagrama, se muestran las conexiones entre el framework de HAR y la plataforma:

Figura 1: Caja de HAR

Estructura general dentro de display-safety

Este diseño agrega una serie de crates nuevos al repositorio display_safety, como se ilustra en la figura 2:

Figura 2: Módulos de abstracción

Un paquete de pruebas es estructuralmente similar a una app, pero solo depende de un crate de implementación de plataforma determinado. El conjunto de pruebas debe hacer referencia a los rasgos y las estructuras definidos en el framework de HAR, pero no debe hacer referencia a implementaciones más complejas.

Descripción general de la capa de abstracción de la plataforma

En esta tabla, se describen los subsistemas específicos de la plataforma definidos por la capa de abstracción de la plataforma de HAR.

Convenciones de nombres y estructuras de frameworks

En esta tabla, se presentan estos nombres y estructuras:

• Son las instancias trait del subsistema esperadas que proporciona el framework de HAR. Cada trait representa un subsistema específico de la plataforma que se debe implementar.

• Nombres esperados de las implementaciones de subsistemas específicos de la plataforma en cualquier crate de la plataforma. Las apps basadas en HAR esperan que se implementen estos nombres específicos.

• Instancias de enum y struct del framework de HAR relacionadas que se suelen usar para pasar información de las implementaciones relacionadas con la plataforma al framework de HAR.

Errores y manejo de errores

Las APIs propuestas usan el tipo Result<> de Rust. Rust requiere que verifiques los tipos Result que contienen errores. De lo contrario, el compilador genera una advertencia o un error. Una verificación en tiempo de compilación aplica la verificación de errores desde el código específico de la plataforma.

Los errores que muestran las implementaciones de la plataforma son del tipo harry::error::Error. Para verificar que los tipos de errores de la plataforma no se filtren en el código de la app, usa el tipo de error estándar que proporciona el framework de HAR.

El tipo harry::error::Error se expande para incluir errores específicos de todos los subsistemas:

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

Los errores irrecuperables se muestran principalmente a través de las interfaces y las devoluciones de llamada definidas.

Diseño detallado del paquete de pruebas

En esta sección, se describe el diseño del paquete de pruebas, que verifica las implementaciones específicas de la plataforma de las abstracciones.

Compila las pruebas del conjunto de pruebas

En el caso de las compilaciones de Soong (definidas por archivos Android.bp), las pruebas se compilan como parte del sistema de compilación de la plataforma de Android, y atest administra su ejecución.

Ejecuta el paquete de pruebas

Para probar una plataforma individual, haz lo siguiente:

Usa el comando atest con el destino de prueba pertinente (por ejemplo, atest <module_name>). Este comando implementa y ejecuta las pruebas en un dispositivo o emulador Android.