Dynamicznie dostępne listy HAL

Android 9 obsługuje dynamiczne wyłączanie sprzętu z Androidem w podsystemach, gdy nie są używane lub niepotrzebne. Jeśli na przykład użytkownik nie korzysta z Wi-Fi, podsystemy Wi-Fi nie powinny zajmować pamięci, zasilania i innych zasobów systemowych. We wcześniejszych wersjach Androida klienty HAL i sterowniki były otwarte na urządzeniach z Androidem przez cały czas i uruchomiono telefon.

Wdrożenie dynamicznego wyłączania obejmuje okablowanie przepływów danych i wykonanie dynamicznych procesach, jak opisano w poniższych sekcjach.

Zmiany w definicjach listy HAL

Dynamiczne wyłączanie wymaga informacji o tym, które procesy obsługują dane HAL (te informacje mogą być również przydatne później w innych kontekstach), tak oraz nie uruchamiać procesów podczas uruchamiania i nie uruchamiać ich ponownie (do żądania), gdy użytkownik ją zamknie.

# 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

Zmiany w init i hwservicemanager

Dynamiczne wyłączenie wymaga też tych informacji: hwservicemanager init, aby uruchomić żądane usługi. W Androidzie 9 init zawiera 3 dodatkowe komunikaty kontrolne (np. ctl.start): ctl.interface_start, ctl.interface_stop i ctl.interface_restart. Te komunikaty mogą posłużyć do zasygnalizowania, że init ma otworzyć lub wyłączyć widok do konkretnych interfejsów sprzętowych. Gdy poproszono o usługę, a nie zarejestrowano, hwservicemanager prosi o zmianę usługi rozpoczęto. Dynamiczne HAL nie wymagają jednak żadnego z nich.

Określanie wyjścia HAL

W Androidzie 9 zdarzenie HAL trzeba skonfigurować ręcznie określonych. W Androidzie 10 i nowszych może też określić na podstawie automatycznych cykli życia.

Dynamiczne wyłączanie wymaga wielu zasad do określenia, kiedy rozpocząć HAL i kiedy wyłączyć HAL. Jeśli HAL z jakiegokolwiek powodu podejmie decyzję o zamknięciu, zostanie automatycznie ponownie uruchomiony, gdy zajdzie taka potrzeba, z wykorzystaniem tych danych podane w definicji HAL oraz infrastruktura zapewniana przez zmiany init i hwservicemanager. Może to wymagać kilka różnych strategii, w tym:

• HAL może samodzielnie wywoływać zdarzenie wyjściowe, jeśli ktoś wywoła zakończenie i podobny interfejs API. To zachowanie musi być określone w odpowiedniej HAL za pomocą prostego interfejsu online.
• Listy HAL mogą być wyłączane po zakończeniu ich zadań (zostały ujęte w pliku HAL ).

Automatyczne cykle życia

Android 10 ma większą obsługę jądra systemu, hwservicemanager, który umożliwia automatyczne wyłączanie HAL gdy klient nie ma klientów. Aby korzystać z tej funkcji, wykonaj wszystkie czynności opisane w również zmiany w definicjach listy HAL, jako:

• Zarejestruj usługę w C++ za pomocą LazyServiceRegistrar zamiast funkcji składowej registerAsService, dla argumentu przykład:

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

• Sprawdź, czy klient HAL przechowuje odwołanie do HAL najwyższego poziomu (parametr zarejestrowany w hwservicemanager) tylko wtedy, gdy jest w użyciu. Aby uniknąć opóźnień w przypadku usunięcia tego odwołania do wątku hwbinder który będzie w dalszym ciągu realizowany, klient powinien również wywołać funkcję IPCThreadState::self()->flushCommands() po usunięciu aby mieć pewność, że osoba zajmująca się segregatorem zostanie poinformowana o powiązanych zmian liczby odwołań.