Supervisión del estado del sistema

Watchdog supervisa el estado de los servicios del proveedor y el servicio VHAL, y finaliza cualquier proceso que no esté en buen estado. Cuando finaliza un proceso en mal estado, Watchdog vuelca el estado del proceso a /data/anr como con otros volcados de aplicaciones que no responden (ANR). Si lo hace, facilita el proceso de depuración.

Supervisión del estado del servicio del proveedor

Los servicios del proveedor se supervisan tanto en el lado nativo como en el de Java. Para que un servicio de proveedor sea monitoreado, el servicio debe registrar un proceso de verificación de estado con Watchdog especificando un tiempo de espera predefinido. Watchdog supervisa el estado de un proceso de comprobación de estado registrado haciendo ping en un intervalo relativo al tiempo de espera que se especifica durante el registro. Cuando un proceso al que se le ha hecho ping no responde dentro del tiempo de espera, se considera que el proceso no está en buen estado.

Supervisión del estado del servicio nativo

Especifique el archivo make de Watchdog AIDL

  1. Incluya carwatchdog_aidl_interface-ndk_platform en shared_libs .

    Android.bp

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

Agregar una política de SELinux

  1. Para agregar una política de SELinux, permita que el dominio de servicio del proveedor use binder (macro binder_use ) y agregue el dominio de servicio del proveedor al dominio del cliente carwatchdog (macro carwatchdog_client_domain ). Consulte el siguiente código para sample_client.te y 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

Implemente una clase de cliente heredando BnCarWatchdogClient

  1. En checkIfAlive , realice una verificación de estado. Una opción es publicar en el controlador de bucle de subprocesos. Si está en buen estado, llame a ICarWatchdog::tellClientAlive . Consulte el siguiente código para SampleNativeClient.h y 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);
}

Inicie un hilo de carpeta y registre el cliente

El nombre de la interfaz del demonio de vigilancia del automóvil es android.automotive.watchdog.ICarWatchdog/default .

  1. Busque el daemon con el nombre y llame a ICarWatchdog::registerClient . Consulte el siguiente código para main.cpp y 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);
}

Supervisión del estado del servicio de Java

Implemente un cliente heredando CarWatchdogClientCallback

  1. Edite el nuevo archivo de la siguiente manera:
    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() {}
};

Registrar el cliente

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

Dar de baja al cliente

  1. Llame CarWatchdogManager.unregisterClient() cuando finalice el servicio:
    private void finishClient() {
    CarWatchdogManager manager =
        (CarWatchdogManager) car.getCarManager(
        Car.CAR_WATCHDOG_SERVICE);
    manager.unregisterClient(mClientCallback);
}

Monitoreo de salud VHAL

A diferencia del monitoreo del estado del servicio del proveedor, Watchdog monitorea el estado del servicio VHAL al suscribirse a la propiedad del vehículo VHAL_HEARTBEAT . Watchdog espera que el valor de esta propiedad se actualice una vez cada N segundos. Cuando el latido no se actualiza dentro de este tiempo de espera, Watchdog finaliza el servicio VHAL.

Nota: Watchdog supervisa el estado del servicio VHAL solo cuando la propiedad del vehículo VHAL_HEARTBEAT es compatible con el servicio VHAL.

