Installing and updating applications

  • Revision slug: Mozilla/Firefox_OS/Security/Installing_and_updating_applications
  • Revision title: Installing and updating applications
  • Revision id: 307367
  • Created:
  • Creator: Sheppy
  • Is current revision? No
  • Comment

Revision Content

{{draft()}}

This article serves as a guide to the application update process on Firefox OS.

Note: Application updating support has not been completed yet.

Implementation overview

App categories

There are three basic categories of applications that are updated using this mechanism:

Core applications
The core applications (those that are shipped as part of the base Firefox OS, such as Dialer) are packaged, certified, pre-installed, and non-removable. These are only updated during a full system upgrade or an update of the Gonk and Gaia levels.
User-installed applications
Applications installed by the user are either packaged or hosted. The update policy for these is the primary topic of this article.
Pre-installed third-party apps
Apps that are pre-installed by the carrier or vendor, but are not part of the core operating system platform, are updated subject to the same rules and guidelines as user-installed applications.

Assumptions about users

For at least early versions of Firefox OS, the following assumptions are made about users:

  • Data transfer is slow, expensive, and intentionally constrained; in other words, we assume that the user has a slow data connection and a limited amount of traffic permitted each month.
  • We assume that the user has little or no access to WiFi; most updates will be performed over their cellular data connection.
  • Devices are rarely roaming.
  • Users keep their data service disabled by default, enabling it only to complete certain transactions.
  • Users keep and use multiple SIM cards.

These are all common user conditions in many countries, so they're fair assumptions to make. Our goal is to try to optimize the updating experience for people for which these apply. These assumptions generally won't negatively impact users that have cheap access to fast WiFi.

Technical design parameters

This section covers a few design principles for the implementation of application updates in Firefox OS.

  • For now, the device will periodically poll the Marketplace for updates; we will later evaluate the possibility of automatically pushing updates.
  • The Marketplace will know the current version of each app.
  • Updates can be downloaded and installed while the current version of the app is open with a low level of risk that this will break the currently-running app.

Developer considerations

This section covers a few things of note to developers in regard to the application update model.

  • Web developers are used to users always being on the latest version of their site; keeping apps up-to-date emulates this model.
  • Security is also improved when as many users as possible are kept up-to-date.

User experience

Design principles

In order to have the best user experience possible in regard to application updating, a few core principles will be kept in mind:

  • Updates should minimize impact to the user; don't interrupt the user any more than necessary, don't adversely impact their connection speed, and so forth.
  • Don't charge the user to update their apps.
  • Minimize the consequences of failed updates.
  • Support backward compatibility for users who can't update their apps, or aren't able to update them often.
  • Avoid presenting users with unneccessary technical details.

Update types

There are three basic types of update:

Manual: individual
This is a user-initiated update of a single application.
Manual: batch
This is a user-initiated update of multiple applications at once.

Revision Source

<p>{{draft()}}</p>
<p>This article serves as a guide to the application update process on Firefox OS.</p>
<div class="note">
  <p><strong>Note:</strong> Application updating support has not been completed yet.</p>
</div>
<h2>Implementation overview</h2>
<h3 id="App_categories">App categories</h3>
<p>There are three basic categories of applications that are updated using this mechanism:</p>
<dl>
  <dt>
    Core applications</dt>
  <dd>
    The core applications (those that are shipped as part of the base Firefox OS, such as Dialer) are packaged, certified, pre-installed, and non-removable. These are only updated during a full system upgrade or an update of the Gonk and Gaia levels.</dd>
  <dt>
    User-installed applications</dt>
  <dd>
    Applications installed by the user are either packaged or hosted. The update policy for these is the primary topic of this article.</dd>
  <dt>
    Pre-installed third-party apps</dt>
  <dd>
    Apps that are pre-installed by the carrier or vendor, but are not part of the core operating system platform, are updated subject to the same rules and guidelines as user-installed applications.</dd>
</dl>
<h3 id="Assumptions_about_users">Assumptions about users</h3>
<p>For at least early versions of Firefox OS, the following assumptions are made about users:</p>
<ul>
  <li>Data transfer is slow, expensive, and intentionally constrained; in other words, we assume that the user has a slow data connection and a limited amount of traffic permitted each month.</li>
  <li>We assume that the user has little or no access to WiFi; most updates will be performed over their cellular data connection.</li>
  <li>Devices are rarely roaming.</li>
  <li>Users keep their data service disabled by default, enabling it only to complete certain transactions.</li>
  <li>Users keep and use multiple SIM cards.</li>
</ul>
<p>These are all common user conditions in many countries, so they're fair assumptions to make. Our goal is to try to optimize the updating experience for people for which these apply. These assumptions generally won't negatively impact users that have cheap access to fast WiFi.</p>
<h3>Technical design parameters</h3>
<p>This section covers a few design principles for the implementation of application updates in Firefox OS.</p>
<ul>
  <li>For now, the device will periodically poll the Marketplace for updates; we will later evaluate the possibility of automatically pushing updates.</li>
  <li>The Marketplace will know the current version of each app.</li>
  <li>Updates can be downloaded and installed while the current version of the app is open with a low level of risk that this will break the currently-running app.</li>
</ul>
<h3>Developer considerations</h3>
<p>This section covers a few things of note to developers in regard to the application update model.</p>
<ul>
  <li>Web developers are used to users always being on the latest version of their site; keeping apps up-to-date emulates this model.</li>
  <li>Security is also improved when as many users as possible are kept up-to-date.</li>
</ul>
<h2>User experience</h2>
<h3>Design principles</h3>
<p>In order to have the best user experience possible in regard to application updating, a few core principles will be kept in mind:</p>
<ul>
  <li>Updates should minimize impact to the user; don't interrupt the user any more than necessary, don't adversely impact their connection speed, and so forth.</li>
  <li>Don't charge the user to update their apps.</li>
  <li>Minimize the consequences of failed updates.</li>
  <li>Support backward compatibility for users who can't update their apps, or aren't able to update them often.</li>
  <li>Avoid presenting users with unneccessary technical details.</li>
</ul>
<h3>Update types</h3>
<p>There are three basic types of update:</p>
<dl>
  <dt>
    Manual: individual</dt>
  <dd>
    This is a user-initiated update of a single application.</dd>
  <dt>
    Manual: batch</dt>
  <dd>
    This is a user-initiated update of multiple applications at once.</dd>
</dl>
Revert to this revision