Gaia/System/Updates

From MozillaWiki
Jump to navigation Jump to search

Overview

There are several types of FxOS updates:

  • Gonk (Kernel)
  • Gecko
  • Gaia
  • Apps
    • Core
    • Pre-installed third party
    • User-installed
      • Packaged
      • Non-packaged


Foundational principles

Security

The reason that we want to push updates pretty aggressively is in part security. One of the main sources of hacked computers is people running old versions of software with known security issues. Mozilla has for a long time been pushing as one of the main security benefits of Firefox our ability to update a large percentage of people's installed versions quickly.

Data consumption control

One of the big benefits of Firefox OS that we are going to try to push is the ability to keep costly data transfers down. Hence we want to avoid large downloads while the user is paying a lot of money for each byte.

Low friction

We reduce user friction by minimizing and automating updates as much as possible.


High level requirements

  • User can update system software
  • User can update installed Apps
  • User can be notified of available updates
  • User can use device and apps while download is in progress
  • User can be notified of insufficient disk space to download update
  • User can be notified of insufficient battery life to conduct update
  • User can review update file size before and after install
  • User can review update details before and after install


Development/Software Channels

  • The requirement is to offer 3 channels for delivering the B2G software stack to users. Each channel will include consistent versions of Gonk, Gecko and Gaia. The proposed channels are:
    • Nightly
    • Beta
      • Weekly stable builds that users can stay on to get the latest bugs fixes and feature enhancements.
    • Release
  • All phones manufactured should default to the Release channel.


References


Gonk (Kernel) Updates

Introduction

  • Changes to this layer in the software stack should only be made when it is absolutely necessary. The requirement here is to ensure a stable build at this level of the software to minimize any issues with the phone at the Gaia level.
  • The update process proposal is take planned fixes here 1 time per quarter and only urgent security/showstopper bugs immediately as needed (and as per our agreement with the carrier partner).
  • Based on a mutual agreement, the OEM or Mozilla will need to host the FOTA servers to support Kernel updates
  • We cannot guarantee user data and device operability is restored to previous version in event of interrupted or corrupted install.

Open questions

  • OTA system updates are high risk because it is possible to brick the device in the process, correct? If so, how do we mitigate that risk?
  • What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?)
  • Do we require the user to plug in the phone if battery is below X %?
    • (sicking) This is somewhat technically doable, but a UX decision if we actually want to. What we can't do is estimate how good the battery is. I think an old "worn out" battery will fall much quicker in battery level than a new one. It's also hard to get a good estimate of how much battery is needed, but we can certainly require battery levels much higher than what's needed (say 30%).
  • What prompts do we present to user?
  • Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no...
  • What is time to install? Several minutes?
  • Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example.
    • (sicking) We don't have good mechanisms for giving lower priority or throttling individual channels in Necko right now. We technically could detect other downloads starting through and abort the update in that case, and then resume once we detect user inactivity.
  • How many reboots are required in the process? Previous April discussion w/ cjones indicated two.
  • Do we provide link to changelog so user can review update details before installing?
    • (sicking) I think this is up to UX to set requirements. Seems technically feasible, but I'm not convinced it's needed given that in every instance we'll likely want to apply the update for security reasons.
  • How large are these updates?
  • Do we check for available device storage before downloading? If insufficient, how do we mitigate?
  • If the user powers down the device while an update is silently downloading in background, can we resume download later on?
    • (sicking) Necko has the ability to download ranges, but this also needs server support. We certainly could require such support though.
  • How much user agency do we provide over installs? Can they defer? For how long? What affordances do we make for out of date software?
  • How can the user review the currently-installed version? From Settings?

Gecko Updates

Introduction

  • See the B2G Gecko update meta bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=715816
  • Gecko updates can happen more frequently than Kernel updates. Based on input from carriers and OEMs, it likely updates at this layer will need to happen somewhere between the current Desktop 6-week train interval and ESR (every 42 weeks).
  • The proposed requirement here is to offer regular updates every 18 weeks. This frequency offers Mozilla and our partners the ability to update functionality on the device at a quicker pace than other competitor OS stacks (iOS and Android), but at the same time not overwhelm our Carrier partners who may not be used to updating software so frequently.
  • Other requirements here are to offer a back-up instance of Gecko to ensure we can failover when necessary (if we somehow shipped an updated Gecko version that resulted in a bug).
  • The updates at the Gecko level should happen silently where the user is not aware of when this is happening.
  • The user will not be charged any carrier network fees for any Gecko update (as agreed upon by Telefonica) given they will be making these updates via a private APN.
  • The user should be able to go into Settings > About to determine the version of the software the are using in order to debug and/or get support for any issue they encounter.