La implementación interna de VHAL puede variar de un proveedor a otro. Los siguientes ejemplos de código se pueden utilizar como referencias.

  1. Registre la propiedad del vehículo VHAL_HEARTBEAT .

    Al iniciar el servicio VHAL, registre la propiedad del vehículo VHAL_HEARTBEAT . En el siguiente ejemplo, unordered_map , que asigna el ID de propiedad a la configuración, se usa para contener todas las configuraciones admitidas. La configuración para VHAL_HEARTBEAT se agrega al mapa, de modo que cuando se consulta VHAL_HEARTBEAT , se devuelve la configuración correspondiente.

    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. Actualice la propiedad del vehículo VHAL_HEARTBEAT .

    Según la frecuencia de verificación de estado de VHAL (explicada en Definir la frecuencia de la verificación de estado de VHAL" ), actualice la propiedad del vehículo VHAL_HEARTBEAT una vez cada N segundos. Una forma de hacerlo es usar RecurrentTimer para llamar a la acción que verifica el estado de VHAL y actualiza la propiedad del vehículo VHAL_HEARTBEAT dentro del tiempo de espera.

    A continuación se muestra una implementación de muestra usando 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. ( Opcional ) Defina la frecuencia de la comprobación de estado de VHAL.

    La propiedad de producto de solo lectura ro.carwatchdog.vhal_healthcheck.interval de Watchdog define la frecuencia de verificación de estado de VHAL. La frecuencia de verificación de estado predeterminada (cuando esta propiedad no está definida) es de tres (3) segundos. Si tres (3) segundos no son suficientes para que el servicio VHAL actualice la propiedad del vehículo VHAL_HEARTBEAT , defina la frecuencia de verificación del estado de VHAL según la capacidad de respuesta del servicio.

Depuración de procesos en mal estado terminados por Watchdog

Watchdog vuelca el estado del proceso y finaliza los procesos en mal estado. Al finalizar un proceso en mal estado, Watchdog registra el texto carwatchdog terminated <process name> (pid:<process id>) en logcat. Esta línea de registro proporciona información sobre el proceso finalizado, como el nombre del proceso y la identificación del proceso.

  1. El logcat se puede buscar para el texto mencionado anteriormente ejecutando:
    $ adb logcat -s CarServiceHelper | fgrep "carwatchdog killed"

    Por ejemplo, cuando la aplicación KitchenSink es un cliente de Watchdog registrado y deja de responder a los pings de Watchdog, Watchdog registra una línea como la que se muestra a continuación cuando finaliza el proceso de KitchenSink registrado.

    05-01 09:50:19.683   578  5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
  2. Para identificar la causa raíz de la falta de respuesta, use el volcado de proceso almacenado en /data/anr tal como lo usaría para los casos de Actividad ANR. Para recuperar el archivo de volcado del proceso finalizado, use los siguientes comandos.
    $ adb root
$ adb shell grep -Hn "pid process_pid" /data/anr/*

    El siguiente resultado de muestra es específico de la aplicación 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 -----

    El archivo de volcado del proceso KitchenSink terminado se encuentra en /data/anr/anr_2020-05-01-09-50-18-290 . Inicie su análisis utilizando el archivo de volcado ANR del proceso terminado.

,

Watchdog supervisa el estado de los servicios del proveedor y el servicio VHAL, y finaliza cualquier proceso que no esté en buen estado. Cuando finaliza un proceso en mal estado, Watchdog vuelca el estado del proceso a /data/anr como con otros volcados de aplicaciones que no responden (ANR). Si lo hace, facilita el proceso de depuración.

Supervisión del estado del servicio del proveedor

Los servicios del proveedor se supervisan tanto en el lado nativo como en el de Java. Para que un servicio de proveedor sea monitoreado, el servicio debe registrar un proceso de verificación de estado con Watchdog especificando un tiempo de espera predefinido. Watchdog supervisa el estado de un proceso de comprobación de estado registrado haciendo ping en un intervalo relativo al tiempo de espera que se especifica durante el registro. Cuando un proceso al que se le ha hecho ping no responde dentro del tiempo de espera, se considera que el proceso no está en buen estado.

Supervisión del estado del servicio nativo

Especifique el archivo make de Watchdog AIDL

  1. Incluya carwatchdog_aidl_interface-ndk_platform en shared_libs .

    Android.bp

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

Agregar una política de SELinux

  1. Para agregar una política de SELinux, permita que el dominio de servicio del proveedor use binder (macro binder_use ) y agregue el dominio de servicio del proveedor al dominio del cliente carwatchdog (macro carwatchdog_client_domain ). Consulte el siguiente código para sample_client.te y 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

Implemente una clase de cliente heredando BnCarWatchdogClient

  1. En checkIfAlive , realice una verificación de estado. Una opción es publicar en el controlador de bucle de subprocesos. Si está en buen estado, llame a ICarWatchdog::tellClientAlive . Consulte el siguiente código para SampleNativeClient.h y 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);
}

Inicie un hilo de carpeta y registre el cliente

El nombre de la interfaz del demonio de vigilancia del automóvil es android.automotive.watchdog.ICarWatchdog/default .

  1. Busque el daemon con el nombre y llame a ICarWatchdog::registerClient . Consulte el siguiente código para main.cpp y 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);
}

Supervisión del estado del servicio de Java

Implemente un cliente heredando CarWatchdogClientCallback

  1. Edite el nuevo archivo de la siguiente manera:
    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() {}
};

Registrar el cliente

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

Dar de baja al cliente

  1. Llame CarWatchdogManager.unregisterClient() cuando finalice el servicio:
    private void finishClient() {
    CarWatchdogManager manager =
        (CarWatchdogManager) car.getCarManager(
        Car.CAR_WATCHDOG_SERVICE);
    manager.unregisterClient(mClientCallback);
}

Monitoreo de salud VHAL

A diferencia del monitoreo del estado del servicio del proveedor, Watchdog monitorea el estado del servicio VHAL al suscribirse a la propiedad del vehículo VHAL_HEARTBEAT . Watchdog espera que el valor de esta propiedad se actualice una vez cada N segundos. Cuando el latido no se actualiza dentro de este tiempo de espera, Watchdog finaliza el servicio VHAL.

Nota: Watchdog supervisa el estado del servicio VHAL solo cuando la propiedad del vehículo VHAL_HEARTBEAT es compatible con el servicio VHAL.

La implementación interna de VHAL puede variar de un proveedor a otro. Los siguientes ejemplos de código se pueden utilizar como referencias.

  1. Registre la propiedad del vehículo VHAL_HEARTBEAT .

    Al iniciar el servicio VHAL, registre la propiedad del vehículo VHAL_HEARTBEAT . En el siguiente ejemplo, unordered_map , que asigna el ID de propiedad a la configuración, se usa para contener todas las configuraciones admitidas. La configuración para VHAL_HEARTBEAT se agrega al mapa, de modo que cuando se consulta VHAL_HEARTBEAT , se devuelve la configuración correspondiente.

    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. Actualice la propiedad del vehículo VHAL_HEARTBEAT .

    Según la frecuencia de verificación de estado de VHAL (explicada en Definir la frecuencia de la verificación de estado de VHAL" ), actualice la propiedad del vehículo VHAL_HEARTBEAT una vez cada N segundos. Una forma de hacerlo es usar RecurrentTimer para llamar a la acción que verifica el estado de VHAL y actualiza la propiedad del vehículo VHAL_HEARTBEAT dentro del tiempo de espera.

    A continuación se muestra una implementación de muestra usando 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. ( Opcional ) Defina la frecuencia de la comprobación de estado de VHAL.

    La propiedad de producto de solo lectura ro.carwatchdog.vhal_healthcheck.interval de Watchdog define la frecuencia de verificación de estado de VHAL. La frecuencia de verificación de estado predeterminada (cuando esta propiedad no está definida) es de tres (3) segundos. Si tres (3) segundos no son suficientes para que el servicio VHAL actualice la propiedad del vehículo VHAL_HEARTBEAT , defina la frecuencia de verificación del estado de VHAL según la capacidad de respuesta del servicio.

Depuración de procesos en mal estado terminados por Watchdog

Watchdog vuelca el estado del proceso y finaliza los procesos en mal estado. Al finalizar un proceso en mal estado, Watchdog registra el texto carwatchdog terminated <process name> (pid:<process id>) en logcat. Esta línea de registro proporciona información sobre el proceso finalizado, como el nombre del proceso y la identificación del proceso.

  1. El logcat se puede buscar para el texto mencionado anteriormente ejecutando:
    $ adb logcat -s CarServiceHelper | fgrep "carwatchdog killed"

    Por ejemplo, cuando la aplicación KitchenSink es un cliente de Watchdog registrado y deja de responder a los pings de Watchdog, Watchdog registra una línea como la que se muestra a continuación cuando finaliza el proceso de KitchenSink registrado.

    05-01 09:50:19.683   578  5777 W CarServiceHelper: carwatchdog killed com.google.android.car.kitchensink (pid: 5574)
  2. Para identificar la causa raíz de la falta de respuesta, use el volcado de proceso almacenado en /data/anr tal como lo usaría para los casos de Actividad ANR. Para recuperar el archivo de volcado del proceso finalizado, use los siguientes comandos.
    $ adb root
$ adb shell grep -Hn "pid process_pid" /data/anr/*

    El siguiente resultado de muestra es específico de la aplicación 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 -----

    El archivo de volcado del proceso KitchenSink terminado se encuentra en /data/anr/anr_2020-05-01-09-50-18-290 . Inicie su análisis utilizando el archivo de volcado ANR del proceso terminado.