Dynamisch verfügbare HALs

Android 9 unterstützt das dynamische Herunterfahren von Android-Hardware Subsysteme zu erstellen, wenn sie nicht verwendet werden oder nicht benötigt werden. Wenn ein Nutzer kein WLAN nutzt, sollten die WLAN-Subsysteme keinen Arbeitsspeicher belegen. Strom oder andere Systemressourcen. In früheren Android-Versionen, HALs/Treibern auf Android-Geräten so lange geöffnet waren, Smartphone gestartet.

Bei der dynamischen Abschaltung werden Datenflüsse verkabelt und wie in den folgenden Abschnitten beschrieben.

Änderungen an HAL-Definitionen

Das dynamische Herunterfahren erfordert Informationen darüber, welche Prozesse welche HAL bereitstellen Schnittstellen (diese Informationen können auch später in anderen Kontexten nützlich sein). Prozesse nicht beim Booten starten und auch nicht neu starten (bis beim Beenden.

# 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

Änderungen an init und hwservicemanager

Beim dynamischen Herunterfahren muss hwservicemanager außerdem init, um die angeforderten Dienste zu starten. In Android 9 init enthält drei zusätzliche Kontrollmeldungen (z.B. ctl.start): ctl.interface_start, ctl.interface_stop und ctl.interface_restart. Mit diesen Meldungen kann init signalisiert werden, dass das Gerät aktiviert und deaktiviert werden soll. Hardware-Schnittstellen zu nutzen. Wenn ein Dienst angefordert wird und nicht registriert, hwservicemanager fordert den Dienst an, begonnen. Dynamische HALs erfordern jedoch keines davon.

HAL-Exit bestimmen

In Android 9 muss der HAL-Exit manuell bestimmt. Ab Android 10 kann es auch mit denen Sie automatischen Lebenszyklen

Beim dynamischen Herunterfahren sind mehrere Richtlinien erforderlich, um zu entscheiden, wann ein HAL und wann ein HAL herunterfahren soll. Wenn ein HAL aus irgendeinem Grund beendet, wird bei Bedarf automatisch neu gestartet. in der HAL-Definition und der Infrastruktur, init und hwservicemanager. Dies könnte eine verschiedene Strategien, darunter:

• Ein HAL könnte einen Exit selbst aufrufen, wenn jemand einen Schließen- oder eine ähnliche API erstellen. Dieses Verhalten muss im entsprechenden HAL angegeben werden .
• HALs können heruntergefahren werden, wenn ihre Aufgabe abgeschlossen ist (im HAL dokumentiert). -Datei).

Automatische Lebenszyklen

Android 10 unterstützt den Kernel und Mit hwservicemanager können HALs automatisch heruntergefahren werden wenn sie keine Kundschaft haben. Um diese Funktion zu nutzen, führen Sie alle Schritte unter Änderungen an HAL-Definitionen als:

• Dienst in C++ mit LazyServiceRegistrar registrieren anstelle der Member-Funktion registerAsService für Beispiel:

  // only one instance of LazyServiceRegistrar per process
  LazyServiceRegistrar registrar;
  registrar.registerAsService(myHidlService /* , "default" */);

• Stellen Sie sicher, dass der HAL-Client eine Referenz zum HAL der obersten Ebene beibehält (die Schnittstelle bei hwservicemanager registriert), wenn sie verwendet wird. Um Verzögerungen zu vermeiden, wenn diese Referenz auf einen hwbinder-Thread gesetzt wird die weiterhin ausgeführt wird, sollte der Client auch IPCThreadState::self()->flushCommands() nach Referenz, um sicherzustellen, dass der Fahrer des Binders über die Änderungen an der Referenzanzahl.