From 6865c09e8bfd26470c8b5a653ef45b0211c67da1 Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Mon, 2 Nov 2020 12:15:05 -0500 Subject: [PATCH] document setting up an update server --- static/build.html | 57 ++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 51 insertions(+), 6 deletions(-) diff --git a/static/build.html b/static/build.html index 0fcbe148..d85a83bf 100644 --- a/static/build.html +++ b/static/build.html @@ -93,6 +93,7 @@
  • Prebuilt apps
  • +
  • Update server
  • Stable release manifest
  • Standalone SDK
  • Android Studio
  • @@ -442,12 +443,12 @@ git submodule update --init --recursive

    Set OFFICIAL_BUILD=true to include the Updater app. You must change the URL in - packages/apps/Updater/res/values/config.xml to your own domain. Using the - official update server with a build signed with different keys will not work and will - essentially perform a denial of service attack on our update service. If you try to - use the official URL, the app will download an official update and will detect it as - corrupted or tampered. It will delete the update and try to download it over and over - again since it will never be signed with your key.

    + packages/apps/Updater/res/values/config.xml to your own update server + URL. Using the official update server with a build signed with different keys will not + work and will essentially perform a denial of service attack on our update service. If + you try to use the official URL, the app will download an official update and will + detect it as corrupted or tampered. It will delete the update and try to download it + over and over again since it will never be signed with your key.

    export OFFICIAL_BUILD=true
    @@ -816,6 +817,50 @@ git am --whitespace=nowarn ../patches/*.patch

    A build of Seedvault is bundled as an apk into an external/ repository. There are no modifications made to it.

    +

    + Update server +

    + +

    GrapheneOS uses a static web server as the update server. The release signing + script generates the necessary metadata alongside the release files. You simply need + to host these files at the URL configured in + packages/apps/Updater/res/values/config.xml. See above for details on + including the Updater app in a release. These are the relevant files:

    + +
    $DEVICE-ota_update-$BUILD_NUMBER.zip
    +$DEVICE-factory-BUILD_NUMBER.zip
    +$DEVICE-factory-BUILD_NUMBER.zip.sig
    +$DEVICE-testing
    +$DEVICE-beta
    +$DEVICE-stable
    + +

    Generally, you should start by uploading the ota_update, factory images and testing + channel metadata.

    + +

    The testing release channel is an example of an internal release + channel not configurable via the update client GUI. Internal release channels can have + arbitrary names. You can override the release channel configured in the update client + via ADB with the following command:

    + +
    adb shell setprop sys.update.channel channel_name
    + +

    Replace channel_name with the name of the release channel, such as + testing.

    + +

    After pushing out and testing the new release via the internal release channel, + it's recommended to build a sample future release and push that out as another update + via an internal testing channel. This is important to test that the changes in your + latest release have not broken the future upgrade path.

    + +

    Finally, once the release has gone through internal testing, upload the metadata + for the beta channel. Once the release has gone through beta testing, upload the + metadata for the stable channel.

    + +

    Delta update packages should simply be uploaded alongside the rest of the releases. + The update client will check for the presence of a delta update from the current + version on the device to the newer release in the selected release channel. There is + no additional metadata to include alongside the delta update package.

    +

    Stable release manifest