Interfejs HAL – statystyki zasilania

Moc zużywana przez poszczególne podsystemy urządzenia jest często mierzona i rejestrowana w warunkach laboratoryjnych w różnych warunkach statycznych, takich jak włączony ekran czy stan bezczynności urządzenia. Funkcja ta działa w przypadku podsystemów o stałym poborze mocy lub w warunkach, które można łatwo zmierzyć w warunkach laboratoryjnych, ale nie w przypadku niektórych przypadków użycia, takich jak wyświetlanie filmu na ekranie.

IPower.hal 1.0 udostępnia interfejs do przekazywania wskazówek dotyczących mocy i raportowania danych kumulatywnych dotyczących stanu uśpienia podsystemu. W Androidzie 10 i nowszych funkcja raportowania kumulowanych statystyk znajduje się w interfejsach API do zbierania statystyk zużycia energii IPowerStats.hal i umożliwia pobieranie danych o zużyciu energii na urządzeniu. Zastępuje on część interfejsu IPower.hal służącą do gromadzenia cząstkowych statystyk, aby wyraźniej oddzielić funkcje.

Dane usługi IPowerStats nie są okresowe. Występują one w kluczowych momentach, np. gdy poziom baterii spadnie o 1%. Pomiarów jest mniej, gdy poziom naładowania baterii jest niski, a więcej, gdy jest wysoki. Dane mogą zostać wysłane z powrotem na serwery i wykorzystane w raportach o błędach do analizy i podziału na grupy. Pomaga to w ciągłym dążeniu do zmniejszenia zużycia energii i wydłużenia czasu pracy na baterii.

IPower.hal i IPowerStats.hal

Na Androidzie 10 dostępne są interfejsy IPower.hal i  IPowerStats.hal, ale funkcja zbierania statystyk IPower.hal jest dostępna tylko w interfejsie IPowerStats.hal. Funkcja IPowerStats.hal obejmuje interfejsy API do pozyskiwania i używania danych zebranych z pomiarów zużycia energii na obsługiwanych urządzeniach:

  • Wykonuje pomiary zużycia energii na poziomie szyn zarówno w przypadku klientów o niskiej częstotliwości (getRailInfo), jak i o wysokiej częstotliwości (streamEnergyData), oraz raportuje nagromadzoną energię od momentu uruchomienia.
  • Raport zawiera informacje dotyczące każdego obsługiwanego atrybutu PowerEntity, dla którego są dostępne dane. PowerEntityto podsystem platformy, urządzenie peryferyjne lub obszar zasilania, który wpływa na łączne zużycie energii przez urządzenie.
  • Zawiera zbiór stanów energopodmiotu (getPowerEntityStateInfo), dla których określone podmioty dostarczają dane o miejscu zamieszkania, a następnie dane zbiorcze dla każdego określonego PowerEntity.

Interfejsy API IPowerStats.hal są używane przez tych klientów:

  • Statsd, aby zbierać dane o zużyciu energii na poszczególne szyny.
  • Perfetto, aby powiązać zużycie energii z aktywnością procesora.
  • Batterystats, aby poprawić atrybucję baterii dzięki wykorzystaniu danych pomiarowych zamiast szacowania zużycia baterii na podstawie wstępnie zdefiniowanych stałych wartości w power_profile.xml.

W Androidzie 10 i nowszych producent urządzenia może wybrać funkcję IPower.hal lub IPowerStats.hal, ale jeśli funkcja IPowerStats.hal nie jest zaimplementowana, wszyscy klienci muszą przejść na funkcję IPower.hal .

Opcje implementacji IPowerStats.hal

Na urządzeniach z Androidem 7–9 dostępne są tylko funkcje IPower.hal. Urządzenia z Androidem 10 muszą mieć sprzętowy podsystem monitorowania zużycia energii lub inne środki umożliwiające monitorowanie i rejestrowanie statystyk zużycia energii. Niektóre układy SoC zbierają statystyki dotyczące zużycia energii, a informacje o pobytach w kraju mogą być dostępne w oprogramowaniu. Sprzęt do monitorowania zasilania jest potrzebny tylko do obsługi getRailInfo(), getEnergyData() i streamEnergyData().

Jeśli wdrożono IPowerStats.hal bez sprzętu do monitorowania zasilania, getRailInfo(), getEnergyData() i streamEnergyData() zwracają NOT_SUPPORTED. Podobnie getPowerEntityInfo(), getPowerEntityStateInfo() i getPowerEntityStateResidencyData() mogą zwracać NOT_SUPPORTED, jeśli nie są przeznaczone do użytku.

Przykłady danych zwracanych przez interfejsy API do monitorowania kolei:

  • Zasilacz wyświetlacza zużył X µW.
  • Pręt zasilania modemu zużył Y µW.