Open questions

  • What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?)
    • (marshall_law)
    • For user prompting sequence / rules, see the requirements laid out by cjones in these bugs:
    • Currently, the plan is to automatically download any Gecko updates to /data/local/updates. IIRC we are working w/ carriers to make sure this isn't billable data.
    • After an update is downloaded, the update is staged in /system/b2g/updated, and the b2g process is cleanly shutdown (and then restarted by the system)
    • Soon after bootup of the new b2g process, the updater runs again, copying the staged updates into /system/b2g to make them live.
    • Note: The updater process will re-mount /system as read-write when it starts, and back to read-only when it exits. This will happen for both staging, and copying the staged files in place. In the event of a failure remounting /system as read-only (before exit), the device will be restarted, allowing the system to mount /system as read-only. See https://bugzilla.mozilla.org/show_bug.cgi?id=764683 for more details
    • (/marshall_law)
    • How different is process from Gonk updates?
  • How often should we check for Gecko update?
    • Every 18 weeks, according to CLee's etherpad outline...
      • (sicking) This sounds too rare given that we ship Gecko updates every 6 weeks which always contain security updates. Usually we count on security researchers being able to reverse engineer those updates and create exploits for older versions of Gecko.
      • (marshall_law) IIRC the reasoning had to do with risk mitigation from carriers (it was a compromise of some kind?)
  • Can we confirm that there will be a back-up instance of Gecko in event of failed updates? If so, what will sequence of it's application be?
  • Does being on 3G/Edge affect when we check for Gecko updates?
    • Should not, since updates will be free OTA via Carrier's private APN.
  • What—if anything—should we tell the user when a Gecko updated is detected? Should we behave differently if the user is on 3G/Edge connection when we detect that an update is available?
    • Download update and apply silently in background, same as Gonk process? Might be too intrusive for these more frequent (18 weeks) Gecko updates?
    • (marshall_law) see above
  • Do we have the technical ability to download the update in the background and only notify the user once the new version is available?
    • (marshall_law) yes
  • Should we do anything special if the phone has been turned off for a few days and is then started?
    • (marshall_law) IIRC, the existing Gecko update internals already have the logic for knowing how long it's been since the last update check. They should be able to detect this and do an update check as soon as the phone is on. We should confirm this, though.
  • Do we need to have a mechanism for pushing extra-critical updates?
  • Should we inform users about how big updates will be before downloading them? Do we have the ability to tell before doing the actual download?
    • (marshall_law) We do have the ability -- the update MAR format specifies update size. We don't currently have plans to inform about the size of an update, but feel free to chime in on any of the bugs listed on how that might work.
  • Do we require the user to plug in the phone if battery is below X %?
    • (sicking) See answer for Gonk
  • What prompts do we present to user?
    • (marshall_law) see above
  • Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no...
    • (marshall_law) we do in Phase 2, which I don't think we plan to have for v1. Will need to check w/ cjones to verify though
  • What is time to install? Several minutes?
    • (marshall_law) It all depends on the size of the update, the speed of the internal disk, the device hardware.. :) We might want to profile this in a few configurations..
  • Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example.
    • (marshall_law) yes, see the bugs about prompting
  • How many device reboots are required in the process?
    • (marshall_law) for Gecko, there shouldn't be any. only a process restart is required. the only time a restart might happen is if /system is somehow left in read-write after the updater is finished, as a fail safe.
  • Do we provide link to changelog so user can review update details before installing?
  • How large are these updates?
    • (marshall_law) they are binary diff'd, so potentially not "huge", but again this all depends on how big the update is. definitely smaller than if we were downloading fresh binaries.
  • Do we check for available device storage before downloading? If insufficient, how do we mitigate?
  • If the user powers down the device while an update is silently downloading in background, can we resume download later on?
    • (sicking) See answer for Gonk
  • How much user agency do we provide over installs? Can they defer? For how long? What affordances do we make for out of date Gecko?
  • How can the user review the currently-installed version? From Settings?

Gaia Updates

Introduction

  • Gaia updates are related to anything that may modify the user interface and experience of the OS. The update interval will also be every 18-weeks to align with Gecko updates.
  • Updates that happen to the Core Apps (Dialer, SMS, Camera, etc.) will happen silently and users will not be charged any carrier network fees for Gaia System and Core App updates (similar to Gecko updates via a private APN). All core apps should be updated simultaneously so that a single B2G version represents the full stack.

Open questions

  • How much are we testing Core app updates before delivering these updates to the APN?
    • This will be tested at the same level we are testing starndard 3G connectivity to the carrier network? From CLee's etherpad outline...
  • Same questions from Gecko apply here:
  • What is the sequence of events (eg: prompt user to restart device, whereupon install process runs?)
    • How different is process from Gecko updates?
  • How often should we check for updates?
  • Will there be a back-up instance of Gaia in event of failed updates? If so, what will sequence of it's application be?
  • Does being on 3G/Edge affect when we check for Gecko updates?
    • Should not, since updates will be free OTA via Carrier's private APN.
  • What—if anything—should we tell the user when a Gecko updated is detected? Should we behave differently if the user is on 3G/Edge connection when we detect that an update is available?
    • Download update and apply silently in background?
  • Do we have the technical ability to download the update in the background and only notify the user once the new version is available?
  • Should we do anything special if the phone has been turned off for a few days and is then started?
  • Do we need to have a mechanism for pushing extra-critical updates?
  • Should we inform users about how big updates will be before downloading them? Do we have the ability to tell before doing the actual download?
  • Do we require the user to plug in the phone if battery is below X %?
  • What prompts do we present to user?
  • Do we have a rollback strategy for failed installs? Previous April discussion w/ cjones indicated no...
  • What is time to install? Several minutes?
  • Can we avoid user friction by downloading silently, and only during periods of user inactivity? Would not want to slow down web browsing while update processed in background, for example.
  • How many device reboots are required in the process?
  • Do we provide link to changelog so user can review update details before installing?
  • How large are these updates?
  • Do we check for available device storage before downloading? If insufficient, how do we mitigate?
  • If the user powers down the device while an update is silently downloading in background, can we resume download later on?
  • How much user agency do we provide over installs? Can they defer? For how long? What affordances do we make for out of date Gaia + Core apps?
  • How can the user review the currently-installed version? From Settings?


