For scripts declaring ADDOND_VERSION=3 automatically mount
vendor, product, system_ext and others (when they're dedicated partitions).
Also expose the get_output_path() function to get the path to where
a file is mounted in case it lives in a dedicated partition.
ab exapmles:
get_output_path "system/product/priv-app/MyApp.apk" = "/postinstall/product/priv-app/MyApk.apk"
get_output_path "system/app/MySystemApp.apk" = "/postinstall/system/app/MySystemApp.apk"
a-only examples:
get_output_path "/mnt/system/system/product/priv-app/MyApp.apk" = "/mnt/system/system/product/priv-app/MyApp.apk"
******************************************************************
Instead of cycling all scripts for each stage, run
pre-backup -> backup -> post-backup in quick succession
(and likewise for restore), to ensure backwards compatibility
with scripts that wrongly assumed their environment not to
change between steps.
This is needed because we want to undo any mounting done for V3
scripts when executing V2 scripts. If a V2 script did mounting in
pre-restore and expected things to still be mounted in restore,
we would break their (yes incorrect) assumption.
Change-Id: I73fbad6f45824fed99e4482128769435348588f5
Add a function that allows to copy files preserving their SELinux
context that is generic enough to work with both busybox and toybox.
Change-Id: If2c245863df5675c18dbf43b6bcedeb33383fc38
We should not test symlinks using -e or -f, otherwise the order in
which the files are backed up and restored matters.
Change-Id: I9b87972b27a63ef562c0c5f46f943eafd0a08ce1
Tips & Tricks
=============
* 50-cm.sh contains only a reference implementation. You may customize the methods however you wish.
For example, 20-foobar.sh pre-backup can use a loop with conditionals to generate a dynamic backup list in
/tmp/foobar_file_list which is later printed by list_files() so the backup method will act on those files.
* Optional methods pre-backup, post-backup, pre-restore, or post-restore may be defined for special purposes.
* Inject new files into /tmp/addon.d/ prior to backuptool.sh backup if you want to act during the current CM upgrade.
* Delete files from /tmp/addon.d/ during post-restore if you want to permanently remove files from /system/addon.d/
Addons may use this approach to run a script only once.
* Scripts run in sort -n order. Prefix with numbers 00 through 99 if want to run in a particular order.
* You can have two separate scripts, implementing only backup in one, and only restore in the other with a different
number prefix of each. This allows even greater control the backup/restore order even further.
* You could use pre-backup to generate a one-time use backup script in /tmp/addon.d/ that deletes itself in
post-restore.
Patch Series
============
http://review.cyanogenmod.com/#change,13265
CyanogenMod/android_build
* edify generator
http://review.cyanogenmod.com/#change,13266
CyanogenMod/android_system_core
* permissions on /system/addon.d
http://review.cyanogenmod.com/#change,13267
CyanogenMod/android_vendor_cm
* 50-cm.sh reference backup script
* modular backuptool.sh
* support backuptool.functions used by /system/addon.d/*.sh scripts
Change-Id: Ifd5eaf9dcfd68d92e5043c21d1bae1dc0ad54860
