[Review] Deployment, startup sequence, and OTA updates related notes

[bhush9]

Last week @shadeslayer and I were at sprint and talked about random points/questions around halium and how to deploy it to device..

---

Stuff to deploy

• rootfs.img
• system.img (android /system)
• boot.img (custome boot.img based on hybris-boot)
• android initrd
• vendor.img (android /vendor or /system/vendor)
• udev rules
• kernel

Questions

• Kernels per distribution might be based on different configs.. how to handle that?
  • halium_defconfig will have least amount of config options enabled
  • required for hardware enablement and the systemd init
  • Distributions can override this kernel config (usecase: apparmor for ubuntu touch)
  • See patch policy below
• rootfs.img
  • Have a config file which can point to rootfs.img
  • allows to have multiple distributions on same device and switch just by adjusting config file
• system.img
  • Don't flash it
  • Keeping it seperate will allow easier multirom support
  • Will keep vendor provided /system partition untouched, which allows for easier system restore
  • Easier deployment (??!)
• boot.img
  • Based on hybris-boot
  • Make it possible to use adb shell here
  • Copy the logic to find system and userdata partitions instead of the fixup-mountpoints script
  • allows to have device independant ramdisk/initrd
• udev.rules
  • Seperate source package which can be packaged by distributions
  • Can not be scripted as sometime we can not directly use rules used by ueventd
  • Use the import cmdline logic to have udev rule execute on different device instead of copy-udev-rules cruft
• vendor.img
  • Needs to be flexible, have a vendor.img in same location as system.img
  • if we can't find one mount the /vendor partition from the device
  • shadeslayer have reservations about points mentioned here
• android-ramdisk.img
  • is produced as gzip'd cpio archive
  • change android_build to produce ext4 images, so can be easily mounted instead of extracting it
  • will be provided by halium
  • will be mounted by the lxc pre-start hook
  • ubuntu touch pre-start hooks needs to be moved into build procedure somehow

OTA spec

• Defaults to halium servers
• Can be overridden by the distributions
• Distribution can not override single parts, they need to override all parts if they wish to
• there could be recovery which implements the client for the OTA spec

Typical boot sequence

1. Fastboot starts kernel with cmdline
2. It loads the initrd
3. Mounts the userdata partition
4. Mounts rootfs image
5. Starts init (systemd) -- weeeeeeeeeeeeeeeee!
6. Mounts the /system, /vendor and other android mount points with sytemd mount units
7. lxc pre-start hook mounts the android ramdisk
8. Starts the lxc container
9. Start the udev
10. Scope of halium is now over, login manager or userspace services now can start

Based on the boot sequence provided above, I've initial prototype locally which is able to start android container.. but still needs some more polish during this week.

Kernel patch policy

• Different distributions (downstream for halium) may want different options enabled on the kernel, or may want to backport different kernel features..
• To handle this we should have following policy
  • Patches which are upstream in mainline kernel tree or in the CM/LineageOS/AOSP kernel tree will be accepted
  • Same policy will be applied for patches which adds new features, however we wont enable those features in default kernel config for halium
  • Distributions can override kernel config options for themselves if they want

[mickybart]

About Questions

1/ Kernels per distribution

We should prefer an approach like mer_verify_kernelconfig reworked for Halium needs. defconfig of every devices are too much different and so it is necessary to know which CONFIG* should be added. It will not be necessary easy to do a diff of a specific defconfig kernel with halium_defconfig to add missing options.

2/ rootfs.img

config file can be set for now somewhere on /data where multiple rootfs.img will be available. The initrd of halium will be able to read the config file and mount the good rootfs.img. In the future we can work to embedded a GUI (based on TWRP ?) that will permit to select images, provide password for dm-crypt etc in the initrd.

3/system.img

I vote for a separation.

• easier
• permit every one to switch to a working Android if needed
• permit distribution to update system.img with package manager
• permit to have different Android versions (useful to test 5, 6, 7 ... and to have another native Android to boot that can be different of the one supported with libhybris)

5/ udev.rules

ueventd.rc and ueventd.$HARDWARE.rc need to be take into account. But some custom rules needs to be done per device :

eg for touchscreen: ACTION=="add|change", KERNEL=="event3", SUBSYSTEM=="input", ENV{ID_INPUT_KEY}="", ENV{ID_INPUT_TOUCHSCREEN}="1"

So final rules should be set by device maintainers (with the help of a script to extract rules) as there is no way to automatically do the one on the example.

6/ vendor.img

for device without vendor.img or vendor partition, a symlink /vendor to /system/vendor should be used (this is done by init.rc for example)

7/ android-ramdisk.img

Alternative: That can be a simple tgz of the out/target/product/"device"/root folder packaged/deployed by the distribution for the device. So we don't need to mount it at all and it can be simply extracted in /opt/android/rootfs for example.

Typical boot sequence

8 Starts the lxc container 9 Start the udev

Should not be 9 before 8 ? The start of lxc container means to start Android init but the init of Android should not populate /dev (so coldboot and /dev content should be done by systemd first). But maybe you are doing it in another way with a separate /dev ?

And I think that the start of lxc/android init should be done by a unit with constraints : After=sysinit.target Before=basic.target