Cómo integrar la Dashcam

La app de Dashcam está diseñada para integrarse con AAOS y brindar a los conductores funciones de grabación de video para mejorar la seguridad. En esta guía, se describen los requisitos técnicos, los pasos de integración y las prácticas recomendadas para garantizar una implementación exitosa.

Requisitos previos

Antes de continuar, asegúrate de que se cumplan las siguientes condiciones previas:

SDK:

  • Se requiere el SDK 31 o una versión posterior.

Hardware:

  • Cámaras EVS o Camera2 disponibles para AAOS.
  • Para grabar videos, debe haber suficiente espacio de almacenamiento interno o compatibilidad con almacenamiento externo extraíble.

Requisitos de software:

  • Asistencia sin paquetes. Para obtener más información, consulta Apps sin agrupar.
  • Permisos. Dashcam requiere permisos del sistema.

Obtén el código fuente

La cámara de tablero es parte de las apps sin empaquetar de AAOS. Para consultar el código sin agrupar, consulta Cómo consultar el código.

Explora el código fuente con Android Code Search.

El código fuente se proporciona en estos tres módulos:

  • Servicio de Dashcam. Lógica de transmisión, grabación y activación.
  • Administrador de Dashcam. Se conecta al servicio de Dashcam y expone una API estable para los clientes.
  • App de Dashcam. Consulta la aplicación de Dashcam con la API de Dashcam Manager

Diagrama de la arquitectura

Dashcam

Usa Soong o Gradle para compilar Dashcam.

Soong

En Soong:

mma DashcamService DashcamManager-lib DashcamApp

Los APKs se encuentran en out/target/product/[lunch-target]/system/priv-app/

Gradle

En Gradle:

./gradlew :dashcam-app:assemble
./gradlew :dashcam-manager:assemble
./gradlew :dashcam-service:assemble

Los APKs se encuentran en out/aaos-apps-gradle-build/

En el archivo README, se proporcionan instrucciones detalladas para compilar Dashcam con Gradle.

Permisos

Se requieren varios permisos del sistema para el servicio de Dashcam y la app de Dashcam.

La forma más sencilla de otorgar estos permisos es incluirlos en una configuración prediseñada con Blueprint o Make.

En el esquema:

Android.bp
android_app_import {
    name: "DashcamApp-prebuilt",
    apk: "DashcamApp.apk",
    privileged: true,
    certificate: "platform",
    required: ["allowed_privapp_com.android.car.dashcam"],
}

prebuilt_etc {
    name: "allowed_privapp_com.android.car.dashcam",
    sub_dir: "default-permissions",
    src: "allowed_privapp_com.android.car.dashcam.xml",
    filename_from_src: true,
}

En Make:

dashcam.mk
PRODUCT_PACKAGES += \
    DashcamApp
PRODUCT_COPY_FILES :=\
vendor/[path-to-vendor-prebuilts]/apps/Dashcam/allowed_privapp_com.android.car.dashcam:$(TARGET_COPY_OUT_PRODUCT)/etc/permissions/com.android.car.dashcam.xml \

Crea un archivo de permisos llamado allowed_privapp_com.android.car.dashcam.xml:

<permissions>
  <privapp-permissions package="com.android.car.dashcam.service">
      <permission name="" />
  </privapp-permissions>
  <privapp-permissions package="com.android.car.dashcam.app">
      <permission name="" />
  </privapp-permissions>
</permissions>

Agrega permisos del manifiesto al archivo de permisos.

Antes de usar Dashcam, otorga previamente permisos de Camera2 al servicio de Dashcam, como se muestra en Cámara de AAOS.

Agrega el archivo de permisos preotorgados al archivo Blueprint o Make de la misma manera que el archivo de permisos.

En pre-grant-permissions-com.android.car.dashcam.xml:

<exceptions>
    <exception package="com.android.car.dashcam.service">
        <permission name="android.permission.CAMERA" fixed="false" />
        <permission name="android.permission.SYSTEM_CAMERA" fixed="false" />
        <permission name="android.permission.CAMERA_HEADLESS_SYSTEM_USER" fixed="false" />
    </exception>
</exceptions>

En Android.bp:

...
required["pre-grant-permissions-com.android.car.dashcaml"]
...

prebuilt_etc {
    name: "pre-grant-permissions-com.android.car.dashcaml",
    sub_dir: "default-permissions",
    src: "pre-grant-permissions-com.android.car.dashcam.xml",
    filename_from_src: true,
}

