Definition
Full Package (full package) is a complete firmware image delivered during OTA upgrade. It is suitable for any version upgrade and does not depend on the current version. It is larger in size but has good compatibility, and is complementary to the Delta Package delta package.
Applicable scenarios
Full packages are suitable for scenarios where device versions are scattered and it is impossible to generate incremental packages for each source version; for first-time mass production devices or upgrades from scratch; as a fallback when incremental package merging fails; and where storage space is sufficient and bandwidth is acceptable. Compared to Delta Package, full packages do not need to consider the source version and can cover all devices with a single build, simplifying version management.
Transmission and storage
The size of a full package is usually from several MB to tens of MB, requiring support for breakpoint resume and segmented download to cope with unstable networks. The device side needs to reserve enough storage space (double space is needed for A/B Partition), and after the download is complete, Firmware Signature verification must be performed. Only after passing the verification can it be written and restarted.
Combined with FOTA Process
In the FOTA process, the platform can intelligently choose full packages or incremental packages based on the current version reported by the device; if there is no matching incremental package, a full package is automatically used. Supports Gray Release gray release and Maintenance Window maintenance window. Both full and incremental packages must undergo signature and integrity verification to ensure upgrade safety.
A full image does not depend on the old version
A full package means these bytes are themselves a bootable image. Once written, they do not need to be stitched to old files left on the device. It therefore does not care which intermediate version the device is running, as long as the hardware and product range match, and it can be the target. The cost is that the size usually covers the whole image. Download time and storage are counted for the whole package, not for the number of lines that changed. The package should carry a clear target version, the hardware it applies to, and integrity material, and the device should check that material before it overwrites anything. Compared with a delta, there are fewer build artifacts: there is no need to produce a patch for every pair of source version and target version. It also must not be read as "pack every file in the directory as it is, and ignore the boot layout." The partition table the boot needs, the boot-related images, and the version marks have to be in the package together, or the device has nothing to boot after the write. When an over-the-air update task chooses a full package, bind the hash of the whole package to the task, so the download cannot be swapped for another file of the same size.
When scattered versions justify a full package
A full package fits these cases: field versions have already forked, and a delta cannot be prepared for every source version; the device is booting for the first time from an empty image off the line, or from a blank partition after repair; delta assembly failed on the device, and a path that does not depend on the old content is needed; storage and bandwidth can hold the whole package, and the service can allow the download time that goes with it. If almost every device is already on one known version, forcing a full package every time occupies a narrowband link for a long stretch, and a sleeping device may not stay awake until the transfer finishes. The choice should be made when the task is created, from the current version the device reports and from the free space, not from one "always full" switch shared by every device. When there is not room for two copies of the image, do not assume an overwrite is still safe. If rollback promises a return to the old version, the old image must still be in the other partition or available to download again. Writing a full package once does not by itself leave a way back.
Space, layout, and version marks left out
A common mistake is to estimate device space from the compressed package size. After unpacking or writing into the partition, the image exceeds the reserve, the write fails halfway, and the old image is damaged too. Another is a version mark inside the full package that does not match the file header. The device boots the new image and still reports the old version, so the platform keeps sending the package. Switching automatically from a failed delta to a full package without repeating the signature check and the hardware match sends another product's full image down. Chunk numbers from a resumed transfer that were not invalidated after the full package changed get the device to assemble old and new chunks into an image that cannot boot. Checking only the file size, and not the hash, accepts a package corrupted on the link as complete. If the boot image is outside the full package, the application is upgraded and the bootloader stays an incompatible older version, which shows up as a boot that fails at random. A success condition that only watches the bytes finish, and not whether the device has reported once from the new partition, stops too early. The write address and boot order of a full package should be in the release notes. A compressed-file name alone does not tell the device which partition to land in, and a failure cannot be told apart as a bad package or a bad address.