OpenDelta was written to provide automatic OTA updates for The OmniROM Project's nightly builds, making use of deltas when possible, to reduce the size of the download.
There's no reason you couldn't use it for weeklies or monthlies as well though!
OpenDelta is licensed under the terms of the GNU General Public License, version 3.0. See the COPYING file for the full license text.
OpenDelta uses binary differentials (VCDIFF, RFC 3284) between the previous and the current release, courtesy of xdelta3 (http://xdelta.org/).
Usually, OTA ZIP files created by Android builds are compressed. Diffs between compressed OTA ZIPs are not ideal - they are significantly larger than the diff between two uncompressed OTA ZIPs would be. So before we create the diff we decompress the contents of the OTA ZIPs.
The whole-file signature of the OTA ZIP is broken (and removed) by this process, and so we also re-sign the decompressed ZIPs with the same keys used to build Android. We create a second diff between the unsigned and re-signed ZIP file, so if needed the client can re-create a properly signed ZIP file.
At the time of this writing, that signature is not actually used. This is because OmniROM doesn't use the public platform test keys, but private keys specific to OmniROM. The recovery running on your device will most likely not be built with these keys, and thus whole-file signature checking will fail anyway (if enabled). So to save a bit of processing, this feature is turned off by default. The needed files are generated and the client knows how to deal with them, so enabling this feature is just a configuration switch away.
The produced delta files are pushed to the public download server, and the current build is saved to a private location to serve as input for the next differential run.
It is important to note that the differential files are named after the input file, not after the output file. Initially this may seem a bit confusing when working with these files, but this way the client doesn't need to know any information about future builds when looking for updates, and no server logic is needed at all - just a public download location - as the delta filename can be reconstructed from getprop's on the device.
The Android client periodically checks in with the download server and retrieves the .delta file for its current build. After parsing it, it knows the name for the next build as well, and then the one after that, etc. So if you don't update for a number of builds, it can still reconstruct the latest build by chaining the deltas. It will check each delta if we already have intermediate files present - perhaps we already performed the work for the last build but never flashed it, for example. Based on all this information it will device to either reconstruct the final flashable ZIP, or just download the latest full OTA and flash that.
Flashing is currently tested only against TWRP.
As OpenDelta depends on an unbroken chain of deltas, you can't just remove the files of a bad/dangerous/etc build. If you want to prevent the client from producing and flashing such a build, rename the relevant .delta file to .delta_revoked.
We'd still have a problem if you want to produce a replacement build, or for some reason have several different builds with the same name, and this is breaking the chain of deltas. The solution for this is to edit the relevant .delta file, and setting the size of the update file to a value larger than the size_official of the out file. This will trigger the client to download the full-size compressed OTA ZIP instead.
To create the delta files on the server, you need several things, some of which can be found in the server directory. The main thing is the opendelta.sh script. It contains a configuration section which you can edit with the correct file locations on your own system. Quite likely you will need to create a wrapper script that pulls in your previous release and your current release, and pushes out the created delta files.
The script depends on xdelta3, zipadjust and minsignapk.
For the builds on your server, make a copy of the jni directory - do not compile inside jni because you may mess up the build of libopendelta.
xdelta3 can be built in (the copy of) jni/xdelta3-3.0.7 by calling ./configure and make.
zipadjust can be built in (the copy of) jni by calling:
gcc -o zipadjust zipadjust.c zipadjust_run.c -lz
dedelta (not used by the script, but maybe helpful when debugging) can be built in (the copy of) jni by calling:
gcc -o dedelta xdelta3-3.0.7/xdelta3.c delta.c delta_run.c
minsignapk Java source is in the server directory, as well as a prebuilt minsignapk.jar file that should work on most systems
For debugging purposes you may wish to build in Eclipse instead of an Android tree, for test-speed benefits. The native part of OpenDelta is also NDK buildable.
You may need to enable the app to show up in the launcher ("System Updates") by editing AndroidManifest.
The APK needs privileged system permissions, and thus needs to placed in /system/priv-app. If you're testing on a build that includes OpenDelta already, remove it from that location and reboot before continuing. If you install the APK through Eclipse it'll end up in /data/app, but will not be granted the right permissions. Move that APK to /system/priv-app and reboot. Now increase the versionCode in AndroidManifest to a larger number, and your Eclipse-installed builds will magically run with the right permissions granted every time. You could use pm grant but you'd have to do that after every install.
Aside from inside the APK, you also need to place the produced libopendelta.so for your architecture in /system/lib. If you're actually working on the native library this gets annoying fast, symlinking that location to the library location from the APK can save you a lot of headache.
-EOF-