Überwachen Sie die Flash-Speichernutzung

Watchdog überwacht die Flash-Speichernutzung, indem es die Gesamtmenge der von allen Apps 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 App oder ein Dienst den Schwellenwert für die Festplatten-E/A-Überbeanspruchung überschreitet, ergreift Watchdog Maßnahmen für die App 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 erzwungen, d. h. alle von einer App/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 App wiederholt die definierten Schwellenwerte für die Festplatten-E/A-Überbeanspruchung überschreitet, ergreift Watchdog Maßnahmen, die in der Überbeanspruchungskonfiguration definiert sind.

  • Alle Apps 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 Anbieter-Apps und -Dienste definieren.
  • Alle Apps von Drittanbietern können sicher beendet werden.

Wenn eine App oder ein Dienst sicher beendet werden kann, deaktiviert Watchdog die App oder den Dienst mit dem App-Komponentenstatus 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 Anbieter-Apps und -Dienste verwendet.

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

Überbeanspruchung der Konfigurationsdefinition

Die Überbeanspruchungskonfiguration wird nach Komponententyp aufgeteilt, z. B. 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 Anbieter-Apps und -Dienste sowie alle Karten- und Medien-Apps. 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 App-Kategorien zuordnen – Karten- und Medien-Apps. Diese Zuordnung wird durchgeführt, um Karten- und Medien-Apps höhere Schwellenwerte für die Festplatten-E/A-Überbeanspruchung bereitzustellen, da diese Apps tendenziell mehr Daten herunterladen und auf die Festplatte schreiben als andere App-Typen.
  • 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 Schwellenwerte auf Komponentenebene ungleich Null definieren, wenn sie die Konfiguration für die 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 App-Kategorien festlegen. Die App-Kategorien müssen eine der unterstützten Kategorien sein – Karten- und Medien-Apps. Die in dieser Konfiguration definierten Schwellenwerte werden mithilfe von 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 Anbieter-Apps und -Dienste aktualisiert werden. Die Konfiguration Application category specific thresholds kann nur durch die Herstellerkonfiguration für alle Karten und Medien-Apps aktualisiert werden.

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

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

Durch diese Klassifizierung können benutzerorientierte Vordergrund-Apps/Dienste mehr Daten schreiben als Hintergrund-Apps/Dienste. Im Garage-Modus laden Apps und Dienste in der Regel Updates herunter, daher ist jeweils ein höherer Schwellenwert erforderlich als für Apps 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 System-Apps und -Dienste.
    • Diese Konfiguration kann auch die Application category mappings aktualisieren. Daher wird dieses Konfigurationsfeld zwischen System- und Anbieterkonfigurationen gemeinsam genutzt.
  • Die Drittanbieterkonfiguration definiert Schwellenwerte für alle Drittanbieter-Apps. Bei allen Apps, die nicht im System vorinstalliert sind, handelt es sich um Apps von Drittanbietern.
    • Alle Drittanbieter-Apps erhalten dieselben Schwellenwerte (z. B. erhält keine Drittanbieter-App spezielle Schwellenwerte), mit Ausnahme von Karten- und Medien-Apps, deren Schwellenwerte durch die Anbieterkonfiguration definiert werden.
    • Die unten aufgeführten Schwellenwerte für die Festplatten-E/A-Überbeanspruchung sind die Standardschwellenwerte für Drittanbieter-Apps. Diese Schwellenwerte werden mit dem System-Image geliefert.
      • 3 GiB schreiben im App-Vordergrundmodus.
      • 2 GiB schreiben im App-Hintergrundmodus.
      • 4 GiB schreiben im System-Garage-Modus.
    • Dies sind Basisschwellenwerte. Diese Schwellenwerte werden aktualisiert, da wir die Festplatten-E/A-Nutzung besser verstehen.

Überbeanspruchung des Konfigurations-XML-Formats

Die Standardkonfiguration des Anbieters kann (dies ist optional ) am Speicherort /vendor/etc/automotive/watchdog/resource_overuse_configuration.xml im Build-Image 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 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 Konfigurationen des Systems und der Komponenten von Drittanbietern.
  • 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 .

Hier ist eine Beispielimplementierung, 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();
}

Apps überwachen ihre Ressourcenüberbeanspruchung

Anbieter- und Drittanbieter-Apps 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

Apps können einen Ressourcenüberlastungs-Listener implementieren und den Listener bei CarWatchdogManager registrieren, um app-spezifische Benachrichtigungen zu erhalten, wenn sie 80 % oder 100 % ihrer Schwellenwerte für die Festplatten-E/A-Übernutzung überschreiten. Apps können diese Benachrichtigungen verwenden, um:

  • Protokollieren Sie die Statistiken zur Festplatten-E/A-Überbeanspruchung für die Offline-Analyse. App-Entwickler 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 App mit dem Abhören von
    private void removeResourceOveruseListener() {
    CarWatchdogManager manager =
            (CarWatchdogManager) car.getCarManager(Car.CAR_WATCHDOG_SERVICE);
    mCarWatchdogManager.removeResourceOveruseListener(
          mListenerImpl);
}
    fertig ist

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

Apps können CarWatchdogManager nach der App-spezifischen 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 „App-Einstellungen“ verfügt über die Einstellungen Prioritize app performance (siehe Abbildung unten), mit denen der Benutzer die Leistung einer App gegenüber dem System und der langfristigen Hardwareleistung priorisieren kann. Diese Einstellung ist nur für Apps verfügbar, die bei Ressourcenüberbeanspruchung sicher beendet werden können. Andernfalls ist diese Einstellung ausgegraut. Wenn diese Einstellung für eine App deaktiviert ist (Standardeinstellung), kann die App bei Ressourcenüberbeanspruchung beendet werden. Andernfalls wird die App 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 App 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 App 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 App deaktiviert, bis der Benutzer die App startet oder sie auf der Einstellungsseite der App aktiviert.
  • Bei deinstallierbaren Apps 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 App geöffnet, von der aus der Benutzer die App deinstallieren kann.

Empfehlung für die Launcher-Implementierung

Wenn Apps aufgrund einer Ressourcenüberbeanspruchung deaktiviert werden, verschwinden die Apps aus der Standard-Launcher-App, da CarService den aktivierten Status der Apps als PackageManager.COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED aktualisiert. OEMs müssen die integrierte Launcher-Implementierung aktualisieren, um diese Apps 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