Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Systemzustand überwachen

Watchdog überwacht den Zustand von Anbietendiensten und des VHAL-Dienstes und beendet alle fehlerhaften Prozesse. Wenn ein fehlerhafter Prozess beendet wird, speichert der Watchdog den Prozessstatus in /data/anr, wie bei anderen ANR-Dumps (Application Not Responding). Das erleichtert die Fehlersuche.

Monitoring des Dienststatus von Drittanbietern

Anbieterservices werden sowohl auf nativer als auch auf Java-Seite überwacht. Damit ein Anbieterservice überwacht werden kann, muss der Dienst einen Systemdiagnoseprozess beim Watchdog registrieren, indem er ein vordefiniertes Zeitlimit angibt. Watchdog überwacht den Status eines registrierten Systemdiagnoseprozesses, indem er ihn in einem Intervall anpingt, das sich auf das bei der Registrierung angegebene Zeitlimit bezieht. Wenn ein angepingter Prozess nicht innerhalb des Zeitlimits antwortet, gilt er als fehlerhaft.

Monitoring des Dienststatus

Watchdog-AIDL-Makefile angeben

Schließe carwatchdog_aidl_interface-ndk_platform in shared_libs ein.

Android.bp

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

SELinux-Richtlinie hinzufügen

Um eine SELinux-Richtlinie hinzuzufügen, muss die Anbieterdienstdomain die Verwendung von Binder (binder_use-Makro) zulassen und die Anbieterdienstdomain muss der carwatchdog-Clientdomain (carwatchdog_client_domain-Makro) hinzugefügt werden. Hier der 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
```

Clientklasse durch Vererbung von BnCarWatchdogClient implementieren

Führen Sie in checkIfAlive eine Systemdiagnose durch. Eine Möglichkeit besteht darin, an den Thread-Loop-Handler zu posten. Wenn alles in Ordnung ist, rufen Sie ICarWatchdog::tellClientAlive an. Hier der 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);
}

Binder-Konversation starten und Client registrieren

Der Name der Schnittstelle des Car Watchdog-Daemons lautet android.automotive.watchdog.ICarWatchdog/default.

Suchen Sie nach dem Daemon mit dem Namen und Aufruf ICarWatchdog::registerClient. Hier der 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);
}

Monitoring des Zustands von Java-Diensten

Client durch Ableiten von CarWatchdogClientCallback implementieren

Bearbeiten Sie die neue Datei so:

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

Client registrieren

Rufen Sie CarWatchdogManager.registerClient() an:

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

Client abmelden

Rufen Sie CarWatchdogManager.unregisterClient() auf, wenn der Dienst abgeschlossen ist:

private void finishClient() {
    CarWatchdogManager manager =
        (CarWatchdogManager) car.getCarManager(
        Car.CAR_WATCHDOG_SERVICE);
    manager.unregisterClient(mClientCallback);
}

VHAL-Statusüberwachung

Im Gegensatz zum Monitoring des Dienststatus von Anbietern überwacht Watchdog den Status des VHAL-Dienstes, indem es die VHAL_HEARTBEAT-Fahrzeugeigenschaft abonniert. Watchdog erwartet, dass der Wert dieser Eigenschaft alle N Sekunden aktualisiert wird. Wenn der Heartbeat innerhalb dieses Zeitlimits nicht aktualisiert wird, beendet Watchdog den VHAL-Dienst.

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

Die interne Implementierung von VHAL kann je nach Anbieter variieren. Verwenden Sie die folgenden Codebeispiele als Referenz.

Registrieren Sie das Attribut VHAL_HEARTBEAT.

Registrieren Sie beim Starten des VHAL-Dienstes die Fahrzeugeigenschaft VHAL_HEARTBEAT. Im folgenden Beispiel wird eine unordered_map verwendet, die die Property-ID der Konfiguration zuordnet, um alle unterstützten Konfigurationen zu speichern. Die Konfiguration für VHAL_HEARTBEAT wird der Karte hinzugefügt, sodass bei einer Anfrage für 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;
}

Aktualisieren Sie das Attribut VHAL_HEARTBEAT des Fahrzeugs.

Aktualisieren Sie die Fahrzeugeigenschaft VHAL_HEARTBEAT alle N Sekunden basierend auf der Häufigkeit der VHAL-Systemdiagnose (siehe Häufigkeit der VHAL-Systemdiagnose definieren). Eine Möglichkeit dazu ist, mit dem RecurrentTimer die Aktion aufzurufen, die den VHAL-Status prüft und die Fahrzeugeigenschaft VHAL_HEARTBEAT innerhalb des Zeitlimits aktualisiert.

Unten sehen Sie ein Beispiel für die Implementierung 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));
       }
}

Optional: Definieren Sie die Häufigkeit der VHAL-Systemdiagnose.
Die schreibgeschützte Produkteigenschaft ro.carwatchdog.vhal_healthcheck.interval von Watchdog definiert die Häufigkeit der VHAL-Systemdiagnose. Die Standardhäufigkeit für Health Checks (wenn diese Eigenschaft nicht definiert ist) beträgt drei Sekunden. Wenn drei Sekunden nicht ausreichen, damit der VHAL-Dienst die Fahrzeugeigenschaft VHAL_HEARTBEAT aktualisiert, definieren Sie die Häufigkeit der VHAL-Systemdiagnose entsprechend der Reaktionsfähigkeit des Dienstes.

Fehlerbehebung bei fehlerhaften Prozessen, die vom Watchdog beendet wurden

Watchdog speichert den Prozessstatus und beendet fehlerhafte Prozesse. Wenn Watchdog einen fehlerhaften Prozess beendet, wird der Text carwatchdog terminated <process name> (pid:<process id>) in logcat protokolliert. Diese Logzeile enthält Informationen zum beendeten Prozess, z. B. den Prozessnamen und die Prozess-ID.

Mit dem folgenden Befehl kann im Logcat nach dem oben genannten Text gesucht werden:
```
$ 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 beim Beenden des registrierten KitchenSink-Prozesses eine Zeile wie die unten stehende.
```
05-01 09:50:19.683   578  5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
```
Um die Ursache für die fehlende Reaktion zu ermitteln, verwenden Sie den Prozess-Dump, der unter /data/anr gespeichert ist, genau wie bei ANR-Fällen (Activity Not Responding). Verwenden Sie die folgenden Befehle, um die Dumpdatei für den beendeten Prozess abzurufen.
```
$ adb root
$ adb shell grep -Hn "pid process_pid" /data/anr/*
```
Die folgende Beispielausgabe bezieht sich auf 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 Dumpdatei für den beendeten KitchenSink-Prozess befindet sich unter /data/anr/anr_2020-05-01-09-50-18-290. Beginnen Sie die Analyse mit der ANR-Dump-Datei des beendeten Prozesses.

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