HAL dinámicamente disponibles

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 controladores/HAL 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 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 arranque y no reiniciarlos (hasta que se solicite 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 indique 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 usar para indicar a init que active 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, las HAL dinámicas no requieren el uso de ninguno de estos.

Determinación de la salida HAL

En Android 9, la salida 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 algún motivo, se reiniciará automáticamente cuando se la necesite de nuevo 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:

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

Ciclos de vida automáticos

Android 10 agrega más compatibilidad con el kernel y hwservicemanager , lo que permite que las HAL se apaguen automáticamente cuando no tengan clientes. Para utilizar esta función, siga todos los pasos de Cambios en las definiciones de HAL , además de:

  • Registre el servicio en C++ con LazyServiceRegistrar en 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 descarta en un subproceso hwbinder que continúa ejecutándose, el cliente también debe llamar a IPCThreadState::self()->flushCommands() después de descartar la referencia para asegurarse de que el controlador del enlazador sea notificado del recuento de referencia asociado. cambios.