Monitorowanie stanu systemu

Watchdog monitoruje stan usług dostawcy i usługi VHAL oraz zamyka każdy proces w złym stanie. Gdy proces w złym stanie zostanie zamknięty, Watchdog zapisuje stan procesu w pliku /data/anr, tak jak w przypadku innych zrzutów błędów typu „Aplikacja nie odpowiada” (ANR). Ułatwia to proces debugowania.

Monitorowanie stanu usług dostawcy

Usługi dostawcy są monitorowane zarówno po stronie natywnej, jak i po stronie Javy. Aby usługa dostawcy była monitorowana, musi zarejestrować proces sprawdzania stanu w Watchdogu, określając wstępnie zdefiniowany limit czasu. Watchdog monitoruje stan zarejestrowanego procesu sprawdzania stanu, wysyłając do niego pingi w odstępach czasu proporcjonalnych do limitu czasu określonego podczas rejestracji. Jeśli proces, do którego wysłano ping, nie odpowie w określonym limicie czasu, zostanie uznany za proces w złym stanie.

Monitorowanie stanu usługi natywnej

Określanie pliku makefile Watchdog AIDL

  1. Dodaj carwatchdog_aidl_interface-ndk_platform do shared_libs.

    Android.bp

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

Dodawanie zasady SELinux

  1. Aby dodać zasadę SELinux, zezwól domenie usługi dostawcy na używanie bindera (binder_use makro) i dodaj domenę usługi dostawcy do carwatchdog domeny klienta (carwatchdog_client_domain makro). Poniżej znajdziesz kod sample_client.te i 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

Implementowanie klasy klienta przez dziedziczenie BnCarWatchdogClient

  1. W checkIfAlive przeprowadź kontrolę stanu. Jedną z opcji jest wysłanie postu do obsługi pętli wątku. Jeśli stan jest dobry, wywołaj ICarWatchdog::tellClientAlive. Poniżej znajdziesz kod SampleNativeClient.h i 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);
    }

Uruchamianie wątku bindera i rejestrowanie klienta

Nazwa interfejsu demona watchdoga w samochodzie to android.automotive.watchdog.ICarWatchdog/default.

  1. Wyszukaj demona według nazwy i wywołaj ICarWatchdog::registerClient. Poniżej znajdziesz kod main.cpp i 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);
    }

Monitorowanie stanu usługi Java

Implementowanie klienta przez dziedziczenie CarWatchdogClientCallback

  1. Edytuj nowy plik w ten sposób:
    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() {}
    };

Rejestrowanie klienta

  1. Wywołaj 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);
    }

Wyrejestrowywanie klienta

  1. Gdy usługa zostanie zakończona, wywołaj CarWatchdogManager.unregisterClient():
    private void finishClient() {
        CarWatchdogManager manager =
            (CarWatchdogManager) car.getCarManager(
            Car.CAR_WATCHDOG_SERVICE);
        manager.unregisterClient(mClientCallback);
    }

Monitorowanie stanu VHAL

W przeciwieństwie do monitorowania stanu usług dostawcy Watchdog monitoruje stan usługi VHAL, subskrybując właściwość pojazdu VHAL_HEARTBEAT. Watchdog oczekuje, że wartość tej właściwości będzie aktualizowana raz na N sekund. Jeśli sygnał heartbeat nie zostanie zaktualizowany w tym limicie czasu, Watchdog zamknie usługę VHAL.

Uwaga: Watchdog monitoruje stan usługi VHAL tylko wtedy, gdy usługa VHAL obsługuje właściwość pojazdu VHAL_HEARTBEAT.

Wewnętrzna implementacja VHAL może się różnić w zależności od dostawcy. Użyj poniższych przykładowych kodów jako odniesienia.

  1. Zarejestruj właściwość pojazdu VHAL_HEARTBEAT.

    Podczas uruchamiania usługi VHAL zarejestruj właściwość pojazdu VHAL_HEARTBEAT. W poniższym przykładzie do przechowywania wszystkich obsługiwanych konfiguracji używana jest unordered_map, która mapuje identyfikator właściwości na konfigurację. Konfiguracja VHAL_HEARTBEAT jest dodawana do mapy, dzięki czemu po wysłaniu zapytania o VHAL_HEARTBEAT zwracana jest odpowiednia konfiguracja.

    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. Zaktualizuj właściwość pojazdu VHAL_HEARTBEAT.

    Na podstawie częstotliwości sprawdzania stanu VHAL (wyjaśnionej w Określanie częstotliwości sprawdzania stanu VHAL"), aktualizuj właściwość pojazdu VHAL_HEARTBEAT raz na N sekund. Można to zrobić na przykład za pomocą RecurrentTimer, aby wywołać działanie które sprawdza stan VHAL i aktualizuje VHAL_HEARTBEAT pojazdu właściwość w limicie czasu.

    Poniżej znajdziesz przykładową implementację z użyciem 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. (Opcjonalnie) Określ częstotliwość sprawdzania stanu VHAL.

    Częstotliwość sprawdzania stanu VHAL jest określana przez właściwość produktu tylko do odczytu ro.carwatchdog.vhal_healthcheck.interval. Domyślna częstotliwość sprawdzania stanu (gdy ta właściwość nie jest zdefiniowana) wynosi 3 sekundy. Jeśli 3 sekundy nie wystarczą, aby usługa VHAL zaktualizowała właściwość pojazdu VHAL_HEARTBEAT, określ częstotliwość sprawdzania stanu VHAL w zależności od czasu reakcji usługi.

Debugowanie procesów w złym stanie zamkniętych przez Watchdoga

Watchdog zapisuje stan procesu i zamyka procesy w złym stanie. Podczas zamykania procesu w złym stanie Watchdog zapisuje w logcat tekst carwatchdog terminated <process name> (pid:<process id>). Ten wiersz dziennika zawiera informacje o zamkniętym procesie, takie jak jego nazwa i identyfikator.

  1. Aby wyszukać w logcat wspomniany tekst, uruchom:
    $ adb logcat -s CarServiceHelper | fgrep "carwatchdog killed"

    Jeśli na przykład aplikacja KitchenSink jest zarejestrowanym klientem Watchdoga i przestanie odpowiadać na pingi Watchdoga, Watchdog zapisze w dzienniku wiersz podobny do poniższego gdy zamknie zarejestrowany proces KitchenSink.

    05-01 09:50:19.683   578  5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
  2. Aby zidentyfikować główną przyczynę braku odpowiedzi, użyj zrzutu procesu przechowywanego w /data/anr, tak jak w przypadku błędów ANR aktywności. Aby pobrać plik zrzutu zamkniętego procesu, użyj tych poleceń.
    $ adb root
    $ adb shell grep -Hn "pid process_pid" /data/anr/*

    Poniższe przykładowe dane wyjściowe dotyczą aplikacji KitchenSink:

    $ 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 -----

    Plik zrzutu zamkniętego procesu KitchenSink znajduje się w /data/anr/anr_2020-05-01-09-50-18-290. Zacznij analizę od pliku zrzutu ANR zamkniętego procesu.