Update Pack Format
This page describes the format of update pack files.
See Update Process for more info on tools available for creating update packs.
The Update Daemon accepts update pack files that contain software/firmware update instructions and associated data (e.g., libraries, executables, resource files).
Update packs can have multiple sections. Each section starts with a JSON description. Optionally, a payload can follow.
If the section has payload, it's expected to start immediately after the last byte of JSON data (no padding or alignment bytes between). If there's no payload, but there's another section, the next byte after the task's description will be the next section's description.
JSON Data
The JSON data for a section is contained within a single UTF-8 encoded JSON object, beginning with an open brace { character and ending with a close brace } character.
Each section type has a different description structure, but they all have a command field indicating which section type it is:
Update System
Atomically updates the collection of apps and the app framework on the system.
The payload contains the framework and app files.
- Note
- Delta updates are not yet supported. More description fields will be added later to support that (such as "deltaFromMd5").
System update description fields are:
Field = Description ---------------------------------------------------------------------------------------------------- command = string = "updateSystem" md5 = string = MD5 hash of system's build staging area (excluding <c>info.properties</c> file). size = integer = Number of bytes of payload associated.
Code sample:
{ "command":"updateSystem", "md5":"098843325eef6af82cdc15a294c39824", "size":335534 }
Update App
Updates an app in the target system. If an app with the same name doesn't already exist in the system, install the app.
The payload is the new app.
- Note
- Delta updates aren't supported yet. New description fields will be added later to support (e.g., deltaFromMd5).
Description fields are:
Field = Description ---------------------------------------------------------------------------------------------------- command = string = "updateApp" name = string = App's name. version = string = App's human-readable version string. md5 = string = MD5 hash of the app's build staging area (excluding info.properties file). size = integer = Number of bytes of payload associated with this task.
Code sample:
{ "command":"updateApp", "name":"helloWorld", "version":"0.8c", "md5":"098843325eef6af82cdc15a294c39824", "size":5534 }
Remove App
Removes an app from the system.
Carries no payload.
The only description field other than the command is the app's name.
Field = Description ---------------------------------------------------------------------------------------------------- command = string = "removeApp" name = string = App's name.
Code sample:
{ "command":"removeApp", "name":"helloWorld" }
Update Firmware
Updates firmware in the module. The task payload is a firmware update file that is to be passed to fwupdate.
The only description field other than the command is the payload (firmware file) size:
Field = Description ---------------------------------------------------------------------------------------------------- command = string = "updateFirmware" size = unsigned integer = Number of bytes of payload associated with this task.
Code sample:
{ "command":"updateFirmware", "size":42043458 }
App Updates Concatenation
App removal and app install update packs can be combined together by concatenating their files together into a single file.
Code sample:
$ cat app1.remove.update app2.wp85.update app3.wp85.update > myMultiAppChanges.update
It's strongly recommended that system updates be used instead of concatenated app changes. System updates are applied atomically preventing problems that can result from a multi-app update being interrupted before all the changes could be applied (e.g., by a power loss, reset, or loss of connectivity.
Copyright (C) Sierra Wireless Inc. Use of this work is subject to license.