Re-design of developer mode settings and USB mode selection system

[peat-psuwit]

Currently, this is how USB mode selection and developer mode works:

• persist.sys.usb.config property makes Android init file(s) config the kernel for the selected mode. The userspace is not started in the Android init files. [1]
• com.canonical.PropertyService D-Bus service support setting and querying USB mode. However, it does nothing more than a glorifying front-end for the aforementioned property.
  • This means the source of truth for USB mode is in the Android property.
• The userspace required for the mode (adbd, mtp-server, or rndis) is started by the Upstart property change event. This requires upstart-property-watcher.
• The service is also responsible for other things, such as writable mode or autopilot, which aren't related to Android properties at all.
• android-gadget-service is a utility that allows the user to set the arbitrary USB mode (including one that isn't supported), as well as interact with other functions of the service.
• Developer mode is always equal to whether ADB USB mode is enabled.
• There's a separated property that controls SSH called persist.service.ssh. This is also set and queried via com.canonical.PropertyService, and also uses upstart-property-watcher.

This has several problems:

• This relies on the Android init system. It won't work on non-Android devices because there's no Android init file to set the USB mode for us.
• Using the property as the source of truth doesn't work on Halium 7.1 based ports as it doesn't have upstart-property-watcher [2].
• On non-Android and Halium 7.1 devices, ADB doesn't work. In this case, we probably want to enable SSH when developer mode is enabled.

I would like to change it to the following:

• Stop using Android property for state persistence. Store this data in /etc/ somewhere.
• Introduce a daemon that manages the device's USB mode.
  • Owns the selected USB mode from the user (except ADB which can always be enabled together with other modes -- more on that later). Save it in /etc/____/____.ini (or something).
  • Has backends that actually set the mode, be it Android property, android_usb or configfs.
  • Has a D-Bus interface that allows setting, querying and listening to USB mode.
• Introduce another daemon (?) that manages the developer mode settings.
  • When developer mode is on, start SSH daemon on all devices because that always works.
  • On devices that have ADB working (i.e. Android 5.1 and earlier), also start adbd and signal (?) USB mode daemon to enable ADB USB mode.
  • Has a D-Bus interface that allows setting, querying and listening to developer mode settings.
• There will be D-Bus watchers for USB tethering (system-level) and MTP (user-level) that will start the appropriate userspace support for the USB mode.
• There will be separated utilities for other functionalities provided by com.canonical.PropertyService. This service will then be removed.

In that, I still have questions:

1. Do we have a system-wide settings store that allows watching? I'm looking for something like gsettings or dconf, but in a machine-wide way. If there's such a thing, the second daemon can be changed to just setting watchers and the first daemon won't have to store the settings itself.
2. Maybe 2 daemons should be merged into one? However, I guess separating them makes more sense.
3. Should developer mode daemon signal USB mode daemon explicitly or should USB mode daemon listens for developer mode changes? Also, should adbd get started by either of daemon or another D-Bus watcher (and which signal)?

---

[1] The exception for this is adbd service, but that's disabled in our container setup. [2] And, I don't want to add upstart-property-watcher to Halium (not even as a "Halium extension") because:

1. When we migrate to systemd, there's no such idea of events in it.
2. This causes the tendency to persist in some settings in the Android property needlessly.

Note that we won't remove it on the devices that have it working, as it's still required for adbd to restart the phone.

[UniversalSuperBox]

Well, two daemons might be overdoing it. :P

android-gadget-service is smart because it doesn't require root access to run, just an unlocked device. This allows phablet's applications to control the mode, provided they aren't confined.

Since we're talking about managing these services only on Ubuntu Touch, and since Ubuntu Touch is a single-user system, you could potentially drop files in a special directory and use Upstart's on file event to configure the jobs you want. That is, until we have systemd and can allow the user to enable or disable jobs. I think that trying to engineer for multi-user is a good idea but is not a strict requirement, since even Canonical wasn't close to UT being multi-user in the end.

Right now, SSH can be enabled via a writable file, /etc/init/ssh.override. The file is copied from the rootfs to /data/system-data/ on first boot and can be modified with root permissions.

Your theoretical daemon could see or watch a bunch of files being created or existing as well as the USB plug event. It doesn't need to be much more complex than this. The hardest part is picking where to put the files, I think.

[Flohack74]

Yeah I also think 1 daemon should be enough. Those things make it just harder to test & maintain if there is no strict reason we really need to do it like this. Otherwise, great proposal! I just think that a Github issue is maybe not the right place to refine this, as not many people will read this here...

[peat-psuwit]

android-gadget-service is smart because it doesn't require root access to run.

It doesn't require root permission because it talks to the aforementioned D-Bus service. That, I guess, is the reason the service is created. Unfortunately, it does too little for USB mode and does too much everything else.

...you could potentially drop files in a special directory and use Upstart's on file event to configure the jobs you want.

Actually, it's a good idea to use file(s) as a change notification. Both Upstart and Systemd have a system that starts a job/unit when file(s) is changed. However, I still think a D-Bus service is still required, as it doesn't make sense for e.g. system settings app to know which file to place/modify.

---

With these comments, I have another idea for this: have a (start-on-demand) D-Bus service called "SystemSettings" that let the user set the settings then write them to files in a directory. Dependents (such as USB mode switcher or MTP service) can use systemd.path units or Upstart file events to react upon file changes.

In a spirit, this is essentially property service but with property dependency removed. However, if we're gonna merge 2 D-Bus services into one, this service shouldn't have specific knowledge of USB mode or developer mode. I still vouch for D-Bus service because it allows us to integrate with PolicyKit later on.