Software Update:updates.xml Format

Background

The updates.xml format is the format used by the AUS server to advertise updates that are available to clients.

Format

A typical updates.xml file looks like this:

<?xml version="1.0"?>

<updates>
  <update type="minor" version="1.0.4" extensionVersion="1.0" 
          detailsURL="http://www.foo.com/1.0.4/whatsnew.html">
    <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" extensionVersion="1.1"
          detailsURL="http://www.foo.com/1.1.2/whatsnew.html">
    <patch type="complete" url="http://www.foo.com/1.1.2-complete.xpi"
           hashFunction="" hashValue="" size=""/>
  </update>
</updates>

Elements & Attributes

Every updates.xml contains a updates element as its root. This element has no attributes.

Beneath updates lives a sequence of update elements, each describing an update to an individual application version.

The attributes for update are as follows:

type	major or minor. Major updates are for major application number revs, minor for security releases or incremental updates.
version	A string in FVF format advertising the version of this application update.
extensionVersion	A string in FVF format advertising the version of the extension API that this application update supplies
detailsURL	A URL string to a web page with more information about the specified update. This will be shown in the UI to the user when they are presented with the option to upgrade.
licenseURL	A URL string to a web page with additional license terms that need to be accepted before the update can be installed (optional, do NOT provide it if this is going to be empty)
isSecurityUpdate	true for security updates, to present a scarier warning to users, false if the update is not a security update we are not heeding this value, nor is AUS setting it, see https://bugzilla.mozilla.org/show_bug.cgi?id=329729#c75 for details
buildID	The BuildID of the build being offered

Within an update element there must be at least one and no more than two patch elements. The patch element describes a patch file that lives on a remote server that must be downloaded and applied to the application to update it to that version. They describe either binary differences between versions of the application (partial patches), or complete updates that replace and remove files as necessary. The attributes for patch are as follows:

type	partial or complete, depending on the patch.
url	A URL to the remote patch file.
hashFunction	The name of the hash function to execute to verify the integrity of the patch.
hashValue	The server-generated hash generated for the file. If the client generated value does not match this, the integrity check fails after download.
size	The size of the update, in bytes.

Additional Client Metadata

The client uses this same format to collect a history of installed updates. In the process, it caches the update file locally in two places:

bin/active-update.xml (the update in progress, persisted across sessions) bin/updates.xml (updates performed in the past)

These files may contain additional attributes representing update state stored by the client.