* Ignore the block devices in case their mount points are symlinks.
This is common on devices where maintainers have chosen not to use
real partitions because of their size being too small to be useful
Also `continue` instead of `break`. Oops.
Change-Id: I3e27abe510219066ecacd81d099220ac8e119f9f
There are addon.d scripts that rely on the value of ADDOND_VERSION
to determine if they're being called from a-only vs a/b backuptool.
If they declare ADDOND_VERSION=3, they shall stop doing that;
otherwise offer them the same environment, that is unset ADDOND_VERSION
for a-only backuptool.
Change-Id: I1be21eda2e6ec9837b3080bb5e7fbe5241318eaa
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
Backup/restore functionality was broken in the
Ia1f4ae95c9e4dae4df844853e81c264bc838f177 change
because of incorrect check of the function's result.
check_prereq() function refactored to return 0 if
backuping/restoration is possible. Any work should be
performed only if check_prereq() succeeds.
Change-Id: Ic977dba675df58a228ef4b882b25beb66cc9d2c6
For non AB devices system partition should be unmounted
if check_prereq function fails.
This patch also refactors backuptool a bit for AB devices
in order to look same as backuptool for non AB devices.
Change-Id: Ia1f4ae95c9e4dae4df844853e81c264bc838f177
* This check was supposed to check whether the script
addon.d version was lower than backuptool's
* Given that the backuptool addon.d version is 1, this
isn't going to happen ever making this check completely
unuseful
Change-Id: I2464749b52bf4e8825e0b4ef42500ee7d3bbfa61
* For some odd reasons executing `cd /system/addon.d` makes the system
hang and unmount error:
umount: /system_root: Device or resource busy
* Don't change directory to not allow the system partition hang
Change-Id: I3d30bdc59c2f05d16823e99046c1dce2e1e6eb73
* If any of these two function gets run on a recovery mounting system
to /system, /system/addon.d won't exist while /system/system/addon.d will.
* Run the functions with $S as argument to make this work correctly
Change-Id: I02e7b91429a9e74d28bdb77e56955dad97ca75ac
* The path /postinstall exists only for A/B, causing:
grep: /postinstall/tmp/addon.d/*sh: No such file or directory
Change-Id: Ia07b3029e949c3e08302457cd08798a4dde00ef6
* Dynamically mount system to the path chosen by the recovery through backuptool
* This can be helpful because of the fragmentation that will happen with system mount in recovery after Q
Change-Id: I2d1e775efcf87e33319bc7790d1e54bca72116d3
* The grep errorlevel output was not properly used by the if,
therefore allowing a device to upgrade with old addons
instead of aborting the backuptool steps
* The LineageOS versions properties were removed from the build.prop,
which is resolved properly in commit:
"lineage: Keep LineageOS versions properties in build.prop"
Change-Id: I0060141c097b3d14c3710eee1e0caf7110634967
* Introduced in the following commit:
"backuptool: Take into account new location for system default props"
Change-Id: I62046447876c2198a0c4f88a4f36f4723d417617
This reverts commit 1022cc7c50.
Change-Id: I7f5a3510f64f0ecabfe9d15b5dbc1a667b210eb8
Signed-off-by: Adrian DC <radian.dc@gmail.com>
* Since A/B addon.d scripts are going to need to do things in a
specific way or things could go horribly wrong for a user, let's
introduce versioning so that scripts can claim to be compatible.
* A script can denote it is compatible with addon.d version 2 by
adding: "# ADDOND_VERSION=2" somewhere in its script.
* Only A/B will require version 2 scripts for now, and version 2
scripts will still run on non-A/B. Additionally if a script does
not explicitly denote its version, assume its version 1.
* Version 1: The same old scripts we've always used. We cannot assume
these will all work with A/B backuptools.
* Version 2: Scripts that denote they are compatible with version 2
must be aware of the fact that A/B devices will run this
script for a rom, during a seamless update, mounted at
/postinstall. The best way to ensure compatibility would
be to use the pre-designated functions found in the
backuptool[,_ab].functions scripts.
Change-Id: I5573018dabd21bb64c7c964e2081806072a75243
* Due to both following commits, backuptool went permissive
and lineage properties got lost from the system on devices
that do not have BOARD_PROPERTY_OVERRIDES_SPLIT_ENABLED
"backuptool: Take into account new location for system default props"
Change-Id: I62046447876c2198a0c4f88a4f36f4723d417617
"lineage: Move to Google's method of defining system default props"
Change-Id: I6cb0e28a7599b010b389cc541015a37010a00f4b
* Once the properties issue is properly resolved in the sources,
a period of time is required for "most" of the users to upgrade
their system with fixed lineage properties before we break addons
by repairing the backuptool script globally
Change-Id: Iea8865ea9bb05eed56a8a0a7b95e3f04b01c4bae
* System default props defined using PRODUCT_SYSTEM_DEFAULT_PROPERTIES
are stored into /system/etc/prop.default, so that's the location where
ro.lineage.version prop needs to be checked now. Although, fallback
to the old location to allow sucessful upgrades.
Change-Id: I62046447876c2198a0c4f88a4f36f4723d417617
If /system is empty, /tmp/addon.d/ will not exist, "*sh" won't be
expanded, md5sum will not generate any output and the variable $s
will be empty. Therefore grep, which will receive only one arg, will
start to read the standard input and never exit, causing the
installation to never end. Fix this checking whether we have files
to read or not.
Change-Id: I656eab42e54b3f81da8c5ac81374b9deddcf8484
* Add the addon.d folder creation to preserve_addon_d
before copying the files back to /system/addon.d
* On CM based ROMs, the path exists for built elements,
but on other AOSP-based ROMs where this script might
be used, the folder might not be created on build and
copy fails, breaking backuptool on second ROM update
Change-Id: I7438823b8d7ad0972649d2bf491d0f6fe423bc99
Keep a blacklist of md5 sums for scripts known to cause issues, and
ignore them when installing new builds
Change-Id: I19a88b58194a32da5eb5fe278f2c5b9a145b57be
backuptool should not be messing with whether /system is mounted
or not as it screws up the expectations of other scripts run
in the install process. instead the mounting/unmounting
functionality has been moved to ota_from_target_files
Change-Id: I0711afd517638e7d0a0c39369d3a776748245dd2
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
Currently the tool only backs up the lib, but not the apk.
Seeing as how the market version of voice search is still not
up to date with the current release, it should still be backed
up with this script.
Change-Id: Ia130bb3e289fc3c2206a60ed0fcfd7dab816425d
Since the destination for all backed up files during an installation was
/tmp, all files sharing a name (like the full_model.bin files from
the various face detectors) ended up being restored as copies of
the last such file, effectively breaking the backup.
As a fix, when backing up files, use the entire original path to make
sure they're kept separate and restorable.
Change-Id: I399f7a9433a225871d97e0ecaeb051a90e68696b