Zasilanie podsystemu urządzenia jest często mierzone i rejestrowane w środowisku laboratoryjnym w przypadku różnych zmiennych warunków, takich jak włączony ekran czy urządzenie znajduje się w stanie bezczynności. Jest to możliwe w podsystemach o stałej wartości pobór mocy lub w warunkach, które można łatwo zmierzyć w środowiskach laboratoryjnych, ale nie w niektórych przypadkach, np. gdy na ekranie wyświetla się film.
IPower.hal 1.0
udostępnia interfejs do przekazywania
wskazówki dotyczące zasilania oraz raportowanie danych skumulowanych dotyczących stanu snu podsystemu.
W Androidzie 10 i nowszych funkcja raportowania statystyk zbiorczych
znajduje się w interfejsach API gromadzenia statystyk mocy obliczeniowej IPowerStats.hal
,
zapewnia sposób pobierania danych o użyciu energii z urządzenia. Zastępuje to tag
część interfejsu IPower.hal
do gromadzenia statystyk,
dla lepszego rozdzielenia funkcji.
Odczyty usługi IPowerStats
nie są okresowe. Występują
w kluczowych momentach, np. gdy poziom naładowania baterii spadnie do 1%. Odczyt jest rzadszy
gdy poziom naładowania baterii jest niski i częściej, gdy jest wysoki. Dane mogą być
są wysyłane z powrotem na serwery i mogą zostać wykorzystane w raportach o błędach do analizy i segregacji.
Wspomaga to trwające wysiłki na rzecz ograniczenia zużycia energii i zwiększania
żywotności baterii.
IPower.hal i IPowerStats.hal
Interfejsy IPower.hal
i
IPowerStats.hal
są dostępne na Androidzie 10, ale
Funkcja zbierania statystyk w: IPower.hal
jest dostępna tylko
z interfejsu IPowerStats.hal
.
Funkcja IPowerStats.hal
obejmuje interfejsy API do pozyskiwania i wykorzystywania
dane zebrane z pomiarów mocy urządzenia w przypadku obsługiwanych urządzeń:
- Wykonuje pomiary energii na poziomie kolei w przypadku niskiej częstotliwości
(
getRailInfo
) i duża częstotliwość (streamEnergyData
) klientów i tworzy raporty na temat energii zakumulowanej od momentu uruchomienia. - Raportuje informacje dotyczące poszczególnych obsługiwanych
PowerEntity
, dla których dostępne są dane.PowerEntity
to podsystem platformy, urządzenie peryferyjne lub domena mocy, która ma wpływ zużycie energii przez urządzenie. - Raportuje zestaw stanów jednostek potęgowych (
getPowerEntityStateInfo
) dla których określone podmioty dostarczają dane dotyczące miejsca zamieszkania, a następnie zgłaszają zgromadzone dane dla każdej określonej wartościPowerEntity
.
Interfejsy API IPowerStats.hal
są używane przez te klienty:
Statsd
, aby zbierać wskaźniki zużycia energii przez poszczególne szyny.Perfetto
, aby skorelować zużycie energii z procesorem działania.Batterystats
, aby poprawić atrybucję baterii dzięki wykorzystaniu szacuje zużycie baterii na podstawie zdefiniowanych wstępnie wartości, a nie szacowanie zużycia baterii w:power_profile.xml.
W przypadku Androida 10 lub nowszego producent urządzenia może wybrać
funkcji IPower.hal
i IPowerStats.hal
, ale
wszyscy klienci muszą przełączyć się na IPower.hal
, jeśli
Parametr IPowerStats.hal
nie jest zaimplementowany .
Opcje implementacji IPowerStats.hal
Na Androidzie 7 dostępne są tylko funkcje IPower.hal
do Androida 9. Urządzenia uaktualnione do Androida 10 muszą
dysponują sprzętowym podsystemem monitorowania zasilania lub innymi narzędziami do monitorowania
i rejestrować statystyki energii. Niektóre układy SOC zbierają
statystyki wykorzystania energii lub uzyskanie miejsca zamieszkania podmiotu energetycznego
informacji za pomocą oprogramowania. Sprzęt do monitorowania mocy jest potrzebny tylko do
obsługuje getRailInfo()
, getEnergyData()
i
streamEnergyData()
Jeśli wdrożysz IPowerStats.hal
bez monitorowania zasilania
sprzęt, getRailInfo(), getEnergyData()
oraz
streamEnergyData()
zwraca NOT_SUPPORTED
. Podobnie
getPowerEntityInfo(), getPowerEntityStateInfo()
i
getPowerEntityStateResidencyData()
może również zwrócić
NOT_SUPPORTED
, jeśli nie jest przeznaczona do stosowania.
Przykłady danych zwracanych przez interfejsy API monitorowania pociągów:
- Zużycie X μW w ramach szyny zasilającej wyświetlacza.
- Kolumna energetyczna modemu zużywała wartość Y μW.
Przykłady danych zwracanych przez interfejsy API stanu uśpienia podsystemu:
- Modem był uśpiony przez X ms.
- Przez Y ms układ SoC był w stanie braku zasilania.
- Procesor graficzny był w stanie zawieszenia przez Z ms.
Użyj podsystemu sprzętowego do monitorowania zasilania
Jeśli urządzenie ma podsystem sprzętowy do monitorowania zasilania,
IPowerStats.hal
przez utworzenie jednego węzła sysfs
z którego PowerStats.hal
może analizować dane, lub przez utworzenie
zbiór wywołań systemowych typu ioctl.
Musisz wdrożyć sterownik jądra w sposób uniemożliwiający działanie akumulatora overflow. Użyty algorytm zależy od unikalnego sprzętu do monitorowania zasilania projektu podsystemu, który musi zapewniać zarówno chwilowe, jak i średnie napięcie magistrali oraz bieżących pomiarów. Sterownik jądra musi przechwytywać te dane w określony sposób który nie oczyszcza akumulatorów energii i musi utrzymywać dane dotyczące skumulowanej energii dla każdej podkolejki od momentu uruchomienia, w postaci 64-bitowej zmienna, która zwiększa się wraz z odczytem energii z każdego akumulatora zapytania.
Statystyki danego komponentu (lub opcjonalnie kilku komponentów) muszą być w polu w jednym węźle. Nie jest to konwencjonalne użycie sysfs. (co zwykle ogranicza każdy węzeł do jednej wartości), zapewnia, że wszystkie dane są spójne.
Wskazówki dotyczące projektowania
- Zmniejsz opóźnienie (maks. 1 ms) podczas odczytu sysfs węzła lub wykonywać wywołania systemowe.
- Upewnij się, że obsługa statystyk nie zwiększa wymiernie zużycie energii:
- Nie zwiększaj wybudzania punktu dostępu ani podsystemu, aby je śledzić takie jak czas w trybie uśpienia.
- Możliwość przenoszenia statystyk między procesorem aplikacji a oprogramowaniem układowym z innym ruchem.
- W razie potrzeby podsystem może korzystać z tych funkcji sterownika:
- Wewnętrzne buforowanie danych w celu uniknięcia opóźnień/wybudzeń kosztem w niewielkim stopniu nieaktualne dane.
- Przeprowadzam ekstrapolację, gdy podsystem jest uśpiony, w celu zapewnienia aktualizacji snu bez wybudzania podsystemu.
Wybierz komponenty, podsystemy i statystyki
Podczas wybierania komponentów lub podsystemów, z których mają pochodzić dane
IPowerStats.hal
, wybierz na urządzeniu wszystko, co zużywa
znaczący (5 mA lub więcej) lub który obsługuje
wiele trybów zużycia energii, takich jak:
- poszczególnych podsystemów SOC.
- Podsystemy częściowo lub całkowicie poza układem SOC, takie jak Wi-Fi, procesora zdjęć czy zabezpieczeń.
- Urządzenia peryferyjne, takie jak diody LED o dużej mocy i kamery.
- Domeny zaawansowane, które używają różnych trybów (np. domena zasilania układu SOC jako całości).
Dostosowywanie
Tę opcjonalną funkcję można dostosowywać. Przypadki użycia projektowania i dostosować sposób jej używania:
- Ustal, które szyny chcesz mierzyć i jak często chcesz je mierzyć.
- Zdecyduj, kiedy odczytywać dane i jak je zinterpretować.
- Na podstawie dostępnych danych zdecyduj, co i kiedy chcesz zrobić.
Weryfikacja
Testy VTS służą do sprawdzenia, czy wymagania dotyczące Androida są spełnione. Komentarze w:
IPowerStats.hal
służą do sprawdzania, czy urządzenie jest
zgodność z przepisami.
Jeśli na przykład wywołasz funkcję getRailInfo()
i nic nie zwróci,
test VTS nie powiedzie się, ponieważ nie otrzymano informacji o monitorowanym
szyny lub zwrócony stan SUCCESS
. Podobnie, jeśli otrzymano
informacje o kolejce, ale towarzyszyła im informacja NON_SUPPORTED
lub
FILE_SYSTEM_ERROR
. To również była niepowodzenie. VTS
sprawdzenie, czy w pliku HAL przestrzegana jest specyfikacja producenta urządzenia;
zgodnie z wymaganiami określonymi w komentarzach na stronach IPower.hal i IPowerStats.hal. An
przykład komentarzy używanych podczas testowania 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);