I’ve changed roles at Mozilla, and have been working a lot less with external groups we work with on Firefox and more with partners interested in Firefox OS. A lot of what I’m focusing on is around explaining how Firefox OS works, what makes it different from other mobile operating systems and ecosystems, and what’s required to bring a Firefox OS device to a given market. I’m not the only one (by far) doing this, but I do find myself assembling a lot of docs to help our potential partners understand things.
I’m going to start posting about what I’ve been working on both here and to the Mozilla wiki, and I’ll start with the update mechanics behind Firefox OS. Note that it’s by no means definitive, and particulars may change for a given deployment scenario. The docs I am creating are intended to lay out the concepts behind things (at a 5,000 foot view), so that people can understand what’s going on and what questions they need to ask from a product marketing, development, and operations point of view.
All of these docs are a work in progress, and will continue to be refined. I do vet them with people who know a lot more about the particulars than I do, but feedback’s always welcome from everywhere. In any event, if you’re interested, I’ll be adding this and others over the next few weeks to the Firefox OS/b2g info troves.
Firefox OS Update Mechanics
Scope
Firefox OS makes use of two update processes to update the device its installed on. Gecko/Gaia Updates (we’re still looking for a better name for these) are used for updating the Gecko and/or Gaia software layers, and Full system updates are used to update Gonk (and, optionally, Gecko and/or Gaia at the same time). Three update clients are used for this process: Mozilla’s update polling client, which is part of Gecko and is responsible for checking for updates; Mozilla’s software update client, which is also built into Gecko and is responsible for downloading, verifying and — in the case of Gecko/Gaia Updates — applying updates; and the device’s Firmware or Google Over the Air (G/FOTA) update facility for full system updates. The Gecko update components use the same core as what’s used in Firefox OS, and the specific modifications for Firefox OS are outlined in bug 737368.
The software update facilities in Gecko is used to check for and download all updates (Gecko/Gaia and Full System) to the device, as well as to apply Gecko/Gaia updates to the device. For full system updates, after checking for and downloading a valid update, the software update client in Gecko hands off the update package to the device’s over-the-air update facility (GOTA or FOTA) for application after the package has been downloaded to the device and validated.
Updates are limited to files (and the settings in those files) stored as part of Gonk, Gecko, and Gaia. User and application data cannot be modified by the update, and updates to these must be made programmatically from within an app that has access to them (e.g. for a setting change, part of an app update would include detecting the setting that needs to be updated and modifying it when the app is run after being updated).
App updates are similar to the Gecko/Gaia update process, but only affect the individual apps (packaged apps or hosted manifests) installed in the user data partition(s) of the device’s file store. While app updates are not covered in detail, it should be noted that an app update can only be applied to that app’s specific data store (e.g. each app has it’s own update payload, applied to its own data store/directory).
Device Storage Map
Firefox OS 1.0 will be tailored for devices with 512MB of storage for the OS and apps, as well as a 2GB storage partition (currently on an SD card) for the device’s media library and update download target (e.g. where downloaded updates are stored prior to application). The 512MB of storage is partitioned statically for the system files (Gonk, Gecko, and Gaia), data files (app & user), an HTTP data cache for storage of cached objects, and a small amount of storage for various OS sundries (e.g. /proc, etc.). The 512MB is currently laid out as below, and the filesystem mount points are documented on the Mozilla wiki in the B2G Architecture section.
Gecko/Gaia updates are applied to the /system/b2g and /system/b2g-staging directories only. Full System updates are applied using the devices recovery facility, and have access to defined mount points, but in practice will only affect Gonk (and, optionally, Gecko and/or Gaia).
Device Management Solution Components
The following components are used with Firefox OS updates, which require an update check endpoint that returns update information in an understood format (see External References for more info on the Firefox OS-specific implementation).
Transport Client: Gecko Software Update clients, via HTTP(S) (see external references)
Transport Package: Mozilla Archive files (see external references)
Version Control: Version ID compiled into binaries, used in update check
Management App: Settings App in Firefox OS
Installers: Gecko Software Update client (Gecko/Gaia), Android FOTA/recovery facility (Full System Updates)
Interface to Android FOTA/Recovery (see bug 778084)
Gecko Update Process Overview
The normally read-only /system file system is where Gecko and Gaia files reside, with the /system/b2g directory being used for the live copy of FirefoxOS, and the /system/b2g-staging directory for updates being applied. No other file system mount points are modified as part of this process (e.g. user data, app data, and cached data are not touched).
- Gecko update client downloads and verifies update package, validates signing cert for package
- On successful verification/validation of update package, the ro /system mount-point is remounted as rw
- Gecko update client applies update package to b2g-staging
- Gecko update client verifies the extracted update in b2g-staging
- After a successful verification pause the b2g process so that it doesn’t encounter an inconsistent state in /system/b2g
- Atomic swap the /system/b2g and /system/b2g-staging directories and restart the device
Full System Update Process Overview
For full system updates, Firefox OS makes use of the device’s OTA update facility (GOTA or FOTA) to apply full system (Gonk, Gecko, and Gaia) updates. The Gecko update client checks for, downloads and validates available system updates to the local file store, and then hands off the image to the GOTA facility. The update is then applied via recovery mode by the GOTA update facility.
- Gecko update client downloads and verifies update package, validates signing cert for package
- On successful verification/validation of update package, the device is rebooted into recovery mode with the downloaded update provided as an update package
- The device enters recovery mode, applies the update, and reboots
System Update Flows (Gecko/Gaia & Full System Updates)
App Update Process Flow
External References
B2G Updates (Mozilla Wiki) – https://wiki.mozilla.org/B2G/Architecture/Runtime_Security#Updates
Gecko’s Software Update client – https://wiki.mozilla.org/Software_Update
Bug 715816 – (b2g-gecko-updates) Tracking: Automatic updates of b2g “userspace” (gecko, built-in apps and dependencies; not third-party apps)
Bug 778084 – (b2g-fota-updates) Tracking: Gecko glue for FOTA updates (see comment 5, in particular, for an overview)
Bug 728081 – (b2g-app-updates) Tracking: Automatic updates of installed applications on B2G
Bug 764194 – (b2g-updates) [meta] Master tracking bug for B2G & app updates
Mozilla Archive files (MARs, used for packaging updates) – https://wiki.mozilla.org/Software_Update:MAR
What about patch/delta updates and falling back to a full package? Is that v2? Could save users and carriers a lot of bandwidth…
The patch updates will definitely be deltas, as data costs – especially where updates aren’t zero-rated and wifi is not available – can be prohibitive to the operator and customer. There’s a lot of discussion still going on about implementation specifics, and the dev and relmgmt teams are working on documenting the specifics behind it. There’s also an understandable amount of concern around qualification (QA & device certification) of updates, and how updates are managed. We’re going to have to get really clear on risk/reward for updates, and how we convince users and operators of the value in them. cjones and team will be releasing the eng doc for the update process next week, and I’ll post about it as well.