Para obtener más información, consulta Cómo integrar una compilación previa en una imagen del sistema y Cómo agregar una lista de entidades permitidas.

Transferencia

El archivo de permisos también se puede transferir de forma local. Usa este método cuando la cámara de tablero prediseñada no esté configurada.

Con el archivo de permisos creado anteriormente en la sección de compilaciones previas, ejecuta lo siguiente:

adb root
adb remount
adb push allowed_privapp_com.android.car.dashcam.xml /etc/permissions/allowed_privapp_com.android.car.dashcam.xml
adb shell chmod 644 /etc/permissions/allowed_privapp_com.android.car.dashcam.xml

Agrega el archivo de permisos previos al otorgamiento de la misma manera que etc/default-permissions/.

Cómo configurar superposiciones

El servicio de cámara para automóvil tiene configuraciones superponibles.

Configuración del servicio

dashcam-service/res/values/config.xml

Este archivo contiene la configuración del servicio:

  • config_file El nombre del archivo de configuración del activador en /assets
  • allow_internal_storage Permitir que las grabaciones se guarden en el almacenamiento interno
  • boot_startup_enabled Inicio del servicio de Dashcam al encender el dispositivo
  • notifications_on Mostrar notificaciones cuando comience la grabación
  • default_app_component La app de cámara para el automóvil predeterminada, que tiene acceso a las grabaciones y a los activadores globales
  • recording_module ComponentName de la implementación de IRecordingModule
  • streaming_module ComponentName de la implementación de IStreamingModule
  • trigger_module ComponentName de la implementación de ITriggerModule

Configuración del activador

Para configurar los activadores de grabación, crea una copia de lo siguiente:

dashcam-service/src/assets/config.xml

y agrégala al directorio de recursos. Apunta a este archivo en el elemento config_file del archivo de configuración del servicio.

La configuración del activador consta de partes de almacenamiento, cámara y activador:

Almacenamiento

La configuración de almacenamiento tiene los siguientes elementos:

  • maxStorageUsagePercent Porcentaje máximo de almacenamiento disponible que usa la cámara para el automóvil antes de descartar grabaciones.

  • maxStorageUsageMegabytes Cantidad máxima de almacenamiento en megabytes que usa la cámara para el automóvil antes de descartar grabaciones.

  • maxAgeHoursBeforePrune Cantidad máxima de horas antes de que se trunque una grabación. Una grabación se puede descartar antes si se alcanzan los límites de almacenamiento.

Cámara

La configuración de la cámara tiene los siguientes elementos:

  • ID de la cámara. Es el ID de la cámara con el prefijo de cámara.

  • prerollLengthMs Es la duración del anuncio previo al video que se almacena con cada evento.

  • width Ancho opcional del búfer que devuelve la cámara.

  • height Altura opcional del búfer que devuelve la cámara.

<CameraConfig>
  <Camera
      ID="EVS:1"
      prerollLengthMs="10000"
      width="1920"
      height="1080" />
  <Camera
      ID="Camera2:1"
      prerollLengthMs="10000" />
</CameraConfig>

En este ejemplo, se muestra el ID de cámara EVS:1 con un avance de 10 segundos en 1080p y el ID de cámara Camera2:1 con un avance de 10 segundos y ancho y alto predeterminados.

Trigger

La configuración del activador consta de una lista de activadores definidos por lo siguiente:

  • name Es el nombre único del activador.

  • cameras IDs de las cámaras.

  • sensorPropertyID ID del sensor con el prefijo del grupo de sensores. Las opciones de prefijo son VHAL o SENSOR_MANAGER.

  • description Es la descripción del activador que se muestra en la IU.

  • recordingLengthMs Es la duración posterior al evento que se debe grabar, expresada en milisegundos.

  • sensorValueType Tipo de datos que produce el sensor. Las opciones son INT, INT_ARRAY, FLOAT, FLOAT_ARRAY y BOOLEAN, STRING.

  • thresholdType Cómo evaluar el valor del sensor en comparación con el thresholdValue. Las opciones son AVERAGE, BOOLEAN, EQUALS, LEAP, LEAP_AVERAGE, LEAP_OVER, PEAK y PEAK_HOLD.

  • thresholdValue Es el valor que se compara con el valor del sensor.

  • thresholdExtra Es el valor adicional necesario para algunos tipos de umbral, como el rango de AVERAGE.

  • triggerCooldown Período de inactividad en milisegundos antes de activar otro evento de este tipo.

