Ubuntu Touch Devices

Introduction

For now we're assuming that Ubuntu Touch runs in a container on top of an Android system. However the design is sufficiently flexible to easily adapt if we decide to drop that split or flip the two (make android the container). Note: as of 2013-07-24, this is not accurate. The Touch images use an Ubuntu base system with Android in a container. This page should be updated to reflect this change.

Partitioning and file system

We're currently assuming we can't easily repartition the device and so make use of the standard partitions. The Android system lives on the system partition, usually accessible as android:/system.

Temporary storage can be found at android:/cache and will be used to store the update images.

The Ubuntu system is installed in android:/data/ubuntu/, that directory will then contain at least two files:

• system.img - ext4 file containing the system. This partition will become ubuntu:/ (/ of the container) and mounted read-only.
• data.img - ext4 file contaiing the userdata. This partition will be mounted to ubuntu:/data (for example) and contain all user data and configuration.

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. Setup the Android layer (factory flash)
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
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.