このページは Cloud Translation API によって翻訳されました。

システムの健全性を監視する,システムの健全性を監視する

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

ベンダーサービスの健全性監視

ベンダーサービスはネイティブ側と Java 側の両方で監視されます。ベンダーサービスを監視するには、事前定義されたタイムアウトを指定して、サービスがヘルスチェックプロセスを Watchdog に登録する必要があります。ウォッチドッグは、登録時に指定されたタイムアウトに関連した間隔で ping を送信することにより、登録されたヘルスチェックプロセスの健全性を監視します。 ping を送信したプロセスがタイムアウト内に応答しない場合、そのプロセスは異常であるとみなされます。

ネイティブサービスの健全性監視

ウォッチドッグ AIDL メイクファイルを指定する

carwatchdog_aidl_interface-ndk_platform shared_libsに含めます。

Android.bp

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

SELinuxポリシーを追加する

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

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

checkIfAliveで、ヘルスチェックを実行します。 1 つのオプションは、スレッドループハンドラーにポストすることです。正常な場合は、 ICarWatchdog::tellClientAliveを呼び出します。 SampleNativeClient.hおよび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);
}

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

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

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

Javaサービスの健全性監視

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

新しいファイルを次のように編集します:

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

クライアントを登録する

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

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

サービスが終了したらCarWatchdogManager.unregisterClient()を呼び出します:

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

VHAL ヘルスモニタリング

ベンダーサービスの健全性監視とは異なり、Watchdog はVHAL_HEARTBEAT車両プロパティをサブスクライブすることで VHAL サービスの健全性を監視します。ウォッチドッグは、このプロパティの値が N 秒ごとに更新されることを期待します。このタイムアウト内にハートビートが更新されない場合、Watchdog は VHAL サービスを終了します。

注:ウォッチドッグは、 VHAL_HEARTBEAT車両プロパティが VHAL サービスでサポートされている場合にのみ、VHAL サービスの正常性を監視します。

VHAL の内部実装はベンダーによって異なる場合があります。次のコードサンプルを参考にしてください。

VHAL_HEARTBEAT車両プロパティを登録します。
VHALサービスを開始する際に、 VHAL_HEARTBEAT車両プロパティを登録します。以下の例では、サポートされているすべての構成を保持するために、プロパティ ID を構成にマップするunordered_map使用されています。 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;
}
```

VHAL_HEARTBEAT車両プロパティを更新します。

VHAL ヘルスチェックの頻度 ( 「VHAL ヘルスチェックの頻度を定義する」で説明) に基づいて、N 秒ごとにVHAL_HEARTBEAT車両プロパティを更新します。これを行う 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));
       }
}

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

ウォッチドッグによって終了された異常なプロセスをデバッグする

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

```
$ adb logcat -s CarServiceHelper | fgrep "carwatchdog killed"
```
を実行すると、logcat で前述のテキストを検索できます。
たとえば、KitchenSink アプリが登録された Watchdog クライアントであり、Watchdog ping に応答しなくなった場合、Watchdog は登録された KitchenSink プロセスを終了するときに次のような行をログに記録します。
```
05-01 09:50:19.683   578  5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
```
応答不能の根本原因を特定するには、アクティビティ 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 ダンプファイルを使用して分析を開始します。