<EventTriggers>
  <EventTrigger
      name="AEB"
      cameras="EVS:1, EVS:2"
      sensorPropertyID="VHAL:289411073"
      description="Automatic Emergency Braking"
      recordingLengthMs="20000"
      sensorValueType="INT"
      thresholdType="EQUALS"
      thresholdValue="2"
      triggerCooldown="5000"/>
</EventTriggers>

En este ejemplo, se muestra un activador en el que TriggerModule supervisa un sensor de VHAL que produce valores enteros. TriggerModule compara la igualdad con el valor del umbral. Cuando se cumple la condición de igualdad, se graba un activador en las cámaras 1 y 2 del EVS.

<EventTrigger
            name="SPEED"
            cameras="Camera2:0, Camera2:1,  Camera2:2,  Camera2:3"
            sensorPropertyID="VHAL:291504648"
            description="Over speed"
            recordingLengthMs="10000"
            sensorValueType="FLOAT"
            thresholdType="AVERAGE"
            thresholdValue="20.0"
            thresholdExtra="10"
            triggerCooldown="2000"/>

En este ejemplo, se muestra un activador en el que TriggerModule supervisa un sensor de VHAL que produce valores de número de punto flotante. TriggerModule compara el promedio del sensor en un rango de muestras de 10 con el valor de umbral de 20.0. El rango de muestras se establece en thresholdExtra. Solo se puede activar un evento nuevo cada 2000 milisegundos, según se establece en triggerCooldown.

Módulos

El Servicio de Cámara de tablero consta de tres módulos:

  • Stream contiene la lógica para controlar las transmisiones de las cámaras.

  • Recording contiene la lógica para controlar las grabaciones.

  • Trigger contiene la lógica para activar una grabación a partir de los datos del sensor. Las APIs de los módulos se definen en sus interfaces correspondientes, IStreamModule, IRecorderModule y ITriggerModule, y se exponen a DashcamManager a través de DashcamServiceAPI.

Módulos de superposición

El servicio de Dashcam usa dashcam-service/res/values/config.xml para determinar dónde encontrar las implementaciones del módulo. Se proporcionan implementaciones predeterminadas para cada módulo. Sin embargo, cada módulo se puede superponer configurando su componente en el valor de configuración correspondiente.

Establece el nombre del componente de implementación del OEM de la siguiente manera:

  • De IRecorderModule a recording_module
  • De IStreamModule a streaming_module
  • De ITriggerModule a trigger_module

En el tiempo de ejecución, el servicio de Dashcam crea una instancia del nombre del componente establecido en config.xml para cada módulo.

Guía para desarrolladores de apps

Dashcam es una solución de cámara para el automóvil lista para producción y personalizable. La cámara de tablero usa las APIs de Dashcam Manager para comunicarse con Dashcam service. Puedes encontrar la API de DashcamManager en IDashcamManager. Cualquier app con los permisos necesarios puede usar el Administrador de Dashcam.

OverlayUI

La app se puede personalizar con superposiciones de recursos del tiempo de ejecución. Para obtener más información, consulta Recursos superpuestos en el tiempo de ejecución. Para ver la lista de elementos superponibles, consulta overlayable.xml.

Extiende los activadores

Los activadores se pueden extender para la sesión actual con una llamada a DashcamManager#addTrigger(). Los activadores agregados persisten solo para la sesión actual.

Inicio automático

No se admite el inicio automático de la grabación. Sin embargo, un activador manual se puede iniciar onBoot con una llamada a DashcamManager.startRecording().

Prácticas recomendadas

  • Almacenamiento. Se recomienda usar almacenamiento externo extraíble.

  • Experiencia del usuario: Diseña la IU de la app de Dashcam para que sea intuitiva y fácil de usar, y cumple con los lineamientos de diseño de AAOS.

  • Optimización del rendimiento: Optimiza el rendimiento de la app para minimizar el uso de recursos y garantizar un funcionamiento fluido en AAOS.

Solución de problemas

  • Problemas de conectividad de la cámara. EVS o Camera2 deben ser compatibles y estar disponibles en el IVI de AAOS.

  • Errores de almacenamiento. Verificar el espacio de almacenamiento disponible y administrar las grabaciones Se recomienda usar almacenamiento externo, ya que el uso del almacenamiento interno puede provocar un desgaste prematuro.