Software Update:Checking For Updates
The Update Service:
- checks for updates to the application on a background timer
- provides a means for the user to check for updates to the application
- provide a set of controls for determining update behavior
The Background Timer
The system will automatically check for updates without user intervention:
- every 24 hours
- on the first startup following an update, to check to see if the patch applied is the newest possible update or if there are newer ones.
The Update Check
- generate update service URL
- determine if updates are available
- determine action
- download patches
- verify patches
- install patches
Update Service URL
The Service URL needs to incorporate data in these dimensions so as to reduce the complexity of the processing on the client side:
- app name
- app locale
- app version
- app buildid (for distinguishing between nightlies on a "tester" build stream for example)
- app buildtarget
e.g.
/firefox/1.0.3.20050414/i586-pc-msvc/en-US/update.xml
The Updates File
update.xml is an XML file that tells about available updates. It is formatted like this:
<?xml version="1.0"?>
<updates>
<update type="minor" version="1.0.4">
<patch type="partial" url="http://www.foo.com/1.0.4-partial.xpi"
hashfunction="" hashvalue="" size=""/>
<patch type="complete" url="http://www.foo.com/1.0.4-complete.xpi"
hashfunction="" hashvalue="" size=""/>
</update>
..
<update type="major" version="1.1.2">
<patch type="complete" url="http://www.foo.com/1.1.2-complete.xpi"
hashfunction="" hashvalue="" size=""/>
</update>
</updates>
The application should provide a preference setting that can be set to hold the application within one version range, e.g. within 1.0.x, never updating to the newest major version but only installing incremental security updates.
The <updates> list specifies the set of updates that can be downloaded and installed and may play a role in updating the application.
Each "partial" update is a diff of the new version from the previous version. If there are several "partial" updates available, they are all downloaded and installed in order. [Note: Initially we may only install a single patch and then rely on a subsequent update check to determine that there are more patches available and install them at that time.]
Before a collection of updates is downloaded and installed, the size attribute for each patch is read to determine file size, and if the sum of the patch sizes is found to be greater than the size of the "complete" patch (which is a jar file whose contents are only file additions, removals and replaces, no file patches), then the "complete" file is downloaded.
We only supply "complete" updates to major versions since we cannot easily pick a version to diff against off of a previous version series, e.g. do we diff off 1.1.4? What if we do a security release 1.1.5 further down the line? It is simpler to make users doing major upgrades redownload the bundle.
This system intrinsically supports updates to the updater - if a point in time is reached at which we can no longer fully update a user to the newest version, we can provide a series of updates that take them to a version that can then be updated further, e.g.
User is using 1.1.1 Newest version is 1.5.9 but due to a bug in the updater in all versions older than 1.1.4, the user cannot update directly to 1.5.9.
The update.xml file for the 1.1.1 user might look something like this:
<?xml version="1.0"?>
<updates>
<update type="minor" version="1.1.2">
<patch type="partial" url="http://www.foo.com/1.1.2-partial.xpi"
hashfunction="" hashvalue="" size=""/>
<patch type="complete" url="http://www.foo.com/1.1.2-complete.xpi"
hashfunction="" hashvalue="" size=""/>
</update>
<update type="minor" version="1.1.3">
<patch type="partial" url="http://www.foo.com/1.1.3-partial.xpi"
hashfunction="" hashvalue="" size=""/>
<patch type="complete" url="http://www.foo.com/1.1.3-complete.xpi"
hashfunction="" hashvalue="" size=""/>
</update>
<update type="minor" version="1.1.4">
<patch type="partial" url="http://www.foo.com/1.1.4-partial.xpi"
hashfunction="" hashvalue="" size=""/>
<patch type="complete" url="http://www.foo.com/1.1.4-complete.xpi"
hashfunction="" hashvalue="" size=""/>
</update>
</updates>
And for the 1.1.4 user like so:
<?xml version="1.0"?>
<updates>
<update type="minor" version="1.1.5">
<patch type="partial" url="http://www.foo.com/1.1.5-partial.xpi"
hashfunction="" hashvalue="" size=""/>
<patch type="complete" url="http://www.foo.com/1.1.5-complete.xpi"
hashfunction="" hashvalue="" size=""/>
</update>
<update type="major" version="1.5.9">
<patch type="complete" url="http://www.foo.com/1.5.9-complete.xpi"
hashfunction="" hashvalue="" size=""/>
</update>
</updates>
So the user of 1.1.1 will have the 1.1.2, 1.1.3, and 1.1.4 patches downloaded and applied in that order. When they start the application the next time, the application will recheck for updates using 1.1.4's enhanced bugfixed updater, and discover 1.1.5 and the 1.5.9 major update.
This implies that the database that manages all of this version information has to know that some updates can only apply to certain version (ranges).
Preference Controls and State
- app.update.enabled
true Enables background update checking false Disables background update checking
- app.update.mode
0 automatically download and install available updates for minor releases, offer updates to major releases 1 automatically download and install available updates for minor releases, do not offer updates to major releases 2 automatically download and install available updates for minor and major releases 3 automatically download available updates for minor and major releases and prompt when ready for installation 4 automatically download available updates for minor releases only prompt when ready for installation
- app.update.interval
86400000 milliseconds between update checks
- app.update.timer
3600000 milliseconds between checks for update interval expiry
- app.update.url
http://aus.mozilla.org/update/firefox/%1%/%2%/%3%/update.xml %1% is the version, in FVF containing the build id; %2% is the build target (OS+Architecture); %3% is the ab-CD locale