Überwachung des Systemzustands,Überwachung des Systemzustands

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

Watchdog überwacht den Zustand der Anbieterdienste und des VHAL-Dienstes und beendet alle fehlerhaften Prozesse. Wenn ein fehlerhafter Prozess beendet wird, gibt der Watchdog den Prozessstatus an /data/anr , wie bei anderen ANR-Dumps (Application Not Responding). Dies erleichtert den Debugging-Prozess.

Zustandsüberwachung des Anbieterdienstes

Anbieterdienste werden sowohl auf der nativen als auch auf der Java-Seite überwacht. Damit ein Anbieterdienst überwacht werden kann, muss der Dienst einen Zustandsprüfungsprozess beim Watchdog registrieren, indem er ein vordefiniertes Timeout angibt. Watchdog überwacht den Zustand eines registrierten Zustandsprüfungsprozesses, indem es ihn in einem Intervall relativ zu dem bei der Registrierung angegebenen Timeout pingt. Wenn ein gepingter Prozess nicht innerhalb des Timeouts antwortet, gilt der Prozess als fehlerhaft.

Zustandsüberwachung des nativen Dienstes

Geben Sie das Watchdog-AIDL-Makefile an

  1. carwatchdog_aidl_interface-ndk_platform in shared_libs auf.

    Android.bp

    cc_binary {
    name: "sample_native_client",
    srcs: [
        "src/*.cpp"
    ],
    shared_libs: [
        "carwatchdog_aidl_interface-ndk_platform",
        "libbinder_ndk",
    ],
    vendor: true,
}

Fügen Sie eine SELinux-Richtlinie hinzu

  1. Um eine SELinux-Richtlinie hinzuzufügen, erlauben Sie der Dienstdomäne des Anbieters die Verwendung von Binder (Makro binder_use ) und fügen Sie die Dienstdomäne des Anbieters zur carwatchdog carwatchdog hinzu (Makro carwatchdog_client_domain ). 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

Implementieren Sie eine Clientklasse, indem Sie BnCarWatchdogClient erben

  1. Führen Sie in checkIfAlive eine Zustandsprüfung durch. Eine Option besteht darin, an den Thread-Loop-Handler zu senden. Wenn fehlerfrei, rufen ICarWatchdog::tellClientAlive . Siehe den folgenden Code für SampleNativeClient.h und SampleNativeClient.cpp :

    SampleNativeClient.h

    class SampleNativeClient : public BnCarWatchdogClient {
public:
    ndk::ScopedAStatus checkIfAlive(int32_t sessionId, TimeoutLength
        timeout) override;
    ndk::ScopedAStatus prepareProcessTermination() override;
    void initialize();

private:
    void respondToDaemon();
private:
    ::android::sp<::android::Looper> mHandlerLooper;
    std::shared_ptr<ICarWatchdog> mWatchdogServer;
    std::shared_ptr<ICarWatchdogClient> mClient;
    int32_t mSessionId;
};

    SampleNativeClient.cpp

    ndk::ScopedAStatus WatchdogClient::checkIfAlive(int32_t sessionId, TimeoutLength timeout) {
    mHandlerLooper->removeMessages(mMessageHandler,
        WHAT_CHECK_ALIVE);
    mSessionId = sessionId;
    mHandlerLooper->sendMessage(mMessageHandler,
        Message(WHAT_CHECK_ALIVE));
    return ndk::ScopedAStatus::ok();
}
// WHAT_CHECK_ALIVE triggers respondToDaemon from thread handler
void WatchdogClient::respondToDaemon() {
  // your health checking method here
  ndk::ScopedAStatus status = mWatchdogServer->tellClientAlive(mClient,
        mSessionId);
}

Starten Sie einen Binder-Thread und registrieren Sie den Client

