HAL für Energiestatistiken

Die Leistung des Geräte-Subsystems wird häufig in einer Laborumgebung für verschiedene stationäre Bedingungen gemessen und aufgezeichnet, z. B. wenn das Display eingeschaltet ist oder sich das Gerät im Ruhemodus befindet. Das funktioniert für Subsysteme mit konstanter Leistungsaufnahme oder unter Bedingungen, die sich in Laborumgebungen leicht messen lassen, aber nicht für bestimmte Anwendungsfälle, z. B. wenn auf einem Bildschirm ein Video wiedergegeben wird.

IPower.hal 1.0 bietet eine Schnittstelle zum Übergeben von Energiesparhinweisen und zum Melden kumulativer Daten zu den Ruhezustandsmesswerten des Subsystems. Unter Android 10 und höher befindet sich die Funktion für kumulative Statistiken in den IPowerStats.hal-APIs zur Erhebung von Energiestatistiken. Sie bietet eine Möglichkeit, Daten zur Geräteenergieverbrauchs zu erfassen. Dadurch wird der Bereich für die Erfassung kumulativer Statistiken in der IPower.hal-Benutzeroberfläche ersetzt, um die Funktionen klarer voneinander zu trennen.

Die IPowerStats-Messwerte werden nicht regelmäßig erfasst. Sie werden in wichtigen Momenten angezeigt, z. B. wenn der Akkustand um 1% sinkt. Die Messungen erfolgen seltener, wenn der Akkuverbrauch niedrig ist, und häufiger, wenn er hoch ist. Die Daten können an die Server zurückgesendet und in Fehlerberichten zur Analyse und Triage verwendet werden. Dies unterstützt die laufenden Bemühungen, den Energieverbrauch zu senken und die Akkulaufzeit zu verlängern.

IPower.hal und IPowerStats.hal

Sowohl die IPower.hal- als auch die IPowerStats.hal-Benutzeroberfläche sind unter Android 10 verfügbar. Die Funktion zum Erfassen von IPower.hal-Statistiken ist jedoch nur über die IPowerStats.hal-Benutzeroberfläche verfügbar. Die IPowerStats.hal-Funktion umfasst APIs zum Abrufen und Verwenden von Daten, die durch On-Device-Energiemessungen auf unterstützten Geräten erfasst wurden:

  • Führt Energiemessungen auf Schienebene sowohl für Clients mit niedriger (getRailInfo) als auch mit hoher Frequenz (streamEnergyData) durch und meldet den seit dem Start angesammelten Energieverbrauch.
  • Enthält Informationen zu den einzelnen unterstützten PowerEntity, für die Daten verfügbar sind. Ein PowerEntity ist ein Plattform-Subsystem, Peripheriegerät oder eine Leistungsdomäne, die sich auf den Gesamtenergieverbrauch des Geräts auswirkt.
  • Die Daten enthalten die Zustände der Energieversorgungsunternehmen (getPowerEntityStateInfo), für die die angegebenen Rechtssubjekte Daten zu ihrem Wohnsitz bereitstellen, sowie die aggregierten Daten für jeden angegebenen PowerEntity.

Die IPowerStats.hal APIs werden von den folgenden Clients verwendet:

  • Statsd, um Messwerte zum Stromverbrauch pro Schiene zu erfassen.
  • Perfetto, um den Stromverbrauch mit der CPU-Aktivität in Beziehung zu setzen.
  • Batterystats, um die Akkuzuordnung zu verbessern, indem gemessene Daten verwendet werden, anstatt den Akkuverbrauch anhand vordefinierter Konstanten in power_profile.xml. zu schätzen

Unter Android 10 und höher kann ein Gerätehersteller zwischen den Funktionen IPower.hal und IPowerStats.hal wählen. Alle Clients müssen jedoch auf IPower.hal zurückgreifen, wenn IPowerStats.hal nicht implementiert ist.

Implementierungsmöglichkeiten für IPowerStats.hal

Unter Android 7 bis Android 9 sind nur die IPower.hal-Funktionen verfügbar. Geräte, die auf Android 10 umgestellt wurden, müssen ein Hardware-Subsystem zur Leistungsüberwachung oder andere Mittel zur Überwachung und Aufzeichnung von Leistungsstatistiken haben. Einige SoCs erfassen Statistiken zur Stromnutzung für Sie. Alternativ können Sie Informationen zum Aufenthaltsort der Energieentität über Software abrufen. Hardware zur Leistungsüberwachung ist nur für getRailInfo(), getEnergyData() und streamEnergyData() erforderlich.

Wenn Sie IPowerStats.hal ohne Hardware zur Leistungsüberwachung implementieren, geben getRailInfo(), getEnergyData() und streamEnergyData() NOT_SUPPORTED zurück. Ebenso kann getPowerEntityInfo(), getPowerEntityStateInfo() oder getPowerEntityStateResidencyData() NOT_SUPPORTED zurückgeben, wenn es nicht verwendet werden soll.

Beispiele für Daten, die von den APIs für die Bahnüberwachung zurückgegeben werden:

  • Die Versorgungsschiene für das Display hat X µW verbraucht.
  • Die Stromversorgung des Modems hat Y µW verbraucht.

