Überwachung der Flash-Speichernutzung

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Watchdog überwacht die Nutzung des Flash-Speichers, indem es die Gesamtmenge der Festplatten-E/A-Schreibvorgänge verfolgt, die von allen Anwendungen und Diensten durchgeführt werden, wobei die Festplatten-E/A-Statistiken pro UID verwendet werden, die vom Kernel am Speicherort „/proc/uid_io/stats“ bereitgestellt werden. Wenn eine Anwendung oder ein Dienst den Schwellenwert für die Festplatten-E/A-Überbeanspruchung überschreitet, ergreift Watchdog Maßnahmen für die Anwendung oder den Dienst. Die Schwellenwerte für Festplatten-E/A-Überbeanspruchung und die bei Überbeanspruchung durchzuführende Aktion sind in der Konfiguration für Festplatten-E/A-Überbeanspruchung vordefiniert.

Schwellenwerte für Überbeanspruchung

  • Die Schwellenwerte für die Festplatten-E/A-Überbeanspruchung werden täglich erzwungen, dh alle von einer Anwendung/einem Dienst vorgenommenen Schreibvorgänge werden seit dem Beginn des aktuellen UTC-Kalendertags aggregiert und mit den in den Überbeanspruchungskonfigurationen definierten Schwellenwerten verglichen.
  • Wenn ein Fahrzeug an einem bestimmten Tag mehrmals gestartet wird, speichert das Watchdog-Modul die Statistiken zur Festplatten-E/A-Nutzung im Flash-Speicher und aggregiert sie seit dem Beginn des aktuellen UTC-Kalendertages.

Überbeanspruchung von Aktionen

Wenn eine Anwendung wiederholt die definierten Schwellwerte für Festplatten-E/A-Überbeanspruchung überschreitet, ergreift Watchdog Maßnahmen, die in der Überbeanspruchungskonfiguration definiert sind.

  • Alle Herstelleranwendungen und -dienste gelten als kritisch für die Stabilität des Gesamtsystems, sodass sie bei einer übermäßigen Festplatten-E/A-Nutzung nicht beendet werden. Die Übernutzungskonfiguration kann jedoch eine Liste von Anbieteranwendungen und -diensten definieren, die sicher beendet werden können.
  • Alle Anwendungen von Drittanbietern können sicher beendet werden.

Wenn eine Anwendung oder ein Dienst sicher beendet werden kann, deaktiviert Watchdog die Anwendung oder den Dienst mit dem Anwendungskomponentenzustand PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED .

Überlastungskonfiguration

Die Überbeanspruchungskonfiguration enthält die Schwellenwerte und Aktionen für die Festplatten-E/A-Überbeanspruchung. Standardmäßige Überbeanspruchungskonfigurationen sind in den System- und Herstellerabbildern definiert und werden mit dem Build ausgeliefert. Anbieter können optional die Anbieterkonfiguration in das Anbieterimage aufnehmen. Wenn die Anbieterkonfiguration nicht bereitgestellt wird, wird die Systemkonfiguration auch für die Anbieteranwendungen und -dienste verwendet.

Watchdog stellt System-APIs über CarWatchdogManager , die es Anbieteranwendungen oder -diensten ermöglichen, die Anbieterkonfiguration jederzeit zu aktualisieren.

Überbeanspruchung der Konfigurationsdefinition

Die Überbeanspruchungskonfiguration wird nach Komponententyp aufgeteilt. Zum Beispiel System, Anbieter und Drittanbieter. OEMs müssen nur die Herstellerkomponentenkonfiguration aktualisieren.

Anbieterkonfiguration