Der Schnittstellenname des Auto-Watchdog-Daemons lautet android.automotive.watchdog.ICarWatchdog/default .

  1. Suchen Sie nach dem Daemon mit dem Namen und rufen ICarWatchdog::registerClient . Siehe den folgenden Code für main.cpp und SampleNativeClient.cpp :

    main.cpp

    int main(int argc, char** argv) {
    sp<Looper> looper(Looper::prepare(/*opts=*/0));

    ABinderProcess_setThreadPoolMaxThreadCount(1);
    ABinderProcess_startThreadPool();
    std::shared_ptr<SampleNativeClient> client =
        ndk::SharedRefBase::make<SampleNatvieClient>(looper);

    // The client is registered in initialize()
    client->initialize();
    ...
}

    SampleNativeClient.cpp

    void SampleNativeClient::initialize() {
    ndk::SpAIBinder binder(AServiceManager_getService(
        "android.automotive.watchdog.ICarWatchdog/default"));
    std::shared_ptr<ICarWatchdog> server =
        ICarWatchdog::fromBinder(binder);
    mWatchdogServer = server;
    ndk::SpAIBinder binder = this->asBinder();
    std::shared_ptr<ICarWatchdogClient> client =
        ICarWatchdogClient::fromBinder(binder)
    mClient = client;
    server->registerClient(client, TimeoutLength::TIMEOUT_NORMAL);
}

Zustandsüberwachung von Java-Diensten

Implementieren Sie einen Client, indem Sie CarWatchdogClientCallback erben

  1. Bearbeiten Sie die neue Datei wie folgt:
    private final CarWatchdogClientCallback mClientCallback = new CarWatchdogClientCallback() {
    @Override
    public boolean onCheckHealthStatus(int sessionId, int timeout) {
        // Your health check logic here
        // Returning true implies the client is healthy
        // If false is returned, the client should call
        // CarWatchdogManager.tellClientAlive after health check is
        // completed
    }

    @Override
    public void onPrepareProcessTermination() {}
};

Registrieren Sie den Kunden

  1. Rufen Sie CarWatchdogManager.registerClient() :
    private void startClient() {
    CarWatchdogManager manager =
        (CarWatchdogManager) car.getCarManager(
        Car.CAR_WATCHDOG_SERVICE);
    // Choose a proper executor according to your health check method
    ExecutorService executor = Executors.newFixedThreadPool(1);
    manager.registerClient(executor, mClientCallback,
        CarWatchdogManager.TIMEOUT_NORMAL);
}

Registrierung des Clients aufheben

  1. Rufen Sie CarWatchdogManager.unregisterClient() auf, wenn der Dienst beendet ist:
    private void finishClient() {
    CarWatchdogManager manager =
        (CarWatchdogManager) car.getCarManager(
        Car.CAR_WATCHDOG_SERVICE);
    manager.unregisterClient(mClientCallback);
}

VHAL-Zustandsüberwachung

Im Gegensatz zur Zustandsüberwachung des Anbieterdienstes überwacht Watchdog den Zustand des VHAL-Dienstes, indem es die Fahrzeugeigenschaft VHAL_HEARTBEAT abonniert. Watchdog erwartet, dass der Wert dieser Eigenschaft einmal alle N Sekunden aktualisiert wird. Wenn der Heartbeat nicht innerhalb dieses Timeouts aktualisiert wird, beendet Watchdog den VHAL-Dienst.

Hinweis: Watchdog überwacht den Zustand des VHAL-Dienstes nur, wenn die Fahrzeugeigenschaft VHAL_HEARTBEAT vom VHAL-Dienst unterstützt wird.

