Watchdog Service

This is a client-side service that monitors a pre-defined list of critical running applications involved in device management (ex. Intune nGMS Agent, MS Authenticator etc.) The Watchdog Service takes the necessary action when an application/service becomes unresponsive. Applications/services to be monitored as well as the actions to be taken are defined in a configuration file.

The AOSP provides various mechanisms to monitor applications and services such as Binder, PackageWatchdog, and Watchdog. All these mechanisms are designed to address specific needs and have some limitations for our use cases:

• Watchdog in AOSP will force a system reboot if any system server threads are unresponsive. It cannot be easily extended to monitor specific applications.
• Binder: The limitation here is that the application/service being monitored must implement onbind() method to let the Watchdog Service know if it crashes.
• PackageWatchdog: Only works for the foreground UI application.

_{Watchdog Service Component Diagram}

To overcome the above limitations, MDEP Watchdog Service was designed as a separate system service. The current design has limitations as it was assumed that monitored applications cannot be modified at the current time. In future releases, MDEP Watchdog Service may be redesigned to add a subscription mechanism and will be more aligned/converged with similar services in MS OEM kits.

A watchdog observer is an object that contains the list of packages to be monitored. It registers with the existing Android PackageWatchdog to receive notifications when a service/application dies.

The configuration file contains the list of applications/services to be monitored by the WatchdogService. This file will be using the JSON format. The Watchdog observer will use the existing Android’s JSON parser to parse this file and create a list of applications to be monitored.

The configuration file needs to be provisioned (installed) to a pre-defined location in the product partition: /product/etc/ A missing configuration file will be considered a critical failure. The Watchdog Service will throw an exception and log an error in such conditions. An empty configuration file or a configuration file without any applications/services listed will also be considered a critical failure. The Watchdog Service will throw an exception and log an error in such conditions.

For every package that needs to be monitored, the following parameters need to be defined in the configuration file:

• Name : Name of the package to be monitored
• Action: The following actions will be supported by the Watchdog Service:
  • Restart: Attempts to restart the application
  • Reboot: Reboots the device
  • ReportOnly: Reports to Telemetry about the crash
• ClassName: This is the name of the class that will be receiving the intent sent by the Watchdog. It could be a service or the broadcast receiver.
• Restart Intent: If the action is set to “Restart” then the exact intent to restart the package must be defined.
• MaxAttempts: This defines the number of times the WatchdogService attempts to restart the application. The default will be set to 1.

System services can only broadcast protected intents specified in: frameworks/base/core/res/AndroidManifest.xml. Due to this limitation the Watchdog Service cannot just parse the intents from the configuration file and broadcast them unless all these intents are also added to the framework manifest. The Watchdog companion application helps overcome this limitation.

This application will be a headless application with just a broadcast receiver to receive intents from the Watchdog Observer. The Watchdog Observer will broadcast the intent: android.intent.action.MDEP_WATCHDOG with extras comprising of the package name, class name, and intent to restart the package. On receiving the above intent, the companion application will parse the extras and restart the corresponding package.