[HowTo] Intelligent EDIFY updater-script - (Decides things during flash) - Android

I recently have started releasing Roms on the G2X. Coming from the Vibrant world where there were so many leaks and versions, that everyone forced wipes on updates, I was shocked when many roms were No-Wipe... Just seemed crazy.
Then on top of that, I realized I had to deal with the fact that custom kernels were ext4 while the stock kernel for the base I was using was ext3.
So I needed a script that could figure out what Rom was currently installed. The requirements:
1) Figure out what Rom is currently installed.
2) WIPE data and convert to ext3 if a non-compatible Rom is installed.
3) DO NOT WIPE data if a compatible Rom is already installed.
4) Install ext3 kernel ONLY if we wiped the partitions
5) Leave existing kernel alone if user already has compatible Rom
6) Backup files that are tied to kernel version (on LG, it's wireless.ko)
I searched high and low, and couldn't find any updater scripts that actually did this. The best I could find was this very useful post: http://forum.xda-developers.com/showthread.php?t=974450 that showed how to use ifelse and file_getprop. He has a lot of good ideas, but what was missing was an actual full updater-script that could be used.
Also, I needed to be able to backup a file from /system and deal with what happens if that file didn't actually exist.
So I wrote wrote my own updater script.
The basic process:
1: Extract needed tools from updater zip to /tmp
2: Run a shell script (tsugib.sh). It copies default.prop to /tmp/build.prop (just a kludge in case the next step fails).
3: Script then copies /system/build.prop to /tmp/build.prop. This is so we can still acess build.prop AFTER formatting /system
4: Control returns to edify, where we use an ifelse statement reading the properties with file_getprop to determine whether or not to wipe.
5: Normal install procedes.
6: Instead of just installing the kernel, we check the backed up build.prop again.
7: If keeping existing kernel, run a shell script (tsugir.sh) to restore the kernel library that was backed up.
8: If not keeping the kernel, then we install a new kernel.
Examples - Keep in mind, these scripts are written specifically for an LG G2X... you will need to modify them to work with your particular phone. In particular, I've REMOVED all sections that symlink files or set permissions. I have commented fully, so hopefully you can see how to integrate this with your phone's own version of updater-scripts.
tusgib.sh - this script does the backing up of build.prop and the kernel-linked wireless.ko file for later restoral if we don't flash a new kernel.
I'm sure I could have also checked to see if build.prop actually exists, before placing the dummy file, but why have a conditional statement if I can just place the dummy file (which won't match on my file_getprop anyway). We have to place the dummy file first, because if the user has formatted /system, then Edify will abort when attempting the file_getprop.
Code:
#!/sbin/sh
#
# Backup current install files.
# Kludgy hack to prevent having to replace kernel
#
cp /system/lib/modules/wireless.ko /tmp/wireless.ko
#
# Kludge since edify breaks if build.prop does not exist.
cp /default.prop /tmp/build.prop
#
# now if there *is* a build.prop, we'll overwrite the default.prop with the correct values.
#
cp /system/build.prop /tmp/build.prop
exit 0
tsugir.sh
I use this file to restore the wireless.ko file which is linked to kernel version. I have to restore the file since it is located in /system, which is wiped regardless of whether we wiped /data. Again, Rom specific. You may not even need this step if you have no files that are linked to kernel version.
Code:
#!/sbin/sh
#
# Restore current wireless.ko
# Kludgy hack to prevent having to replace kernel
#
cp /tmp/wireless.ko /system/lib/modules/wireless.ko
exit 0
And, here is the sample updater-script.
Code:
#
# Splash Message for the User
#
ui_print("");
ui_print("Tsugi 2.3.4 Smart Updater");
ui_print("");
show_progress(0.500000, 0);
ui_print("Preparing to Install...");
#
# LG G2XPartition Info
#
# Highly recommended to research and put your own phone's partition info here
# so you have a handy reference when editing updater-script.
#
# op7 = /data, - pillage on full wipe
# op1 = /system, - pillage only with full update (doesn't require wipe tho)
# op2 = /cache, - always pillage to avoid issues.
# op8 = /emmc, 1p1 = /sdcard - don't pillage unless u like mad users
#
# Kludges to make this a smart updater.
# 1: Backup build.prop so it can be accessed after installing /system
# 2: Check if Tsugi is already installed
# - NO: Perform FULL WIPE and INSTALL NEW KERNEL
# - YES: DO NOT WIPE, backup and RESTORE WIRELESS.KO
#
ui_print(" Checking Existing Install...");
# extract needed tools
package_extract_file("system/bin/tsugib.sh", "/tmp/tsugib.sh");
package_extract_file("system/bin/tsugir.sh", "/tmp/tsugir.sh");
set_perm(0, 0, 0777, "/tmp/tsugib.sh");
set_perm(0, 0, 0777, "/tmp/tsugir.sh");
#
# backup files to keep
# backs up current build.prop to /tmp so it can be checked
# /system must be mounted for this.
#
run_program("/sbin/busybox", "mount", "/system");
run_program("/tmp/tsugib.sh");
#
# Now unmount system since having it mounted will
# break formatting (if we format).
#
unmount("/system");
#
# Since I didn't include a CLEAR way to identify my Rom in early versions,
# I'll identify it by the LG release version for now
# but this may change in the future
#
# Any value can be checked here, such as ro.modversion or ro.developer or any that you just
# add to the file yourself.
#
ifelse(
file_getprop("/tmp/build.prop", "ro.build.lge.version.release") == "LG-L95G-V10c_final",
(
ui_print("Compatible Rom Detected. Not wiping.");
),
(
ui_print("Incompatible Rom. Wiping.");
run_program("/sbin/mke2fs", "/dev/block/mmcblk0p7");
run_program("/sbin/tune2fs", "-j", "/dev/block/mmcblk0p7");
run_program("/sbin/mke2fs", "/dev/block/mmcblk0p1");
run_program("/sbin/tune2fs", "-j", "/dev/block/mmcblk0p1");
run_program("/sbin/mke2fs", "/dev/block/mmcblk0p2");
run_program("/sbin/tune2fs", "-j", "/dev/block/mmcblk0p2");
)
);
#
# On LG this does not wipe user data.
# Just the cache
# Make sure you have the correct paths.
#
ui_print(" Clearing dalvik");
run_program("/sbin/busybox", "mount", "/data");
delete_recursive("/data/local");
delete_recursive("/data/dalvik-cache");
#
# Completely wipes /system partition, but this leaves user data alone.
#
ui_print(" Clearing system");
run_program("/sbin/busybox", "mount", "/system");
delete_recursive("/system");
#
# I found that if I don't wipe /cache there can sometimes be issues.
#
ui_print(" Clearing cache");
run_program("/sbin/busybox", "mount", "/cache");
delete_recursive("/cache");
#
# Normal rom extraction...
#
ui_print("Extracting new Rom...");
package_extract_dir("system", "/system");
#
# IN THIS SECTION YOU WOULD SYMLINK YOUR TOOLBOX,
# BUSYBOX and ANY OTHER TOOLS YOU NEED.
#
#
show_progress(0.500000, 40);
ui_print(" Linking Tools...");
# many many lines removed for demonstration purposes.
#
# Extract any data (such as preinstalled apps that user can uninstall)
#
ui_print("Extracting Data....");
package_extract_dir("data", "/data");
ui_print(" Setting Permissions....");
#
# Much setting of permissions removed for demo purposes.
#
#
# Extract anything to the user's SDCard such as ringtones, etc
#
package_extract_dir("sdcard", "/sdcard");
show_progress(0.200000, 0);
#
# If coming from compatible Rom, then
# don't touch kernel. Kernel will remain as user had it. Restore wireless.ko from backup.
#
# If incompatible Rom, then install new Kernel.
# We check the BACKED UP build.prop since the already installed one would NOW match which
# may not be correct.
#
# Use whatever method your rom uses for installing the kernel. It may be very different.
#
ifelse(
file_getprop("/tmp/build.prop", "ro.build.lge.version.release") == "LG-L95G-V10c_final",
(
ui_print("Leaving Existing Kernel.");
run_program("/tmp/tsugir.sh");
),
(
ui_print("Installing LG Kernel.");
package_extract_file("boot.img", "/tmp/boot.img");
run_program("/sbin/busybox", "dd", "if=/dev/zero", "of=/dev/block/mmcblk0p5");
run_program("/sbin/busybox", "dd", "if=/tmp/boot.img", "of=/dev/block/mmcblk0p5");
delete("/tmp/boot.img");
)
);
#
# Now do any post-kernel install cleanup.
#
ui_print(" Cleaning Up....");
unmount("/data");
unmount("/system");
unmount("/cache");
ui_print(" ");
show_progress(0.100000, 0);
ui_print(" ");
ui_print("Injection Complete");
ui_print(" ");
ui_print("You may now #OCCUPY your G2X.");
Also it may be possible that some updater binaries don't support ifelse. I haven't heard of any that don't, but I always see the warning that it may not be supported.
If you need to do updater-script troubleshooting, you can adb into recovery and should be able to view the recovery log in the /tmp directory.
Now, keep in mind.. this updater-script is based on LG G2X partitions and install techniques. Your Rom may do it very differently, but as long as your updater binary and version of recovery supports all the needed features (mine did), then you can use a similar method on your own updater-script.