App Updates

Introduction

Apps can be divided into two categories, each with their own update policies.

  • Core apps
  • Pre-installed 3rd party apps
  • User-installed apps

Core apps

About

  • Are all packaged apps
  • Are pre-installed with the OS
  • Are not user-removable
  • Will survive a factory reset
    • We ensure that Core apps are available after a factory reset by storing them in the System partition, in /system/b2g/webapps, instead of the usual /data/local/webapps.

Updates

  • Core apps updates are bundled with Gecko updates, and are therefore governed by Gecko update policies.


Pre-installed third party apps

About

  • These are 3rd party apps that come bundled with the phone.
  • Are governed by same rules as User-installed apps.

Updates

  • Are governed by same rules as User-installed apps.

Open questions

  • Can these be uninstalled by the user
  • What happens with these on a factory reset? Are they removed if installed? Re-spawn if uninstalled?

User-installed apps

About

  • Can be packaged or non-packaged
    • Differences between packaged and non-packaged apps should generally not be surfaced to the user.
    • For both types, we ensure that they stay up-to-date by checking for new versions at regular intervals.
  • Updates are not be free and will incur data charges when on the carrier’s network.

Non-packaged app updates

  • Non-packaged apps can specify the location of an offline-cache manifest to be loaded at install time. This offline-cache is subsequently updated.
  • Update availability is checked by polling the developer website.
  • We don't yet have the ability to tell a packaged app that an update is available.

Packaged app updates

  • Update availability is checked by polling the store to see whether a new package available.
  • We also have the ability to tell the app that an update is available.

Deferred download

  • We have the ability to download and install app updates while the previous versions are running. The new version is made available on app restart.

Open questions

  • How often should we check for app update?
    • Once a day, only on WiFi?
  • Does the frequency of usage affect how often we check for app updates?
  • Does being on 3G/Edge affect when we check for app updates?
  • What should we tell the user when an app update is detected?
  • What should we tell the user when an app update is detected while the app is running, or should we rely on the app to do so? (note that while we can inform a running app about an update being available, we can't detect if the app is actually doing anything useful with that information)
  • Should we behave differently if the user is on 3G/Edge connection when we detect that an update is available?
  • Can the user inspect permissions enumerated in the app at the time of installation? Should we let the user know if an update expands the list of permissions?
  • Do we need to have a mechanism for pushing extra-critical updates?
  • Should we inform users about how big updates will be before downloading them?
    • For un-packaged apps we generally can't tell how big an update is going to be. We could implement mechanisms for doing estimates, but we don't have anything right now
    • For packaged apps we could implement such a mechanism, but it depends on the protocols we use (see below):
    • What protocol should we use for detecting that an app update is available and downloading the update? This is a question we need to hammer out with the store people and the AMO people who have a lot of experience with updates for addons. The last two solutions involve new server-side APIs to be defined, but could potentially be more efficient. Three possibilities which have been discussed:
      • Check if the HTTP Etag of the package has changed by sending a conditional HTTP request with a If-None-Match header. This is what the work-in-progresss implementation in bug 772364 is doing.
      • Group all the applications by store, and send to each store the list to check with ones to update. This could also return hashes for the new packages which could be safely downloaded from mirrors.
      • If the user has authentication credentials with a store, use a store specific api to get a list of updated applications.
  • Should we enable batch download of updates?
  • Should we indicate download+install progress to user?
  • Should we surface "this app has been updated" information to user?
  • Do we create user configuration options? eg:
    • Download and install apps in background.
  • How do we ensure backwards compatibility for apps that cannot update? eg: User is on Edge connection and rarely accesses via WiFi. Would their apps stop working once they are out of date?


mozApps API Changes

To support the previously described behaviour, we need a couple of additions to the content facing mozApps API, on the Application object:

  • Add a |readonly boolean removable| property.
  • Add a |DOMEventListener onupdated| event listener to be notified when an application has been updated. This let a dashboard update any displayed item that could have changed (icon, application name, etc.)

Open questions:

  • Do we also need an event signaling that an update is available?
  • Do we also need an event signaling that an update has been downloaded?
Retrieved from "https://wiki.allizom.org/index.php?title=Gaia/System/Updates&oldid=459212"