Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the BSD License.
©2010 Google
We want extensions to be autoupdated for some of the same reasons as Google Chrome itself: to incorporate bug and security fixes, add new features or performance enhancements, and improve user interfaces.
If you publish your extension using the Chrome Developer Dashboard, you can ignore this page. You can use the dashboard to release updated versions of your extension to users, as well as to the Extensions Gallery or Chrome Web Store.
If you want to host your extension somewhere other than the gallery or store, keep reading. You should also read Hosting and Packaging.
Every few hours, the browser will check if any installed extensions have an autoupdate URL. For each one, it will make a request to that URL looking for an update manifest XML file. If the update manifest mentions a version of an extension that is more recent than what's installed, it will download and install the new version. Similar to manual updates, the new crx must be signed with the same private key as the currently installed version.
For those who are hosting their own extensions, you need to add the "update_url" key to your manifest.json file like this:
{ "name": "My extension", ... "update_url": "http://myhost.com/mytestextension/updates.xml", ... }
The "update manifest" returned by the server should be an XML document that looks like this (parts you'll want to modify highlighted):
<?xml version='1.0' encoding='UTF-8'?> <gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'> <app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'> <updatecheck codebase='http://myhost.com/mytestextension/mte_v2.crx' version='2.0' /> </app> </gupdate>
(This XML format is borrowed from that used by Omaha, Google's update infrastructure. See http://code.google.com/p/omaha/ for more details.)
appid
The 'appid' property is the extension id, generated based on a hash of the extension's public key as described in Packaging. You can find out the id of your extension by going to chrome://extensions.
codebase
The 'codebase' property is a URL to the crx file.
version
This is used by the client to determine whether it should download the crx file at 'codebase'. It should match the version parameter in the crx file's manifest.json file.
The update manifest XML file may contain information about multiple extensions by including multiple <app>
tags.
The default update check frequency is several hours, but you can force an update using the Extensions page's Update extensions now button.
Another option is to use the --extensions-update-frequency command-line flag to set a more frequent interval in seconds. For instance, to make checks run every 45 seconds, you would run Google Chrome like this:
chrome.exe --extensions-update-frequency=45
Note that this affects checks for all installed extensions, so consider the bandwidth and server load implications of this. You may want to temporarily uninstall all but the one extension you are testing with, and should not run with this option turned on during normal browser usage.
The basic autoupdate mechanism is designed to make the server-side work as easy as just dropping a static XML file onto any plain webserver such as apache, and updating that XML file as you release new versions of your extension(s).
More advanced developers may wish to take advantage of the fact that we add on parameters to the request for the update manifest to indicate the extension id and version. Then they can use the same update_url for all of their extensions pointing to a URL running dynamic server side code instead of a static XML file.
The format of the request parameters is:
?x=<extension_data>
where <extension_data>
is an URL-encoded string of the format:
id=<id>&v=<version>
So for example, say we have two extensions installed
Extension 1 with id "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" and version "1.1"
Extension 2 with id "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" and version "0.4"
and that both point at the same update_url: http://test.com/extension_updates.php
The two requests made would be:
http://test.com/extension_updates.php?x=id%3Daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%26v%3D1.1
http://test.com/extension_updates.php?x=id%3Dbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb%26v%3D0.4
Note: in releases before 3.0.196.x there was a bug in how request parameters were put together (http://crbug.com/17469).
While not implemented yet, we will eventually list multiple extensions in a single request for each unique update_url. For the above example, the request would end up being:
http://test.com/extension_updates.php?x=id%3Daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%26v%3D1.1&x=id%3Dbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb%26v%3D0.4
If the number of installed extensions using the same update_url is large enough that a GET request URL would be too long (probably greater than 1024 characters or so), the update check will instead issue a POST with the request parameters in the POST body.
As we add more APIs to the extensions system, it's possible you will want to release an updated version of an extension that will only work with newer versions of the browser. While Google Chrome itself is autoupdated, it can take a few days before the majority of the user base has updated to any given new release. To ensure that a given extension update will apply only to Google Chrome versions at or higher than a specific version, you would add the prodversionmin parameter to the <app>
tag in your update manifest. For example:
<?xml version='1.0' encoding='UTF-8'?> <gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'> <app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'> <updatecheck codebase='http://myhost.com/mytestextension/mte_v2.crx' version='2.0' prodversionmin='3.0.193.0'/> </app> </gupdate>
This would ensure that users of this extension would autoupdate to version 2 only if they are running Google Chrome 3.0.193.0 or greater.