A implementação do desligamento dinâmico envolve conectar fluxos de dados e executar processos dinâmicos, conforme detalhado nas seções a seguir.
Mudanças nas definições HAL
O desligamento dinâmico requer informações sobre quais processos atendem quais interfaces HAL (essas informações também podem ser úteis posteriormente em outros contextos), bem como não iniciar processos na inicialização e não reiniciá-los (até que sejam solicitados novamente) quando eles saírem.
# 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
Mudanças no init e no hwservicemanager
O desligamento dinâmico também exige que o hwservicemanager
diga ao init
para iniciar os serviços solicitados. No Android 9, init
inclui três mensagens de controle adicionais (por exemplo, ctl.start
): ctl.interface_start
, ctl.interface_stop
e ctl.interface_restart
. Essas mensagens podem ser usadas para sinalizar init
para ativar e desativar interfaces de hardware específicas. Quando um serviço é solicitado e não está registrado, hwservicemanager
solicita que o serviço seja iniciado. No entanto, HALs dinâmicos não exigem o uso de nenhum deles.
Determinar a saída HAL
No Android 9, a saída HAL deve ser determinada manualmente. Para Android 10 e superior, também pode ser determinado com ciclos de vida automáticos .
O desligamento dinâmico requer diversas políticas para decidir quando iniciar um HAL e quando encerrar um HAL. Se um HAL decidir sair por qualquer motivo, ele será reiniciado automaticamente quando for necessário novamente usando as informações fornecidas na definição do HAL e a infraestrutura fornecida pelas alterações em init
e hwservicemanager
. Isso pode envolver algumas estratégias diferentes, incluindo:
- Um HAL pode optar por chamar exit se alguém chamar uma API próxima ou semelhante. Este comportamento deve ser especificado na interface HAL correspondente.
- HALs podem ser desligados quando sua tarefa for concluída (documentado no arquivo HAL).
Ciclos de vida automáticos
O Android 10 adiciona mais suporte ao kernel e hwservicemanager
, o que permite que os HALs sejam desligados automaticamente sempre que não tiverem clientes. Para usar esse recurso, execute todas as etapas em Alterações nas definições HAL , bem como:
- Registre o serviço em C++ com
LazyServiceRegistrar
em vez da função membro,registerAsService
, por exemplo:// only one instance of LazyServiceRegistrar per process LazyServiceRegistrar registrar; registrar.registerAsService(myHidlService /* , "default" */);
- Verifique se o cliente HAL mantém uma referência ao HAL de nível superior (a interface registrada com
hwservicemanager
) somente quando estiver em uso. Para evitar atrasos se esta referência for descartada em um encadeamento hwbinder que continua em execução, o cliente também deve chamarIPCThreadState::self()->flushCommands()
após descartar a referência para garantir que o driver do fichário seja notificado da contagem de referência associada mudanças.