Flash-Speichernutzung überwachen

Watchdog überwacht die Nutzung des Flash-Speichers, indem er die Gesamtmenge der Laufwerks-E/A-Vorgänge verfolgt Schreibvorgänge von allen Apps und Diensten unter Verwendung der Laufwerks-E/A-Statistiken pro UID vom Kernel unter "/proc/uid_io/stats" bereitgestellt. Wenn eine App oder Dienst den Grenzwert für Überlastung des Laufwerks überschreitet, führt Watchdog App oder Dienst. Grenzwerte für die Überlastung der Laufwerk-E/A und zu ergreifende Maßnahmen bei Überbelegung ist in der Konfiguration der Laufwerks-E/A-Übernutzung vordefiniert.

Grenzwerte für Übernutzung

  • Die Grenzwerte für die Überlastung der E/A-Laufwerke werden täglich erzwungen, d. h. Von einer Anwendung oder einem Dienst ausgeführte Schreibvorgänge werden seit Beginn der auf den aktuellen UTC-Kalendertag geprüft und auf die in der die übermäßige Verwendung von Konfigurationen.
  • Wird ein Fahrzeug an einem Tag mehrmals gestartet, zeigt das Watchdog-Modul speichert die E/A-Nutzungsstatistiken des Laufwerks im Flash-Speicher und aggregiert sie, Beginn des aktuellen koordinierten Kalendertags (UTC).

Überbeanspruchte Aktionen

Wenn eine App wiederholt die festgelegte Laufwerks-E/A-Überlastung überschreitet Schwellenwerten, führt Watchdog die in der Überbeanspruchungskonfiguration definierten Aktionen aus.

  • Alle Apps und Dienste von Anbietern gelten als kritisch Gesamtsystemstabilität zu verhindern, sodass sie nicht bei Überlastung der Laufwerk-E/A beendet werden. Sie können jedoch Die Überbelegungskonfiguration kann eine Liste von Anbieter-Apps definieren, die sicher beendet werden können und Dienste.
  • Alle Drittanbieter-Apps können wieder beendet werden.

Wenn eine App oder ein Dienst sicher beendet werden kann, deaktiviert Watchdog die App oder den Dienst mit der App. Komponentenstatus PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED

Überbeanspruchte Konfiguration

Die Konfiguration für die Überbeanspruchung enthält die Grenzwerte für die Überlastung des Laufwerks-E/A Aktionen. Standardkonfigurationen für die Überbelegung werden im System und vom Anbieter definiert und mit dem Build versendet. Anbieter können den entsprechenden Konfiguration im Anbieter-Image. Wenn die Anbieterkonfiguration wird die Systemkonfiguration für die Anbieter-Apps und und Dienste.

Watchdog stellt System-APIs über CarWatchdogManager zur Verfügung, wodurch Anbieter, Apps oder Dienste, aktualisieren die Anbieterkonfiguration jederzeit.

Definition der übermäßigen Verwendung

Die übermäßige Nutzung ist nach Komponententyp aufgeteilt, z. B. System, Anbieter, und von Drittanbietern. OEMs müssen nur die Konfiguration der Anbieterkomponente aktualisieren.

Anbieterkonfiguration

In der Anbieterkonfiguration sind Schwellenwerte für die Überlastung des Laufwerks-E/A und alle Anbieter-Apps und -Dienste sowie alle Karten- und Medien-Apps. Die Konfiguration enthält die folgenden Konfigurationsfelder.

  • Präfixe von Anbieterpaketen. Alle Pakete, die im werden als Anbieterpakete betrachtet. Zusätzlich zu diesen können Anbieter vorinstallierte Pakete als Anbieterpakete klassifizieren, indem sie Durch Hinzufügen der Paketpräfixe zur Konfiguration der Anbieterpaketpräfixe Diese Konfiguration akzeptiert keine regulären Ausdrücke.
  • Sicheres Beenden von Paketen. Anbieter können festlegen, -Pakete können sicher beendet werden, indem Sie die vollständigen Paketnamen zum sichere Beendigungspakete.
  • Zuordnungen von Anwendungskategorien: Anbieter können jedes Paket zuordnen (einschließlich Drittanbieterpaketen) zu einer der beiden unterstützten Apps Kategorien: Karten- und Medien-Apps Diese Zuordnung erfolgt, um Karten zur Verfügung zu stellen. und Medien-Apps haben zu viele E/A-Grenzwerte für Laufwerke. Apps laden tendenziell mehr Daten herunter und schreiben auf die Festplatte als andere Apps Typen.
  • Grenzwerte auf Komponentenebene: Definiert allgemeine Schwellenwerte für alle Anbieterpakete (d. h. Pakete, die nicht unter Paketspezifische Grenzwerte oder App-Kategorie-spezifische Schwellenwerte diesen Schwellenwerten). Anbieter müssen auf Komponentenebene Schwellenwerte nicht null definieren, wenn das Definieren der Überlastungskonfiguration von Laufwerks-E/A.
  • Paketspezifische Schwellenwerte: Zulieferunternehmen können spezielle für bestimmte Anbieterpakete. Die Zuordnungen sollten den Parameter vollständige Paketnamen. Die in dieser Konfiguration definierten Schwellenwerte haben Vorrang Über Schwellenwerten, die in anderen Konfigurationen für ein bestimmtes Paket definiert sind.
  • Schwellenwerte für die Anwendungskategorie. Anbieter können angeben, spezielle Schwellenwerte für bestimmte App-Kategorien. Die App Kategorien müssen eine der unterstützten Kategorien sein - Karten und Medien. Apps. Die in dieser Konfiguration definierten Schwellenwerte sind bestimmten Pakete mithilfe von Anwendungskategoriezuordnungen erstellen.
  • Systemweite Grenzwerte: Anbieter dürfen diese Konfiguration nicht angeben.

