Related
Hi all! This is a guide from PIRATEPARTY about the creation of a simple UPDATE.ZIP to flash on your Android phone, in recovery mode.
I've created a repository on GITHUB where you can download the "update.zip" that we'll use and modify.
So, this is the repository: update.zip--for-Android-Devices-
You can download it as ZIP archive and rename it as update.zip .
So, we have now the most important file, that we're going to modify:
All the apps that you want to insert in the archive and install on the phone, must have the .apk estension and you have to put them in /data/app . Then, if you want also the app data files, you have to take these files from your phone, going with a rooted file manager (i suggest Root_Explorer) to /data/data , copying the app folder and pasting it in /data/data of the UPDATE.ZIP.
So we have all the apps and datas that we want. Now, we have to write the script.
Let's go to META-INF/com/google/android/ and open 'updater-script' with a simple text editor.
The only lines that you have to modify are:
Code:
set_perm(1000, 1000, 0644, "/data/app/[PACKAGE].apk");
set_perm_recursive(1000, 1000, 0777, 0777, "/data/data/PACKAGE_DATA_FOLDER");
delete("/data/dalvik-cache/[email protected]@[PACKAGE][email protected]");
For each app you have to write these lines. This is an example if you want to put ROOT_EXPLORER.APK in the UPDATE.ZIP:
Code:
set_perm(1000, 1000, 0644, "/data/app/ROOT_EXPLORER.APK");
set_perm_recursive(1000, 1000, 0777, 0777, "/data/data/ROOT_EXPLORER_DATA_FOLDER");
delete("/data/dalvik-cache/[email protected]@ROOT [email protected]");
That' all. But if you want to delete some apps from your phone, you have to write between
Code:
ui_print("| 80% Installing Applications |");
and
Code:
package_extract_dir("data", "/data");
this line:
Code:
delete("/APK_DIR/APP.APK");
IT'S IMPORTANT TO LEAVE AN EMPTY LINE AT THE END OF THE SCRIPT, OTHERWISE THE ZIP WON'T WORK!
You can easily find the name of the app going with Root Explorer to /system/app and searching the same app.
If you also want to add your modified Apps, you've to sign them with a simple app: Auto-Sign, putting them in /auto-sign/update/app and renaming it to Launcher.apk .
You can download AUTO-SIGN from the attachements!
With it you can sign your apks or your zip. So, finally, when you'll finish your zip, you'll have to put it in Auto-Sign folder ("/auto-sign").
Then, open Auto-Sign, choose your zip or apk, and click AUTO-SIGN. It will create a new apk or zip, name as SIGNED-apk/zip.
Now, you only have to put the update.zip on your sd-card and flash it! Have fun guys!
mackief,
Thanks for your tutorial. I wrote a removal script for GB that deletes everything i don't use in my ROM. I recently moved to ICS and that very script is still working but, each time, during restart, I lose root rights.
Any idea where it could come from?
What rom are u using?? What device??
I think that the problem is about the rom, cause you said that u didnt have problem in previous rom and you used the same script...
So, to find the problem, i have to know the rom, the device, and the script.
Can you post the script here?
mackief,
Sorry for having been so long to answer, I was not monitoring the thread
I use nightly CM9 roms for my Note (N7000). You'll find attached my latest script that still bothers me.
If you can have a look at it, it would be nice.
good lession for tweaking my one x
vua777 said:
good lession for tweaking my one x
Click to expand...
Click to collapse
I'm glad do help you!
The_Steph said:
mackief,
Sorry for having been so long to answer, I was not monitoring the thread
I use nightly CM9 roms for my Note (N7000). You'll find attached my latest script that still bothers me.
If you can have a look at it, it would be nice.
Click to expand...
Click to collapse
I read your script, but i think that the only problem is about the root app: Superuser and his components. So, check out if some elements that you want to delete are associated to Superuser, and dont delete superuser.apk .
However, usually, in CM9 there are some apps that you CANT and HAVE NOT to delete. I suggest to you to read this file: REMOVABLE APPS
So, Superuser gives you root rights, so dont delete it.
Dont delete the list of apps that is on the link above.
The last suggestion is that you have to check if you're deleting something else that can create bugs with superuser and his working.
Write me if you want to know something else or also if these solutions arent useful: i'll help you! Bye!
Interesting guide. I am curious though, you have it setting permissions but have you tried it without doing so? I ask because I made a script for CWM which copies my apk's to data/app/ and I don't set permissions and have no issues. In theory you shouldn't need to, the apk should retain the proper permissions even when copied. As well, why not set the permissions for the entire contents of the folder, ie, set the permission recursively like you do for data/data and have it run at the end of the script once everything is copied?
Lastly, one thing to note with this method of installing apps is that your first boot will take awhile, the ROM has to create the Dalvik for all the apps you just flashed, I hadn't considered that when i first ran my script and thought something was wrong.
Волк said:
Interesting guide. I am curious though, you have it setting permissions but have you tried it without doing so? I ask because I made a script for CWM which copies my apk's to data/app/ and I don't set permissions and have no issues. In theory you shouldn't need to, the apk should retain the proper permissions even when copied. As well, why not set the permissions for the entire contents of the folder, ie, set the permission recursively like you do for data/data and have it run at the end of the script once everything is copied?
Lastly, one thing to note with this method of installing apps is that your first boot will take awhile, the ROM has to create the Dalvik for all the apps you just flashed, I hadn't considered that when i first ran my script and thought something was wrong.
Click to expand...
Click to collapse
At first, i have to say to u that permissions can be not specified: i think that all the files that u put in a folder have the same permission of the folder. I set permissions only for safety.
Then, about the first boot duration, there's nothing wrong.
The system only take a while to put into effects the changes, creating the Dalvik for example.. Don't worry: it's normal!
I know it's building dalvik, it simply hadn't occurred to me initially that that was the reason for it not booting. A file can have a different permission than the folder, but I think it's only that you can have the folder r/w and a file r/o. Then, on your script you can just set permissions recursively and save yourself setting permission for each app/file individually.
Sent from my LG-P999 using xda premium
Yeah! You can just do it!
Before CWM 5, I used to have a script that would let me add lots of files without individual lines for each.
It worked similar to gapps, where files are separated by commas.
Any ideas?
I will be adding sound files to system/media/audio/alarm.
What are symlinks?
Sent from my MB525 using Tapatalk 2
hermeticist said:
Before CWM 5, I used to have a script that would let me add lots of files without individual lines for each.
It worked similar to gapps, where files are separated by commas.
Any ideas?
I will be adding sound files to system/media/audio/alarm.
Click to expand...
Click to collapse
U can easily write the package_extract command:
Code:
package_extract_dir("???", "/???");
You write the folder, and then the android folder when you want to extract the script package.
Then you set the permission of the folder and all is done!
pjgowtham said:
What are symlinks?
Sent from my MB525 using Tapatalk 2
Click to expand...
Click to collapse
Symlinks are Simbolic Links, so they link a folder to another folder, for example, a linked folder...
In Windows, you can create a link on the desktop and you can change the name of the linked icon, but it is anyway connect to the same file, with different name.
So, the symlinks are files that connect with other files. When the os see this symlinks, it read the element info to which it is connected??
It's not difficult to understand. I suggest to you to read this: SymLinks
Hope i've helped u all! If it doesnt, ask me again!
mackief said:
U can easily write the package_extract command:
Code:
package_extract_dir("???", "/???");
You write the folder, and then the android folder when you want to extract the script package.
Then you set the permission of the folder and all is done!
Click to expand...
Click to collapse
Thanks.
I'm a little unclear about setting permissions though. Would you mind explaining?
Thanks i understood
Sent from my MB525 using Tapatalk 2
hermeticist said:
Thanks.
I'm a little unclear about setting permissions though. Would you mind explaining?
Click to expand...
Click to collapse
So, if u want to set folder permissions, this is the code:
Code:
set_perm_recursive(1000, 1000, 0777, 0777, "/data/data/PACKAGE_DATA_FOLDER");
And these permissions are for a 'read-only' folder.
If u want to set file permissions, this is the code:
Code:
set_perm(1000, 1000, 0644, "/data/app/[PACKAGE].apk");
Also these permissions are for a 'read-only' file.
So do u need something else??
Hope u understood!
OK, here's one I can't seem to figure out, I want to copy data/app to my SD card. I tried(with /data mounted):
run_program("/sbin/busybox", "mkdir", "/sdcard/app/");
run_program("/sbin/busybox", "cp", "r", "/data/app/", "/sdcard/app/");
it fails with status 6, and log shows syntax error. I'm at a loss.
You're telling it to copy a file named "r". Change it to "-r".
I tried that already, I actually changed it to that, I played with my code a few times before posting.
Here is the last version I tried: http://db.tt/10DQzTQM
Sent from my LG-P999 using xda premium
nice tuto thank you very much for it
please i am noobe here
i have a unpadte to make but i don't know how here the structure of it
how to do the script please
Hi,
This is just to let everyone know that the latest updates being pushed by Asus breaks Voodoo OTA Rootkeeper's su backups.
Basically it removes the setuid bit from the su backup that is kept in /system/su-backup and from all binaries in the /system partition.
So you will lose root and will not be able to restore it with Rootkeeper after this OTA.
Luckily, the "1-Click Transformer Root" tool still works on it:
http://forum.xda-developers.com/showthread.php?p=26918950
So you can gain root once again and keep your stock recovery with OTAs enabled.
Cheers!
idcrisis said:
Basically it removes the setuid bit from the su backup that is kept in /system/su-backup and from all binaries in the /system partition.
Click to expand...
Click to collapse
Do you still have the OTA dlpkgfile? If so, could you please share it somewhere (dropbox/box.com/wuala/etc.)?
sbiriguda said:
Do you still have the OTA dlpkgfile? If so, could you please share it somewhere (dropbox/box.com/wuala/etc.)?
Click to expand...
Click to collapse
Here you go:
http://www.mediafire.com/?d1cq2f911ipd35r
From what I can see the culprit seems to be these lines in the updater-script:
Code:
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
Let us know if you find another place to hide the damn thing.
Maybe /system/.subackup or /system/.subackup/.subackup
Worth a try perhaps.
idcrisis said:
Code:
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
Let us know if you find another place to hide the damn thing.
Maybe /system/.subackup or /system/.subackup/.subackup
Click to expand...
Click to collapse
Nope, set_perm_recursive traverses the entire hierarchy, so the first line will nuke the setuid/setgid bits on whatever executable it finds under /system.
I'm a bit puzzled - though - since the same line is present in each and every OTA released by Asus and to my knowledge no-one has ever had any problem with OTA Rootkeper.
sbiriguda said:
Nope, set_perm_recursive traverses the entire hierarchy, so the first line will nuke the setuid/setgid bits on whatever executable it finds under /system.
I'm a bit puzzled - though - since the same line is present in each and every OTA released by Asus and to my knowledge no-one has ever had any problem with OTA Rootkeper.
Click to expand...
Click to collapse
I had also kept another copy for safekeeping in case they manually detected for the Rootkeeper copy of su. This was stored as /system/etc/su-backup and had mode 06755 as /system/su-backup.
Both were changed to 00755 by the update presumably from the first line.
I would think the second line would be present in all the past updates, but the first may not have been or for some reason wasn't working properly in the previous updates.
Or something very strange happened on my tablet. Unlikely as I have kept everything very close to stock.
Someone else may be able to confirm by tomorrow perhaps when it's been pushed far and wide.
The tf101 9.2.1.24 update nukes Voodoo backups to
Hello, i was able to restore su backup from voodoo after upgrading from 21 to 24 on my tf101, without any problems
Rooted with wolf's method 3 on .21
Regards
PERI also works on the latest update
Confirmed on other tablets, 9.2.2.6 breaks Rootkeeper by wiping the setuid bit from all binaries in /system recursively.
Onwards to next idea!
I have been experiencing alot difficulties while pushing Framework-res.apk and SystemUI.apk in my Stock deodexed rom as well as Custom Roms. It always end up in a bootloop.
Can somebody make updater-script for both files separately and make a flashable zip for them, so that whenever I have to flash these 2 files, I just replace them in those zips and I'm ready to go?
I tried learning editing Updater-script, but I always ended up in some errors.
Please Help.
I would really appreciate it, I know its just a 10 minutes work for some people here. :fingers-crossed:
Please Help me
Code:
run_program("/sbin/busybox", "mount", "/system");
package_extract_dir("app", "/system/app");
run_program("/sbin/busybox", "umount", "/system");
systemui above
framework-res below
Code:
run_program("/sbin/busybox", "mount", "/system");
package_extract_dir("framework", "/system/framework");
run_program("/sbin/busybox", "umount", "/system");
not 10mins,
less than a minute
Hey thank you!
Thank u for these codes,
What about Update-binary in META-INF folder? Is it same for every flashable zip? Can I use these codes on both Stock and custom roms?
varun90rulz said:
Thank u for these codes,
What about Update-binary in META-INF folder? Is it same for every flashable zip? Can I use these codes on both Stock and custom roms?
Click to expand...
Click to collapse
open updater-script with notepad and paste these codes,
the update-binary is universal so yea
deathnotice01 said:
open updater-script with notepad and paste these codes,
the update-binary is universal so yea
Click to expand...
Click to collapse
Thanks! I'll just check this and will ask if anything goes wrong! Thanks a lot. :good:
deathnotice01 said:
open updater-script with notepad and paste these codes,
the update-binary is universal so yea
Click to expand...
Click to collapse
i thought editing it in normal notepad will cause problems
status 0?
status 6?
status 7 or something?
74M3NUMB3RS said:
i thought editing it in normal notepad will cause problems
status 0?
status 6?
status 7 or something?
Click to expand...
Click to collapse
works fine with me
I have heard that too
74M3NUMB3RS said:
i thought editing it in normal notepad will cause problems
status 0?
status 6?
status 7 or something?
Click to expand...
Click to collapse
I read somewhere opening in Notepad causes trouble, I use Notepad++ for this purpose.
I have a one question:
what using this code "/sbin/busybox"
varun90rulz said:
I read somewhere opening in Notepad causes trouble, I use Notepad++ for this purpose.
Click to expand...
Click to collapse
Note pad ++ updated would be more appropriate to use.
varun90rulz said:
I have been experiencing alot difficulties while pushing Framework-res.apk and SystemUI.apk in my Stock deodexed rom as well as Custom Roms. It always end up in a bootloop.
Can somebody make updater-script for both files separately and make a flashable zip for them, so that whenever I have to flash these 2 files, I just replace them in those zips and I'm ready to go?
I tried learning editing Updater-script, but I always ended up in some errors.
Please Help.
I would really appreciate it, I know its just a 10 minutes work for some people here. :fingers-crossed:
Please Help me
Click to expand...
Click to collapse
Follow these steps :
1. If you have a custom rom then get its updater-script,open it with notepad++
2. Find & copy this line mount("ext4", "EMMC", "/dev/block/@@@@@", "/system");
Note: @@@@@ will be something different for your device
3.FINAL STEPS MAKE YOUR UPDATER-SCRIPT:
Write these lines
mount("ext4", "EMMC", "/dev/block/@@@@@", "/system");
delete("/system/app/framework-res.apk");
package_extract_dir("system", "/system");
set_perm_recursive(0, 0, 0755, 0644, "/system/framework");
unmount("/system");
That's it & u r done.
Press the Thanks button if i helped you :good:
& Lemme know for any queries
Hello!!
I have a problem, and I'll struggle to give as many details necessary for a fast solving.
During this last week, I've been trying to build my own ROM from scratch, for educational purposes. I managed to compile a ROM from SlimBean source, and everything went fine. It works. I replaced the Holo launcher with Trebuchet Launcher on it. Unfortunately, on the Nexus 4, Trebuchet preferences aren't accessible due to the lack of a default menu button. I managed to make an app with some help from a nice guy in this thread (http://forum.xda-developers.com/showthread.php?p=42090229#post42090229) to launch the Trebuchet Preferences activity. It's a very simple app. Placing the app in system/app, then flashing the ROM, makes the app force close on opening. Placing the app in data/app inside the ROM zip, then flashing the ROM makes the app to not install. The app simply doesn't show in the app drawer. When manually installing the app, it works like a charm.
I added the following lines in the updater-script:
Code:
package_extract_dir("data", "/data");
set_perm(1000, 1000, 0771, "/data");
set_perm_recursive(1000, 1000, 0771, 0644, "/data/app");
My ROM.zip consists of the following stuffs:
system, data, meta-inf, boot.img
In my /data folder I only have an "app" folder, where the app is located. Do I need other stuff for the app to work normally? The weird thing it that I tried to put other apps in this folder, and they installed normally.
TL;DR:
I made a simple app, put it in my ROM.zip in the data/app folder, and it doesn't show up in the app drawer after installing the zip.
Hope you can help me out. Thanks for future replies.
Edit : PM sent
XT907
rooted
unlocked
TWRP 2.5
Stock ROM 4.1.2 98.15.66
Thinking about taking the 98.18.78 OTA and keeping stock. Had a couple of ideas to keep root and keep TWRP.
Looking in META-INF/com/google/android/updater-script from /cache/Blur_Version.98.15.66.XT907.Verizon.en.US.zip, the problem lines are:
Code:
# This breaks root
2863: set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");
Code:
# This breaks TWRP on reboot
2828: assert(package_extract_dir("recovery", "/system"));
So, looks like the options are
1. Edit the OTA .zip by
a. Adding to updater-script
Code:
set_perm(0, 0, 6755, "/system/xbin/su");
b. Include a script to move recovery-from-boot.p to recovery-from-boot.bak (overwriting previous) and calling from updater-script.
c. Re-sign the zip and flash in TWRP.
-or-
2. Flash the OTA in TWRP, then manually edit /system/xbin/su permissions to 6755 and rename /system/recovery-from-boot.p to /system/recovery-from-boot.bak before rebooting.
Questions are: Anyone tried either? After flashing a .zip in TWRP, can you return to the command line to do stuff before rebooting?
Thank you!
That is interesting.
Is there any way to stop the checks for stock apps and install over them?
donslade said:
That is interesting.
Is there any way to stop the checks for stock apps and install over them?
Click to expand...
Click to collapse
Not exactly. Most of the updates in the OTA are in the form of binary patches. These patches contain instructions to modify existing binaries, and only represent the changes to the files. That is why the OTA is only 50 MB, whereas a full copy of all the affected binaries would be much larger, as high as 600 MB.
For the patch to work, it has to affect the exact same binary that Moto/VZW used to generate the patch. This is why the OTA verifies the checksums of the files to be patched before performing the update.
I suppose you could remove some of the check (apply_patch_check) and apply (apply_patch) commands from the updater-script to ignore updates to bloatware.