Watchdog überwacht den Zustand der Anbieterdienste und des VHAL-Dienstes und beendet alle fehlerhaften Prozesse. Wenn ein fehlerhafter Prozess beendet wird, speichert der Watchdog den Prozessstatus wie bei anderen ANR-Dumps (Application Not Responding) nach /data/anr
. Dies erleichtert den Debugging-Prozess.
Überwachung des Zustands des Anbieterservices
Anbieterdienste werden sowohl auf nativer als auch auf Java-Seite überwacht. Damit ein Anbieterdienst überwacht werden kann, muss der Dienst einen Integritätsprüfungsprozess beim Watchdog registrieren, indem er ein vordefiniertes Zeitlimit angibt. Watchdog überwacht den Zustand eines registrierten Zustandsprüfungsprozesses, indem er ihn in einem Intervall anpingt, das dem bei der Registrierung angegebenen Zeitlimit entspricht. Wenn ein gepingter Prozess nicht innerhalb des Timeouts antwortet, gilt der Prozess als fehlerhaft.
Überwachung des nativen Dienstzustands
Geben Sie das Watchdog-AIDL-Makefile an
- Fügen Sie
carwatchdog_aidl_interface-ndk_platform
inshared_libs
ein.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
- Um eine SELinux-Richtlinie hinzuzufügen, erlauben Sie der Anbieterdienstdomäne die Verwendung von Binder (Makro
binder_use
) und fügen Sie die Anbieterdienstdomäne zurcarwatchdog
Clientdomäne hinzu (Makrocarwatchdog_client_domain
). Sehen Sie sich den Code unten fürsample_client.te
undfile_contexts
an: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 Client-Klasse, indem Sie BnCarWatchdogClient erben
- Führen Sie in
checkIfAlive
eine Integritätsprüfung durch. Eine Möglichkeit besteht darin, im Thread-Loop-Handler zu posten. Wenn es fehlerfrei ist, rufen SieICarWatchdog::tellClientAlive
auf. Sehen Sie sich den folgenden Code fürSampleNativeClient.h
undSampleNativeClient.cpp
an: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 Name der Auto-Watchdog-Daemon-Schnittstelle lautet android.automotive.watchdog.ICarWatchdog/default
.
- Suchen Sie nach dem Daemon mit dem Namen und rufen Sie
ICarWatchdog::registerClient
auf. Sehen Sie sich den folgenden Code fürmain.cpp
undSampleNativeClient.cpp
an: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); }
Überwachung des Java-Dienstzustands
Implementieren Sie einen Client, indem Sie CarWatchdogClientCallback erben
- 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
- Rufen Sie
CarWatchdogManager.registerClient()
auf: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); }
Melden Sie den Client ab
- 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-Gesundheitsüberwachung
Im Gegensatz zur Überwachung des Zustands des Anbieterdienstes überwacht Watchdog den Zustand des VHAL-Dienstes durch Abonnieren der Fahrzeugeigenschaft VHAL_HEARTBEAT
. Watchdog erwartet, dass der Wert dieser Eigenschaft 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 je nach Anbieter variieren. Verwenden Sie die folgenden Codebeispiele als Referenz.
- Registrieren Sie die Fahrzeugeigenschaft
VHAL_HEARTBEAT
.Registrieren Sie beim Starten des VHAL-Dienstes die Fahrzeugeigenschaft
VHAL_HEARTBEAT
. Im folgenden Beispiel wird eineunordered_map
verwendet, die die Eigenschafts-ID der Konfiguration zuordnet, um alle unterstützten Konfigurationen zu speichern. Die Konfiguration fürVHAL_HEARTBEAT
wird der Karte hinzugefügt, sodass bei einer AbfrageVHAL_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; }
- Fahrzeugeigenschaft
VHAL_HEARTBEAT
aktualisieren.Aktualisieren Sie die Fahrzeugeigenschaft
VHAL_HEARTBEAT
basierend auf der Häufigkeit der VHAL-Integritätsprüfungen (erläutert unter Definieren der Häufigkeit der VHAL-Integritätsprüfungen ) einmal alle N Sekunden. Eine Möglichkeit, dies zu tun, besteht darin, mit demRecurrentTimer
die Aktion aufzurufen, die die VHAL-Integritätsprüfung überprüft Aktualisiert die FahrzeugeigenschaftVHAL_HEARTBEAT
innerhalb einer Zeitüberschreitung.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)); } }
- ( Optional ) Definieren Sie die Häufigkeit der VHAL-Integritätsprüfung.
Die schreibgeschützte Produkteigenschaft
ro.carwatchdog.vhal_healthcheck.interval
von Watchdog definiert die Häufigkeit der VHAL-Gesundheitsprüfungen. Die Standardhäufigkeit der Integritätsprüfung (wenn diese Eigenschaft nicht definiert ist) beträgt drei Sekunden. Wenn drei Sekunden nicht ausreichen, damit der VHAL-Dienst die FahrzeugeigenschaftVHAL_HEARTBEAT
aktualisiert, definieren Sie die Häufigkeit der VHAL-Zustandsprüfung abhängig von der Reaktionsfähigkeit des Dienstes.
Debuggen Sie fehlerhafte Prozesse, die vom Watchdog beendet wurden
Watchdog speichert den Prozessstatus 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.
- 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 beim Beenden des registrierten KitchenSink-Prozesses eine Zeile wie die folgende Zeile.
05-01 09:50:19.683 578 5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
- Um die Grundursache für die Nichtreaktion zu ermitteln, verwenden Sie den unter
/data/anr
gespeicherten Prozessspeicherauszug, genau wie Sie ihn für Aktivitäts-ANR-Fälle verwenden würden. Um die Dump-Datei für den beendeten Prozess abzurufen, verwenden Sie die folgenden Befehle.$ 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.