Die Anbieterkonfiguration definiert die Schwellenwerte und Aktionen für die Festplatten-E/A-Überbeanspruchung für alle Anbieteranwendungen und -dienste sowie alle Karten- und Medienanwendungen. Die Konfiguration enthält die folgenden Konfigurationsfelder.

  • Vendor package prefixes . Alle in der Vendor-Partition installierten Pakete werden als Vendor-Pakete betrachtet. Zusätzlich zu diesen Paketen können Anbieter vorinstallierte Pakete als Anbieterpakete klassifizieren, indem sie die Paketpräfixe zur Konfiguration der vendor package prefixes hinzufügen. Diese Konfiguration akzeptiert keine regulären Ausdrücke.
  • Safe-to-terminate packages . Anbieter können angeben, welche Anbieterpakete sicher beendet werden können, indem sie die vollständigen Paketnamen zur safe-to-terminate packages Paketkonfiguration hinzufügen.
  • Application category mappings . Anbieter können jedes Paket (einschließlich Pakete von Drittanbietern) einer der beiden unterstützten Anwendungskategorien zuordnen – Karten- und Medienanwendungen. Diese Zuordnung erfolgt, um Karten- und Medienanwendungen höhere Schwellenwerte für die Festplatten-E/A-Überbeanspruchung bereitzustellen, da diese Anwendungen dazu neigen, mehr Daten herunterzuladen und auf die Festplatte zu schreiben als andere Anwendungstypen.
  • Component level thresholds . Definiert generische Schwellenwerte für alle Herstellerpakete (dh Pakete, die nicht durch Package specific thresholds oder Application category specific thresholds abgedeckt sind, erhalten diese Schwellenwerte). Anbieter müssen Schwellenwerte ungleich Null auf Komponentenebene definieren, wenn sie die Konfiguration für Festplatten-E/A-Überbeanspruchung definieren.
  • Package specific thresholds . Anbieter können spezielle Schwellenwerte für bestimmte Anbieterpakete definieren. Die Zuordnungen sollten die vollständigen Paketnamen enthalten. Die in dieser Konfiguration definierten Schwellenwerte haben Vorrang vor Schwellenwerten, die in anderen Konfigurationen für ein bestimmtes Paket definiert sind.
  • Application category specific thresholds . Anbieter können spezielle Schwellenwerte für bestimmte Anwendungskategorien festlegen. Die Anwendungskategorien müssen eine der unterstützten Kategorien sein – Karten- und Medienanwendungen. Die in dieser Konfiguration definierten Schwellenwerte werden mithilfe der Application category mappings bestimmten Paketen zugeordnet.
  • System-wide thresholds . Anbieter dürfen diese Konfiguration nicht angeben.

Anbieterpaketpräfixe , Safe-to-terminate packages , Schwellenwerte auf Component level thresholds und Vendor package prefixes Package specific thresholds können nur durch die Anbieterkonfiguration für Anbieteranwendungen und -dienste aktualisiert werden. Die Application category specific thresholds kann nur durch die Anbieterkonfiguration für alle Karten- und Medienanwendungen aktualisiert werden.

Die Überbeanspruchungsschwellen enthalten die Menge an Bytes, die währenddessen geschrieben werden dürfen

  • Ein Anwendungs-/Dienst-Vordergrundmodus im Vergleich zum Hintergrundmodus
  • und System-Garage-Modus.

Diese Klassifizierung ermöglicht es benutzerorientierten Vordergrundanwendungen/-diensten, mehr Daten zu schreiben als Hintergrundanwendungen/-diensten. Im Garage-Modus neigen Anwendungen und Dienste dazu, Updates herunterzuladen, sodass jeder einen höheren Schwellenwert benötigt als Anwendungen und Dienste, die in anderen Modi ausgeführt werden.

System- und Drittanbieterkonfigurationen

OEMs sollten das System und Konfigurationen von Drittanbietern nicht aktualisieren.

  • Die Systemkonfiguration definiert E/A-Übernutzungsschwellenwerte und Aktionen für Systemanwendungen und -dienste.
    • Diese Konfiguration kann auch die Application category mappings aktualisieren. Daher wird dieses Konfigurationsfeld von System- und Anbieterkonfigurationen gemeinsam genutzt.
  • Die Konfiguration von Drittanbietern definiert Schwellenwerte für alle Anwendungen von Drittanbietern. Alle Anwendungen, die nicht im System vorinstalliert sind, sind Anwendungen von Drittanbietern.
    • Alle Anwendungen von Drittanbietern erhalten dieselben Schwellenwerte (z. B. erhält keine Anwendung von Drittanbietern spezielle Schwellenwerte), mit Ausnahme von Karten- und Medienanwendungen, deren Schwellenwerte durch die Konfiguration des Anbieters definiert werden.
    • Die unten angegebenen Schwellenwerte für Festplatten-E/A-Überbeanspruchung sind die Standardschwellenwerte für Anwendungen von Drittanbietern. Diese Schwellenwerte werden mit dem Systemabbild geliefert.
      • 3GiB schreiben im Vordergrundmodus der Anwendung.
      • 2 GiB schreiben im Hintergrundmodus der Anwendung.
      • 4GiB schreiben im Systemgaragenmodus.
    • Die vorgenannten Schwellenwerte sind Basisschwellenwerte. Diese Schwellenwerte werden aktualisiert, sobald wir die Datenträger-E/A-Nutzung besser verstehen.

