Definition
Delta Package (incremental package) only contains the differential data from the source version to the target version, small in size, fast to transfer, suitable for bandwidth-limited scenarios. The source version must be specified, complementing the Full Package.
Generation Principle
Incremental packages use binary diff algorithms (such as bsdiff, hdiff, etc.) to compare the source firmware version with the target firmware version, outputting only the difference blocks. The device must have the source version firmware; after downloading the incremental package, it performs merging and verification to generate the target version. Compared with Full Package full packages, incremental packages usually reduce transmission size by 50%–90%, which is particularly important for narrowband scenarios like NB-IoT and 2G.
Usage Constraints
Incremental packages must explicitly specify the source version and are only applicable for a directed upgrade path from "source version → target version." If device versions are scattered (multiple versions coexisting), a corresponding incremental package must be generated for each source version, or a full package can be used for uniform upgrading. The platform needs to check the device's current version in the OTA task and automatically downgrade to a full package or skip if the match fails.
Combined with FOTA Process
In the FOTA firmware over-the-air upgrade process, the platform automatically selects an incremental or full package based on the current version reported by the device; during Gray Release gray release, it is possible to first push incremental packages to some versions for verification before expanding the range. Incremental packages also require Firmware Signature signature verification to ensure integrity.
Which version conditions a delta package can assume
A delta package means transmitting only the difference between the source-version image and the target-version image. The device applies that difference locally to the source image it holds and produces the target image. The source version in the package header is not a remark. It is the condition for assembly to start. The running version the device reports, and the image version actually stored in the slot, must match the source version the package declares. Matching the version string is not enough. If the image in the field was partly rewritten, or was built with different compile options, the difference blocks land in the wrong place. A delta package fits an upgrade of the same product and the same build series, where source versions are concentrated and link bandwidth is tight. When versions are widely scattered, maintaining a delta for every source version costs more than sending the full package.
In use, the platform should read the device’s current version first, then choose the matching delta. If none matches, send the full package or skip the device. Do not force the nearest delta on. The device needs enough temporary space to hold the difference blocks and the assembled result at the same time. If there is room to download but not to assemble, the package fails at the last step. The assembled result still needs an integrity check before it is written to a bootable location. Used with an A/B partition, assembly should happen in the idle slot or in a separate temporary area. Do not overwrite the running slot in place. A failed assembly would then leave no bootable system.
Merging when the source version does not match
A common mistake is to compare only the target version and not the source version. A device already on an intermediate version is given the delta “from the first version to the latest.” The patch position is wrong, the assembled image fails its check, and in a severe case the slot is written so that it cannot boot. Another mistake is reusing a version number. Two builds of different content share one number, the delta tool matches by number, and the content does not match. A delta algorithm or block size that differs between the build side and the device also shows up as download success and install failure. If the target package is compiled again after the delta is built, and the old delta is kept, the hashes on the two sides are no longer a pair.
A retry after failure must not apply another delta on top of a half-finished result. Discard the unfinished assembly, confirm again that the source image is still the original, then decide whether to download the delta again or switch to the full package. If job statistics count “delta downloaded” as “upgrade succeeded,” assembly failures are hidden. The version path of an OTA update also has to be written into the release note: which source versions may use a delta, and which versions must take the full package. A sample unit whose file system was changed privately in the field should not be included in a delta batch. It no longer holds the source image assumed when the delta was built.
Where the process stops when there is not enough room to assemble
A small delta package only means the transfer stage saved space. The device still needs room for the difference blocks, a readable copy of the source image, and the assembled target image. If any of the three does not fit, stop before download or before assembly, and leave the current bootable system untouched. Some devices write the difference blocks straight into the idle slot. Assembly runs out of space halfway, and the slot is neither the old system nor the new one. A retry that applies another delta then sticks it onto the half-finished result, and the failure reason becomes unreadable. The right stopping point is: if space is insufficient, abandon this assembly, delete the unfinished temporary result, keep the source image, and switch to the full package or wait until space has been cleared.
The source-version check also has to happen before any erase. If the version string the device reports, the checksum of the image in the slot, and the source package used to build the delta do not agree, do not start assembly. A reused version number, or a field image rewritten during debugging, belongs in this class. Job statistics should count download complete, assembly failed, and boot switched separately. The first number cannot be treated as the upgrade being finished. The release note should list the source versions this delta allows. A device not on that list should not automatically receive the nearest package, even if the target version is the same. After assembly succeeds, the completion condition for this device is still the self-check after boot.