Präfixe von Anbieterpaketen, sicher zu beendende Pakete, Grenzwerte auf Komponentenebene und Paketspezifische Schwellenwerte Konfigurationen für Grenzwerte können nur durch die Anbieterkonfiguration für Apps und Dienste von Anbietern. App-Kategoriespezifisch kann die Konfiguration von Grenzwerten nur durch die Anbieterkonfiguration für alle Karten- und Medien-Apps.

Die Grenzwerte für die Überbeanspruchung beinhalten die Menge an Byte, die während folgender Ereignisse geschrieben werden dürfen:

  • Vordergrundmodus und Hintergrundmodus einer App oder eines Dienstes
  • Garagensystemmodus

Durch diese Klassifizierung können Nutzer, die Apps und Dienste im Vordergrund sehen, mehr Daten schreiben als Hintergrund-Apps und -Dienste. Im Garage-Modus Apps und Dienste laden in der Regel Updates herunter und benötigen daher jeweils einen höheren Schwellenwert als Apps und Dienste, die in anderen Modi ausgeführt werden.

System- und Drittanbieterkonfigurationen

OEMs sollten die System- und Drittanbieterkonfigurationen nicht aktualisieren.

  • In der Systemkonfiguration sind Grenzwerte für die E/A-Überlastung und Maßnahmen für System-Apps und -Dienste.
    • Mit dieser Konfiguration kann auch die Anwendungskategorie Zuordnungen. Daher wird dieses Konfigurationsfeld von System und Anbieter gemeinsam verwendet Konfigurationen.
  • In der Drittanbieterkonfiguration sind Grenzwerte für alle Drittanbieter Apps. Alle Apps, die nicht vorinstalliert sind, werden Drittanbieter-Apps.
    • Alle Drittanbieter-Apps erhalten dieselben Grenzwerte (z. B. keine Apps von Drittanbietern gelten spezielle Grenzwerte), außer Karten und Medien Apps, deren Schwellenwerte durch die Anbieterkonfiguration definiert werden.
    • Die folgenden Grenzwerte für die Überlastung der Laufwerk-E/A-Vorgänge sind die Standardgrenzwerte für den Drittanbieter-Apps. Diese Grenzwerte werden mit dem System-Image versendet.
      • 3 GiB Schreiben im Vordergrundmodus der App.
      • 2 GiB Schreiben im Hintergrundmodus der Anwendung ausführen.
      • 4 GiB Schreiben im Garagenmodus des Systems.
    • Dies sind Basisgrenzwerte. Diese Schwellenwerte werden aktualisiert, wenn mehr über Laufwerks-E/A festgestellt wird Nutzung.

Konfigurations-XML-Format übermäßig verwenden

Die Standardanbieterkonfiguration kann am Standort platziert werden (optional). /vendor/etc/automotive/watchdog/resource_overuse_configuration.xml im Build-Image befinden. Wenn diese Konfiguration nicht angegeben ist, wird auch auf die Apps und Dienste des Anbieters angewendet.

Die XML-Datei sollte nur ein Tag für jedes Konfigurationsfeld enthalten. E/A-Überbeanspruchung Konfiguration in der XML-Datei definiert sein. Alle Schwellenwerte sollten MiB-Einheit angegeben ist.

Im Folgenden finden Sie ein Beispiel für eine 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>

Übernutzungskonfiguration über CarWatchdogManager-System-APIs aktualisieren

