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.
Switch to English

HAL disponibles dinámicamente

Android 9 admite el apagado dinámico de los subsistemas de hardware de Android cuando no están en uso o no se necesitan. Por ejemplo, cuando un usuario no está usando Wi-Fi, los subsistemas de Wi-Fi no deberían consumir memoria, energía u otros recursos del sistema. En versiones anteriores de Android, los HAL / controladores se mantenían abiertos en los dispositivos Android durante todo el tiempo que se iniciaba un teléfono Android.

La implementación del apagado dinámico implica conectar los flujos de datos y ejecutar procesos dinámicos como se detalla en las siguientes secciones.

Cambios en las definiciones de HAL

El apagado dinámico requiere información sobre qué procesos sirven a qué interfaces HAL (esta información también puede ser útil más adelante en otros contextos), así como no iniciar procesos en el inicio y no reiniciarlos (hasta que se soliciten nuevamente) cuando salen.

# some init.rc script associated with the HAL
service vendor.some-service-name /vendor/bin/hw/some-binary-service
    # init language extension, provides information of what service is served
    # if multiple interfaces are served, they can be specified one on each line
    interface android.hardware.light@2.0::ILight default
    # restarted if hwservicemanager dies
    # would also cause the hal to start early during boot if disabled wasn't set
    class hal
    # will not be restarted if it exits until it is requested to be restarted
    oneshot
    # will only be started when requested
    disabled
    # ... other properties

Cambios en init y hwservicemanager

El apagado dinámico también requiere que hwservicemanager le hwservicemanager a init que inicie los servicios solicitados. En Android 9, init incluye tres mensajes de control adicionales (por ejemplo, ctl.start ): ctl.interface_start , ctl.interface_stop y ctl.interface_restart . Estos mensajes se pueden utilizar para indicar a init que init y desactive interfaces de hardware específicas. Cuando se solicita un servicio y no está registrado, hwservicemanager solicita que se inicie el servicio. Sin embargo, los HAL dinámicos no requieren el uso de ninguno de estos.

Determinando la salida de HAL

En Android 9, la salida de HAL debe determinarse manualmente. Para Android 10 y superior, también se puede determinar con ciclos de vida automáticos .

El apagado dinámico requiere varias políticas para decidir cuándo iniciar una HAL y cuándo apagar una HAL. Si una HAL decide salir por cualquier motivo, se reiniciará automáticamente cuando se necesite nuevamente utilizando la información proporcionada en la definición de HAL y la infraestructura proporcionada por los cambios en init y hwservicemanager . Esto podría involucrar un par de estrategias diferentes, que incluyen:

  • Un HAL podría optar por llamar a exit en sí mismo si alguien llama a una API de cierre o similar. Este comportamiento debe especificarse en la interfaz HAL correspondiente.
  • Los HAL pueden apagarse cuando se completa su tarea (documentado en el archivo HAL).

Ciclos de vida automáticos

Android 10 agrega más soporte al kernel y hwservicemanager , lo que permite que los HAL se apaguen automáticamente cuando no tienen clientes. Para utilizar esta función, siga todos los pasos de Cambios en las definiciones de HAL , así como:

  • Registre el servicio en C ++ con LazyServiceRegistrar lugar de la función miembro, registerAsService , por ejemplo:
    // only one instance of LazyServiceRegistrar per process
    LazyServiceRegistrar registrar;
    registrar.registerAsService(myHidlService /* , "default" */);
  • Verifique que el cliente HAL mantenga una referencia al HAL de nivel superior (la interfaz registrada con hwservicemanager ) solo cuando esté en uso. Para evitar retrasos si esta referencia se coloca en un subproceso hwbinder que continúa ejecutándose, el cliente también debe llamar a IPCThreadState::self()->flushCommands() después de IPCThreadState::self()->flushCommands() la referencia para asegurarse de que el controlador del vinculador sea notificado del recuento de referencias asociado cambios.