Überwachen Sie die Flash-Speichernutzung

Watchdog überwacht die Flash-Speichernutzung, indem es die Gesamtmenge der von allen Anwendungen und Diensten durchgeführten Festplatten-E/A-Schreibvorgänge mithilfe der vom Kernel am Speicherort „/proc/uid_io/stats“ bereitgestellten Festplatten-E/A-Statistiken pro UID überwacht. 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 die Festplatten-E/A-Überbeanspruchung und die bei Überbeanspruchung zu ergreifenden Maßnahmen sind in der Konfiguration der Festplatten-E/A-Überbeanspruchung vordefiniert.

Schwellenwerte für Überbeanspruchung

  • Die Schwellenwerte für die Festplatten-E/A-Überbeanspruchung werden täglich durchgesetzt, d. h. alle von einer Anwendung/einem Dienst durchgeführten Schreibvorgänge werden seit Beginn des aktuellen UTC-Kalendertages 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 Beginn des aktuellen UTC-Kalendertages.

Übermäßige Aktionen

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

  • Alle Anwendungen und Dienste von Anbietern gelten als entscheidend für die Gesamtsystemstabilität und werden daher nicht bei übermäßiger Festplatten-E/A-Belastung beendet. Die Überbeanspruchungskonfiguration kann jedoch eine Liste sicher zu beendender Anbieteranwendungen und -dienste definieren.
  • 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 Anwendungskomponentenstatus PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED .

Überbeanspruchte Konfiguration

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

Watchdog stellt System-APIs über CarWatchdogManager zur Verfügung, 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 Konfiguration der Anbieterkomponenten 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 gelten als Vendor-Pakete. 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 Konfiguration safe-to-terminate packages hinzufügen.
  • Application category mappings . Anbieter können jedes Paket (einschließlich Paketen von Drittanbietern) einer der beiden unterstützten Anwendungskategorien zuordnen – Karten- und Medienanwendungen. Diese Zuordnung wird durchgeführt, um Karten- und Medienanwendungen höhere Schwellenwerte für die Festplatten-E/A-Überbeanspruchung bereitzustellen, da diese Anwendungen tendenziell mehr Daten herunterladen und auf die Festplatte schreiben als andere Anwendungstypen.
  • Component level thresholds . Definiert generische Schwellenwerte für alle Anbieterpakete (d. h. Pakete, die nicht durch Package specific thresholds oder Application category specific thresholds abgedeckt sind, erhalten diese Schwellenwerte). Anbieter müssen bei der Definition der Festplatten-I/O-Überlastungskonfiguration Schwellenwerte auf Komponentenebene ungleich Null festlegen.
  • Package specific thresholds . Anbieter können spezielle Schwellenwerte für bestimmte Anbieterpakete festlegen. 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.

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

Die Überbeanspruchungsschwellenwerte enthalten die Anzahl der Bytes, die währenddessen geschrieben werden dürfen

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

Durch diese Klassifizierung können benutzerorientierte Vordergrundanwendungen/-dienste mehr Daten schreiben als Hintergrundanwendungen/-dienste. Im Garage-Modus laden Anwendungen und Dienste in der Regel Updates herunter, daher ist für jeden ein höherer Schwellenwert erforderlich als für Anwendungen und Dienste, die in anderen Modi ausgeführt werden.

System- und Drittanbieterkonfigurationen

OEMs sollten das System und die Konfigurationen von Drittanbietern nicht aktualisieren.

  • Die Systemkonfiguration definiert Schwellenwerte und Aktionen für die E/A-Überbeanspruchung für Systemanwendungen und -dienste.
    • Diese Konfiguration aktualisiert möglicherweise auch die Application category mappings . Daher wird dieses Konfigurationsfeld von System- und Anbieterkonfigurationen gemeinsam genutzt.
  • Die Drittanbieterkonfiguration definiert Schwellenwerte für alle Drittanbieteranwendungen. Bei allen Anwendungen, die nicht im System vorinstalliert sind, handelt es sich um 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 Anbieterkonfiguration definiert werden.
    • Die unten aufgeführten Schwellenwerte für die Festplatten-E/A-Überbeanspruchung sind die Standardschwellenwerte für Anwendungen von Drittanbietern. Diese Schwellenwerte werden mit dem System-Image geliefert.
      • 3GiB schreiben im Vordergrundmodus der Anwendung.
      • 2GiB schreiben im Anwendungshintergrundmodus.
      • 4GiB schreiben im System-Garage-Modus.
    • Bei den oben genannten Schwellenwerten handelt es sich um Basisschwellenwerte. Diese Schwellenwerte werden aktualisiert, sobald wir die Festplatten-E/A-Nutzung besser verstehen.

Überbeanspruchung des Konfigurations-XML-Formats

