Watchdog überwacht die Nutzung des Flash-Speichers, indem die Gesamtzahl der Schreibvorgänge der Festplatten-E/A von allen Apps und Diensten anhand der vom Kernel unter „/proc/uid_io/stats“ bereitgestellten Statistiken pro UID erfasst wird. Wenn eine App oder ein Dienst den Grenzwert für die Übernutzung der Festplatten-E/A überschreitet, ergreift Watchdog Maßnahmen für die App oder den Dienst. Die Grenzwerte für die Überlastung der Laufwerks-E/A und die Aktion bei Überlastung sind in der Konfiguration für die Überlastung der Laufwerks-E/A vordefiniert.
Grenzwerte für Übernutzung
- Die Grenzwerte für die übermäßige Nutzung der Festplatten-I/O werden täglich erzwungen. Das bedeutet, dass alle Schreibvorgänge einer App/eines Dienstes seit Beginn des aktuellen Kalendertags (UTC) zusammengefasst und mit den in den Konfigurationen für die übermäßige Nutzung definierten Grenzwerten verglichen werden.
- Wenn ein Fahrzeug an einem bestimmten Tag mehrmals gestartet wird, speichert das Watchdog-Modul die Statistiken zur Laufwerk-E/A-Nutzung im Flash-Speicher und aggregiert sie seit Beginn des aktuellen Kalendertags in UTC.
Aktionen bei Überbeanspruchung
Wenn eine App wiederholt die definierten Grenzwerte für die Laufwerk-I/O-Übernutzung überschreitet, ergreift Watchdog die in der Übernutzungskonfiguration definierten Maßnahmen.
- Alle Anbieter-Apps und ‑Dienste gelten als kritisch für die allgemeine Systemstabilität und werden daher nicht bei übermäßiger Laufwerk-E/A beendet. In der Konfiguration für die Übernutzung kann jedoch eine Liste von Anbieter-Apps und ‑Diensten definiert werden, die sicher beendet werden können.
- Alle Drittanbieter-Apps können sicher beendet werden.
Wenn eine Anwendung oder ein Dienst sicher beendet werden kann, deaktiviert Watchdog die Anwendung oder den Dienst mit dem Komponentenstatus
PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED
der Anwendung.
Konfiguration für Überbeanspruchung
Die Konfiguration für die Überbeanspruchung enthält die Grenzwerte und Aktionen für die Überlastung des Laufwerks. Standardmäßige Übernutzungskonfigurationen werden in den System- und Anbieter-Images definiert und mit dem Build ausgeliefert. Anbieter können die Anbieterkonfiguration optional in das Anbieterbild aufnehmen. Wenn die Anbieterkonfiguration nicht angegeben ist, wird die Systemkonfiguration auch für die Anbieter-Apps und ‑Dienste verwendet.
Watchdog stellt System-APIs über CarWatchdogManager
bereit, sodass Anbieter von Apps oder Diensten die Anbieterkonfiguration jederzeit aktualisieren können.
Übermäßige Nutzung der Konfigurationsdefinition
Die Konfiguration der Übernutzung wird nach dem Komponententyp unterteilt, z. B. nach System, Anbieter und Drittanbieter. OEMs müssen nur die Konfiguration der Anbieterkomponente aktualisieren.
Anbieterkonfiguration
In der Anbieterkonfiguration werden die Grenzwerte und Aktionen für die Übernutzung der Laufwerk-E/A für alle Anbieter-Apps und ‑Dienste sowie für alle Karten- und Medien-Apps definiert. Die Konfiguration enthält die folgenden Konfigurationsfelder.
- Paketpräfixe von Anbietern Alle in der Anbieterpartition installierten Pakete werden als Anbieterpakete betrachtet. Zusätzlich zu diesen Paketen können Anbieter vorinstallierte Pakete als Anbieterpakete klassifizieren, indem sie die Paketpräfixe der Konfiguration für Anbieterpaketpräfixe hinzufügen. Diese Konfiguration akzeptiert keine regulären Ausdrücke.
- Pakete, die sicher beendet werden können Anbieter können angeben, welche Anbieterpakete sicher beendet werden können, indem sie der Konfiguration safe-to-terminate packages (Pakete, die sicher beendet werden können) die vollständigen Paketnamen hinzufügen.
- Zuordnungen von Anwendungskategorien Anbieter können jedes Paket (einschließlich Drittanbieterpakete) einer der beiden unterstützten App-Kategorien zuordnen: Karten- und Medien-Apps. Durch diese Zuordnung erhalten Karten- und Medien-Apps höhere Grenzwerte für die Übernutzung der Laufwerk-E/A-Vorgänge, da diese Apps in der Regel mehr Daten herunterladen und auf das Laufwerk schreiben als andere App-Typen.
- Grenzwerte auf Komponentenebene Definiert generische Schwellenwerte für alle Anbieterpakete (d. h. Pakete, die nicht von paketspezifischen Schwellenwerten oder Anwendungskategorie-spezifischen Schwellenwerten abgedeckt sind, diese Schwellenwerte erhalten). Anbieter müssen bei der Definition der Konfiguration für die Übernutzung der Laufwerk-E/A-Leistung Grenzwerte auf Komponentenebene angeben, die nicht null sind.
- Paketspezifische Grenzwerte Anbieter können spezielle Grenzwerte für bestimmte Anbieterpakete festlegen. Die Zuordnungen sollten die vollständigen Paketnamen enthalten. Die in dieser Konfiguration definierten Grenzwerte haben Vorrang vor Grenzwerten, die in anderen Konfigurationen für ein bestimmtes Paket definiert sind.
- Schwellenwerte für die Anwendungskategorie. Anbieter können spezielle Grenzwerte für bestimmte App-Kategorien angeben. Die App-Kategorien müssen zu einer der unterstützten Kategorien gehören: Karten- und Medien-Apps. Die in dieser Konfiguration definierten Grenzwerte werden mithilfe von Zuordnungen zu Anwendungskategorien bestimmten Paketen zugeordnet.
- Systemweite Grenzwerte Anbieter dürfen diese Konfiguration nicht angeben.
Konfigurationen für Paketpräfixe von Anbietern, sicher beendbare Pakete, Grenzwerte auf Komponentenebene und paketspezifische Grenzwerte können nur über die Anbieterkonfiguration für Anbieter-Apps und ‑Dienste aktualisiert werden. Die Konfiguration der Kategoriespezifischen Grenzwerte für Anwendungen kann nur über die Anbieterkonfiguration für alle Karten- und Medien-Apps aktualisiert werden.
Die Grenzwerte für die Übernutzung enthalten die Anzahl der Byte, die während der folgenden Zeiträume geschrieben werden dürfen:
- Vordergrund- und Hintergrundmodus einer App oder eines Dienstes
- Garagenmodus des Systems
Durch diese Klassifizierung können Apps und Dienste im Vordergrund, die für Nutzer sichtbar sind, mehr Daten schreiben als Apps und Dienste im Hintergrund. Im Garagenmodus laden Apps und Dienste in der Regel Updates herunter. Daher ist für jede App und jeden Dienst ein höherer Grenzwert erforderlich als für Apps und Dienste, die in anderen Modi ausgeführt werden.
System- und Drittanbieterkonfigurationen
OEMs sollten die System- und Drittanbieterkonfigurationen nicht aktualisieren.
- In der Systemkonfiguration werden Grenzwerte und Aktionen für die Überlastung der E/A-Leistung für System-Apps und ‑Dienste definiert.
- Mit dieser Konfiguration können auch die Zuordnungen der Anwendungskategorie aktualisiert werden. Daher wird dieses Konfigurationsfeld von den System- und Anbieterkonfigurationen gemeinsam genutzt.
- In der Drittanbieterkonfiguration sind Grenzwerte für alle Drittanbieter-Apps definiert. Alle nicht im System vorinstallierten Apps sind Drittanbieter-Apps.
- Alle Drittanbieteranwendungen erhalten dieselben Grenzwerte (z. B. keine Drittanbieter-App erhält spezielle Schwellenwerte), mit Ausnahme von Karten- und Medienanwendungen, deren Schwellenwerte durch die Anbieterkonfiguration definiert werden.
- Die folgenden Grenzwerte für die übermäßige Nutzung der Festplatten-I/O sind die Standardgrenzwerte für Drittanbieter-Apps. Diese Grenzwerte sind im System-Image enthalten.
- 3 GiB Schreibvorgänge im App-Vordergrundmodus
- 2 GiB Schreibzugriff im App-Hintergrundmodus
- 4 GiB Schreibvorgänge im System-Garage-Modus.
- Dies sind Basisgrenzwerte. Diese Grenzwerte werden aktualisiert, sobald mehr über die Laufwerk-I/O-Nutzung bekannt ist.
Übermäßige Verwendung des XML-Formats für die Konfiguration
Die Standardkonfiguration des Anbieters kann (optional) im Build-Image unter /vendor/etc/automotive/watchdog/resource_overuse_configuration.xml
platziert werden. Wenn diese Konfiguration nicht angegeben ist, wird die systemdefinierte Konfiguration auch auf Anbieter-Apps und ‑Dienste angewendet.
Die XML-Datei sollte nur ein Tag für jedes Konfigurationsfeld enthalten. Die Konfiguration der E/A-Überbeanspruchung muss in der XML-Datei definiert sein. Alle Grenzwerte sollten in der Einheit MiB angegeben werden.
Unten finden Sie eine Beispiel-XML-Konfiguration:
<resourceOveruseConfiguration version="1.0"> <componentType> VENDOR </componentType> <!-- List of safe to kill vendor packages. --> <safeToKillPackages> <package> com.vendor.package.A </package> <package> com.vendor.package.B </package> </safeToKillPackages> <!-- List of vendor package prefixes. --> <vendorPackagePrefixes> <packagePrefix> com.vendor.package </packagePrefix> </vendorPackagePrefixes> <!-- List of unique package names to app category mappings. --> <packagesToAppCategoryTypes> <packageAppCategory type="MEDIA"> com.vendor.package.A </packageAppCategory> <packageAppCategory type="MAPS"> com.google.package.B </packageAppCategory> <packageAppCategory type="MEDIA"> com.third.party.package.C </packageAppCategory> </packagesToAppCategoryTypes> <ioOveruseConfiguration> <!-- Thresholds in MiB for all vendor packages that don't have package specific thresholds. --> <componentLevelThresholds> <state id="foreground_mode"> 1024 </state> <state id="background_mode"> 512 </state> <state id="garage_mode"> 3072 </state> </componentLevelThresholds> <packageSpecificThresholds> <!-- IDs must be unique --> <perStateThreshold id="com.vendor.package.C"> <state id="foreground_mode"> 400 </state> <state id="background_mode"> 100 </state> <state id="garage_mode"> 200 </state> </perStateThreshold> <perStateThreshold id="com.vendor.package.D"> <state id="foreground_mode"> 1024 </state> <state id="background_mode"> 500 </state> <state id="garage_mode"> 2048 </state> </perStateThreshold> </packageSpecificThresholds> <!-- Application category specific thresholds. --> <appCategorySpecificThresholds> <!-- One entry per supported application category --> <perStateThreshold id="MEDIA"> <state id="foreground_mode"> 600 </state> <state id="background_mode"> 700 </state> <state id="garage_mode"> 1024 </state> </perStateThreshold> <perStateThreshold id="MAPS"> <state id="foreground_mode"> 800 </state> <state id="background_mode"> 900 </state> <state id="garage_mode"> 2048 </state> </perStateThreshold> </appCategorySpecificThresholds> </ioOveruseConfiguration> </resourceOveruseConfiguration>
Konfiguration für übermäßige Nutzung über die System-APIs von CarWatchdogManager aktualisieren
Die obige XML-Konfiguration kann nur im Build-Image angegeben werden. Wenn ein OEM die On-Device-Konfiguration nach der Veröffentlichung eines Builds aktualisieren möchte, kann er die folgenden APIs verwenden, um Änderungen an der On-Device-Konfiguration vorzunehmen.
- Gewähren Sie dem Anrufer die Berechtigung
Car.PERMISSION_CONTROL_CAR_WATCHDOG_CONFIG
. - Die vorhandenen Konfigurationen müssen verwendet werden, um die neuen Konfigurationen zu aktualisieren und festzulegen. Verwenden Sie die
CarWatchdogManager.getResourceOveruseConfigurations
der API, um die vorhandenen Konfigurationen abzurufen. Wenn vorhandene Konfigurationen nicht verwendet werden, werden alle Konfigurationen (einschließlich System- und Drittanbieterkonfigurationen) überschrieben. Dies wird nicht empfohlen. - Aktualisieren Sie die vorhandenen Konfigurationen mit den Deltaänderungen und legen Sie die neuen Konfigurationen fest. Aktualisieren Sie nicht die System- und Drittanbieterkomponenten-Konfigurationen.
- Verwenden Sie die API
CarWatchdogManager.setResourceOveruseConfigurations
, um die neuen Konfigurationen festzulegen. - Verwenden Sie das Flag
CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO
, um die Konfigurationen für die Überlastung der Laufwerk-E/A abzurufen und festzulegen.
Hier ein Beispiel für eine Implementierung, mit der die Konfigurationen für die Ressourcenübernutzung aktualisiert werden:
void updateResourceOveruseConfigurations() { CarWatchdogManager manager = (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE); List<ResourceOveruseConfiguration> resourceOveruseConfigurations = manager.getResourceOveruseConfigurations( CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO); List<ResourceOveruseConfiguration> newResourceOveruseConfigurations = new List<>(); ResourceOveruseConfiguration vendorConfiguration; for(ResourceOveruseConfiguration config : resourceOveruseConfigurations) { // Do not update the configurations of the system and third-party component types. if (config.getComponentType() != ResourceOveruseConfiguration.COMPONENT_TYPE_VENDOR) { newResourceOveruseConfigurations.add(config); continue; } vendorConfiguration = config; } if (vendorConfiguration == null) { ResourceOveruseConfiguration.Builder vendorConfigBuilder = new ResourceOveruseConfiguration.Builder(); initializeConfig(vendorConfigBuilder); newResourceOveruseConfigurations.add(vendorConfigBuilder.build()); } else { ResourceOveruseConfiguration newVendorConfig = updateConfig(vendorConfiguration); newResourceOveruseConfigurations.add(newVendorConfig); } int result = manager.setResourceOveruseConfigurations( newResourceOveruseConfigurations, if (result != CarWatchdogManager.RETURN_CODE_SUCCESS) { // Failed to set the resource overuse configurations. } } /** Sets the delta between the old configuration and the new configuration. */ ResourceOveruseConfiguration updateConfig( ResourceOveruseConfiguration oldConfiguration) { // Replace com.vendor.package.A with com.vendor.package.B in the safe-to-kill list. List<String> safeToKillPackages = oldConfiguration.getSafeToKillPackages(); safeToKillPackages.remove("com.vendor.package.A"); safeToKillPackages.add("com.vendor.package.B"); ResourceOveruseConfiguration.Builder configBuilder = new ResourceOveruseConfiguration.Builder( oldConfiguration.getComponentType(), safeToKillPackages, oldConfiguration.getVendorPackagePrefixes(), oldConfiguration.getPackagesToAppCategoryTypes()); configBuilder.addVendorPackagePrefixes("com.vendor."); configBuilder.addPackagesToAppCategoryTypes("com.vendor.package.B", ResourceOveruseConfiguration.APPLICATION_CATEGORY_TYPE_MAPS); IoOveruseConfiguration oldIoConfiguration = oldConfiguration.getIoOveruseConfiguration(); IoOveruseConfiguration.Builder ioConfigBuilder = new IoOveruseConfiguration.Builder( oldIoConfiguration.getComponentLevelThresholds(), oldIoConfiguration.getPackageSpecificThresholds(), oldIoConfiguration.getAppCategorySpecificThresholds(), oldIoConfiguration.getSystemWideThresholds()); // Define the amount of bytes based on the flash memory specification, expected lifetime, // and estimated average amount of bytes written by a package during different modes. ioConfigBuilder.addPackageSpecificThresholds("com.vendor.package.B", new PerStateBytes(/* foregroundModeBytes= */ 2 * 1024 * 1024 * 1024, /* backgroundModeBytes= */ 500 * 1024 * 1024, /* garageModeBytes= */ 3 * 1024 * 1024 * 1024)); return configBuilder.setIoOveruseConfiguration(ioConfigBuilder.build()).build(); }
Apps, die die Ressourcenübernutzung überwachen
Anbieter- und Drittanbieter-Apps können auf Benachrichtigungen zu appspezifischen Ressourcenübernutzungen von Watchdog warten oder CarWatchdogManager
bis zu 30 Tage lang nach den Statistiken zur appspezifischen Ressourcenübernutzung abfragen.
Benachrichtigungen zur Ressourcenübernutzung erhalten
Apps können einen Ressourcenüberlastungs-Listener implementieren und ihn bei CarWatchdogManager
registrieren, um appspezifische Benachrichtigungen zu erhalten, wenn sie 80% oder 100% ihrer Grenzwerte für die Festplatten-I/O-Überlastung überschreiten. Apps können diese Benachrichtigungen für Folgendes verwenden:
- Protokollieren Sie die Statistiken zu Laufwerk-E/A-Überlastungen für die Offlineanalyse. App-Entwickler können dieses Logging nutzen, um das Problem mit der Laufwerk-E/A-Überlastung zu beheben.
- Reduzieren Sie die Laufwerk-E/A-Schreibvorgänge, bis die Überlastungszähler zurückgesetzt werden.
Java-Client
- Implementieren Sie den Listener, indem Sie
CarWatchdogManager.ResourceOveruseListener
übernehmen:class ResourceOveruseListenerImpl implements CarWatchdogManager.ResourceOveruseListener { @Override public void onOveruse( @NonNull ResourceOveruseStats resourceOveruseStats) { // 1. Log/Upload resource overuse metrics. // 2. Reduce writes until the counters reset. IoOveruseStats ioOveruseStats = resourceOveruseStats.getIoOveruseStats(); // Stats period - [ioOveruseStats.getStartTime(), ioOveruseStats.getStartTime() // + ioOveruseStats.getDurationInSeconds()] // Total I/O overuses - ioOveruseStats.getTotalOveruses() // Total bytes written - ioOveruseStats.getTotalBytesWritten() // Remaining write bytes for the current UTC calendar day - // ioOveruseStats.getRemainingWriteBytes() } } }
- Registrieren Sie die Listenerinstanz, indem Sie
CarWatchdogManager.addResourceOveruseListener
aufrufen.private void addResourceOveruseListener() { CarWatchdogManager manager = (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE); // Choose a proper executor to handle resource overuse notifications. Executor executor = mContext.getMainExecutor(); manager.addResourceOveruseListener( executor, CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO, mListenerImpl); }
- Listenerinstanz abmelden, wenn die App fertig ist mit dem Zuhören auf:
private void removeResourceOveruseListener() { CarWatchdogManager manager = (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE); mCarWatchdogManager.removeResourceOveruseListener( mListenerImpl); }
Nativer Client
- Fügen Sie
carwatchdog_aidl_interface-ndk_platform
in dieshared_libs
-Abhängigkeit der Build-Regel ein.Android.bp
cc_binary { name: "sample_native_client", srcs: [ "src/*.cpp" ], shared_libs: [ "carwatchdog_aidl_interface-ndk_platform", "libbinder_ndk", ], vendor: true, }
- Fügen Sie eine SELinux-Richtlinie hinzu, damit die Domain des Anbieterdienstes den Binder (
binder_user
-Makro) verwenden kann, und fügen Sie die Domain des Anbieterdienstes dercarwatchdog
-Clientdomain(carwatchdog_client_domain macro)
hinzu. Unten finden Sie den Code fürsample_client.te
undfile_contexts
.sample_client.te
type sample_client, domain; type sample_client_exec, exec_type, file_type, vendor_file_type; carwatchdog_client_domain(sample_client) init_daemon_domain(sample_client) binder_use(sample_client)
file_contexts
/vendor/bin/sample_native_client u:object_r:sample_client_exec:s0
- Implementieren Sie den Listener für die Ressourcenübernutzung, indem Sie
BnResourceOveruseListener
erben. Überschreiben SieBnResourceOveruseListener::onOveruse
, um Benachrichtigungen zur Ressourcenübernutzung zu verwalten.ResourceOveruseListenerImpl.h
class ResourceOveruseListenerImpl : public BnResourceOveruseListener { public: ndk::ScopedAStatus onOveruse( ResourceOveruseStats resourceOveruseStats) override; private: void initialize(); void terminate(); std::shared_ptr<ICarWatchdog> mWatchdogServer; std::shared_ptr<IResourceOveruseListener> mListener; }
ResourceOveruseListenerImpl.cpp
ndk::ScopedAStatus ResourceOveruseListenerImpl::onOveruse( ResourceOveruseStats resourceOveruseStats) { // 1. Log/Upload resource overuse metrics. // 2. Reduce writes until the counters reset. if (stats.getTag() != ResourceOveruseStats::ioOveruseStats) { // Received resourceOveruseStats doesn't contain I/O overuse stats. } const IoOveruseStats& ioOveruseStats = stats.get(); // Stats period - [ioOveruseStats.startTime, // ioOveruseStats.startTime + ioOveruseStats.durationInSeconds] // Total I/O overuses - ioOveruseStats.totalOveruses // Total bytes written - ioOveruseStats.writtenBytes // Remaining write bytes for the current UTC calendar day - // ioOveruseStats.remainingWriteBytes return ndk::ScopedAStatus::ok(); }
- Starten Sie einen Binder-Thread-Pool und registrieren Sie den Ressourcenüberlastungs-Listener beim Watchdog-Server. Der Watchdog-Server ist unter dem Dienstnamen
android.automotive.watchdog.ICarWatchdog/default
registriert.main.cpp
int main(int argc, char** argv) { ABinderProcess_setThreadPoolMaxThreadCount(1); ABinderProcess_startThreadPool(); std::shared_ptr<ResourceOveruseListenerImpl> listener = ndk::SharedRefBase::make<ResourceOveruseListenerImpl>(); // The listener is added in initialize(). listener->initialize(); ... Run service ... // The listener is removed in terminate(). listener->terminate(); }
ResourceOveruseListenerImpl.cpp
void ResourceOveruseListener::initialize() { ndk::SpAIBinder binder(AServiceManager_getService( "android.automotive.watchdog.ICarWatchdog/default")); std::shared_ptr<ICarWatchdog> server = ICarWatchdog::fromBinder(binder); mWatchdogServer = server; std::shared_ptr<IResourceOveruseListener> listener = IResourceOveruseListener::fromBinder(this->asBinder()); mWatchdogServer->addResourceOveruseListener( std::vector<int>{ResourceType.IO}, listener); mListener = listener; } void ResourceOveruseListener::terminate() { mWatchdogServer->removeResourceOveruseListener(mListener); }
Statistiken zur Ressourcenübernutzung abfragen
Apps können CarWatchdogManager nach den app-spezifischen I/O-Übernutzungsstatistiken ATS für die letzten 30 Tage abfragen.
Java-Client
Verwenden Sie CarWatchdogManager.getResourceOveruseStats
, um die Statistiken zur Ressourcenüberlastung abzurufen. Geben Sie das Flag CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO
an, um Statistiken zur Übernutzung der Laufwerk-E/A abzurufen.
private void getResourceOveruseStats() { CarWatchdogManager manager = (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE); // Returns resource overuse stats with I/O overuse stats for the past // 7 days. Stats are available for up to the past 30 days. ResourceOveruseStats resourceOveruseStats = mCarWatchdogManager.getResourceOveruseStats( CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO, CarWatchdogManager.STATS_PERIOD_PAST_7_DAYS); IoOveruseStats ioOveruseStats = resourceOveruseStats.getIoOveruseStats(); // Stats period - [ioOveruseStats.getStartTime(), ioOveruseStats.getStartTime() // + ioOveruseStats.getDurationInSeconds()] // Total I/O overuses - ioOveruseStats.getTotalOveruses() // Total bytes written - ioOveruseStats.getTotalBytesWritten() // Remaining write bytes for the UTC calendar day - // ioOveruseStats.getRemainingWriteBytes() }
Nativer Client
Verwenden Sie CarWatchdogServer.getResourceOveruseStats
, um die Statistiken zur Ressourcenüberlastung abzurufen. Übergeben Sie das ResourceType.IO
-Enum, um Statistiken zur Überlastung der Laufwerks-E/A abzurufen.
void getResourceOveruseStats() { ndk::SpAIBinder binder(AServiceManager_getService( "android.automotive.watchdog.ICarWatchdog/default")); std::shared_ptr<ICarWatchdog> server = ICarWatchdog::fromBinder(binder); // Returns the stats only for the current UTC calendar day. const std::vector<ResourceOveruseStats> resourceOveruseStats; ndk::ScopedAStatus status = server.getResourceOveruseStats( std::vector<int>{ResourceType.IO}, &resourceOveruseStats); if (!status.isOk()) { // Failed to get the resource overuse stats. return; } for (const auto& stats : resourceOveruseStats) { if (stats.getTag() != ResourceOveruseStats::ioOveruseStats) { continue; } const IoOveruseStats& ioOveruseStats = stats.get(); // Stats period - [ioOveruseStats.startTime, // ioOveruseStats.startTime + ioOveruseStats.durationInSeconds] // Total I/O overuses - ioOveruseStats.totalOveruses // Total bytes written - ioOveruseStats.writtenBytes // Remaining write bytes for the current UTC calendar day - // ioOveruseStats.remainingWriteBytes } }
Nutzerfreundlichkeit bei Ressourcenübernutzung
In den folgenden Abschnitten wird beschrieben, was passiert, wenn eine Ressourcenübernutzung auftritt.
Einstellung „App-Leistung priorisieren“
Die Seite Einstellungen der App enthält Einstellungen fürPrioritize app performance
(siehe Abbildung unten). Damit können Nutzer die Leistung einer App gegenüber der System- und der langfristigen Hardwareleistung priorisieren. Diese Einstellung ist nur für Anwendungen verfügbar, die bei übermäßiger Ressourcennutzung sicher beendet werden können. Andernfalls ist diese Einstellung deaktiviert. Wenn diese Einstellung für eine App deaktiviert ist (Standardeinstellung), kann die App bei Ressourcenübernutzung beendet werden.
Andernfalls wird die App nicht bei übermäßiger Ressourcennutzung beendet.
Wenn der Nutzer diese Einstellung aktiviert, werden im folgenden Bestätigungsdialogfeld die Auswirkungen beschrieben:
Nach 90 Tagen wird diese Einstellung automatisch auf die Standardeinstellungen zurückgesetzt. Das Tageslimit kann mit einer RRO-Overlay-App mit watchdogUserPackageSettingsResetDays
bis zu einem Maximum von 180 Tagen geändert werden. Weitere Informationen finden Sie unter Wert der Ressourcen einer App zur Laufzeit ändern. Das folgende Beispiel-Overlay-Tag kann in AndroidManifest.xml
eingefügt werden:
<overlay android:priority="<insert-value>" android:targetPackage="com.android.car.updatable" android:targetName="CarServiceCustomization" android:resourcesMap="@xml/overlays" />
In res/values/config.xml
:
<resources> <integer name="watchdogUserPackageSettingsResetDays">value</integer> </resources>
In res/xml/overlays.xml
:
<overlay> <item target="integer/watchdogUserPackageSettingsResetDays" value="@integer/watchdogUserPackageSettingsResetDays" /> </overlay>
Einstellung für Apps mit Einfluss auf die Systemleistung
Die Einstellungen enthalten den Abschnitt Apps mit Leistungseinbußen (siehe Abbildung 1). Wenn Sie darauf tippen, wird eine Liste der Apps angezeigt, die aufgrund von übermäßigem Flash-Speicherverbrauch eingeschränkt wurden und sich negativ auf die Systemleistung auswirken. Dies entspricht der CDD 3.5.1-Anforderung [C-1-1].
Abbildung 1. Apps mit Einfluss auf die Systemleistung
Hier sind Apps aufgeführt, die aufgrund von Ressourcenüberlastung beendet wurden (siehe Abbildung 2). Die aufgeführten Apps können priorisiert werden. Weitere Informationen finden Sie unter Priorität der Einstellung für die App-Leistung festlegen.
Abbildung 2. Liste der Apps, die aufgrund von Ressourcenüberlastung beendet wurden.
Nutzerbenachrichtigung
Wenn eine App oder ein Dienst innerhalb eines bestimmten Zeitraums wiederholt die Festplatten-I/O überlastet (z. B. Daten über die definierten Grenzwerte hinaus auf die Festplatte schreibt) und bei Ressourcenüberlastung sicher beendet werden kann, wird der Nutzer benachrichtigt, nachdem das Fahrzeug den Status „Distractions allowed“ (Fahrer ablenken erlaubt) erreicht hat.
Die erste Nutzerbenachrichtigung (während der Fahrt) wird als Pop-up-Benachrichtigung angezeigt. Die anderen Benachrichtigungen werden im Benachrichtigungscenter angezeigt.
Wenn eine App beispielsweise wiederholt die Festplatten-I/O überlastet, erhält der Nutzer die folgende Benachrichtigung:
- Wenn der Nutzer auf die Schaltfläche App priorisieren klickt, wird die Einstellungsseite der App geöffnet. Dort kann er die Einstellung App-Leistung priorisieren aktivieren oder deaktivieren.
- Wenn der Nutzer auf die Schaltfläche App deaktivieren klickt, wird die App deaktiviert, bis der Nutzer sie auf der Seite „Einstellungen“ der App startet oder aktiviert.
- Bei nicht installierten Apps wird die Schaltfläche App deaktivieren durch die Schaltfläche App deinstallieren ersetzt. Wenn der Nutzer auf die Schaltfläche App deinstallieren klickt, wird die Seite „Einstellungen“ der App geöffnet, über die er die App deinstallieren kann.
Empfehlung für die Implementierung des Launchers
Wenn Apps aufgrund von Ressourcenüberlastung deaktiviert werden, verschwinden sie aus der Standard-Launcher-App, da CarService den Aktivierungsstatus der Apps auf PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED
aktualisiert.
OEMs müssen die Implementierung des integrierten Launchers aktualisieren, damit diese Apps als ungewöhnlich angezeigt werden, damit Nutzer sie bei Bedarf verwenden können. Beachten Sie die folgenden Empfehlungen, die auf dem Build-Release basieren.
Android SC V2 Release
- Die Launcher-Implementierung sollte das Flag
MATCH_DISABLED_UNTIL_USED_COMPONENTS
verwenden, wenn die Liste der Pakete abgerufen wird, die im Launcher angezeigt werden sollen. - Wenn der Nutzer auf eine App klickt, die sich im Status
PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED
befindet, muss die Launcher-App die App aktivieren, indem sie den aktivierten Status so festlegt: