Gaia/System/Updates/Apps: Difference between revisions

From MozillaWiki
< Gaia‎ | System‎ | Updates
Jump to navigation Jump to search
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
= App Updates =
= App Updates: Background =  


== Introduction ==
== App Types ==


Apps can be divided into three categories, each with their own update policies.
There are three types of installed apps, each with their own update policies.


* Core apps
* Core apps
* Pre-installed 3rd party apps
** Are packaged, certified, pre-installed, non-removable.
** Are only updated within Full System or atomic Gecko+Gaia updates.
* Pre-installed third-party apps
** Are updated subject to same update policies as User-installed apps (see below)
* User-installed apps
* User-installed apps
** Are packaged or hosted.
** Update policies are described in rest of this page.


== Core apps ==
== Users ==


=== About ===
For initial FxOS versions, should assume the following about users:


* Are all packaged apps
* '''Data is slow, expensive, and intentionally constrained.'''
* Are pre-installed with the OS
* Very limited access to WiFi
* Are not user-removable
* Rarely in Roaming mode
* Will survive a factory reset
* Turn data connections off by default, and only activate for brief transactions.
** 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.
* Use multiple SIM cards.
* Users think Installed vs Un-installed. Not Free vs Paid. (per Jonas)
* Packaged apps can specify version notes within their mini-manifests
*


=== Updates ===
== Technical parameters ==


* Core apps updates are bundled with Gecko updates, and are therefore governed by Gecko update policies.
* Can poll Marketplace for update.
* Will evaluate pushing updates to users in future versions.
* Marketplace will know current version off app.
* Updates can download and install while current version is open.
* There is relatively low risk of new app versions breaking old.
* There is a higher risk of Gecko changes breaking apps.
* Content servers will know version of the installed app that they are sending content to.
* Good apps will provide backwards compatibility
* App revocation will be handled by the store. It will sign a special update with a "revoked" app type (vs. "certified" or  "privileged").
* Manifest enables devs to specify specific features required by apps.


Hosted apps


* We cannot separate "Poll for update", from "Start update".
* We can specify when poll happens, however. For v1 we can Add additional checks. But we cannot remove the  "Poll on Open" behavior).
* Have no way of knowing file size (contents are remotely hosted).
* Current version can be used while new version downloads in background.


== Pre-installed third party apps ==


=== About ===
== Developers ==


* These are 3rd party apps that come bundled with the phone.
* Web devs are used to users always being on latest version. Simplifies development.
* Are governed by same rules as User-installed apps.
* Security also benefits when as many users as possible are up-to-date.


=== Updates ===


* Are governed by same rules as User-installed apps.
= Questions =


=== Open questions ===
* How are 3rd party apps tested with different versions of b2g releases?
* What needs to be exposed regarding privacy? e.g. What data are sent for updates?
* What happens when the manifest version changes?  Does this trigger any sort of notification for the user?


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


== User-installed apps ==
== Design principles ==


=== About ===
* Low-friction. Minimize user interruptions, connection speed impacts, etc.
* Free. Avoid user charges.
* Safe. Minimize changes and consequences of failed updates.
* Patient. Support backwards compatibility for users who cannot update.
* Friendly. Avoid presenting users with excess technical details.


* Can be packaged or non-packaged
== Design Specs ==
** Differences between packaged and non-packaged apps should generally not be surfaced to the user.
For the latest UX specifications, please visit
** For both types, we ensure that they stay up-to-date by checking for new versions at regular intervals.
https://mozilla.box.com/system
* Updates are not be free and will incur data charges when on the carrier’s network.


=== Non-packaged app updates ===
== Update Types ==


* Non-packaged apps can specify the location of an offline-cache manifest to be loaded at install time. This offline-cache is subsequently updated.
* Manual: Individual
* Update availability is checked by polling the developer website.
* Manual: Batch
* We don't yet have the ability to tell a packaged app that an update is available.
* Silent
 
=== 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?

Latest revision as of 19:04, 30 May 2013

App Updates: Background

App Types

There are three types of installed apps, each with their own update policies.

  • Core apps
    • Are packaged, certified, pre-installed, non-removable.
    • Are only updated within Full System or atomic Gecko+Gaia updates.
  • Pre-installed third-party apps
    • Are updated subject to same update policies as User-installed apps (see below)
  • User-installed apps
    • Are packaged or hosted.
    • Update policies are described in rest of this page.

Users

For initial FxOS versions, should assume the following about users:

  • Data is slow, expensive, and intentionally constrained.
  • Very limited access to WiFi
  • Rarely in Roaming mode
  • Turn data connections off by default, and only activate for brief transactions.
  • Use multiple SIM cards.
  • Users think Installed vs Un-installed. Not Free vs Paid. (per Jonas)
  • Packaged apps can specify version notes within their mini-manifests

Technical parameters

  • Can poll Marketplace for update.
  • Will evaluate pushing updates to users in future versions.
  • Marketplace will know current version off app.
  • Updates can download and install while current version is open.
  • There is relatively low risk of new app versions breaking old.
  • There is a higher risk of Gecko changes breaking apps.
  • Content servers will know version of the installed app that they are sending content to.
  • Good apps will provide backwards compatibility
  • App revocation will be handled by the store. It will sign a special update with a "revoked" app type (vs. "certified" or "privileged").
  • Manifest enables devs to specify specific features required by apps.

Hosted apps

  • We cannot separate "Poll for update", from "Start update".
  • We can specify when poll happens, however. For v1 we can Add additional checks. But we cannot remove the "Poll on Open" behavior).
  • Have no way of knowing file size (contents are remotely hosted).
  • Current version can be used while new version downloads in background.


Developers

  • Web devs are used to users always being on latest version. Simplifies development.
  • Security also benefits when as many users as possible are up-to-date.


Questions

  • How are 3rd party apps tested with different versions of b2g releases?
  • What needs to be exposed regarding privacy? e.g. What data are sent for updates?
  • What happens when the manifest version changes? Does this trigger any sort of notification for the user?

User Experience

Design principles

  • Low-friction. Minimize user interruptions, connection speed impacts, etc.
  • Free. Avoid user charges.
  • Safe. Minimize changes and consequences of failed updates.
  • Patient. Support backwards compatibility for users who cannot update.
  • Friendly. Avoid presenting users with excess technical details.

Design Specs

For the latest UX specifications, please visit https://mozilla.box.com/system

Update Types

  • Manual: Individual
  • Manual: Batch
  • Silent
Retrieved from "https://wiki.allizom.org/index.php?title=Gaia/System/Updates/Apps&oldid=661863"