Die Standardkonfiguration des Anbieters kann ( optional ) am Speicherort /vendor/etc/automotive/watchdog/resource_overuse_configuration.xml im Build-Image platziert werden. Wenn diese Konfiguration nicht angegeben ist, 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 Konfiguration der E/A-Überbeanspruchung 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 Konfiguration auf dem Gerät nach der Veröffentlichung eines Builds aktualisieren möchte, kann er die folgenden APIs verwenden, um Änderungen an der Konfiguration auf dem Gerät vorzunehmen.

  • Erteilen Sie dem Aufrufer die Berechtigung Car.PERMISSION_CONTROL_CAR_WATCHDOG_CONFIG .
  • Zum Aktualisieren und Festlegen der neuen Konfigurationen müssen die vorhandenen Konfigurationen verwendet werden . 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 Drittanbieter-Komponentenkonfigurationen.
  • Verwenden Sie die API CarWatchdogManager.setResourceOveruseConfigurations , um die neuen Konfigurationen festzulegen.
  • Um die Festplatten-E/A-Überbeanspruchungskonfigurationen abzurufen und festzulegen, verwenden Sie das Flag CarWatchdogManager.FLAG_RESOURCE_OVERUSE_IO .

Unten ist eine Beispielimplementierung dargestellt, die die Konfigurationen zur Ressourcenüberbeanspruchung 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();
}

Anwendungen überwachen ihre Ressourcenüberbeanspruchung

Anwendungen von Anbietern und Drittanbietern können auf app-spezifische Benachrichtigungen zur Ressourcenüberbeanspruchung von Watchdog warten oder CarWatchdogManager nach den app-spezifischen Statistiken zur Ressourcenüberbeanspruchung für die letzten 30 Tage abfragen.

Achten 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 Schwellenwerte für die Festplatten-E/A-Übernutzung ü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 beheben.
  • Reduzieren Sie die E/A-Schreibvorgänge auf der Festplatte, bis die Überlastungszähler zurückgesetzt werden.

Java-Client

  1. Implementieren Sie den Listener, indem Sie CarWatchdogManager.ResourceOveruseListener erben:
    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, indem Sie 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 die Überwachung beendet hat:
    private void removeResourceOveruseListener() {
        CarWatchdogManager manager =
                (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);
        mCarWatchdogManager.removeResourceOveruseListener(
              mListenerImpl);
    }
    

Nativer Client

  1. Nehmen Sie carwatchdog_aidl_interface-ndk_platform in die shared_libs Abhängigkeit der Build-Regel auf.

    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 eine SELinux-Richtlinie hinzu, um der Anbieterdienstdomäne die Verwendung von Binder zu ermöglichen (Makro binder_user ) und fügen Sie die Anbieterdienstdomäne zur carwatchdog Clientdomäne hinzu (carwatchdog_client_domain macro) . Siehe den Code unten 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überlastungs-Listener, indem Sie BnResourceOveruseListener erben. Überschreiben Sie 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 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

Anwendungen können CarWatchdogManager nach der anwendungsspezifischen E/A-Überlastungsstatistik 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 ResourceType.IO Enumeration, um Statistiken zur Datenträger-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überbeanspruchung UX

Priorisieren Sie die App-Leistungseinstellung

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

Wenn der Benutzer diese Einstellung umschaltet, werden im folgenden Bestätigungsdialog die Auswirkungen des Umschaltens auf die Einstellung beschrieben.

Nach 90 Tagen wird diese Einstellung automatisch auf den Standardwert zurückgesetzt. Das Tageslimit kann mit einer RRO-Overlay-App mithilfe von watchdogUserPackageSettingsResetDays bis zu einem Maximum von 180 Tagen geändert werden. Weitere Informationen finden Sie unter Ändern des Werts der Ressourcen einer App zur Laufzeit . 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>

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 aufgrund einer Ressourcenüberbeanspruchung sicher beendet werden kann, wird der Benutzer benachrichtigt, nachdem das Fahrzeug den Zulassungstreiber eingegeben hat -Ablenkungszustand.

Die erste Benutzerbenachrichtigung (während einer Fahrt) wird als Heads-up-Benachrichtigung veröffentlicht und die anderen Benachrichtigungen werden im Benachrichtigungscenter veröffentlicht.

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

  • Wenn der Benutzer auf die Schaltfläche „App priorisieren“ klickt, wird die Einstellungsseite der Anwendung geöffnet, 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 geöffnet, von der aus der Benutzer die App deinstallieren kann.

Empfehlung für die Launcher-Implementierung

Wenn Anwendungen aufgrund einer 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 aktualisiert. OEMs müssen die integrierte Launcher-Implementierung aktualisieren, um diese Anwendungen als ungewöhnlich anzuzeigen, damit Benutzer sie bei Bedarf verwenden können. Sehen Sie sich die folgenden Empfehlungen basierend auf der Build-Version an.

Android SC V2-Version