Die interne VHAL-Implementierung kann von Anbieter zu Anbieter variieren. Die folgenden Codebeispiele können als Referenzen verwendet werden.

  1. Registrieren Sie die Fahrzeugeigenschaft VHAL_HEARTBEAT .

    Registrieren Sie beim Starten des VHAL-Dienstes die Fahrzeugeigenschaft VHAL_HEARTBEAT . Im folgenden Beispiel wird eine unordered_map , die die Eigenschafts-ID der Konfiguration zuordnet, verwendet, um alle unterstützten Konfigurationen aufzunehmen. Die Konfiguration für VHAL_HEARTBEAT wird der Karte hinzugefügt, sodass bei der Abfrage von VHAL_HEARTBEAT die entsprechende Konfiguration zurückgegeben wird.

    void registerVhalHeartbeatProperty() {
        const VehiclePropConfig config = {
                .prop = toInt(VehicleProperty::VHAL_HEARTBEAT),
                .access = VehiclePropertyAccess::READ,
                .changeMode = VehiclePropertyChangeMode::ON_CHANGE,
        };
       // mConfigsById is declared as std::unordered_map<int32_t, VehiclePropConfig>.
       mConfigsById[config.prop] = config;
}
  2. Fahrzeugeigenschaft VHAL_HEARTBEAT .

    Aktualisieren Sie die VHAL_HEARTBEAT -Fahrzeugeigenschaft basierend auf der VHAL-Zustandsprüfungshäufigkeit (erklärt in Definieren der Häufigkeit der VHAL-Zustandsprüfung" ) einmal alle N Sekunden. Eine Möglichkeit, dies zu tun, besteht darin, den RecurrentTimer zu verwenden, um die Aktion aufzurufen, die den VHAL-Zustand prüft und aktualisiert die Fahrzeugeigenschaft VHAL_HEARTBEAT innerhalb des Timeouts.

    Unten sehen Sie eine Beispielimplementierung mit RecurrentTimer :

    int main(int argc, char** argv) {
        RecurrentTimer recurrentTimer(updateVhalHeartbeat);
        recurrentTimer.registerRecurrentEvent(kHeartBeatIntervalNs,
                                           static_cast<int32_t>(VehicleProperty::VHAL_HEARTBEAT));
        … Run service …
        recurrentTimer.unregisterRecurrentEvent(
                static_cast<int32_t>(VehicleProperty::VHAL_HEARTBEAT));
}

void updateVhalHeartbeat(const std::vector<int32_t>& cookies) {
       for (int32_t property : cookies) {
              if (property != static_cast<int32_t>(VehicleProperty::VHAL_HEARTBEAT)) {
                     continue;
              }

              // Perform internal health checking such as retrieving a vehicle property to ensure
              // the service is responsive.
              doHealthCheck();

              // Construct the VHAL_HEARTBEAT property with system uptime.
              VehiclePropValuePool valuePool;
              VehicleHal::VehiclePropValuePtr propValuePtr = valuePool.obtainInt64(uptimeMillis());
              propValuePtr->prop = static_cast<int32_t>(VehicleProperty::VHAL_HEARTBEAT);
              propValuePtr->areaId = 0;
              propValuePtr->status = VehiclePropertyStatus::AVAILABLE;
              propValuePtr->timestamp = elapsedRealtimeNano();

              // Propagate the HAL event.
              onHalEvent(std::move(propValuePtr));
       }
}
  3. ( Optional ) Definieren Sie die Häufigkeit der VHAL-Zustandsprüfung.

    Die schreibgeschützte Produkteigenschaft ro.carwatchdog.vhal_healthcheck.interval von Watchdog definiert die Häufigkeit der VHAL-Zustandsprüfung. Die standardmäßige Integritätsprüfungshäufigkeit (wenn diese Eigenschaft nicht definiert ist) beträgt drei (3) Sekunden. Wenn drei (3) Sekunden für den VHAL-Dienst nicht ausreichen, um die Fahrzeugeigenschaft VHAL_HEARTBEAT zu aktualisieren, definieren Sie die Häufigkeit der VHAL_HEARTBEAT -Zustandsprüfung abhängig von der Reaktionsfähigkeit des Dienstes.

Debuggen Sie fehlerhafte Prozesse, die vom Watchdog beendet wurden

Watchdog gibt den Prozessstatus aus und beendet fehlerhafte Prozesse. Beim Beenden eines fehlerhaften Prozesses protokolliert Watchdog den Text carwatchdog terminated <process name> (pid:<process id>) in logcat. Diese Protokollzeile enthält Informationen über den beendeten Prozess wie den Prozessnamen und die Prozess-ID.

  1. Der Logcat kann nach dem oben genannten Text durchsucht werden, indem Sie Folgendes ausführen:
    $ adb logcat -s CarServiceHelper | fgrep "carwatchdog killed"

    Wenn die KitchenSink-App beispielsweise ein registrierter Watchdog-Client ist und nicht mehr auf Watchdog-Pings reagiert, protokolliert Watchdog eine Zeile wie die folgende, wenn der registrierte KitchenSink-Prozess beendet wird.

    05-01 09:50:19.683   578  5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
  2. Verwenden Sie zum Identifizieren der Grundursache für das Nichtreagieren den unter /data/anr gespeicherten Prozess-Dump, so wie Sie ihn für Aktivitäts-ANR-Fälle verwenden würden. Verwenden Sie die folgenden Befehle, um die Dump-Datei für den beendeten Prozess abzurufen.
    $ adb root
$ adb shell grep -Hn "pid process_pid" /data/anr/*

    Die folgende Beispielausgabe ist spezifisch für die KitchenSink-App:

    $ adb shell su root grep -Hn "pid 5574" /data/anr/*.

    /data/anr/anr_2020-05-01-09-50-18-290:3:----- pid 5574 at 2020-05-01 09:50:18 -----
/data/anr/anr_2020-05-01-09-50-18-290:285:----- Waiting Channels: pid 5574 at 2020-05-01 09:50:18 -----

    Die Dump-Datei für den beendeten KitchenSink-Prozess befindet sich unter /data/anr/anr_2020-05-01-09-50-18-290 . Beginnen Sie Ihre Analyse mit der ANR-Dump-Datei des beendeten Prozesses.

,

Watchdog überwacht den Zustand der Anbieterdienste und des VHAL-Dienstes und beendet alle fehlerhaften Prozesse. Wenn ein fehlerhafter Prozess beendet wird, gibt der Watchdog den Prozessstatus wie bei anderen ANR-Dumps (Application Not Responding) in /data/anr aus. Dies erleichtert den Debugging-Prozess.

Zustandsüberwachung des Anbieterdienstes

Anbieterdienste werden sowohl auf der nativen als auch auf der Java-Seite überwacht. Damit ein Anbieterdienst überwacht werden kann, muss der Dienst einen Zustandsprüfungsprozess beim Watchdog registrieren, indem er ein vordefiniertes Timeout angibt. Watchdog überwacht den Zustand eines registrierten Zustandsprüfungsprozesses, indem es ihn in einem Intervall relativ zu dem bei der Registrierung angegebenen Timeout pingt. Wenn ein gepingter Prozess nicht innerhalb des Timeouts antwortet, gilt der Prozess als fehlerhaft.

Zustandsüberwachung des nativen Dienstes

Geben Sie das Watchdog-AIDL-Makefile an

  1. carwatchdog_aidl_interface-ndk_platform in shared_libs auf.

    Android.bp

    cc_binary {
    name: "sample_native_client",
    srcs: [
        "src/*.cpp"
    ],
    shared_libs: [
        "carwatchdog_aidl_interface-ndk_platform",
        "libbinder_ndk",
    ],
    vendor: true,
}

Fügen Sie eine SELinux-Richtlinie hinzu

  1. Um eine SELinux-Richtlinie hinzuzufügen, erlauben Sie der Dienstdomäne des Anbieters die Verwendung von Binder (Makro binder_use ) und fügen Sie die Dienstdomäne des Anbieters zur carwatchdog carwatchdog hinzu (Makro carwatchdog_client_domain ). 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

Implementieren Sie eine Clientklasse, indem Sie BnCarWatchdogClient erben

  1. Führen Sie in checkIfAlive eine Zustandsprüfung durch. Eine Option besteht darin, an den Thread-Loop-Handler zu senden. Wenn fehlerfrei, rufen ICarWatchdog::tellClientAlive . Siehe den folgenden Code für SampleNativeClient.h und SampleNativeClient.cpp :

    SampleNativeClient.h

    class SampleNativeClient : public BnCarWatchdogClient {
public:
    ndk::ScopedAStatus checkIfAlive(int32_t sessionId, TimeoutLength
        timeout) override;
    ndk::ScopedAStatus prepareProcessTermination() override;
    void initialize();

private:
    void respondToDaemon();
private:
    ::android::sp<::android::Looper> mHandlerLooper;
    std::shared_ptr<ICarWatchdog> mWatchdogServer;
    std::shared_ptr<ICarWatchdogClient> mClient;
    int32_t mSessionId;
};

    SampleNativeClient.cpp

    ndk::ScopedAStatus WatchdogClient::checkIfAlive(int32_t sessionId, TimeoutLength timeout) {
    mHandlerLooper->removeMessages(mMessageHandler,
        WHAT_CHECK_ALIVE);
    mSessionId = sessionId;
    mHandlerLooper->sendMessage(mMessageHandler,
        Message(WHAT_CHECK_ALIVE));
    return ndk::ScopedAStatus::ok();
}
// WHAT_CHECK_ALIVE triggers respondToDaemon from thread handler
void WatchdogClient::respondToDaemon() {
  // your health checking method here
  ndk::ScopedAStatus status = mWatchdogServer->tellClientAlive(mClient,
        mSessionId);
}

Starten Sie einen Binder-Thread und registrieren Sie den Client

Der Schnittstellenname des Auto-Watchdog-Daemons lautet android.automotive.watchdog.ICarWatchdog/default .

  1. Suchen Sie nach dem Daemon mit dem Namen und rufen ICarWatchdog::registerClient . Siehe den folgenden Code für main.cpp und SampleNativeClient.cpp :

    main.cpp

    int main(int argc, char** argv) {
    sp<Looper> looper(Looper::prepare(/*opts=*/0));

    ABinderProcess_setThreadPoolMaxThreadCount(1);
    ABinderProcess_startThreadPool();
    std::shared_ptr<SampleNativeClient> client =
        ndk::SharedRefBase::make<SampleNatvieClient>(looper);

    // The client is registered in initialize()
    client->initialize();
    ...
}

    SampleNativeClient.cpp

    void SampleNativeClient::initialize() {
    ndk::SpAIBinder binder(AServiceManager_getService(
        "android.automotive.watchdog.ICarWatchdog/default"));
    std::shared_ptr<ICarWatchdog> server =
        ICarWatchdog::fromBinder(binder);
    mWatchdogServer = server;
    ndk::SpAIBinder binder = this->asBinder();
    std::shared_ptr<ICarWatchdogClient> client =
        ICarWatchdogClient::fromBinder(binder)
    mClient = client;
    server->registerClient(client, TimeoutLength::TIMEOUT_NORMAL);
}