Überbeanspruchung des Konfigurations-XML-Formats

Die standardmäßige Anbieterkonfiguration kann ( optional ) an der Stelle /vendor/etc/automotive/watchdog/resource_overuse_configuration.xml im Build-Image platziert werden. Wenn diese Konfiguration nicht angegeben wird, wird die vom System definierte Konfiguration auch auf Anbieteranwendungen und -dienste angewendet.

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

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

Aktualisieren Sie die Überbeanspruchungskonfiguration über die CarWatchdogManager-System-APIs

Die obige XML-Konfiguration kann nur im Build-Image bereitgestellt 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.

  • Erteilen Sie dem Aufrufer die Berechtigung Car.PERMISSION_CONTROL_CAR_WATCHDOG_CONFIG .
  • Muss die vorhandenen Konfigurationen verwenden , um die neuen Konfigurationen zu aktualisieren und festzulegen. Verwenden Sie die API CarWatchdogManager.getResourceOveruseConfigurations , um die vorhandenen Konfigurationen abzurufen. Wenn vorhandene Konfigurationen nicht verwendet werden, werden alle Konfigurationen (einschließlich System- und Drittanbieterkonfigurationen) überschrieben, was nicht empfohlen wird.
  • Aktualisieren Sie die vorhandenen Konfigurationen mit den Deltaänderungen und legen Sie die neuen Konfigurationen fest. Aktualisieren Sie nicht die System- und Komponentenkonfigurationen von Drittanbietern.
  • Verwenden Sie die API CarWatchdogManager.setResourceOveruseConfigurations , um die neuen Konfigurationen festzulegen.
  • Verwenden Sie das Flag CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO , um die Festplatten-I/O-Überbelegungskonfigurationen abzurufen und festzulegen.

Eine Beispielimplementierung, die die Ressourcenübernutzungskonfigurationen aktualisiert, ist unten dargestellt.

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();
}

Anwendungen, die ihre Ressourcenübernutzung überwachen

Anwendungen von Anbietern und Drittanbietern können von Watchdog auf App-spezifische Ressourcenübernutzungsbenachrichtigungen warten oder CarWatchdogManager nach den App-spezifischen Ressourcenübernutzungsstatistiken für die letzten 30 Tage abfragen.

Hören Sie auf Benachrichtigungen über Ressourcenüberbeanspruchung

Anwendungen können einen Ressourcenüberlastungs-Listener implementieren und den Listener bei CarWatchdogManager registrieren, um anwendungsspezifische Benachrichtigungen zu erhalten, wenn sie 80 % oder 100 % ihrer Festplatten-E/A-Übernutzungsschwellenwerte überschreiten. Anwendungen können diese Benachrichtigungen verwenden, um:

  • Protokollieren Sie die Statistiken zur Festplatten-E/A-Überbeanspruchung für die Offline-Analyse. Anwendungsentwickler können diese Protokollierung verwenden, um das Problem der Festplatten-E/A-Überbeanspruchung zu debuggen.
  • Reduzieren Sie die Festplatten-E/A-Schreibvorgänge, bis die Überbelegungszähler zurückgesetzt werden.

Java-Client

  1. Implementieren Sie den Listener, indem 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()
                }
          }
    }
    
    erben
  2. Registrieren Sie die Listener-Instanz, indem 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);
    }
    
    aufrufen
  3. Heben Sie die Registrierung der Listener-Instanz auf, wenn die Anwendung das Abhören beendet hat:
    private void removeResourceOveruseListener() {
        CarWatchdogManager manager =
                (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);
        mCarWatchdogManager.removeResourceOveruseListener(
              mListenerImpl);
    }
    

