[X 2014 Android Development] mikeoswego:
Xdelta3 is a stupid utility, it has no idea what it is doing when it applies a patch; it doesn't know that it is deleting files,etc. It just finds the differences between 2 files and can create a patch from those differences or it can make a new file based on the original and apply the changes.

It would be possible to stack paches but not in the way you are thinking. When I name the patches, the part before the -- is the file it will patch, the part after is the file that will be created. So 3.1f--3.1f-v4a.patch will only patch the original 3.1f file to have Viper. 3.1f--3.1f-de.patch will patch the original 3.1f to be 3.1f-de the debloated image. It would be possible to have a patch like 31.f-v4a--3.1f-v4a-de. You would take your 3.1f image and run the v4a patch on it and create the 31.f-v4a image, then you could apply the 31.f-v4a--3.1f-v4a-de to the image you just created and make a debloated version in this example.

So it would be possible to have a tree of patches that would allow you to go whatever way each person wanted to go but its not going to happen.

I have this process somewhat automated (and it could be more automated) but here is how it works.. I create the base image like 3.1f. Then, for the debloated image, I make a copy of the base image, mount it to my linux box and run a series of delete commands to remove the "bloat" apps from the image. As you may know, when you delete a file, nothing is erased, just the directory of files on the disk (image) is updated to say the file is deleted. So, now I have 2 different image files, the only difference between them being the few bytes in the file directory showing some files as being "deleted." Then Xdelta3 compares those 2 files finds those few bytes that are different between the 2 and writes out a differences file that can be applied to the original file. It stores a checksum of the original file so that it knows that a patch is being applied to correct base image.

So, each of these patches (or if I was posting whole Images for each version) require me to make a copy of the image add/delete files, edit certain files depending on what the change is (Viper changes 3 config files adds some library files, and replaces one stock file. CF.lumen adds some files and changes one stock file.) I have a system with a reasonably fast SSD drive but it still takes more than a blink of an eye to make a copy of that 2.9gb file, it takes some time to apply the changes, it takes some time to create the patch, it takes some time to compress them, upload them, etc. So that is why I'm only creating patches as they are requested instead of creating every conceivable patch; I have to create a new full image for each combination. It's only a few minutes for each combination but if there were 20 combinations it would be a hassle.

I've realized that as far as the cf.lumen and Viper mods, I can probably use symlinks like for the Emoji patch. Right now the Emoji patch requires manually copying the font file to the symlink location. I could write a simple script that could be run from terminal on the phone, adb shell, or from a windows batch/linux script file on a system with working ADB to automate that process. If I can symlink the files affected by CF.Lumen and Viper4Android (I think I can, just haven't had time to try), I can get this back to single image (or at least small number of images) where if you don't want CF.lumen, you can run the removal script (or put it back with a different command), the symlinked files will be set to the correct option, reboot and there you go. Same for Viper. As far as the whole debloat thing, there is a command that can be scripted that not only disables an app, it completely hides it from the system. So that would be another thing to add, a script that would let you effectively debloat the rom by a script, or debloat/undebloat individual apps as each person desired. Once that was done, my only maintenance task would be to place updated apps into the system image, and update things like the Xposed framework, SU, busybox, etc. as new releases are made.