Zustandsüberwachung von Java-Diensten

Implementieren Sie einen Client, indem Sie CarWatchdogClientCallback erben

  1. Bearbeiten Sie die neue Datei wie folgt:
    private final CarWatchdogClientCallback mClientCallback = new CarWatchdogClientCallback() {
    @Override
    public boolean onCheckHealthStatus(int sessionId, int timeout) {
        // Your health check logic here
        // Returning true implies the client is healthy
        // If false is returned, the client should call
        // CarWatchdogManager.tellClientAlive after health check is
        // completed
    }

    @Override
    public void onPrepareProcessTermination() {}
};

Registrieren Sie den Kunden

  1. Rufen Sie CarWatchdogManager.registerClient() :
    private void startClient() {
    CarWatchdogManager manager =
        (CarWatchdogManager) car.getCarManager(
        Car.CAR_WATCHDOG_SERVICE);
    // Choose a proper executor according to your health check method
    ExecutorService executor = Executors.newFixedThreadPool(1);
    manager.registerClient(executor, mClientCallback,
        CarWatchdogManager.TIMEOUT_NORMAL);
}

Registrierung des Clients aufheben

  1. Rufen Sie CarWatchdogManager.unregisterClient() auf, wenn der Dienst beendet ist:
    private void finishClient() {
    CarWatchdogManager manager =
        (CarWatchdogManager) car.getCarManager(
        Car.CAR_WATCHDOG_SERVICE);
    manager.unregisterClient(mClientCallback);
}