Die obige XML-Konfiguration kann nur im Build-Image bereitgestellt werden. Wenn ein Der OEM aktualisiert die On-Device-Konfiguration nach der Veröffentlichung eines Builds. mit den folgenden APIs Änderungen an der Konfiguration auf dem Gerät vornehmen.

  • Erteile die Berechtigung Car.PERMISSION_CONTROL_CAR_WATCHDOG_CONFIG dem Anrufer.
  • Die vorhandenen Konfigurationen müssen zum Aktualisieren und Festlegen des neue Konfigurationen erstellen. API verwenden CarWatchdogManager.getResourceOveruseConfigurations, um die vorhandenen Konfigurationen erstellen. Wenn keine vorhandenen Konfigurationen verwendet werden, (einschließlich System- und Drittanbieterkonfigurationen) überschrieben, was nicht empfohlen wird.
  • Vorhandene Konfigurationen mit den Deltaänderungen aktualisieren und neue Konfigurationen. Aktualisieren Sie nicht die System- und Drittanbieterkomponente. Konfigurationen.
  • Die API CarWatchdogManager.setResourceOveruseConfigurations verwenden um die neuen Konfigurationen festzulegen.
  • Verwenden Sie das Flag, um Konfigurationen für die Überbeanspruchung des Laufwerks abzurufen und festzulegen CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO

Hier ist ein Implementierungsbeispiel, das die Konfigurationen für die übermäßige Nutzung von Ressourcen aktualisiert:

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 übermäßige Nutzung ihrer Ressourcen überwachen

Anbieter- und Drittanbieter-Apps können appspezifische Ressourcen erfassen zu viele Benachrichtigungen von Watchdog verwenden oder CarWatchdogManager für die App abfragen Statistiken zu Überlastung bestimmter Ressourcen für die letzten 30 Tage angezeigt werden.

Auf Benachrichtigungen über übermäßige Ressourcennutzung warten

Apps können einen Ressourcenüberlastungs-Listener implementieren und den Listener mit CarWatchdogManager, um app-spezifische Benachrichtigungen zu erhalten, 80% oder 100% ihrer Laufwerk-E/A-Grenzwerte überschreiten. Apps können Folgendes verwenden: diese Benachrichtigungen an:

  • Protokollieren Sie die Statistiken zu Laufwerk-E/A-Überlastungen für die Offlineanalyse. App-Kampagnen Entwickler können diese Protokollierung nutzen, um das Problem mit der Laufwerk-E/A-Überlastung zu beheben.
  • Reduzieren Sie die E/A-Schreibvorgänge auf dem Laufwerk, bis die Übernutzungszähler zurückgesetzt werden.

Java-Client

  1. Implementieren Sie einen Listener durch Übernahme von CarWatchdogManager.ResourceOveruseListener: 
    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()
            }
      }
}
  2. Registrieren Sie die Listener-Instanz durch den Aufruf von CarWatchdogManager.addResourceOveruseListener 
    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);
}
  3. Heben Sie die Registrierung der Listener-Instanz auf, wenn die App Folgendes erfasst hat: 
    private void removeResourceOveruseListener() {
    CarWatchdogManager manager =
            (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);
    mCarWatchdogManager.removeResourceOveruseListener(
          mListenerImpl);
}

Nativer Client

  1. carwatchdog_aidl_interface-ndk_platform einschließen in shared_libs-Abhängigkeit der Build-Regel.

    Android.bp

    cc_binary {
    name: "sample_native_client",
    srcs: [
        "src/*.cpp"
    ],
    shared_libs: [
        "carwatchdog_aidl_interface-ndk_platform",
        "libbinder_ndk",
    ],
    vendor: true,
}
  2. SELinux-Richtlinie hinzufügen, um der Domain des Anbieterdienstes die Verwendung von Binder zu ermöglichen (binder_user-Makro) und fügen Sie die Anbieterdienst-Domain zum carwatchdog-Clientdomain (carwatchdog_client_domain macro). Unten findest du den Code für sample_client.te und file_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
  3. Listener für Ressourcenüberlastung durch Übernehmen von BnResourceOveruseListener Überschreiben BnResourceOveruseListener::onOveruse für den Umgang mit übermäßiger Ressourcennutzung Benachrichtigungen.

    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();
}
  4. Binder-Thread-Pool starten und Listener für Übernutzung der Ressource registrieren mit dem Watchdog-Server. Watchdog-Server ist unter dem Dienstnamen registriert android.automotive.watchdog.ICarWatchdog/default

    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 zu übermäßiger Nutzung von Ressourcen abfragen

Apps können CarWatchdogManager hinsichtlich der app-spezifischen E/A-Überbeanspruchung abfragen Statistik ATS der letzten 30 Tage.

Java-Client

Nutzen Sie CarWatchdogManager.getResourceOveruseStats, um die Statistik zur Überlastung von Ressourcen. Übergeben Sie die CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO Flag, um die E/A-Überlastungsstatistiken des Laufwerks 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

