Ubuntu Touch Devices

Introduction

Ubuntu Touch as it's currently run on the Nexus devices, boots into Ubuntu and then starts an Android container to run the various binary daemons and drivers.

The whole system is read-only with only some specific files being diverted to writable storage using bind-mounts, the exact list of those tends to evolve overtime so it's best to look directly into lxc-android-config for the current fstab.

Partitioning and file system

We basically use two main partitions, system and userdata. The system partition stores the actual operating system and is read-only, userdata stores any user configuration and data and is obviously writable.

The userdata partition currently contains the following sub-directories:

• android-data - Mounted as /data in the Android partition
• system-data - Writable directory for system data and settings, structure is identical to the rootfs
• user-data - Writable user directory, mounted as /home

For devices that don't have a 2GB system partition and that can't be resized, a system.img file is created on the userdata partition and used instead (through loop-mounting).

The current version of the system is stored in ubuntu:/etc/ubuntu-build

Update scenarios

First flash (at the manufacturer):

1. Pre-generated full disk images flashed directly to the various partitions
2. First boot

First flash (for community ports):

1. Flash an updated recovery image
2. Download an initial full OS image
3. Reboot into recovery -- upgrader code
4. The upgrader environment does the initial unpack and sets up the Ubuntu rootfs.
5. The system reboots

Full/partial update:

1. Client figures out what's the highest version the phone can be upgraded to in one shot.
2. The files are downloaded and validated.
3. Reboot into recovery -- upgrader code
4. The upgrader environment unpacks the updates in the right order, checks the signature of the update and read the metadata.
5. In case of a full image update, the partition is recreated (mkfs) before unpacking.
6. Copy all the files to the right partition.
7. In case of delta update, process all removals
8. The file is removed and the upgrader processes the next one until all are applied.
9. The system reboots

Factory reset:

1. Reboot into recovery
2. Select the factory reset option (this can also be triggered from the booted system)
3. The user data partition is formated.
4. The system reboots

Requirements

Over wire device flashing

This is for e.g.:

• factory install of OS on device
• users replacing their existing firmware with Ubuntu OS
• recovery to factory state after broken update
• reverting to an older OS version

This would typically be done over USB.

Preserving user data isn't mandatory but could be an option.

Updating replaces the existing system image.

Incremental OS update

This is to deliver OS updates to production devices.

Updates should be as small as possible as to avoid large downloads for the end-users and heavy load for the servers hosting the update data.

This would typically be done over the air (OTA), over WiFi or mobile data connection.

Device reset

End-users have a mean to restore the device to a clean state, removing all their personal data (contacts, photos, installed apps) etc. For instance, this is what you would do if you were to permanently give your device to someone else; it might also be a mean to recover from installed apps breaking your system.

Secure deletion (e.g. shred) is not mandatory but could be implemented as a nice to have option in the future.

One implementation option would be to keep a factory image around to allow reverting to a known good system ROM (e.g. the one from the factory), but this would consume extra space so wouldn’t typically be implemented in production. This would typically be useful while developing the upgrade system as to quickly revert to a known good state after a broken OS upgrade.

Secure delivery

OS updates need to be delivered securely.

Full OS images and OS updates need to carry a signature for all files installed on the system.

The installed filesystem itself isn't hashed at every boot and as it supports updating, can't really be signed.

However the updates themselves can be signed and the signature checked by the downloader and/or the updater in the initrd. Unless the user can acquire root privileges on the device, they won't be able to alter the base system in any way as only the data partition should be exported over USB, the rest being accessible only to the device itself.

Read-only OS

It’s desirable to have the rootfs read-only (outside of OS updates) as to avoid filesystem corruption and unwanted user changes to the root filesystem.

Recovery partition

The recovery partition will include a custom kernel+initrd used for our updates and factory reset. This will support:

• Menu based options allowing the user to flash from eMMC and do factory reset.
• Automated update mode that can be triggered by the update client and which will automatically apply any pending update.