VHAL-Zustandsüberwachung

Im Gegensatz zur Zustandsüberwachung des Anbieterdienstes überwacht Watchdog den Zustand des VHAL-Dienstes, indem es die Fahrzeugeigenschaft VHAL_HEARTBEAT abonniert. Watchdog erwartet, dass der Wert dieser Eigenschaft einmal alle N Sekunden aktualisiert wird. Wenn der Heartbeat nicht innerhalb dieses Timeouts aktualisiert wird, beendet Watchdog den VHAL-Dienst.

Hinweis: Watchdog überwacht den Zustand des VHAL-Dienstes nur, wenn die Fahrzeugeigenschaft VHAL_HEARTBEAT vom VHAL-Dienst unterstützt wird.

Die interne VHAL-Implementierung kann von Anbieter zu Anbieter variieren. Die folgenden Codebeispiele können als Referenzen verwendet werden.

  1. Registrieren Sie die Fahrzeugeigenschaft VHAL_HEARTBEAT .

    Registrieren Sie beim Starten des VHAL-Dienstes die Fahrzeugeigenschaft VHAL_HEARTBEAT . Im folgenden Beispiel wird eine unordered_map , die die Eigenschafts-ID der Konfiguration zuordnet, verwendet, um alle unterstützten Konfigurationen aufzunehmen. Die Konfiguration für VHAL_HEARTBEAT wird der Karte hinzugefügt, sodass bei der Abfrage von VHAL_HEARTBEAT die entsprechende Konfiguration zurückgegeben wird.

    void registerVhalHeartbeatProperty() {
        const VehiclePropConfig config = {
                .prop = toInt(VehicleProperty::VHAL_HEARTBEAT),
                .access = VehiclePropertyAccess::READ,
                .changeMode = VehiclePropertyChangeMode::ON_CHANGE,
        };
       // mConfigsById is declared as std::unordered_map<int32_t, VehiclePropConfig>.
       mConfigsById[config.prop] = config;
}
  2. Fahrzeugeigenschaft VHAL_HEARTBEAT .

    Aktualisieren Sie die Fahrzeugeigenschaft VHAL_HEARTBEAT basierend auf der VHAL-Zustandsprüfungshäufigkeit (erklärt in Definieren der Häufigkeit der VHAL-Zustandsprüfung" ) einmal alle N Sekunden. Eine Möglichkeit, dies zu tun, besteht darin, den RecurrentTimer zum Aufrufen der Aktion zu verwenden, die den VHAL-Zustand prüft und aktualisiert die Fahrzeugeigenschaft VHAL_HEARTBEAT innerhalb des Timeouts.

    Unten sehen Sie eine Beispielimplementierung mit RecurrentTimer :

    int main(int argc, char** argv) {
        RecurrentTimer recurrentTimer(updateVhalHeartbeat);
        recurrentTimer.registerRecurrentEvent(kHeartBeatIntervalNs,
                                           static_cast<int32_t>(VehicleProperty::VHAL_HEARTBEAT));
        … Run service …
        recurrentTimer.unregisterRecurrentEvent(
                static_cast<int32_t>(VehicleProperty::VHAL_HEARTBEAT));
}

void updateVhalHeartbeat(const std::vector<int32_t>& cookies) {
       for (int32_t property : cookies) {
              if (property != static_cast<int32_t>(VehicleProperty::VHAL_HEARTBEAT)) {
                     continue;
              }

              // Perform internal health checking such as retrieving a vehicle property to ensure
              // the service is responsive.
              doHealthCheck();

              // Construct the VHAL_HEARTBEAT property with system uptime.
              VehiclePropValuePool valuePool;
              VehicleHal::VehiclePropValuePtr propValuePtr = valuePool.obtainInt64(uptimeMillis());
              propValuePtr->prop = static_cast<int32_t>(VehicleProperty::VHAL_HEARTBEAT);
              propValuePtr->areaId = 0;
              propValuePtr->status = VehiclePropertyStatus::AVAILABLE;
              propValuePtr->timestamp = elapsedRealtimeNano();

              // Propagate the HAL event.
              onHalEvent(std::move(propValuePtr));
       }
}
  3. ( Optional ) Definieren Sie die Häufigkeit der VHAL-Zustandsprüfung.

    Die schreibgeschützte Produkteigenschaft ro.carwatchdog.vhal_healthcheck.interval von Watchdog definiert die Häufigkeit der VHAL-Zustandsprüfung. Die standardmäßige Integritätsprüfungshäufigkeit (wenn diese Eigenschaft nicht definiert ist) beträgt drei (3) Sekunden. Wenn drei (3) Sekunden für den VHAL-Dienst nicht ausreichen, um die Fahrzeugeigenschaft VHAL_HEARTBEAT zu aktualisieren, definieren Sie die Häufigkeit der VHAL_HEARTBEAT -Zustandsprüfung abhängig von der Reaktionsfähigkeit des Dienstes.

Debuggen Sie fehlerhafte Prozesse, die vom Watchdog beendet wurden

Watchdog gibt den Prozessstatus aus und beendet fehlerhafte Prozesse. Beim Beenden eines fehlerhaften Prozesses protokolliert Watchdog den Text carwatchdog terminated <process name> (pid:<process id>) in logcat. Diese Protokollzeile enthält Informationen über den beendeten Prozess wie den Prozessnamen und die Prozess-ID.

  1. Der Logcat kann nach dem oben genannten Text durchsucht werden, indem Sie Folgendes ausführen:
    $ adb logcat -s CarServiceHelper | fgrep "carwatchdog killed"

    Wenn die KitchenSink-App beispielsweise ein registrierter Watchdog-Client ist und nicht mehr auf Watchdog-Pings reagiert, protokolliert Watchdog eine Zeile wie die folgende, wenn der registrierte KitchenSink-Prozess beendet wird.

    05-01 09:50:19.683   578  5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
  2. Verwenden Sie zum Identifizieren der Grundursache für das Nichtreagieren den unter /data/anr gespeicherten Prozess-Dump, so wie Sie ihn für Aktivitäts-ANR-Fälle verwenden würden. Verwenden Sie die folgenden Befehle, um die Dump-Datei für den beendeten Prozess abzurufen.
    $ adb root
$ adb shell grep -Hn "pid process_pid" /data/anr/*

    Die folgende Beispielausgabe ist spezifisch für die KitchenSink-App:

    $ adb shell su root grep -Hn "pid 5574" /data/anr/*.

    /data/anr/anr_2020-05-01-09-50-18-290:3:----- pid 5574 at 2020-05-01 09:50:18 -----
/data/anr/anr_2020-05-01-09-50-18-290:285:----- Waiting Channels: pid 5574 at 2020-05-01 09:50:18 -----

    Die Dump-Datei für den beendeten KitchenSink-Prozess befindet sich unter /data/anr/anr_2020-05-01-09-50-18-290 . Beginnen Sie Ihre Analyse mit der ANR-Dump-Datei des beendeten Prozesses.