ウォッチドッグはベンダー サービスと 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 ダンプ ファイルを使用して分析を開始します。