Gaia/System/Updates/Apps: Difference between revisions

From MozillaWiki
< Gaia‎ | System‎ | Updates
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
= App Updates: Overview =
= 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 ===
 
* 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.
For initial FxOS versions, should assume the following about users:
* 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.


=== Package apps ===
* '''Data is slow, expensive, and intentionally constrained.'''
 
* Very limited access to WiFi
See section below.
* Rarely in Roaming mode
 
* Turn data connections off by default, and only activate for brief transactions.
=== Answered questions ===
* Use multiple SIM cards.
 
* 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.
 
 
 
== 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.)
 
= Packaged Apps =
 
== Users ==
 
* Limited access to wifi
* Rarely roaming
* Off-by-default data connections
* SIM card swapping
* Expensive data
* Mental models are "installed" vs "not-installed"


== Technical parameters ==
== Technical parameters ==


* Can poll Marketplace for update, or push update to user.
* Can poll Marketplace for update.
* Marketplace will know installed version #.
* Will evaluate pushing updates to users in future versions.
* We can download and install updates while current version is running. New version is then available on app restart
* Marketplace will know current version off app.
* Low risk of new versions breaking old.
* Updates can download and install while current version is open.
* There is relatively low risk of new app versions breaking old.


== Developers ==
== Developers ==


* Web devs are used to their users being on latest version. Makes development easier.
* Web devs are used to users always being on latest version. Simplifies development.
* Long term, we want world where as many users as possible are always on newest app versions. Great for security, development, etc.
* Security also benefits when as many users as possible are up-to-date.


== Challenge ==


* Our long term vision depends on ubquitious, fast, affordable connectivity. But those conditions do not exist in initial launch markets. It may be a challenge convincing users to use and update apps if data connectivity is a requirement.
= User Experience =


== Design principles ==
== Design principles ==
Line 117: Line 48:
* Friendly. Avoid presenting users with excess technical details.
* Friendly. Avoid presenting users with excess technical details.


== User-facing Steps ==
== Update Types
 
* Inform
* Request confirmation
* Show Process
* Confirm success / failure
* Prompt for new permissions at next run
 
== Potential tactics (v2?) ==
 
* Batch process updates?
** Poll Marketplace(s) for list of all available updates, and A) present menu to user with Update Individual and Update All options, and/or B) download automatically.
* Poll less frequently, depending on connection type?
* Poll less frequently, depending on frequency of app use?
* Update all apps automatically with Gecko+Gaia atomic updates?
* Enable users to opt-out? eg: "Don't remind me again"?
* Enable users to specify per-app update permissions? eg: app by app silent update?
* Incentivize updates? "Update for free credits"
* Allow users to set global update preferences?
 
Questions:


* Can/should apps tell inform users of available updates?
* Manual: Individual
* Package apps: require full .ZIP contents update every single time?
* Manual: Batch
* Marketplace maintains receipts of transactions and can be used as update channel?
* Silent
* Can users defer updates and still use app? Sounds like this will be up to app devs to ensure on app-by-app basis?
* How often will packaged apps be updated? It could get obnoxious if I am constantly being pinged by the app to update.
* Do we have strategies to reduce file sizes? ala Binary diffs in Gecko+Gaia updates?

Revision as of 06:10, 23 August 2012

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.

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.

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.


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.

== Update Types

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