L'implementazione dell'arresto dinamico comporta il cablaggio dei flussi di dati e l'esecuzione i processi dinamici, come descritto nelle sezioni seguenti.
Modifiche alle definizioni dell'HAL
L'arresto dinamico richiede informazioni su quali processi gestiscono quale HAL (queste informazioni possono essere utili anche in un secondo momento in altri contesti) e non avviare i processi all'avvio e non riavviarli (fino richiesto di nuovo) quando escono.
# 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
Modifiche a init e hwservicemanager
L'arresto dinamico richiede anche che hwservicemanager
indichi
init
per avviare i servizi richiesti. In Android 9,
init
include tre messaggi di controllo aggiuntivi (ad es.
ctl.start
): ctl.interface_start
,
ctl.interface_stop
e ctl.interface_restart
.
Questi messaggi possono essere utilizzati per segnalare a init
di attivare o disattivare la visualizzazione
interfacce hardware specifiche. Quando un servizio viene richiesto e non è
registrato, hwservicemanager
richiede che il servizio venga
a iniziare. Tuttavia, gli HAL dinamici non richiedono l'utilizzo di nessuno di questi.
Determina l'uscita dell'HAL
In Android 9, l'uscita dell'HAL deve essere manuale determinato. Per Android 10 e versioni successive, può anche essere determinato con cicli di vita automatici.
La chiusura dinamica richiede più criteri per decidere quando avviare un
HAL e quando arrestare un HAL. Se un HAL decide di uscire per qualsiasi motivo,
verrà riavviato automaticamente quando sarà nuovamente necessario utilizzando le informazioni
fornita nella definizione dell'HAL e nell'infrastruttura fornita dalle modifiche
init
e hwservicemanager
. Ciò potrebbe comportare
un paio di diverse strategie, tra cui:
- Un HAL può scegliere di chiamare l'uscita su se stesso se qualcuno chiama una chiusura un'API simile. Questo comportamento deve essere specificato nell'HAL corrispondente a riga di comando.
- Gli HAL possono arrestarsi una volta completata l'attività (documento nell'HAL) ).
Ciclo di vita automatici
Android 10 aggiunge più supporto al kernel
hwservicemanager
, che consente l'arresto automatico degli HAL
ogni volta che non hanno clienti. Per utilizzare questa funzione, esegui tutti i passaggi in
Modifiche alle definizioni dell'HAL
come:
- Registra il servizio in C++ con
LazyServiceRegistrar
anziché la funzione membro,registerAsService
, per esempio:// only one instance of LazyServiceRegistrar per process LazyServiceRegistrar registrar; registrar.registerAsService(myHidlService /* , "default" */);
- Verifica che il client HAL conservi un riferimento all'HAL di primo livello (il
registrata con
hwservicemanager
) solo quando è in uso. Per evitare ritardi se questo riferimento viene eliminato in un thread hwbinder che continua a essere eseguito, il client dovrebbe anche richiamareIPCThreadState::self()->flushCommands()
dopo l'eliminazione di riferimento per garantire che al sistema di gestione dei raccoglitori venga notificato l'indirizzo le modifiche al conteggio dei riferimenti.