816
edits
Gaia/System/Updates: Difference between revisions
Jump to navigation
Jump to search
→Gonk (Kernel) Updates
m (→Introduction) |
|||
| Line 62: | Line 62: | ||
== Introduction == | == Introduction == | ||
* | * Updates to this layer in the software stack should only be made when absolutely necessary. | ||
* The | * Updates are made to ensure a stable build and minimize any conflicts with Gaia. | ||
* The proposal is to update regularly once per quarter, and immediately in event of urgent security/showstopper bugs (subject to 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 | * 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 functionality is restored to previous version in event of interrupted or corrupted install. | * We cannot guarantee user data and device functionality is restored to previous version in event of interrupted or corrupted install. | ||
== Proposed high-level requirements == | |||
==== Josh Carpenter, Aug 15 ==== | |||
* Minimize the risk of unsuccessful install, the consequences of which can include bricking the device (!) | |||
* Minimize the need for user intervention, but provide detailed information for more advanced users. Simple by default, advanced as optional. | |||
* Minimize user interruption. Do not impede the user's control of the device. | |||
== Open questions == | == 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? | * 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 | * What is are the technically-necssary events in the update process? (eg: restart device, whereupon install process runs, device restarts again, boot up?) | ||
* Do we require the user to plug in the phone if battery is below X %? | * 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%). | ** (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%). | ||
* | * There is no rollback feature for failed installs, correct? Previous April discussion w/ cjones indicated no... | ||
* 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. | * 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. | ** (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. | ||
| Line 81: | Line 88: | ||
* Do we provide link to changelog so user can review update details before installing? | * 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. | ** (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. | ||
* | * Approximately how large are these updates? | ||
* What is time to install? Several minutes? | |||
* Do we check for available device storage before downloading? If insufficient, how do we mitigate? | * 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? | * 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. | ** (sicking) Necko has the ability to download ranges, but this also needs server support. We certainly could require such support though. | ||
* | * Can user defer installs? If so, for how long? | ||
* | * What affordances do we make for out of date software? eg: Presumably I cannot update to a new version of Gaia if my Gonk or Gecko are out of date. | ||
* Can the user review the currently-installed version? From Settings? | |||
= Gecko Updates = | = Gecko Updates = | ||