How adbd starts

The adbd service life cycle is managed by the init process. The daemon will be started when the two following conditions are true.

  1. The device is in developer mode.
  2. Adb over USB or adb over Wifi are enabled.

init itself doesn't have any special knowledge about adbd. Everything it needs to know comes from the various .rc files (telling it what to do when various properties are set) and the processes that set those properties.

There are two main scenarios where init will start adbd. When the device boots and when a user runs a device into "developer mode".

When the device boots

The behavior of init is controlled by .rc files, commands, and system properties.

  • The adbd service is described here.
  • The rc language tie together properties, commands, and services.

When a device boots, the script init.usb.rc checks if persistent property persist.sys.usb.config is set, in which case the values is copied into sys.usb.config. When this value is written, it triggers init to run start adbd.

When the device is already booted

When the device is up and running, it could be in "Developer Mode" but adbd service may not be running. It is only after the user toggles "Developer options" -> "USB debugging" or "Developer options" -> "Wireless debugging" via the GUI that adbd starts.

Note that the previous description is valid for user builds. In the case of userdebug and eng, properties set at build-time, such as ro.adb.secure or persist.sys.usb.config, will automate adbd starting up and disable authentication.

Four layers are involved.

  1. GUI USB / GUI Wireless
  2. AdbSettingsObserver
  3. AdbService
  4. init process

GUI (USB)

  1. The confirmation dialog is displayed from AdbPreferenceController.showConfirmationDialog.
  2. Validation is performed in AdbPreferenceController.writeAdbSettings once the dialog is validated by user
  3. Settings.Global.ADB_ENABLED is set.
Settings.Global.putInt(mContext.getContentResolver(),
Settings.Global.ADB_ENABLED, enabled ? ADB_SETTING_ON : ADB_SETTING_OFF);

GUI (Wireless)

In the case of "Wireless debugging" toggle, the same kind of interaction leads to ADB_WIFI_ENABLED being set.

Settings.Global.putInt(mContext.getContentResolver(), Settings.Global.ADB_WIFI_ENABLED , 1);

AdbSettingsObserver

  1. Both ADB_ENABLED and ADB_WIFI_ENABLED are monitored by AdbSettingsObserver.

  2. When a change is detected, the Observers calls AdbService::setAdbEnabled.

AdbService

  1. AdbService.startAdbd is called. This talks to the init process by setting ctl.start or ctl.stop to "adbd". This step is equivalent to .rc files start adbd and stop adbd.

USBDeviceManager (USB only)

If USB is involved (as opposed to ADB Wifi), (USBDeviceManager.onAdbEnabled ) is called to recompose the gadget functions. As a side effect, persistent property persist.sys.usb.config is set so init will automatically start adbd service on the next device start.

  1. MSG_ENABLE_ADB message is sent from onAdbEnabled.

  2. In UsbDeviceManager.setAdbEnabled property persist.sys.usb.config is set.

  3. The manager needs to recompose the functions into a gadget.

    1. UsbDeviceManager.setEnabledFunctions.
    2. UsbDeviceManager.setUsbConfig().

init

init monitors properties ctl.start and ctl.stop and interprets changes as requests to start/stop a service. See init built-in commands (such as start and stop) here.

To let other systems observe services' lifecycle, init sets properties with known prefixes.

  • Lifecycle: init.svc.SERVICE_NAME (init.svc.adbd), which can be set to "running", "stopped", "stopping" (see Service::NotifyStateChange for all possible values).
  • Bootime: ro.boottime.SERVICE_NAME (ro.boottime.adbd).