システムの健全性のモニタリング

ウォッチドッグは、ベンダー サービスと VHAL サービスの健全性をモニタリングし、異常なプロセスを終了します。異常なプロセスが終了すると、ウォッチドッグは他のアプリケーション応答なし(ANR)ダンプと同様に、プロセス ステータスを /data/anr にダンプします。これにより、デバッグ プロセスが容易になります。

ベンダー サービスの健全性のモニタリング

ベンダー サービスは、ネイティブ側と Java 側の両方でモニタリングされます。ベンダー サービスをモニタリングするには、事前定義されたタイムアウトを指定して、ヘルスチェック プロセスをウォッチドッグに登録する必要があります。ウォッチドッグは、登録時に指定されたタイムアウトに対して一定の間隔でプロセスに ping を実行することで、登録されたヘルスチェック プロセスの状態をモニタリングします。ping が実行されたプロセスがタイムアウト内に応答しない場合、そのプロセスは異常とみなされます。

ネイティブ サービスの健全性のモニタリング

ウォッチドッグ AIDL の makefile を指定する

  1. carwatchdog_aidl_interface-ndk_platformshared_libs に含めます。

    Android.bp

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

SELinux ポリシーを追加する

  1. SELinux ポリシーを追加するには、ベンダー サービス ドメインにバインダー(binder_use マクロ)の使用を許可し、ベンダー サービス ドメインを carwatchdog クライアント ドメイン(carwatchdog_client_domain マクロ)に追加します。 sample_client.tefile_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

BnCarWatchdogClient を継承してクライアント クラスを実装する

  1. checkIfAlive でヘルスチェックを実行します。たとえば、スレッドループ ハンドラに投稿するなどの方法があります。正常である場合は ICarWatchdog::tellClientAlive を呼び出します。 SampleNativeClient.hSampleNativeClient.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);
    }

バインダー スレッドを開始し、クライアントを登録する

カー ウォッチドッグ デーモンのインターフェース名は android.automotive.watchdog.ICarWatchdog/default です。

  1. 名前でデーモンを検索し、ICarWatchdog::registerClient を呼び出します。 main.cppSampleNativeClient.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);
    }

Java サービスの健全性のモニタリング

CarWatchdogClientCallback を継承してクライアントを実装する

  1. 新しいファイルを以下のように編集します。
    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() {}
    };

クライアントを登録する

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

クライアントの登録を解除する

  1. サービスの終了時に CarWatchdogManager.unregisterClient() を呼び出します。
    private void finishClient() {
        CarWatchdogManager manager =
            (CarWatchdogManager) car.getCarManager(
            Car.CAR_WATCHDOG_SERVICE);
        manager.unregisterClient(mClientCallback);
    }

VHAL ヘルス モニタリング

ベンダー サービスの健全性のモニタリングとは異なり、ウォッチドッグは VHAL_HEARTBEAT 車両プロパティに登録することで VHAL サービスの健全性をモニタリングします。ウォッチドッグは、このプロパティの値が N 秒ごとに更新されることを想定しています。このタイムアウト内にハートビートが更新されない場合、ウォッチドッグは VHAL サービスを終了します。

注: ウォッチドッグは、VHAL_HEARTBEAT 車両プロパティが VHAL サービスでサポートされている場合にのみ、VHAL サービスの健全性をモニタリングします。

VHAL の内部実装はベンダーによって異なる場合があります。以下のコードサンプルは、参照として使用できます。

  1. VHAL_HEARTBEAT 車両プロパティを登録します。

    VHAL サービスを開始するときに、VHAL_HEARTBEAT 車両プロパティを登録します。 以下の例では、unordered_map を使用して、プロパティ ID を構成にマッピングし、サポートされているすべての構成を保存しています。VHAL_HEARTBEAT の構成がマップに追加されることで VHAL_HEARTBEAT がクエリされると、対応する構成が返されます。

    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. VHAL_HEARTBEAT 車両プロパティを更新します。

    VHAL ヘルスチェックの頻度(VHAL ヘルスチェックの頻度の定義に記載されています)に従って、VHAL_HEARTBEAT 車両プロパティを N 秒ごとに 1 回更新します。 これを行う方法の 1 つとしては、RecurrentTimer を使用して、VHAL の健全性を確認し、タイムアウト内に VHAL_HEARTBEAT 車両プロパティを更新するアクションを呼び出すことです。

    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. (省略可)VHAL ヘルスチェックの頻度を定義します。

    ウォッチドッグの ro.carwatchdog.vhal_healthcheck.interval 読み取り専用プロダクト プロパティは、VHAL ヘルスチェック頻度を定義します。このプロパティが定義されていない場合、デフォルトのヘルスチェックは 3 秒ごとに行われます。VHAL サービスが VHAL_HEARTBEAT 車両プロパティを更新するのに 3 秒では不十分な場合、サービスの応答性に応じて VHAL ヘルスチェックの頻度を定義します。

ウォッチドッグによって終了した異常なプロセスのデバッグ

ウォッチドッグはプロセス状態をダンプし、異常なプロセスを終了します。異常なプロセスを終了すると、Watchdog はテキスト carwatchdog terminated <process name> (pid:<process id>) を logcat に記録します。このログ行には、プロセス名やプロセス ID など、終了したプロセスに関する情報が含まれています。

  1. 次のコマンドを実行して、logcat で上記のテキストを検索できます。
    $ adb logcat -s CarServiceHelper | fgrep "carwatchdog killed"

    たとえば、KitchenSink アプリが登録済みのウォッチドッグ クライアントであり、ウォッチドッグ ping に応答しなくなった場合、ウォッチドッグは、登録済みの KitchenSink プロセスを終了するときに、次のような行をログに記録します。

    05-01 09:50:19.683   578  5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
  2. 応答がない場合の根本原因を特定するには、Activity ANR の場合と同様に、/data/anr に保存されているプロセスダンプを使用します。終了したプロセスのダンプファイルを取得するには、次のコマンドを使用します。
    $ adb root
    $ adb shell grep -Hn "pid process_pid" /data/anr/*

    次のサンプルは、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 -----

    終了した KitchenSink プロセスのダンプファイルは /data/anr/anr_2020-05-01-09-50-18-290 にあります。終了したプロセスの ANR ダンプファイルを使用して分析を開始します。