okay nobody had any suggestions...
Now I'm stumped....
Is there any way to check that a file EXISTS without using an assert - I do not want the install to ABORT if the file does not exist.... currently, even trying to use read_file will cause an abort if the file does not exist. This of course means I can't use the method of checking for tsugi.txt that I thought I could...
EDIT:.... okay, looks like I'll have to use a shell script to do the dirty work... have ifelse act upon the exit code of the shell script... and I'm hoping run_program is actually smart enough to pass the return code.... Who in the world thought that edify scripting was sufficient?
EDIT2: Still NOT working.... either my shell scripting is worse than I think, or run_program does NOT actually pass the result back to the calling function, thus I *cannot* do this:
Code:
ifelse ( run_program("/tmp/tsugicheck.sh"), ui_print("result 1"), ui_print("result 2) )
Looks like I can either move more updater-script functions out to the shell script... or use the shell script to set properties that can then be checked by edify scripting...

Hey,
I don't really have suggestions for you but I am really interested in this kind of script. If works, I too would love to have this thing in my ROM.
BTW, instead of reading a txt file which might not be there and crashing the script, how about reading the build.prop??
Build.prop is there in every system and usually every developers modifies it before releasing his/her ROM build.

IlluminatedOne said:
Hey,
I don't really have suggestions for you but I am really interested in this kind of script. If works, I too would love to have this thing in my ROM.
BTW, instead of reading a txt file which might not be there and crashing the script, how about reading the build.prop??
Build.prop is there in every system and usually every developers modifies it before releasing his/her ROM build.
Click to expand...
Click to collapse
The problem with Build.prop is I'm not sure if getprop can deal with substrings... That is, if the version is "Tsugi 11-23-11-1048" and another version is "Tsugi 11-25-11-0430" to only match on the Tsugi portion. I did add a developer ID which doesn't vary between versions, but I only did that on the very last release.
I was thinking maybe of using the shell script to build a temporary properties file that describes the current install - which kernel, addons, etc - and then edify can use getprop on THAT file to match the current install. And, of course, by knowing which kernel is installed, I know if I can safely install the ext3 kernel, or if they require an ext4 kernel, etc.
I've seen another updater script that shells out and uses the actual filename of the update zip to modify the installation. that seems a little complicated to me, personally... since it assumes the user is going to name the file ahead of time. I want the updater to figure things out on its own.

Calling a shell script from the updater-script would be the best way, you could check for a file/string, if it exists, echo one to a temp file, and then the updater-script checks if the file is there, if it is, it installs the rom, if it isnt, then it aborts and prints goodbye
or the easiest way
Call a shell script from the updater-script, and let it do all the work, and recovery show output from the script too!

Worked out a bit of a compromise, and I back up the existing build.prop to the tmp partition on the phone using a shell script, then I can use file_getprop on it as needed, even after the /system partition is wiped. Once I determine if a new kernel needs to be flashed or not, I restore the old wireless.ko (which is linked to kernel build on a g2x) back to the system directory if necessary. All works out pretty smoothly.
I am surprised more people don't use ifelse and getprop in their updater scripts. If anyone wants to steal the work I've done in a more intelligent update script, I have rolled it out on the current version of my Rom here: http://forum.xda-developers.com/showthread.php?t=1358724 ... anyone can feel free to use bits and pieces of the updater script to make their updates a little smarter.
The only catch so far, is if someone already has my rom installed, and wants to revert to the ext3 kernel, they have to flash a scrubber (which i've provided) which reformats the partitions, since you can't revert from ext4 to ext3 without a wipe.. and the whole purpose of the intelligent updater was to avoid putting an ext3 kernel onto an ext4 install...
In theory, the shell script can detect all sorts of things about the current install and create a specific properties file that can be checked by the edify script to modify the new installation, but I haven't implemented that much intelligence.

Thanks. I am gonna look into your Intelligent Script. All I need is to figure out a simple thing, that is to wipe or not. Will get back here if I have any questions.

IlluminatedOne said:
Thanks. I am gonna look into your Intelligent Script. All I need is to figure out a simple thing, that is to wipe or not. Will get back here if I have any questions.
Click to expand...
Click to collapse
Btw, the 12-06 version had a bug in the shell script... if the user wiped /system manually before running the script, there would be no build.prop...
EDIT:
Copied the info I posted here up to the first post and made this a HowTo...

Nice How To
I've seen various installer methods coming from the g2 forums. Kind of liked the meXdroid method. This is a wonderful guide though. Was going to try to make an installer [like meX but different] that installed d2sd and deletes a2sd if cued [a2sd default] for wildfire s users. Severe memory challenges with that device. Wish me luck and any pointers are more than welcome.
Rob

insink71 said:
I've seen various installer methods coming from the g2 forums. Kind of liked the meXdroid method. This is a wonderful guide though. Was going to try to make an installer [like meX but different] that installed d2sd and deletes a2sd if cued [a2sd default] for wildfire s users. Severe memory challenges with that device. Wish me luck and any pointers are more than welcome.
Rob
Click to expand...
Click to collapse
The more you can move off to shell scripts, the more power you have during the install....
Unfortunately, I am no good with shell scripting in any detail, and even worse (hopeless) at string operations... A person good at shell scripting could do a lot more.
The basic lesson is that Edify is way too simple, you have to run shell scripts to do a lot of ops.
The one thing I couldn't find a way to do that I would've liked was an interactive install. I saw that ages ago back when I had a G1, but it depended on the keyboard. Maybe with the new touch-enabled recoveries it will be possible, but I suspect it'll be a while (if ever) before we see that built for "older" devices.

lotherius said:
okay nobody had any suggestions...
Now I'm stumped....
Is there any way to check that a file EXISTS without using an assert - I do not want the install to ABORT if the file does not exist.... currently, even trying to use read_file will cause an abort if the file does not exist. This of course means I can't use the method of checking for tsugi.txt that I thought I could...
EDIT:.... okay, looks like I'll have to use a shell script to do the dirty work... have ifelse act upon the exit code of the shell script... and I'm hoping run_program is actually smart enough to pass the return code.... Who in the world thought that edify scripting was sufficient?
EDIT2: Still NOT working.... either my shell scripting is worse than I think, or run_program does NOT actually pass the result back to the calling function, thus I *cannot* do this:
Code:
ifelse ( run_program("/tmp/tsugicheck.sh"), ui_print("result 1"), ui_print("result 2) )
Looks like I can either move more updater-script functions out to the shell script... or use the shell script to set properties that can then be checked by edify scripting...
Click to expand...
Click to collapse
Hi,
I read your post and your script. Very helpful to learn edify possibilities
I would like to ask a question:
How can I assert that a given file (/path/File_Check.do) exists using edify with assert command?
Also, how can I do it in an external script that will cause the update.zip to stop or continue depending on answer?
Any help would be appreciated

Phil3759 said:
Hi,
I read your post and your script. Very helpful to learn edify possibilities
I would like to ask a question:
How can I assert that a given file (/path/File_Check.do) exists using edify with assert command?
Also, how can I do it in an external script that will cause the update.zip to stop or continue depending on answer?
Any help would be appreciated
Click to expand...
Click to collapse
In edify, I don't know,
but you can use a script.
In your updater-script you can copy one files (with only 1 string "ro.chiave=0") and one script in /tmp and run the script (somthing like that)
Code:
package_extract_file("test/test.prop", "/tmp/test.prop");
package_extract_file("test/script1", "/tmp/script1");
set_perm(0, 0, 0777, "/tmp/script1");
set_perm(0, 0, 0777, "/tmp/test.prop");
run_program("/tmp/script1");
the script
Code:
#!/system/bin/sh
CHKRIP=0
EXTRIP="/path/File_Check.do"
PROP_PATH="/tmp/test.prop"
if [ -f $EXTRIP ]; then
echo "Find file"
CHKRIP=1
fi
if [ $CHKRIP -eq 1 ]; then
#Update test.prop
echo "ro.chiave=1" > $PROP_PATH
fi
Now in the updater-script you can test the ro.chiave value like that
Code:
ifelse
(
file_getprop("/tmp/test.prop", ro.chiave) == "1",
(
ui_print("DO SOMTHING");
),
(
ui_print("FILE NOT FOUND");
)
);
run_program("/sbin/reboot");
run_program("/xbin/reboot");
This is only an idea
Ciaooooo

fbatti73 said:
In edify, I don't know,
but you can use a script.
In your updater-script you can copy one files (with only 1 string "ro.chiave=0") and one script in /tmp and run the script (somthing like that)
Code:
package_extract_file("test/test.prop", "/tmp/test.prop");
package_extract_file("test/script1", "/tmp/script1");
set_perm(0, 0, 0777, "/tmp/script1");
set_perm(0, 0, 0777, "/tmp/test.prop");
run_program("/tmp/script1");
the script
Code:
#!/system/bin/sh
CHKRIP=0
EXTRIP="/path/File_Check.do"
PROP_PATH="/tmp/test.prop"
if [ -f $EXTRIP ]; then
echo "Find file"
CHKRIP=1
fi
if [ $CHKRIP -eq 1 ]; then
#Update test.prop
echo "ro.chiave=1" > $PROP_PATH
fi
Now in the updater-script you can test the ro.chiave value like that
Code:
ifelse
(
file_getprop("/tmp/test.prop", ro.chiave) == "1",
(
ui_print("DO SOMTHING");
),
(
ui_print("FILE NOT FOUND");
)
);
run_program("/sbin/reboot");
run_program("/xbin/reboot");
This is only an idea
Ciaooooo
Click to expand...
Click to collapse
Thank you a lot
I would run assert on file_getprop to avoid auto reboot
Thank you again. Thought it was possible in edify, but yes, easier in script
Sent from my GT-I9100 using Tapatalk 2

lotherius said:
Is there any way to check that a file EXISTS without using an assert - I do not want the install to ABORT if the file does not exist.... currently, even trying to use read_file will cause an abort if the file does not exist. This of course means I can't use the method of checking for tsugi.txt that I thought I could...
[...]
... or use the shell script to set properties that can then be checked by edify scripting...
Click to expand...
Click to collapse
That last idea is the only thing I can think of that would work:
Have the shell script echo a value out to a tmp file based on whether the file exists and have an ifelse with either a file_getprop or a read_file conditional for the contents.
Edit: Doh, that's exactly what fbatti73 wrote out above. That's what I get for reading the first page and skimming the 2nd
Gave it another think though, this MIGHT work.. :
Code:
ifelse(run_program("/sbin/busybox", "[", "-f", "/system/etc/FILETOTEST", "]", "&&", "/sbin/busybox", "true"),
(ui_print("FILE EXISTS");
),
(
ui_print("FILE DOES NOT EXIST");
)
);
Edit: Tried it out for my new Nexus Louder installer and the above doesn't work, though it should, just edify being idiotic I guess. Resorted to the following:
Code:
ui_print("Checking for previous install...");
package_extract_file("instchk.sh", "/tmp/instchk.sh");
set_perm(0, 0, 0755, "/tmp/instchk.sh");
run_program("/tmp/instchk.sh");
ifelse(file_getprop("/tmp/insttest", "installed") == "1",
(ui_print("");
ui_print("Nexus Louder is already installed.");
ui_print("");
ui_print("To upgrade or repatch please run");
ui_print("revert for version: ", file_getprop("/system/etc/.nexuslouder", "installed.version"), ".");
ui_print("");
delete("/tmp/instchk.sh", "/tmp/insttest");
ui_print("Script will now exit...");
ui_print("");
unmount("/system");
unmount("/data");
abort();
),
(package_extract_file(".nexuslouder", "/system/etc/.nexuslouder");
delete("/tmp/instchk.sh", "/tmp/insttest");
)
);
And the instchk.sh is as follows:
Code:
#!/system/bin/sh
# check for the install file and write a value for edify to check
[ -f /system/etc/.nexuslouder ] && echo installed=1 > /tmp/insttest || echo installed=0 > /tmp/insttest
Pretty much the same as fbatti73, but perhaps streamlined a little. Hope my trial and error helps someone in the future. Cheers.

osm0sis said:
That last idea is the only thing I can think of that would work:
Have the shell script echo a value out to a tmp file based on whether the file exists and have an ifelse with either a file_getprop or a read_file conditional for the contents.
Edit: Doh, that's exactly what fbatti73 wrote out above. That's what I get for reading the first page and skimming the 2nd
Gave it another think though, this MIGHT work.. :
Code:
ifelse(run_program("/sbin/busybox", "[", "-f", "/system/etc/FILETOTEST", "]", "&&", "/sbin/busybox", "true"),
(ui_print("FILE EXISTS");
),
(
ui_print("FILE DOES NOT EXIST");
)
);
Edit: Tried it out for my new Nexus Louder installer and the above doesn't work, though it should, just edify being idiotic I guess.
Click to expand...
Click to collapse
If you want to chain commands with "&&", you'll need to invoke the "sh" binary since it's the shell that knows how to handle that. The "[" busybox applet will just receive it as an additional argument and not know what to do with it.
This will work:
Code:
ifelse(run_program("/system/bin/sh", "-c", "/sbin/busybox [ -f /system/etc/FILETOTEST ] && /sbin/busybox true"), ...
sh requires exactly 2 arguments: "-c" and another string with the command line as typed on the interactive shell.
To simplify the particular scenario you're targeting, you can simply run the normal test (or "[" ) command and use == to validate the exit code:
Code:
ifelse(run_program("/system/bin/sh", "-c", "test -f /system/etc/FILETOTEST") == 0, ...
The sh binary understands the built-in "test" command (at least on my device), so this will work even without using busybox. (Just the toolbox-bundled sh).

Bringing back an old thread but thanks to the ideas here it allow me to put together a script for my vrTheme template.
Basically the layout of this script goes as followed:
It will copy and paste the backup.sh file over to the /tmp folder of the recovery.
It will then run a security check of that backup.sh file when commanded to run it.
If the file does not run like it is suppose to (which means the file wasn't copied over properly) then it will abort the installation immediately and notify the user on the screen as well as giving a suggestion that they review their recovery log.
If the backup.sh runs then it will proceed forward with the installation.
The backup.sh will copy your build.prop file over to the /tmp folder of your recovery.
Then the updater-script will read the fingerprint found within the build.prop file.
If the fingerprint does not match then it will delete the copied backup.sh and build.prop file, abort the installation, and let the user know that their Rom is incompatible.
If the fingerprint does match then it will give an ok to proceed forward with the installation.
At this point some other scripts will be applied to the device for assisting with injecting the themes whether images or xml files in to their respectable apk's and push back to their respectable locations.
This script was exactly what I needed to keep it device specific and insuring integrity.
Click below to review:
Code:
##########################################################################################
# Script By Modding.MyMind #
# K2_CL Partition Info #
# #
# Highly recommended to research and put your own phone's partition info here #
# so you have a handy reference when editing the updater-script. #
# #
# mmcblk0p22: "misc" #
# mmcblk0p21: "recovery" #
# mmcblk0p20: "boot" #
# mmcblk0p35: "system" #
# mmcblk0p29: "local" #
# mmcblk0p36: "cache" #
# mmcblk0p37: "userdata" #
# mmcblk0p25: "devlog" #
# mmcblk0p27: "pdata" #
# mmcblk0p38: "fat" #
# mmcblk0p30: "extra" #
# mmcblk0p32: "carrier" #
# mmcblk0p16: "radio" #
# mmcblk0p17: "adsp" #
# mmcblk0p15: "dsps" #
# mmcblk0p18: "wcnss" #
# mmcblk0p19: "radio_config" #
# mmcblk0p23: "modem_st1" #
# mmcblk0p24: "modem_st2" #
# mmcblk0p31: "skylink" #
# mmcblk0p33: "cdma_record" #
# mmcblk0p34: "reserve" #
# #
# Modifications to make this a smart updater. #
# 1: Backup build.prop so it can be accessed after installing /system #
# or so the device can be properly confirmed in general. #
# 2: Check if backup.sh is already installed for security checks and rom compatibility. #
# #
# #
# #
##########################################################################################
package_extract_file("backup.sh", "/tmp/backup.sh");
set_perm(0, 0, 0777, "/tmp/backup.sh");
run_program("/sbin/busybox", "mount", "/system");
ifelse(
run_program("/tmp/backup.sh"),
(
ui_print(" ");
ui_print("Checking For Compatibility!");
ifelse(
file_getprop("/tmp/build.prop", "ro.build.fingerprint") == "htc/sprint_wwe_boost/k2cl:4.1.2/JZO54K/209682.6:user/release-keys",
(
ui_print(" ");
ui_print("Compatible Rom Detected!");
delete("/tmp/backup.sh");
delete("/tmp/build.prop");
ui_print("--Ok to proceed!");
ui_print(" ");
ifelse(
is_mounted("/system") == "/system", unmount("/system")
);
ifelse(
is_mounted("/data") == "/data", unmount("/data")
);
ifelse(
is_mounted("/cache") == "/cache", unmount("/cache")
);
ui_print(" ");
ui_print("Preparing To Inject Theme.");
#####################################################################
# Double checking to insure they are unmounted! Harmless procedure. #
#####################################################################
ui_print(" ");
ifelse(
is_mounted("/system") == "/system", unmount("/system")
);
ifelse(
is_mounted("/data") == "/data", unmount("/data")
);
ifelse(
is_mounted("/cache") == "/cache", unmount("/cache")
);
#############################################################
# Beginning the injection of modified images and xml files. #
#############################################################
ui_print(" ");
ui_print("Final Preparations...");
ui_print(" ");
ui_print(" ");
run_program("/sbin/busybox", "mount", "/system");
run_program("/sbin/busybox", "mount", "/data");
run_program("/sbin/busybox", "mount", "/cache");
ui_print("Injecting!!!");
package_extract_dir("vrtheme", "/cache/vrtheme");
set_perm(0, 0, 0755, "/cache/vrtheme/installtheme.sh");
set_perm(0, 0, 0755, "/cache/vrtheme/zip");
set_perm(0, 0, 0755, "/cache/vrtheme/cleanup.sh");
set_perm(0, 0, 0755, "/cache/vrtheme/zipalign");
run_program("/cache/vrtheme/installtheme.sh");
ui_print(" ");
ui_print("Theming Completed!");
ui_print(" ");
#######################
# Performing cleanup. #
#######################
run_program("/cache/vrtheme/cleanup.sh");
######################
# Unmounting mounts. #
######################
ui_print("--> Unmounting partitions");
run_program("/sbin/umount", "/system");
run_program("/sbin/umount", "/data");
#################################################
# Let user know that the injection is complete. #
#################################################
ui_print(" ");
ui_print("Injection Done!");
),
(
##############################################################################################################
# Rom found incompatible so remove copied build.prop and backup.sh file then unmount and abort installation. #
# Notify user of the current status. #
##############################################################################################################
ui_print(" ");
ui_print(" ");
delete("/tmp/backup.sh");
delete("/tmp/build.prop");
run_program("/sbin/umount", "/system");
run_program("/sbin/umount", "/data");
ui_print("Incompatible Rom Detected!");
ui_print("Not Recommended To Continue!");
)
);
),
(
run_program("/sbin/umount", "/system");
ui_print("ERROR READING YOUR ROM'S FINGERPRINT!");
ui_print("Please review your recovery.log!");
ui_print(" ");
ui_print("This Installation Will Be Aborted!");
)
);

I know that this is an old thread but I'm just trying to check with a script if a file already exists or not.
This is the code I am using but without success:
Code:
ifelse(run_program("/system/bin/sh", "-c", "test -e /system/priv-app/LGSystemUI/LGSystemUI.apk_orig") == 0,
(
ui_print("BACKUP ALREADY EXISTS");
),
(
ui_print("BACKUP DOES NOT EXIST");
ui_print("Backing up original...");
run_program("/sbin/busybox", "mv", "/system/priv-app/LGSystemUI/LGSystemUI.apk", "/system/priv-app/LGSystemUI/LGSystemUI.apk_orig");
)
);
Can anybody please help me?

KreNtal said:
I know that this is an old thread but I'm just trying to check with a script if a file already exists or not.
This is the code I am using but without success:
Code:
ifelse(run_program("/system/bin/sh", "-c", "test -e /system/priv-app/LGSystemUI/LGSystemUI.apk_orig") == 0,
(
ui_print("BACKUP ALREADY EXISTS");
),
(
ui_print("BACKUP DOES NOT EXIST");
ui_print("Backing up original...");
run_program("/sbin/busybox", "mv", "/system/priv-app/LGSystemUI/LGSystemUI.apk", "/system/priv-app/LGSystemUI/LGSystemUI.apk_orig");
)
);
Can anybody please help me?
Click to expand...
Click to collapse
Yes i can, but you'll have to wait until I'm at home later today.
I used to do the exact same thing, though its a long time ago so I'll have to take a closer look.

crazymister said:
Yes i can, but you'll have to wait until I'm at home later today.
I used to do the exact same thing, though its a long time ago so I'll have to take a closer look.
Click to expand...
Click to collapse
You will definitely make my day. I'll wait patiently.

KreNtal said:
I know that this is an old thread but I'm just trying to check with a script if a file already exists or not.
Code:
ifelse(run_program("/system/bin/sh", "-c", "test -e /system/priv-app/LGSystemUI/LGSystemUI.apk_orig") == 0,
Can anybody please help me?
Click to expand...
Click to collapse
you used above code, but i think you forgot some --> "" <--
try this line instead:
run_program("/system/bin/sh", "-c", "test -e /system/priv-app/LGSystemUI/LGSystemUI.apk_orig") == "0",
or in complete code:
Code:
ifelse(
run_program("/system/bin/sh", "-c", "test -e /system/priv-app/LGSystemUI/LGSystemUI.apk_orig") == "0",
(
ui_print("BACKUP ALREADY EXISTS");
),
(
ui_print("BACKUP DOES NOT EXIST");
ui_print("Backing up original...");
run_program("/sbin/busybox", "mv", "/system/priv-app/LGSystemUI/LGSystemUI.apk", "/system/priv-app/LGSystemUI/LGSystemUI.apk_orig");
)
);

Related

Help With an Edify Error

Okay, I have done this before and it worked fine. This time it's not working.
In my script I put :
Code:
package_extract_file("scripts/touchfiles.sh", "/tmp/touchfiles.sh");
set_perm(0, 0, 0777, "/tmp/touchfiles.sh");
run_program("/tmp/touchfiles.sh");
touchfiles.sh has this inside:
Code:
#!/sbin/sh
#
#
#
touch /tmp/aroma/themenew.prop
touch /tmp/aroma/stocknew.prop
touch /tmp/aroma/themestock.prop
touch /tmp/aroma/stockstock.prop
exit 0
The result is file not found when it gets to the run_program part.
I can adb shell in and cd to /tmp and see the file. I can cat the file. But when I attempt to execute it, I get file not found.
I know it's something stupid that too many hours behind the keyboard is preventing me from seeing.
Anybody see what's wrong?
Thanks!
D
.
Wait a sec,the script start but don't find the /tmp/aroma/.. or the touchfiles.sh don't start?
I don't have understand this.
dsb9938 said:
Okay, I have done this before and it worked fine. This time it's not working.
In my script I put :
Code:
package_extract_file("scripts/touchfiles.sh", "/tmp/touchfiles.sh");
set_perm(0, 0, 0777, "/tmp/touchfiles.sh");
run_program("/tmp/touchfiles.sh");
touchfiles.sh has this inside:
Code:
#!/sbin/sh
#
#
#
touch /tmp/aroma/themenew.prop
touch /tmp/aroma/stocknew.prop
touch /tmp/aroma/themestock.prop
touch /tmp/aroma/stockstock.prop
exit 0
The result is file not found when it gets to the run_program part.
I can adb shell in and cd to /tmp and see the file. I can cat the file. But when I attempt to execute it, I get file not found.
I know it's something stupid that too many hours behind the keyboard is preventing me from seeing.
Anybody see what's wrong?
Thanks!
D
.
Click to expand...
Click to collapse
Can you paste the error?
Sent from my Galaxy Nexus using xda premium
Running shell scripts
I'm not sure, but
1. I don't think you can execute shell scripts directly.
2. to run a shell script the shell needs to be available, so /system needs to have been mounted
Try something like (no need to make the script executable):
# ensure /system is mounted (replace the mount parameters with the ones for your system)
ifelse( is_mounted("/system") == "/system",
ui_print(" /system already mounted!"),
ifelse (mount("ext4", "EMMC", "/dev/block/stl12", "/system") == "/system",
ui_print(" Successfully mounted /system" ),
ui_print(" Could not mount, aborting") ) );
assert( is_mounted("/system") == "/system" );
package_extract_file("scripts/touchfiles.sh", "/tmp/touchfiles.sh");
run_program( "/system/bin/sh", "/tmp/touchfiles.sh");

[For 2ND ROM]sec_data symlinker [preload symlinker for 1rst ROM too]

Hi,
I use JB 4.1.2 ROM in 2nd ROM on my I9100.
Sometime, i want to have an approximate LITE version of ROM i modded in 2nd ROM.
For that, i move some apks from \data\sec_data\ to \data\sec_data\retired\ (retired is a personal name given to this folder, name it as you want), and as a purist maniac, i delete the correspondant symlink in\system\app\.
At this point, another maniac purist can tell me that it's not necesary to delete LN apk's files from \system\app\ folder too because if real apks are removed from \data\sec_data\ they become unexecutable during 2nd ROM playing even with LNs unecesary residual files in \system\app\.
After some tests, i have to re-imput some apks from \retired\ folder i move them, to their \data\sec_data\ original folder, but symlink are also necesary in \system\app\ folder too else they never work .
So, how to re-enable LN apk's files in \system\app\ from APKs present in \data\sec_data\ folder ?
According Many40 in this source which give me the idea to create this thread, there is a way to execute shell command from terminal emulator, to create a symlink from source location to desired location of destination folder :
ln -s TARGET_PATH SYMLINK_PATH
for example :
ln -s /data/sec_data/program.apk /system/app/program.apk
I tried <> method to automate the symlink managment and i usually flash a ZIP i make for this :
create_data_sec_data-vs_system_app_symlinks.zip
In this flasher, we have :
create_data_sec_data-vs_system_app_symlinks.zip\META-INF\com\google\android\updater-script :
show_progress(0.900000, 120);
ui_print("*********************************");
ui_print("SYMLINKING DATA_SEC_DATA to SYSTEM-APP FOLDER");
mount("ext4", "EMMC", "/dev/block/mmcblk0p12", "/preload");
mount("ext4", "EMMC", "/dev/block/mmcblk0p9", "/system");
mount("ext4", "EMMC", "/dev/block/mmcblk0p10", "/data");
mount("ext4", "EMMC", "/dev/block/mmcblk0p7", "/cache");
show_progress(0.100000, 0);
sleep(1);
package_extract_dir("tmp", "/tmp");
set_perm(0, 0, 0755, "/tmp/create_sec_data_symlinks");
run_program("/tmp/create_sec_data_symlinks");
show_progress(0.100000, 0);
sleep(1);
unmount("/system");
unmount("/data");
unmount("/cache");
unmount("/preload");
ui_print("Symlinks OK");
and
create_data_sec_data-vs_system_app_symlinks.zip\tmp\create_sec_data_symlinks :
#!/system/bin/mksh
mount -o remount rw /system
cd /data/sec_data
# Can't create array with /sbin/sh, hence we use mksh
apk_list=( `ls | grep .apk` )
odex_list=( `ls | grep .odex` )
items=${apk_list[*]}" "${odex_list[*]}
for item in ${items[@]}
do
ln -s /data/sec_data/$item /system/app/$item
done
the 2nd file in attachment ( create_preload_symlink_system_app_vs_system_app_symlinks.zip) is for users of JB 4.1.2 ROM in 1rst position with managed APKs in \preload\symlink\system\app\ folder symlinked to \system\app\
Hope many much user of JB 4.1.2 ROM in 2nd position and expect my method acceptable .
Thanks
Other Idea for dual-boot (i think dorimanx v8 only)
I want to thank Nemotatu for his Rom you can see here and for his great idea which consist to use a script to to move system APKs
from /preload/symlink/system/app/ to /data/sec_data/ and re-symlink them too.
In his original script, he moves /preload/symlink/system/app/*.apk to /data/app/app/*.apk , i prefer use the path
/data/sec_data/ as usual.
QUESTION :
Instead of rescript updater-script in a ZIP of a ROM to adapt it for 2nd position ROM, can we flash original ZIP
without any modification on updater-script, reboot recovery a loose dorimanx kernel but reboot recovery
once more time, have a reflash of dorimanx V8.xx, reboot recovery one more too, and finally flash this script
to move /preload/symlink/system/app/*.apk to /data/sec_data/*.apk and symlink them too to /system/app/ as
usual for 2nd ROM (also in 1rst habitual position, it's not my pb here)
Can we have a discuss here about this idea ? other purpose about this?
what modification i give :
In attachments, the original file from Nemotatu, and mine.
After reflexion, it could be an idea to avoid two JB 4.1.2 in dualboot ?
imagine we flash this script on 1rst rom and with dorimanx v8.xx, clone it after in 2nd rom.....
what append if you flash another jb 4.1.2 rom in 1rst rom and dorimanx v8.xx after, is you cloning process gave before make 2nd rom working ?
Great work, bro = )
Edit:little more explanation to my script
1st moving system apps ( not the symlinked apks) like Superuser,... etc to /tmp.
2- cleaning /system/app folder from old links
3- moving preload apps to data/app/app
4- re-symlink from /data
5- restore system apps from /tmp

[GUIDE][VRTheme-MOD][How-To] Make your TW VR-Theme flash on 4.4 and 4.3 from one zip

Android Version Check for Touch Wiz VR-Theme Install on 4.4 & 4.3 Based Roms
As you may know, since Android has updated to 4.4 KK, some files have been moved to new folders and file names have been changed making it a pain to install your old TW 4.3 VR-Theme on a 4.4 Rom. The main change I've seen is the addition of System/Priv-App. I'm going to show you how to make a script to put into your updater-script to check which version of Android the user is running, and how to modify the files so that it will install either, the files for a 4.4 based rom theme, or a 4.3 and earlier based rom theme all from the same zip. This essentially requires a 4.4 theme and your original 4.3 theme but will auto detect which one needs flashed. It will not convert your 4.3 to a 4.4 theme.
The files we will need to alter are:
Updater-script
VRtheme Folder itself (will be duplicated and one renamed)
Installtheme.sh (located inside VRTheme folder will also be renamed and modified in the duplicated folder)
System and Data apps (If your using them, will need to be duplicated and renamed)
Let's get started!
You can do these in any order but I'll go through it the way it all played out in my brain!
First, In the 4.4 VRtheme zip, I modified the updater script-located in META-INF/com/google/android/updater-script
by adding a Rom detection code just after the "mount" process, see RED text
If the user is running a 4.4 Rom the code will skip down to the bottom and install the theme files for 4.4, See the bottom Red text
None of these files need to be changed as long as you set up the original VRtheme folders to install the 4.4 theme. Just add your themed files into the folders as normal and it will flash
*IF* the code detects user is not running 4.4 (setup to work with anything other than 4.4 at this time so it will flash to 4.3,4.2 etc.)
It will complete the ifelse statement with what you instruct it to do. Which, in this case, we tell it to extract and install vrtheme4.3 and the installtheme4.3.sh which are the duplicated and renamed VRtheme folder and installtheme.sh file. See Blue Text
Code:
run_program("/sbin/busybox", "mount", "/system");
run_program("/sbin/busybox", "mount", "/data");
run_program("/sbin/busybox", "mount", "/dalvik");
[COLOR="Red"]ui_print(" Version Check For Theme Install");
ui_print(" By DroidMissionary");
ui_print("");
ui_print(" Checking Android Version");
# Check build version so we know which theme package to install 4.4 or earlier
ifelse(
is_substring("4.4", file_getprop("/system/build.prop","ro.build.version.release")),
(
ui_print(" Android 4.4 ROM detected");
ui_print(" Applying 4.4 Theme");
ui_print(" ");
),[/COLOR]
[COLOR="Blue"] (
ui_print(" *** Pre 4.4 Rom Detected ***");
ui_print(" ");
ui_print(" Applying 4.3 and Earlier Theme");
ui_print(" ");
ui_print(" Theming In Process");
ui_print(" ");
package_extract_dir("vrtheme4.3", "/sdcard/vrtheme4.3");
set_perm(0, 0, 0755, "/sdcard/vrtheme4.3/installtheme4.3.sh");
set_perm(0, 0, 0755, "/sdcard/vrtheme4.3/zip");
set_perm(0, 0, 0755, "/sdcard/vrtheme4.3/cleanup.sh");
set_perm(0, 0, 0755, "/sdcard/vrtheme4.3/zipalign");
run_program("/sdcard/vrtheme4.3/installtheme4.3.sh");
run_program("/sdcard/vrtheme4.3/cleanup.sh");
[COLOR="DarkOrange"]package_extract_dir("system4.3", "/system");[/COLOR]
run_program("/sbin/busybox", "umount", "/system");
run_program("/sbin/busybox", "umount", "/data");
run_program("/sbin/busybox", "umount", "/dalvik");
run_program("/sbin/busybox", "umount", "/sdcard");
)
);
[/COLOR]
[COLOR="Red"]package_extract_dir("vrtheme", "/sdcard/vrtheme");
set_perm(0, 0, 0755, "/sdcard/vrtheme/installtheme.sh");
set_perm(0, 0, 0755, "/sdcard/vrtheme/zip");
set_perm(0, 0, 0755, "/sdcard/vrtheme/cleanup.sh");
set_perm(0, 0, 0755, "/sdcard/vrtheme/zipalign");
run_program("/sdcard/vrtheme/installtheme.sh");
run_program("/sdcard/vrtheme/cleanup.sh");
package_extract_dir("system", "/system");
package_extract_dir("data", "/data");
ui_print("Additional files copied");
run_program("/sbin/busybox", "umount", "/system");
run_program("/sbin/busybox", "umount", "/data");
run_program("/sbin/busybox", "umount", "/dalvik");
run_program("/sbin/busybox", "umount", "/sdcard");
ui_print("Thanks for using VillainTheme Flasher");[/COLOR]
Second, I opened the 4.3/4.2 Theme and renamed the VRTheme folder to VRtheme4.3.
Do this also for the system and data folders if you are using them, in this case only system was used so I renamed it to system4.3
The modified system folder is called out in the Blue section above. See orange text ABOVE for the 4.3 system folder call out.
After you have them renamed, add them into you main zip file with the original VTtheme folders that contain the 4.4 theme.
This will keep them separated and allow you to call them out individually in the install-script and installtheme.sh
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
From here, I opened VrTheme4.3 folder and renamed installtheme.sh to installtheme4.3.sh. This way I would know which one it's for
Now that it is renamed, we need to go in and modify sections of the installtheme.sh that call out for the VRTheme folder. Since this is for the 4.3 theme, we will locate these call outs and simply add 4.3 to the end of VRTheme through-out the file. See Green Text for modified names
Code:
#!/sbin/sh
# Copyright VillainROM 2011. All Rights Reserved
# cleanup from last time
[ -d /sdcard/vrtheme-backup ] && rm -r /sdcard/vrtheme-backup
# we need to first go through each file in the "app" folder, and for each one present, apply the modified theme to the APK
# let us copy each original APK here first.
echo "Processing /system/app/"
busybox mkdir -p /sdcard/vrtheme-backup/system/app
busybox mkdir -p /sdcard/[COLOR="Green"]vrtheme4.3[/COLOR]/apply/system/app
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/system/app/
for f in $(ls)
do
echo "Processing $f"
cp /system/app/$f /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/app/
cp /system/app/$f /sdcard/vrtheme-backup/system/app/
done
echo "Backups done for system apps"
# repeat for /system/framework now
[ -d /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/system/framework ] && framework=1 || framework=0
if [ "$framework" -eq "1" ]; then
echo "Processing /system/framework"
busybox mkdir -p /sdcard/vrtheme-backup/system/framework
busybox mkdir -p /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/framework
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/system/framework
for f in $(ls)
do
echo "Processing $f"
cp /system/framework/$f /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/framework/
cp /system/framework/$f /sdcard/vrtheme-backup/system/framework/
done
echo "Backups done for frameworks"
fi
# repeat for /data/app now
[ -d /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/data ] && dataapps=1 || dataapps=0
if [ "$dataapps" -eq "1" ]; then
echo "Processing /data/app/"
busybox mkdir -p /sdcard/vrtheme-backup/data/app
busybox mkdir -p /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/data/app
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/data/app/
for f in $(ls)
do
echo "Processing $f"
cp /data/app/$f /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/data/app/
cp /data/app/$f /sdcard/vrtheme-backup/data/app/
done
echo "Backups done for data apps"
fi
# for each of the system apps needing processed
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/app/
for f in $(ls)
do
echo "Working on $f"
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/system/app/$f/
/sdcard/[COLOR="Green"]vrtheme4.3[/COLOR]/zip -r /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/app/$f *
done
echo "Patched system files"
if [ "$dataapps" -eq "1" ]; then
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/data/app/
for f in $(ls)
do
echo "Working on $f"
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/data/app/$f/
/sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/zip -r /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/data/app/$f *
done
echo "Patched data files"
fi
if [ "$framework" -eq "1" ]; then
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/framework
for f in $(ls)
do
echo "Working on $f"
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/system/framework/$f/
/sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/zip -r /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/framework/$f *
done
echo "Patched framework files"
fi
# and now time to zipalign
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/app/
busybox mkdir aligned
for f in $(ls)
do
echo "Zipaligning $f"
/sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/zipalign -f 4 $f ./aligned/$f
done
if [ "$dataapps" -eq "1" ]; then
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/data/app/
busybox mkdir aligned
for f in $(ls)
do
echo "Zipaligning $f"
/sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/zipalign -f 4 $f ./aligned/$f
done
fi
if [ "$framework" -eq "1" ]; then
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/framework/
busybox mkdir aligned
for f in $(ls)
do
echo "Zipaligning $f"
/sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/zipalign -f 4 $f ./aligned/$f
done
fi
# time to now move each new app back to its original location
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/app/aligned/
cp * /system/app/
chmod 644 /system/app/*
if [ "$dataapps" -eq "1" ]; then
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/data/app/aligned/
cp * /data/app/
chmod 644 /data/app/*
fi
if [ "$framework" -eq "1" ]; then
cd /sdcard/[COLOR="green"]vrtheme4.3[/COLOR]/apply/system/framework/aligned/
cp * /system/framework/
chmod 644 /system/framework/*
fi
# Do not remove the credits from this, it's called being a douche
echo "VillainTheme is done"
# we are all done now
That is it! After you have the 4.3 folders in place, renamed, and the install script/installtheme.sh calling out the correct folders, you are ready to flash!
Feel free to use any of my script in your theme zips, please just give credit and leave thanks​
Problems I ran into myself
The theme failed to install immediately upon starting to flash: My file was breaking when I unzipped the original, modified the files, and then re-zipped for some reason, to correct it, I modified the files then opened the original zip with 7zip file manager without un-zipping it, and pushed my files into the original zip overwriting the original. This allowed the original to flash with my modified files. It was acting like an improper signature on a decompiled/compiled apk.
Theme claimed it had installed but went quickly through the process and nothing installed:I need to modify the installtheme.sh to call out the proper 4.3 folders
I'd Like to give thanks to firstly, the most important factor @RockRatt
He allowed me to use his 4.4 theme template to build this Mod and is currently Helping me get my start in theming
All the Rom Devs
VRtheme system for the theme system of course
and
The XDA-Community
**Notes**
I am new to programming/ theming, really everything besides reading and replying to posts.
If you see an error or have a way to clean up or make things better please let me know, I'm always looking to improve​
Generic theme zip containing the Updater-script and Installtheme.sh - This theme zip is not however fully setup for installing on multiple platforms so just pull the two files and build your theme as shown in this post.
https://www.dropbox.com/s/ico5e9ouh15cu0d/MissionaryThemeScripts.zip
If anyone has ideas for other scripts, let me know and I'll work with you to make it happen
Great job and Thanks for working this out for me so I didn't have to post two different zips for each theme. I just posted up the full 4.2/4.3--4.4.2 vr theme for a test on my thread. Hopefully I will get a few testers. Again Great job and Thank you
Sent From My Spiderman,Ironman,Red,Dark Blue,Green, GreyedOut BadAss Themed I337
RockRatt said:
Great job and Thanks for working this out for me so I didn't have to post two different zips for each theme. I just posted up the full 4.2/4.3--4.4.2 vr theme for a test on my thread. Hopefully I will get a few testers. Again Great job and Thank you
Sent From My Spiderman,Ironman,Red,Dark Blue,Green, GreyedOut BadAss Themed I337
Click to expand...
Click to collapse
No problem buddy! I'll head over and grab a zip and test it out for ya, Thanks again for everything.
Well done!
Just saved me a ton of time..
:laugh:
Very interesting. I'm in the process of converting 4.3 to 4.4.2 themes. I will give your method a spin....
Nice work bro.
Haters Make Me Famous
Deviant Team Member
The Sickness said:
Very interesting. I'm in the process of converting 4.3 to 4.4.2 themes. I will give your method a spin....
Nice work bro.
Haters Make Me Famous
Deviant Team Member
Click to expand...
Click to collapse
Thanks man, it just pulls from the two different locations in the zip automatically depending on which version it detects so keep your 4.3 folder the same and add a 4.4 folder with all the renamed images etc. And just change the folder names in the updater-script to match your folder names. The script is for the community so use at your leisure, just give me a shout out :thumbup:
Sent from my SAMSUNG-SGH-I337 using XDA Premium 4 mobile app
ghostshel said:
Well done!
Just saved me a ton of time..
:laugh:
Click to expand...
Click to collapse
The Sickness said:
Very interesting. I'm in the process of converting 4.3 to 4.4.2 themes. I will give your method a spin....
Nice work bro.
Haters Make Me Famous
Deviant Team Member
Click to expand...
Click to collapse
Would either of you like me to send you "generic" updater-script instead of having to mod it all the way through yourselves?
Droidmissionary said:
Would either of you like me to send you "generic" updater-script instead of having to mod it all the way through yourselves?
Click to expand...
Click to collapse
Sure bro, that would save me some time
Haters Make Me Famous
Deviant Team Member
The Sickness said:
Sure bro, that would save me some time
Haters Make Me Famous
Deviant Team Member
Click to expand...
Click to collapse
https://www.dropbox.com/s/ico5e9ouh15cu0d/MissionaryThemeScripts.zip
I made a theme zip. These updater_scripts/Binary are touchy and tend to fail if I just copy certain parts so I usually just use 7 zip to pull the meta-inf folder out of the zip over to my theme folder then work on it from there. I'm probably just not smart enough to know how to work with them fully yet. The Updater-script and installtheme.sh are both in the zip. This file however is not fully setup for installing on multiple android versions yet due to the fact that I don't have the older theme folders in place but it does have the 2 important files. Let me know if this fails.
Droidmissionary said:
https://www.dropbox.com/s/ico5e9ouh15cu0d/MissionaryThemeScripts.zip
I made a theme zip. These updater_scripts/Binary are touchy and tend to fail if I just copy certain parts so I usually just use 7 zip to pull the meta-inf folder out of the zip over to my theme folder then work on it from there. I'm probably just not smart enough to know how to work with them fully yet. The Updater-script and installtheme.sh are both in the zip. This file however is not fully setup for installing on multiple android versions yet due to the fact that I don't have the older theme folders in place but it does have the 2 important files. Let me know if this fails.
Click to expand...
Click to collapse
Thanks bro....I will try em out tomorrow after work. My old butt is in bed lol
Haters Make Me Famous
Deviant Team Member
Droidmissionary said:
Would either of you like me to send you "generic" updater-script instead of having to mod it all the way through yourselves?
Click to expand...
Click to collapse
Heck yes. That works.
ghostshel said:
Heck yes. That works.
Click to expand...
Click to collapse
Check a couple posts earlier
Sent from my SAMSUNG-SGH-I337 using XDA Premium 4 mobile app
Droidmissionary said:
Check a couple posts earlier
Sent from my SAMSUNG-SGH-I337 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Yea, I got it thanks!

Creating a Flashable Zip to start a TWRP Restore

Hi everyone.
I have a TWRP backup of Boot, System, and Data that I need to restore to a number of SM-T580 devices.
Typically TWRP requires backup paths to be in the format TWRP/BACKUPS/[android_id]/[whatever], but I have found that if you use the the CLI, you can get generalize the android_id part. IE: something like this works fine from the TWRP terminal:
Code:
twrp restore /sdcard/TWRP/BACKUPS/x/y
Having gotten this far, I'd like to see if I could make this a little easier to run for other members of my team. I've found a number of guides on creating Flashable Zip's which contain scripts in them that could themselves call upon shell scripts, so this looks like it may be the easiest way for my team to run the restore without having to use the terminal or know the android_id of any of the devices.
I borrowed my META-INF\com\google\android\update-binary from this Ultra Lean Rom, and my updater-script looks like this:
Code:
package_extract_dir("META-INF/tmp", "/tmp");
set_perm(0, 0, 0777, "/tmp/restore.sh");
run_program("/tmp/restore.sh");
META-INF/tmp/restore.sh looks like this:
Code:
#!/sbin/sh
/sbin/twrp restore /sdcard/TWRP/BACKUPS/x/y
When I put this on the device and try to run in through the Install process though, it will just sit there trying to "install" indefinitely. The restore.sh does get extracted into /tmp though, and if you run /tmp/restore.sh from the terminal the restore works great, but it just hangs from the Install process.
I have also tried the following lines in place of the above run_program line:
Code:
run_program("/sbin/busybox", "sh", "-c '/sbin/twrp restore /sdcard/TWRP/BACKUPS/x/y'");
run_program("/sbin/busybox", "sh", "/sdcard/restore.sh");
run_program("/sbin/sh -c '/sbin/twrp restore /sdcard/TWRP/BACKUPS/x/y'");
run_program("/sbin/busybox", "sh", "-c 'twrp restore /sdcard/TWRP/BACKUPS/x/y'");
run_program("/sbin/busybox", "sh", "-c", "'", "twrp", "restore", "/sdcard/TWRP/BACKUPS/x/y", "'");
run_program("/sbin/sh", "-c", "'", "twrp", "restore", "/sdcard/TWRP/BACKUPS/x/y", "'");
run_program("/sbin/sh -c 'twrp restore /sdcard/TWRP/BACKUPS/x/y'");
run_program("/sbin/sh", "-c 'twrp restore /sdcard/TWRP/BACKUPS/x/y'");
run_program("/sdcard/restore.sh");
run_program("/sbin/busybox", "sh", "/sdcard/restore.sh");
run_program("/sbin/sh", "/sdcard/restore.sh");
run_program("/sbin/sh", "twrp", "restore", "/sdcard/TWRP/BACKUPS/x/y");
In those cases I had manually put restore.sh in /sdcard/ and chmod'd it ahead of time. I'd also tried all of the above with restore.sh being extracted to /tmp but didn't paste for the sake of redundancy.
I have also tried switching out the top line to "#!/sbin/busybox sh" and "/sbin/twrp" to just "twrp" in recovery.sh, and pretty much every possible combination of all of the above, but only ever getting it the install process to either hang indefinitely or in some cases finish immediately with no errors (but no restore either).
I know this is probably a bit of a longshot as it's probably a niche need, but if anyone has any thoughts on this I'd appreciate it. Thank you in advance for your feedback.

Please help me with this debloat flashable zip

Hello Everyone
I created a small flashable zip in order to remove the apps I don't want COMPLETELY from /system/app but for no apparent reason it doesn't remove anything.
Here's what I have wrote inside the updater-script file :
Code:
unmount("/system");
unmount("/data");
unmount("/preload");
ui_print(" ");
ui_print("Mounting partitions..");
run_program("/sbin/mount", "-t", "auto", "/system");
run_program("/sbin/mount", "-t", "auto", "/data");
run_program("/sbin/mount", "-t", "auto", "/cache");
ui_print("Partitions mounted.");
ui_print("Starting debloat process..");
ui_print("Removing apps from /system/app");
delete_recursive("/system/app/BookmarkProvider");
run_program("/sbin/rm", "-rf", "system/app/Browser");
run_program("/sbin/rm", "-rf", "system/app/FaceUnlockService-res");
run_program("/sbin/rm", "-rf", "system/app/NfcNci");
ui_print(" ");
ui_print("Removal Process Finished.");
ui_print(" ");
ui_print("Cleaning Cache");
run_program("/sbin/rm", "-rf", "/cache");
ui_print(" ");
ui_print("Unmounting partitions: /system /data /cache");
unmount("/data");
unmount("/cache");
unmount("/system");
ui_print(" ");
It's mind boggling because the script runs flawlessly when I flash it through Recovery except it doesn't remove ANYTHING!
Some one please tell me what am I doing wrong here?
I've also attached the flashable zip file.
Device : Samsung Galaxy Note 3
Rom : LineageOS (Rooted with Magisk)
Recovery : TWRP 3.4.0-1 (Latest)
Busybox : Installed through Magisk.
Thanks.
Excerpt of known commands in OTA updater-script
unmount
Syntax
unmount <mount_point>
Description
Unmounts the filesystem mounted at mount_point.
run_program
Syntax
run_program <program-file> [<args> ...]
Description
Run an external program included in the update package.
delete_recursive
Syntax
delete_recursive <file-or-dir1> [... <file-or-dirN>]
Description
Delete a file or directory with all of it's contents recursively.
mount
Syntax
mount <fs_type, partition_type, name, mount_point>
Description
Mounts a filesystem of fs_type at mount_point. partition_type must be one of these: system , userdata, etc.pp.
This in mind the main failure in your script is misuse of run_program, IMHO
Spoiler
Mount.
You could test those using terminal first...
But why not just use TWRP's file manager?
jwoegerbauer said:
Excerpt of known commands in OTA updater-script
unmount
Syntax
unmount <mount_point>
Description
Unmounts the filesystem mounted at mount_point.
run_program
Syntax
run_program <program-file> [<args> ...]
Description
Run an external program included in the update package.
delete_recursive
Syntax
delete_recursive <file-or-dir1> [... <file-or-dirN>]
Description
Delete a file or directory with all of it's contents recursively.
mount
Syntax
mount <fs_type, partition_type, name, mount_point>
Description
Mounts a filesystem of fs_type at mount_point. partition_type must be one of these: system , userdata, etc.pp.
This in mind the main failure in your script is misuse of run_program, IMHO
Click to expand...
Click to collapse
Can you please point out to where the problem comes from precisly and what's wrong with the run_program command I wrote? Sorry I'm total noob
CXZa said:
Spoiler
Mount.
You could test those using terminal first...
But why not just use TWRP's file manager?
Click to expand...
Click to collapse
I appreciate your help but I still cannot figure it out. This is just a snip from a big list of apps that I try to debloat so that's why I created this flashable zip.
Marvino. said:
I appreciate your help but I still cannot figure it out. This is just a snip from a big list of apps that I try to debloat so that's why I created this flashable zip.
Click to expand...
Click to collapse
Deleting those with file manager is much faster than typing that script...
How about mounting them first in TWRP and then running the script? Of course edit it 1st so it skips the mounting part...
BTW, yours looks like very much like this one.
Easy debloat script for Oreo Stock ROMs
I haven't seen anyone post any easy debloat script, so here is my personal one for N8. This is made for OREO - but it will work for Nougat-based ROMs too, as long as the file names haven't been changed. This could also work well for S8, S9 and...
forum.xda-developers.com
Marvino. said:
Can you please point out to where the problem comes from precisly and what's wrong with the run_program command I wrote? Sorry I'm total noob
Click to expand...
Click to collapse
Why not simply carefully read my post? And also why do you ignore that within an updater-script the built-in mount and delete_recursive functions have to be used, instead of run_program - what indeed serves a complete other purpose?
Again:
Mount
This built-in command mounts a partition, so if you want to operate on files within system and/or data partition you have to mount system partition, data for data partition with this built-in function.
To mount system :
mount(“ext4″, “EMMC”, “/dev/block/mmcblk0p5″, “/system”);
Here mmcblk0p5 is the name of system partition for mtk 6589 chipsets (this name varies from device to device)
To mount data:
mount(“ext4″, “EMMC”, “/dev/block/mmcblk0p7″, “/data”); (partition name varies from device to device)
Take the time and look inside here.
CXZa said:
BTW, yours looks like very much like this one.
Easy debloat script for Oreo Stock ROMs
I haven't seen anyone post any easy debloat script, so here is my personal one for N8. This is made for OREO - but it will work for Nougat-based ROMs too, as long as the file names haven't been changed. This could also work well for S8, S9 and...
forum.xda-developers.com
Click to expand...
Click to collapse
Only to have said it: The updater-script, which is offered with the link - what also circulates under different names on the internet - is crap: the author(s) have no idea how to write a updater-script.
@Marvino.
Code:
delete_recursive("/system/app/BookmarkProvider");
delete_recursive("/system/app/Browser");
delete_recursive("/system/app/FaceUnlockService-res");
delete_recursive("/system/app/NfcNci");
jwoegerbauer said:
Only to have said it: The updater-script, which is offered with the link - what also circulates under different names on the internet - is crap: the author(s) have no idea how to write a updater-script.
Click to expand...
Click to collapse
Well, it might have worked in his device okay. Busybox mount use fstab in /etc. Not normally there in TWRP. So one should use device path as well.
The hardiest part I guess is to select what to remove really. What might work for some, might make a nice little sushi tray for another...
Have never understood it why people use true EDIFY conformant synthax when creating an OTA package: An OTA script can get realized as plain shell script - what makes things drastically easier and device independent.
BTW: All EDIFY functions can get replaced by equivalent user-written functions. See also here,

Categories

Resources