Przykłady danych zwróconych przez interfejsy API stanu snu podsystemu:

  • Modem był w stanie uśpienia przez X ms.
  • SoC był w stanie oszczędzania energii przez Y ms.
  • GPU był w stanie zawieszenia przez Z ms.

Używanie sprzętowego subsystemu monitorowania zasilania

Jeśli projekt urządzenia zawiera sprzętowy podsystem monitorowania zasilania, zaimplementuj IPowerStats.hal, tworząc pojedynczy węzeł sysfs, z którego PowerStats.hal może analizować dane, lub tworząc zbiór wywołań systemowych typu ioctl.

Sterownik jądra musi być zaimplementowany w taki sposób, aby zapobiec przepełnieniu licznika. Używany algorytm zależy od unikalnego projektu podsystemu monitorowania zasilania sprzętowego, który musi zapewniać pomiary napięcia i prądu zarówno w czasie rzeczywistym, jak i średnie. Sterownik jądra musi rejestrować te dane w sposób, który nie powoduje wyczyszczania akumulatorów energii. Musi też utrzymywać dane o nagromadzonej energii dla każdego podprocesu od momentu uruchomienia w postaci 64-bitowej zmiennej, która jest zwiększana o wartość odczytu energii z każdego zapytania dotyczącego akumulatora.

Statystyki danego komponentu (lub opcjonalnie wielu komponentów) muszą znajdować się w jednym węźle. Chociaż nie jest to typowe użycie sysfs (które zwykle ogranicza każdy węzeł do jednej wartości), zapewnia spójność wszystkich danych.

Wskazówki dotyczące projektowania

  • Utrzymywanie niskiej latencji (maksymalnie 1 ms) podczas odczytu z węzła sysfs lub wykonywania wywołań systemowych.
  • Upewnij się, że funkcje statystyczne nie zwiększają znacząco zużycia energii:
    • Nie zwiększaj liczby wybudzeń punktu dostępu (AP) ani podsystemów, aby śledzić takie parametry jak czas spędzony w trybie uśpienia.
    • Przesyłaj statystyki między procesorem aplikacji a oprogramowaniem układowym w sposób okazjonalny, gdy jest to możliwe, z innym ruchem.
  • W razie potrzeby podsystem może używać tych funkcji sterownika:
    • Buforowanie danych wewnętrznie, aby uniknąć opóźnień lub wybudzeń kosztem nieco nieaktualnych danych.
    • Wykonywanie ekstrapolacji, gdy podsystem jest uśpiony, aby uzyskać zaktualizowany czas uśpienia bez budzenia podsystemu.

Wybieranie komponentów, podsystemów i statystyk

Wybierając komponenty lub podsystemy, z których mają być zbierane daneIPowerStats.hal, wybierz na urządzeniu wszystko, co zużywa znaczną ilość prądu (co najmniej 5 mA) lub obsługuje wiele trybów zużycia energii, np.:

  • poszczególne podsystemy SoC;
  • Podsystemy częściowo lub całkowicie poza SoC, takie jak Wi-Fi, procesor obrazu czy procesor zabezpieczeń.
  • urządzenia peryferyjne, takie jak diody LED o dużej mocy i kamery;
  • Domeny zasilania, które używają różnych trybów (np. domena zasilania dla SoC jako całości).

Dostosowywanie

Ta opcjonalna funkcja może być dostosowywana. Przypadki użycia w projektowaniu i dostosowywanie:

  • Określ, które ścieżki chcesz mierzyć i jak często.
  • Określ, kiedy i jak interpretować dane.
  • Na podstawie danych decyduj, jakie działania podjąć i kiedy.

Weryfikacja

Testy VTS sprawdzają, czy są spełnione wymagania dotyczące Androida. Komentarze w pliku IPowerStats.hal służą do sprawdzania zgodności urządzenia.

Jeśli na przykład wywołasz funkcję getRailInfo(), która nie zwraca nic, test VTS kończy się niepowodzeniem, ponieważ nie otrzymasz informacji o monitorowanych szynach lub zwrócony zostanie stan SUCCESS. Podobnie, jeśli otrzymasz informacje o treningu, ale będą one zawierać odpowiedź NON_SUPPORTED lub FILE_SYSTEM_ERROR, to też będzie to niepowodzenie. VTS weryfikuje, czy specyfikacja producenta urządzenia jest zgodna z pliku HAL, korzystając z wymagań w komentarzach IPower.hal i IPowerStats.hal. Poniżej przedstawiamy przykład komentarzy używanych w testach VTS:

/**
* Rail information:
* Reports information related to the rails being monitored.
*
* @return rails Information about monitored rails.
* @return status SUCCESS on success or NOT_SUPPORTED if
* feature is not enabled or FILESYSTEM_ERROR on filesystem nodes
* access error.
*/
getRailInfo()
generates(vec<e;RailInfo>e; rails, Status status);