Nutzen Sie CarWatchdogServer.getResourceOveruseStats, um die Statistik zur Überlastung von Ressourcen. Übergeben Sie die Aufzählung ResourceType.IO, um die Überbeanspruchung des Laufwerks-E/A abzurufen Statistiken.

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
      }
}

Zu viele Ressourcen

In den folgenden Abschnitten wird die Nutzererfahrung bei übermäßiger Nutzung von Ressourcen beschrieben.

Einstellung „App-Leistung priorisieren“

Die Seite Einstellungen der App enthält Einstellungen fürPrioritize app performance (siehe Abbildung unten), mit denen Nutzer die Leistung einer App gegenüber dem System priorisieren können. und langfristigen Hardwareleistung. Diese Einstellung ist nur für Apps verfügbar, die sicher sind bei Überbeanspruchung der Ressource beendet werden. Andernfalls ist diese Einstellung deaktiviert. Wenn diese Einstellung deaktiviert (Standardeinstellung) für eine App deaktiviert ist, kann sie bei übermäßiger Ressourcennutzung beendet werden. Andernfalls wird die App nicht bei übermäßiger Ressourcennutzung beendet.

Wenn der Nutzer diese Einstellung aktiviert, wird im folgenden Bestätigungsdialogfeld Auswirkungen auf die Einstellung:

Nach 90 Tagen wird diese Einstellung automatisch auf die Standardeinstellung zurückgesetzt. Das Tageslimit kann mit einer RRO-Overlay-App unter Verwendung von watchdogUserPackageSettingsResetDays geändert maximal 180 Tage. Weitere Informationen finden Sie unter Den Wert der Ressourcen einer App während der Laufzeit ändern Die folgendes 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, die sich auf die Leistung auswirken

Die Einstellungen enthält den Bereich Apps, die sich auf die Leistung auswirken. (siehe Abbildung 1). Beim Antippen eine Liste von Apps, die aufgrund des Flash-Speichers eingeschränkt wurden und die Systemleistung beeinträchtigen. Dies folgt CDD 3.5.1-Anforderung [C-1-1]

Apps mit Einfluss auf die Systemleistung

Abbildung 1: Apps, die sich auf die Leistung auswirken

Anwendungen, die aufgrund von Ressourcenüberlastung beendet wurden, sind hier aufgeführt (siehe Abbildung 2). Die aufgeführten Apps dürfen zu priorisieren. Weitere Informationen finden Sie unter Priorisiere die App-Leistung.

Liste der Anwendungen, die aufgrund von Ressourcenüberlastung beendet wurden

Abbildung 2: Liste der Anwendungen, die aufgrund einer übermäßigen Ressourcennutzung beendet wurden.

Nutzerbenachrichtigung

Wenn eine App oder ein Dienst wiederholt Laufwerks-E/A-Vorgänge (z. B. Schreibvorgänge Daten innerhalb eines bestimmten Zeitraums auf der Festplatte über die definierten Schwellenwerte hinaus bei übermäßiger Ressourcennutzung beendet wird, wird der Nutzer benachrichtigt, sobald das Fahrzeug den Status „allow-driver-distraction“.

Die erste Nutzerbenachrichtigung (während der Fahrt) wird als Vorwarnung gepostet. Benachrichtigung und die anderen Benachrichtigungen werden in der Benachrichtigung gepostet. in der Mitte.

Wenn eine App beispielsweise wiederholt Laufwerks-E/A übermäßig beansprucht, erhält der Nutzer den Fehlercode folgende Benachrichtigung:

  • Wenn der Nutzer auf die Schaltfläche App priorisieren klickt, wird das Symbol App-Einstellungsseite gestartet, auf der Nutzende die Einstellung App-Leistung priorisieren:
  • Wenn der Nutzer auf die Schaltfläche App deaktivieren klickt, wird die App ist deaktiviert, bis der Nutzer die App startet oder im auf der Seite „Einstellungen“.
  • Bei deinstallierten Apps ist die Schaltfläche App deaktivieren durch die Schaltfläche App deinstallieren ersetzt. Wenn Nutzende auf die App deinstallieren, wird die Seite mit den Einstellungen der App geöffnet. über die der Nutzer die App deinstallieren kann.

Empfehlung für die Launcher-Implementierung

Wenn Apps aufgrund einer Überlastung von Ressourcen deaktiviert werden, sind sie nicht mehr auf der Standard-Launcher-App, da CarService die aktiviert als PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED OEMs müssen die integrierte Launcher-Implementierung aktualisieren, um diese Apps als ungewöhnlich, damit Nutzende sie bei Bedarf verwenden können. Beachten Sie die folgenden Empfehlungen, die auf dem Build-Release basieren.

Android SC V2 Release