816
edits
Gaia/System/Updates: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
There are several types of FxOS updates: | There are several types of FxOS updates: | ||
* Kernel | * Gonk (Kernel) | ||
* Gecko | * Gecko | ||
* Apps | * Gaia | ||
* | * Apps | ||
** Packaged | ** Core | ||
** Non-packaged | ** Pre-installed third party | ||
** User-installed | |||
*** Packaged | |||
*** Non-packaged | |||
| Line 40: | Line 43: | ||
== Development/Software Channels == | |||
= Kernel Updates = | * 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. | |||
= Gonk (Kernel) Updates = | |||
== Introduction == | == Introduction == | ||
| Line 72: | Line 85: | ||
* Do we need to have a mechanism for pushing extra-critical updates? | * 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? | * 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? | ||
= 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. [don't mind about Gaia updates really, just need to make sure they're somehow tied to specific Gecko updates to limit the test matrix -akeybl] | |||
* 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 system bits, see previous note] | |||
== Open questions == | |||
* How much are we testing Core app updates before delivering these updates to the APN? | |||
** [clee]: This will be tested at the same level we are testing starndard 3G connectivity to the carrier network. | |||
| Line 81: | Line 108: | ||
* Core apps | * Core apps | ||
* Pre-installed 3rd party apps | |||
* User-installed apps | * User-installed apps | ||
| Line 89: | Line 117: | ||
== | == Core apps == | ||
=== About | === About === | ||
* Are all packaged apps | * Are all packaged apps | ||
| Line 105: | Line 133: | ||
== | == 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. | ||
== User-installed apps == | |||
=== About === | |||
* Can be packaged or non-packaged | * Can be packaged or non-packaged | ||
** Differences between packaged and non-packaged apps should generally not be surfaced to the user. | ** 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. | ** 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 app updates === | ||
| Line 135: | Line 177: | ||
* Does being on 3G/Edge affect when 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? | ||
* 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 | * 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) | ||
information) | |||
* Should we behave differently if the user is on 3G/Edge connection when we detect that an update is available? | * 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? | * 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? | ||
| Line 167: | Line 208: | ||
* Do we also need an event signaling that an update is available? | * 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? | * Do we also need an event signaling that an update has been downloaded? | ||