Nativer Client

  1. carwatchdog_aidl_interface-ndk_platform in die shared_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,
    }
    
  2. Fügen Sie die SELinux-Richtlinie hinzu, um der Dienstdomäne des Anbieters die Verwendung von Binder (Makro binder_user ) zu erlauben, und fügen Sie die Dienstdomäne des Anbieters der Client-Domäne carwatchdog (carwatchdog_client_domain macro) . Siehe den folgenden 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. Implementieren Sie den Ressourcenübernutzungs-Listener, indem BnResourceOveruseListener erben. BnResourceOveruseListener::onOveruse , um Benachrichtigungen über Ressourcenüberbeanspruchung zu verarbeiten.

    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. Starten Sie einen Binder-Thread-Pool und registrieren Sie den Ressourcenüberlastungs-Listener beim Watchdog-Server. Der Watchdog-Server ist unter dem 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 Überbeanspruchung von Ressourcen abfragen

Anwendungen können CarWatchdogManager nach den anwendungsspezifischen E/A-Übernutzungsstatistiken ATS für die letzten 30 Tage abfragen.

Java-Client

Verwenden Sie CarWatchdogManager.getResourceOveruseStats , um die Statistiken zur Ressourcenübernutzung abzurufen. Übergeben Sie das Flag CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO , um die Statistiken zur Festplatten-E/A-Überbeanspruchung 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übernutzung abzurufen. Übergeben Sie die Aufzählung ResourceType.IO , um die Statistiken zur Festplatten-E/A-Überbeanspruchung 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
      }
}

Ressourcenübernutzung UX

Priorisieren Sie die App-Leistungseinstellung

Die Seite „Anwendungseinstellungen“ verfügt über die Einstellungen „ Prioritize app performance priorisieren“ (siehe Abbildung unten), die es dem Benutzer ermöglichen, die Leistung einer Anwendung gegenüber der System- und langfristigen Hardwareleistung zu priorisieren. Diese Einstellung ist nur für Anwendungen verfügbar, die sicher bei Ressourcenüberlastung beendet werden können. Andernfalls ist diese Einstellung ausgegraut. Wenn diese Einstellung für eine Anwendung deaktiviert ist (Standardeinstellung), kann die Anwendung bei Ressourcenüberlastung beendet werden. Andernfalls wird die Anwendung bei Ressourcenüberlastung nicht beendet.

Wenn der Benutzer diese Einstellung umschaltet, beschreibt der folgende Bestätigungsdialog die Auswirkungen des Umschaltens auf die Einstellung.

Benutzerbenachrichtigung

Wenn eine Anwendung oder ein Dienst innerhalb eines bestimmten Zeitraums wiederholt Festplatten-E/A überbeansprucht (z. B. Daten über die definierten Schwellenwerte hinaus auf die Festplatte schreibt) und bei Ressourcenüberlastung sicher beendet werden kann, wird der Benutzer benachrichtigt, nachdem das Fahrzeug in den Zulassungstreiber eintritt -Ablenkungszustand.

Die erste Benutzerbenachrichtigung (während einer Fahrt) wird als Heads-up-Benachrichtigung gepostet und die anderen Benachrichtigungen werden im Benachrichtigungszentrum gepostet.

Wenn eine App beispielsweise wiederholt Festplatten-E/A überbeansprucht, erhält der Benutzer die folgende Benachrichtigung:

  • Wenn der Benutzer auf die Schaltfläche „ App priorisieren“ klickt, wird die Einstellungsseite der Anwendung gestartet, auf der der Benutzer die Einstellung „ App-Leistung priorisieren“ aktivieren oder deaktivieren kann.
  • Wenn der Benutzer auf die Schaltfläche App deaktivieren klickt, wird die Anwendung deaktiviert, bis der Benutzer die App startet oder sie auf der Einstellungsseite der Anwendung aktiviert.
  • Bei deinstallierbaren Anwendungen wird die Schaltfläche „App deaktivieren“ durch die Schaltfläche „ App deinstallieren“ ersetzt. Wenn der Benutzer auf die Schaltfläche „ App deinstallieren“ klickt, wird die Seite „Einstellungen“ der Anwendung gestartet, auf der der Benutzer die App deinstallieren kann.

Empfehlung für die Launcher-Implementierung

Wenn Anwendungen aufgrund von Ressourcenüberbeanspruchung deaktiviert werden, verschwinden die Anwendungen aus der Standard-Launcher-App, da CarService den aktivierten Status der Anwendungen als PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED . OEMs müssen die integrierte Launcher-Implementierung aktualisieren, um diese Anwendungen als ungewöhnlich anzuzeigen, damit Benutzer sie bei Bedarf verwenden können. Beachten Sie die folgenden Empfehlungen basierend auf der Build-Version.

Android SC V2-Version