Gaia/System/Updates: Difference between revisions

Jump to navigation Jump to search

Gaia/System/Updates (view source)

Revision as of 06:22, 16 August 2012

7,191 bytes added ,  16 August 2012
no edit summary
No edit summary
Line 227: Line 227:
* 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) See answer for Gonk
** (sicking) See answer for Gonk
= Gecko+Gaia: Draft process for atomic Gecko+Gaia updates =
Josh Carpenter, Aug 15
== Overview ==
==== Design principles ====
* Silent. 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.
==== Steps ====
# Check for update
# Confirm available drive space
# Check connection
# Download
# Check Battery
# Install
# Follow-up
== 1. Check for update ==
=== Automatic (push) ===
* Update server pushes silent "update available" notification to device.
=== Automatic (poll) ===
* Device checks with server for available update at scheduled time/interval.
===  Manually ===
* User initiates "Check for Updates" via UI input. Probably from Settings > Device > Device Information (although this has not been specced yet).
== 2. Confirm available drive space ==
# Check size of download.
# Check there is sufficient storage on device to download the update. Define minimum sufficient storage as some multiple of the update file size, in order to leave sufficient room for day to day device operation.
=== Sufficient (download size x 2) ===
Proceed to next step.
=== Insufficient ===
Two possibilities: fail silently, or user prompt.
==== Fail Silently ====
Fail silently if update process was initiated Automatically (Push or Poll).
* Update fails and goes into Wait state.
* X minutes/hours/days (?) elapse -> Check sufficient storage again.
==== Prompt ====
Prompt user if update process was initiated Manually, and device is On and Unlocked. Contents as follows:
* Image: Icon
* Title: "Update available"
* Body: "A FxOS update is available there is not enough space to download it. Free up space by deleting videos, files, etc."
* Input: "OK"
User presses [OK]:
* Update fails and goes into Wait state.
* X minutes/hours/days (?) elapse -> Check sufficient storage again.
Because these prompts interrupt the user, we should consider a nuanced approach. For example, upon second prompt give user option to not be reminded again (although that creates fragmentation problems), or to choose between two varying reminder intervals (eg: 1 Day and 1 Week).
== 3. Check connection ==
Ensure updates are free for user by taking into account connection type before downloading.
=== No connection ===
The Network Status is one of following:
* Airplane Mode
* Searching
* No Network
Update process can encounter this when:
* Process is Manually initiated.
* Process was Automatically initiated, but delayed due to insufficient drive space, and connection type has changed in meantime.
The Update process fails. Two possibilities (same as the two possibilities under "Paid", below).
=== WiFi ===
Proceed to next step.
=== Free (APN) ===
Proceed to next step.
=== Paid ===
User is on paid data connection, probably Roaming. To avoid incurring charges, update fails. Two possibilities:
==== Silent ====
Fail silently if update process was initiated Automatically (Push or Poll).
* Update fails and goes into Wait state.
* Exit Wait state when one of following occurs:
** Connection type changes (eg: upon connection type change push the new type to the Updater)
** Time interval passes (eg: check connection type every X hours/days)
** New update push notification is received. Restart update process.
==== Prompt ====
Prompt user if update process was initiated Manually, and device is On and Unlocked. Contents as follows:
* Image: Icon
* Title: "Cannot download update" (verbiage TBD)
* Body: "There is no data connection. FxOS cannot be updated. Connect to a WiFi or Data connection." (verbiage TBD)
* Input: "OK"
User presses [OK]:
* Update fails and goes into Wait state.
* Exit Wait state when one of following occurs:
** Connection type changes (eg: upon connection type change push the new type to the Updater)
** Time interval passes (eg: check connection type every X hours/days)
** New update push notification is received. Restart update process.
There's a lot room to improve the flow of this scenario. eg:
* Detect reason for failure (eg: Airplane mode vs Roaming) and tailor prompt accordingly (eg: present option to turn Airplane Mode off).
* Check available WiFi connections and offer user chance to connect if an Open and/or Remembered network is detected.
== 4. Download ==
Once initiated, downloads are as follows:
* Silent & invisible (no visible UI such as progress bars)
* Pause for user network activity
* Auto-complete in event of interruption. eg:
** Connection type changes to Roaming.
** Connection type changes to Airplane Mode.
** User turns off device.
** Battery dies.
We should also create error handler for: Storage space dropped below minimum threshold during update download. eg: While update is downloading, user copies video to device storage via USB.
Once download is complete, proceed to next step.
== 5. Check Battery ==
In order to minimize risk of failed update, check battery level before starting installation. Defer or proceed depending on % remaining.
Given the following caveats:
* System can detect current battery level, but not drain rate (varies with battery age)...
* It will be difficult to estimate the amount of power required to complete an install, given variations in device specs, update sizes, etc...
...we should build healthy margins into any "minimum required battery" thresholds. eg: Minimum 30%.
* If minimum threshold is met, proceed to next step.
* If minimum threshold is not met, two possibilities:
=== Fail Silently ===
Put installation into Wait state until future condition is met
Need to flesh this out further.
=== Prompt user ===
Prompt user to plug in to power source in order to proceed. Offer option to cancel, or initiate automatically as soon as power connection is detected.
Need to flesh this out further.
== 6. Install ==
Installation process begins. The are three possibilities, depending on the current state of the device:
=== Manual Install ===
* The device is On and Unlocked.
* Because the installations are disruptive (requires a B2G process restart), the user is first prompted to initiate or defer the installation.
* User has option to install immediately, or defer install.
Need to flesh this out further.
=== Silent Install ===
* The device is On, Locked, and the likelyhood of use is low (eg: it is evening)
* The Install process executes without turning on the screen.
* The user is only made aware that the update has occured once it is complete, and they Unlock the device.
Need to flesh this out further.
=== Automatic Install ===
* The device awakens from Off state.
* Occurs when user has deferred a Manual Install prompt, and the device has been powered Off. When the device is turned On, we automatically install the update (after running another Battery check).
Need to flesh this out further.
== 7. Clean-up ==
After install, we can consider informing the user that the update has occurred, and offer details such as link to update details (eg: "What's new in FxOS").


= Gaia Updates =
= Gaia Updates =
Joshcarpenter
816

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/461487"

Navigation menu