HAL disponibles dinámicamente

Android 9 admite el cierre dinámico de hardware de Android subsistemas del modelo cuando no están en uso o no son necesarios. Por ejemplo, cuando un usuario no esté usando Wi-Fi, los subsistemas de Wi-Fi no deberían ocupar memoria energía u otros recursos del sistema. En versiones anteriores de Android, los controladores o HALs se mantuvieron abiertas en dispositivos Android durante todo el tiempo se inició el teléfono.

Implementar el cierre 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 cierre dinámico requiere información sobre qué procesos entregan cada HAL interfaces (esta información también puede ser útil más adelante en otros contextos), ya que así como no iniciar procesos durante el inicio y no reiniciarlos (hasta que 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 cierre dinámico también requiere que hwservicemanager indique lo contrario. init para iniciar los servicios solicitados. En Android 9, init incluye tres mensajes de control adicionales (p.ej., ctl.start): ctl.interface_start, ctl.interface_stop y ctl.interface_restart. Estos mensajes se pueden usar para indicarle a init que muestre o desaparezca interfaces de hardware específicas. Cuando se solicita un servicio y no se lo hace registrado, hwservicemanager solicita que el servicio se empezaste. Sin embargo, las HAL dinámicas no requieren el uso de ninguno de estos.

Cómo determinar la salida de la HAL

En Android 9, la salida de la HAL debe hacerse de forma manual determinado. En Android 10 y versiones posteriores, también se puede determinarse con ciclos de vida automáticos.

El cierre dinámico requiere varias políticas para decidir cuándo iniciar un HAL y cuándo apagar una HAL. Si una HAL decide salir por algún motivo, se reiniciará automáticamente cuando vuelva a ser necesario y usará la información proporcionadas en la definición de HAL y la infraestructura proporcionada por los cambios en init y hwservicemanager. Esto podría implicar un un par de estrategias diferentes, entre ellas:

  • Un HAL podría optar por llamar a la salida por sí misma si alguien llama a cerrar con una API similar. Este comportamiento debe especificarse en la HAL correspondiente interfaz de usuario.
  • Las HAL pueden apagarse cuando se completa una tarea (se documenta en el HAL .

Ciclos de vida automáticos

Android 10 agrega más compatibilidad con el kernel y hwservicemanager, que permite que las HAL se apaguen automáticamente cuando no tienen clientes. Para usar esta función, sigue todos los pasos También cambios en las definiciones de HAL. como:

  • Registra el servicio en C++ con LazyServiceRegistrar. en lugar de la función de miembro, registerAsService, para ejemplo: 
    // only one instance of LazyServiceRegistrar per process
LazyServiceRegistrar registrar;
registrar.registerAsService(myHidlService /* , "default" */);
  • Verifica que el cliente de la HAL conserve una referencia a la HAL de nivel superior (el registrada con hwservicemanager) solo cuando es en uso. Para evitar demoras si se descarta esta referencia en un subproceso hwbinder que se siga ejecutando, el cliente también debería llamar IPCThreadState::self()->flushCommands() después de descartar para asegurarte de que el controlador de Binder reciba la notificación del en el recuento de referencias.