Beispiele für Daten, die von den APIs für den Ruhemodus des Subsystems zurückgegeben werden:

  • Das Modem war X ms lang im Ruhemodus.
  • Der SoC war für Y ms im Energiesparmodus.
  • Die GPU war für Z ms im Ruhemodus.

Hardware-Subsystem zur Leistungsüberwachung verwenden

Wenn Ihr Gerätedesign ein Hardware-Subsystem zur Leistungsüberwachung hat, implementieren Sie IPowerStats.hal, indem Sie einen einzelnen sysfs-Knoten erstellen, aus dem PowerStats.hal Daten analysieren kann, oder eine Sammlung von Systemaufrufen vom Typ ioctl erstellen.

Sie müssen Ihren Kerneltreiber so implementieren, dass ein Akkumulatorüberlauf verhindert wird. Der verwendete Algorithmus hängt vom individuellen Design des Hardware-Subsystems zur Leistungsüberwachung ab, das sowohl aktuelle als auch durchschnittliche Busspannungs- und Strommessungen bereitstellen muss. Der Kerneltreiber muss diese Daten so erfassen, dass die Energieakkumulatoren nicht gelöscht werden. Außerdem muss er die akkumulierten Energiedaten für jeden Sub-Rail seit dem Start in Form einer 64‑Bit-Variablen beibehalten, die mit der Energiemessung aus jeder Akkumulatorabfrage erhöht wird.

Statistiken für eine bestimmte Komponente (oder optional für mehrere Komponenten) müssen sich auf einem einzigen Knoten befinden. Dies ist zwar keine herkömmliche Verwendung von sysfs (normalerweise wird jeder Knoten auf einen einzelnen Wert beschränkt), aber so wird sichergestellt, dass alle Daten konsistent sind.

Designleitfaden

  • Die Latenz beim Lesen aus dem sysfs-Knoten oder bei Systemaufrufen sollte niedrig (maximal 1 ms) sein.
  • Achten Sie darauf, dass die Unterstützung von Statistikfunktionen den Stromverbrauch nicht messbar erhöht:
    • Erhöhen Sie nicht die Anzahl der Weckvorgänge für den Zugangspunkt (Access Point, AP) und/oder das Subsystem, um Parameter wie die im Ruhemodus verbrachte Zeit zu erfassen.
    • Statistiken werden nach Möglichkeit opportunistisch mit anderen Daten zwischen dem App-Prozessor und der Firmware übertragen.
  • Bei Bedarf kann das Subsystem die folgenden Treiberfunktionen verwenden:
    • Daten intern im Cache speichern, um Latenz/Aufweckungen zu vermeiden, auf Kosten leicht veralteter Daten.
    • Extrapolierung, wenn das Subsystem inaktiv ist, um eine aktualisierte Ruhezeit anzugeben, ohne das Subsystem zu wecken.

Komponenten, Teilsysteme und Statistiken auswählen

Wählen Sie bei der Auswahl der Komponenten oder Untersysteme, von denen IPowerStats.hal-Daten erfasst werden sollen, alle Komponenten auf dem Gerät aus, die einen erheblichen Stromverbrauch (5 mA oder mehr) haben oder mehrere Modi für den Energieverbrauch unterstützen, z. B.:

  • Einzelne SoC-Subsysteme.
  • Teilweise oder vollständig außerhalb des SoC befindliche Subsysteme wie WLAN, der Bildprozessor oder der Sicherheitsprozessor.
  • Peripheriegeräte wie leistungsstarke LEDs und Kameras
  • Energiedomains, die unterschiedliche Modi verwenden (z. B. die Energiedomain für das SoC insgesamt).

Personalisierung

Diese optionale Funktion kann angepasst werden. Anwendungsfälle entwerfen und die Nutzung anpassen:

  • Legen Sie fest, welche Räder gemessen werden sollen und wie oft.
  • Entscheiden Sie, wann Sie die Daten lesen und wie Sie sie interpretieren möchten.
  • Entscheiden Sie anhand Ihrer Daten, welche Maßnahmen Sie ergreifen und wann Sie dies tun sollten.

Zertifizierungsstufe

Mit VTS-Tests wird sichergestellt, dass die Android-Anforderungen erfüllt sind. Die Kommentare in IPowerStats.hal werden verwendet, um zu prüfen, ob ein Gerät den Anforderungen entspricht.

Wenn Sie beispielsweise getRailInfo() aufrufen und nichts zurückgegeben wird, schlägt der VTS-Test fehl, da Sie keine Informationen zu den überwachten Rails erhalten haben oder der Status SUCCESS zurückgegeben wurde. Wenn Sie Informationen zu Bahnverbindungen erhalten haben, die aber mit einer NON_SUPPORTED- oder FILE_SYSTEM_ERROR-Antwort versehen waren, ist das ebenfalls ein Fehler. Der VTS prüft anhand der Anforderungen in den Kommentaren in IPower.hal und IPowerStats.hal, ob die Spezifikation des Geräteherstellers in der HAL-Datei eingehalten wird. Unten sehen Sie ein Beispiel für Kommentare, die bei VTS-Tests verwendet werden:

/**
* 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);