Watchdog עוקב אחרי התקינות של שירותי הספק ושל שירות VHAL, ומפסיק כל תהליך לא תקין. כשתהליך לא תקין מסתיים, Watchdog מעביר את סטטוס התהליך לדמפ ב-/data/anr
, כמו בדמפים אחרים של Application Not Responding (ANR). כך קל יותר לבצע תהליך ניפוי באגים.
מעקב אחר תקינות השירות של הספק
אנחנו בודקים את שירותי הספקים גם ב-Native וגם ב-Java. כדי ששירות של ספק מסוים יתבצע במעקב, צריך לרשום ב-Watchdog תהליך לבדיקה תקינה של השירות, ולציין זמן קצוב מראש לתפוגה. הטיימר המפקח (watchdog) עוקב אחר את התקינות של תהליך רשום של בדיקת תקינות על ידי שליחת פינגים במרווחים ביחס לזמן הקצוב לתפוגה שצוין במהלך הרישום. אם תהליך שנשלח אליו אות ping לא מגיב בתוך זמן הקצוב לתפוגה, התהליך נחשב לא תקין.
מעקב אחרי תקינות השירות במקור
ציון קובץ ה-makefile של Watchdog 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 (מאקרו
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
צריך לבצע בדיקת תקינות. אפשרות אחת היא לפרסם את האירוע בטיפול בלולאת השרשור. אם הוא תקין, צריך להתקשר למספר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); }
התחלת שרשור ב-Binder ורישום הלקוח
שם ממשק הדימון (daemon) של הרכב הוא
android.automotive.watchdog.ICarWatchdog/default
- מחפשים את הדימון (daemon) עם השם ומתקשרים אל
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 על ידי הרשמה לנכס הרכב VHAL_HEARTBEAT
.
Watchdog מצפה שהערך של המאפיין הזה יתעדכן פעם ב-N שניות.
כשפעימת הלב לא מתעדכנת במסגרת הזמן הקצוב הזה, טיימר המפקח (watchdog) מסיים את VHAL
לאחר השיפור.
הערה: Watchdog עוקב אחר תקינות שירות VHAL רק כאשר
מאפיין הרכב VHAL_HEARTBEAT
נתמך על ידי שירות VHAL.
ההטמעה הפנימית של VHAL עשויה להשתנות בהתאם לספק. תוכלו להיעזר בדוגמאות הקוד הבאות.
- רישום נכס הרכב
VHAL_HEARTBEAT
.כשמפעילים את שירות VHAL, צריך לרשום את נכס הרכב
VHAL_HEARTBEAT
. בדוגמה הבאה,unordered_map
, שממפה את מזהה הנכס ל-config הוא משמש לשמירת כל ההגדרות הנתמכות. ההגדרה של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"), מעדכנים את מאפיין הרכב
VHAL_HEARTBEAT
פעם אחת בכל N שניות. דרך אחת לעשות זאת היא באמצעות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.
קריאה בלבד של
ro.carwatchdog.vhal_healthcheck.interval
של הטיימר המפקח (watchdog) מגדיר את תדירות בדיקת התקינות של VHAL. תדירות ברירת המחדל של בדיקת התקינות (כשהנכס הזה לא מוגדר) היא שלוש שניות. אם לא 3 שניות מספיק ששירות VHAL יעדכן את מאפיין הרכבVHAL_HEARTBEAT
, להגדיר את התדירות של בדיקת התקינות של VHAL בהתאם לתגובתיות השירות.
ניפוי באגים בתהליכים לא תקינים שהסתיימו על ידי Watchdog
ה-watchdog מוחק את מצב התהליך ומסיים תהליכים לא בריאים. כשמפסיקים תהליך לא תקין, Watchdog מתעד את הטקסט carwatchdog terminated
<process name> (pid:<process id>)
ביומן logcat. שורת היומן הזו מספקת מידע על התהליך שהופסק, כמו שם התהליך ומזהה התהליך.
- אפשר לחפש את ה-Logcat כדי למצוא את הטקסט הנ"ל באמצעות הרצת:
$ adb logcat -s CarServiceHelper | fgrep "carwatchdog killed"
לדוגמה, כשאפליקציית KitchenSink היא לקוח רשום של Watchdog והיא לא מגיבה להודעות ה-ping של Watchdog, Watchdog מתעד שורה כמו השורה הבאה ביומן כשהוא מסיים את התהליך המורשם של KitchenSink.
05-01 09:50:19.683 578 5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
- כדי לזהות את שורש הבעיה של חוסר התגובה, משתמשים ב-dump של התהליך שנשמר ב-
/data/anr
בדיוק כמו במקרים של ANR בפעילות. כדי לאחזר את קובץ ה-Dump של התהליך שהסתיים, משתמשים בפקודות הבאות.$ 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 של התהליך שהופסק.