Hello everybody
Well, I'm creating a Custom ROM, but when I'm getting in Setting>Security, setting stop immediatly...
I've read that I should wrote in a terminal : su; mount -o rw,remount /system ; cd /vendor/firmware/keymaster; chmod 0644 * ...
But can I fix it with the updater script ? I try : set_perm_recursive(0, 2000, 0644, 0644, "/system/vendor/firmware/keymaster"); but it didn't work... why ? There is other solution ? Thanks
Hi there,
Please read this thread: Aroma, Edify, updater script Question and Answer thread
Also you can review some of the guides started in this forum and ask if you have more about right there:
xda-developers -> Chef Central -> Android
Good luck
Related
I want to place a script I have written in init.d, so that it will be executed on every startup.
Here's what I am doing:
busybox mount -o rw,remount /system"
busybox cp -f /sdcard/*******/script /system/etc/init.d/script
busybox chmod +x /etc/init.d/script
update-rc.d script 99
The "update-rc.d script 99" line is where I run into trouble, it fails with an "update-rc.d not found" error.
Does anyone know what the proper command would be to make this work in Android??
i am not sure if it is different.... but I have always used a script that I made by naming it a number between 1 and 99 depending on when you want it to be read in the boot up. Like my favorite "86supersettings" and placing it it /system/etc/init. d and chmod to 750.
does this help?
Sent from my HTC Vision using XDA Premium App
Thank you so much... thats EXACTLY what I needed!
I was wondering how to use the init.d folder to run scripts during boot.
I have
# enable init.d support
service run_parts /system/xbin/run-parts /system/etc/init.d
oneshot
In my init.rc file but I do not have the init.d folder in /system/ect/
I have been trying to figure this out for about three days now. It might not even be possible but im sure someone knows better than me. Any help would be greatly appreciated!
Sent from my SCH-I500 using Tapatalk
You have to create the folder /init.d in /system/etc/init.d if it is not present.
Then, in updater-script you have to set the correct permissions to the init.d folder,
Updater script:
Code:
set_perm_recursive(0, 2000, 0755, 0750, "/system/etc/init.d");
set_perm(0, 0, 0755, "/system/etc/init.d");
e334 said:
You have to create the folder /init.d in /system/etc/init.d if it is not present.
Then, in updater-script you have to set the correct permissions to the init.d folder,
Updater script:
Code:
set_perm_recursive(0, 2000, 0755, 0750, "/system/etc/init.d");
set_perm(0, 0, 0755, "/system/etc/init.d");
Click to expand...
Click to collapse
How do I use the updater script and will any script I put into init.d be run at boot or do the scripts have to be named a certain way?
Sent from my SCH-I500 using Tapatalk
Since you are using the busybox run-parts method in init.rc, you have to add the files 00banner 99complete (pull from another working rom). Any other script you add has to start with a number greater than 00 and smaller than 99. For example: 04modules
The scripts execute from the smallest number to the greatest.
You can find the updater-script in the unzipped rom you are modifying, under the directory META-INF/com/google/android/
Do u know of any roms that have the other two files I can grab and ounce I do will I need to modify them any?
Sent from my SCH-I500 using Tapatalk
Most roms, such as cyanogenmod 6 series, should have them.
Thank you very much! I will give it a try
Sent from my SCH-I500 using Tapatalk
Thanks e334 that worked perfectly! You don't know how much I appreciate the help. Thanks again.
Sent from my SCH-I500 using Tapatalk
csanmba said:
How do I use the updater script and will any script I put into init.d be run at boot or do the scripts have to be named a certain way?
Sent from my SCH-I500 using Tapatalk
Click to expand...
Click to collapse
For init.rc
# Execute files in /etc/init.d before booting
service userinit /system/xbin/busybox run-parts /system/etc/init.d
oneshot
class late_start
user root
group root
I was trying to uninstall some carrier apps through ADB on Windows, via CMD. I wasnt unable to do so, and investigating about my problem, I found that I can uninstall through Titanium Backup . Now I dont have anymore the vodafone apps and trial games that came with my Samsung Galaxy I5510!.
But for what I am writing this, is that for unknown reasons to my, when trying to uninstall through ADB, I always have the problem of READ ONLY FILE SYSTEM. I tried to remount through this command:
mount -o rw,remount /dev/block/stl9 /system
that I found here: http://forum.xda-developers.com/showthread.php?t=872128 , at the ADB Workshop, at deleting files.
this command:
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3
# chmod 777 /system
from here: http://www.pocketmagic.net/?p=757
I was forgetting other thing, the first time I used ADB was guiding myself with this guide: http://www.thedroiddemos.com/2010/0...how-to-remove-carrier-bloatware-from-android/
Maybe in the future I need to use ADB again, so thats why I am writing this, even though my problem with the carrier apps is solved.
And I have the stock Android 2.2 Froyo rooted with SuperOne Click.
And (again), I dont know where to place this post, my smartphone doesnt have a subforum, and I also ask for the admins to add the subsection
Thanks in advance!
Well, this is interesting, 26 views, and noone answered.
.
Thread moved to Q&A due to it being a question. Would advise you to read forum rules and post in correct section.
Failure to comply with forum rules will result in an infraction and/or ban depending on severity of rule break.
No one answered because your post is not written very clear and slightly confusing.
To make your /system writeable execute this command as superuser:
mount -o rw,remount /system /system
Click to expand...
Click to collapse
try root explorer it gives r/w and r/o permissions !
I already figured it out how to remove those annoying apps. I used Titanium Backup, I didnt knew it had the ability to remove system apps
Hi guys this is a small intro to updater script by a newbie for a newbie to understand more and more what it has and what it means:highfive::highfive::highfive:
now what is the updater-script and update-binary present in the META-INF>com>google>android in any flashable zip package
1. updater-script - it is just a text file which contains all the commands which tells the clockworkmod what to do with the given
zip file. the updater-script is written in the edify scripting language.
2. update-binary - it is a binary which is requiered by the clockworkmod to translate the human readable format of the updater-
script to machine readable format for execution of the updater-script in our device.
exploring the updater-script:
now let's start exploring the updater-script !
1. open the updater script with notepad++ (strongly recommended)
2. now i will try and explain commands generally used in the updater-script,
assert(getprop("ro.product.device") == "ST15i" || getprop("ro.build.product") == "ST15i" ||
getprop("ro.product.device") == "ST15a" || getprop("ro.build.product") == "ST15a" ||
getprop("ro.product.device") == "smultron" || getprop("ro.build.product") == "smultron");
the above bunch of lines checks the device model to confirm that the zip file is flashed on the device
for which it is specifically created for. These bunch of lines are very important because it prevents
flashing of zip file which is not intended for the device hence avoiding any problems due to flashing
the wrong zip. for example the above lines checks for the value of "ro.product.device" and
"ro.build.product"in the build.prop file of the already existing rom in the device, if any of the three
defined values ST15i, ST15a, smultron are found it will continue with the next line of updater-script
otherwise flashing gets aborted with error in getprop.
format("yaffs2", "MTD", "system", "/system");
the above command explains itself, it is used to format the specified partition
syntax explanation:
format - the main command to direct the cwm to format using the following parameters
"yaffs2" - filesystem type used in the device
"MTD" - type of the partition used in the file system
"system" - location of the partition to be formatted
"/system" - name of the partition to be formatted
ui_print("Format Completed");
the above command is also self explanatory, it directs the cwm to display the following text
enclosed in double quotes in the user interface (display).
after succesful formatting it displays "Format Completed" in the device screen.
mount("yaffs2", "MTD", "system", "/system");
the mount command directs the cwm to mount the following file system and the following partition
the syntax is just as explained in the format command except that this command mounts the
defined partition whereas the format command formats the defined partition.
let's review what we have done till now,
1. we have checked the device to confirm that this is the device for which we created the zip.
2. we have formatted the system partition of the device.(this is only done when a new complete rom is being flashed, for flashing mods you
should never format the system partition!)
3. we have mounted the system partition of the device.
now let's continue,
package_extract_dir("system", "/system");
this command searches for the directory (folder) named "system" in the root of the zip file and
copies all the content of the "system" folder from the zip file into the "/system" partition
which is already mounted by the previous mount command.
remember the structure of the file system in the zip file and the "/system" partition of the device must be always identical.
for eg., you have created a mod by editing the systemUI.apk and you want to flash it, the system UI.apk resides in "/system/app"
so the structure of the file system in the update zip should be "/system/app/systemUI.apk"
ie., the update zip should contain folder named "system" at the root of it and folder named "app" inside the "system" folder and the
modded "systemUI.apk" must be placed inside the "app" folder.
package_extract_file("autoroot.sh", "/tmp/autoroot.sh");
this command searches for the file named "autoroot.sh" in the root of the zip file and
copies the file to "/tmp" folder and names it as "autoroot.sh" (here it does not change the name)
symlink("mksh", "/system/bin/sh");
the above command creates a symlink.
okay, now let's see about symlinks,
symlink is nothing but shortcuts, for example if a file is requiered in two different places instead of copy pasting the file
in two different locations, the file is copied to one of the two locations and in the other location a shortcut to the file(symlink)
is created. the source and the symlink can have different names (actually this is the prime use of symlinks).
to explain in a noob friendly manner,
take the above symlink, it creates a shortcut(symlink) for the command "mksh" and places it in the path of the operating system.
the shortcut(symlink) directs to the file "/system/bin/sh" , so whenever the os gets a request to execute the "mksh" command, the actual
binary that gets excuted will be "/system/bin/sh" .
creating symlinks saves a lot of space because instead of copying the whole file and placing it in requiered places we are just
creating shortcuts which directs to the source file which can be placed anywhere in the file system (generally placed in the path of the os).
set_perm_recursive(0, 0, 0755, 0644, "/system");
the above command is used to set permission recursively for the files and folders present inside a folder (in this case for "/system" folder).
syntax explanation:
0 - uid - it defines that the following permission is set for the user id 0 .
0 - gid - it defines that the following permission is set for the group id 0 .
0775 - dirmode - it defines that 0775 permission to set to directories contained within the specified directory.
0644 - filemode - it defines that 0644 permission to set to files contained within the specified directory.
"/system" - target directory to set the above mentioned permissions.
set_perm(0, 3003, 06755, "/system/bin/ip");
the above command is used to set permission for a individual file (in this case for "/system/bin/ip" file).
syntax explanation:
0 - uid - it defines that the following permission is set for the user id 0 .
3003 - gid - it defines that the following permission is set for the group id 3003 .
06775 - it defines that 06775 permission to set to the specific file.
"/system/bin/ip" - target file to set the above mentioned permissions.
run_program("/tmp/autoroot.sh");
remember the file autoroot.sh from package_extract_file command?
that file is supposed to be a shell script, the above command directs cwm to execute the "autoroot.sh" shell script present in "/tmp" folder.
unmount("/system");
the unmount command directs the cwm to unmount the following partition
the syntax is just as explained in the mount command except that this command unmounts the
defined partition whereas the mount command mounts the defined partition.
Okay now going into slightly complex and/or not widely used updater-script commands,
Ifelse
Syntax:
Ifelse(condition),(do_this),(else_do_this);
Example:
ifelse mount("yaffs2", "MTD", "system", "/system") == "system", ui_print("Mounted!"), ui_print("Mount Failed!");
Ifelse command can be explained simply as asking the system to do something based on the result of a condition.
From the example:
The ifelse command would attempt to mount the MTD partition named "system" to "/system".
If the mounting process succeeds (the condition), the script will display "Mounted!", else it will display "Mount Failed!"
abort()
It just abort's the script execution
Note: it is usually paired with some other command for example the getprop command or with ifelse.
Independently specifying abort() in the updater-script will kill the script abruptly right there so use this command carefully.
ALWAYS LEAVE A BLANK LINE AT THE END OF THE update-script (if the code contains 50 lines then 51 lines should be visible
in the notepad++ including a blank line after the end of the script)
ALWAYS REMEMBER TO SET THE EOL (end of line) CONVERSION OF updater-script
IN UNIX FORMAT BEFORE SAVING (notepad++ > edit > EOL conversion > UNIX format)
the above mentioned commands are just basic edify scripting commands which are generally used in updater-script.
for detailed scripting and coding in edify scripting language check out the following sources:
source of update-binary
introdution to edify
http://forum.xda-developers.com/wiki...cript_language
scratchpad-documenting-edify-commands-for-android-updater-scritps
http://forum.xda-developers.com/show....php?t=1290062
Broken Links!!!
source of update-binary
introdution to edify
http://forum.xda-developers.com/wiki...cript_language
scratchpad-documenting-edify-commands-for-android-updater-scritps
http://forum.xda-developers.com/show....php?t=1290062[/QUOTE]
broken links!!! :silly:
Dude cut the reply short
Sent from my Droid Bionic using xda app-developers app
Sorry brother! i mean these links are not working!!
Current Device : MT11i Xperia Neo V
ROM : Xperia Ultimate HD ™
Build Number : 2.0.3
Kernel : Suave Kernel
Root Status : Rooted
Bootloader : Unlocked
Previous Devices : Samsung Galaxy Y
GT-5360(Sold)
Sent from my MT11i using XDA Premium HD app
tharu_roxx said:
Sorry brother! i mean these links are not working!!
Sent from my MT11i using XDA Premium HD app
Click to expand...
Click to collapse
Dont quote large posts on a whole...be specific...if u dont be specific..it may annoy others and even may affect the beauty of XDA... Next time do take a note of this....
Now please modify ur post..and keep only those links that u were referring to...
-via my "Galaxy Royale"
First i noticed it dude! When um gonna edit it, xda doesn't allowed me(as i was a new member) now it's ok....thanx!!!
Current Device : MT11i Xperia Neo V
ROM : Xperia Ultimate HD ™
Build Number : 2.0.3
Kernel : Suave Kernel
Root Status : Rooted
Bootloader : Unlocked
Previous Devices : Samsung Galaxy Y
GT-5360(Sold)
Sent from my MT11i using XDA Premium HD app
kartiknnn said:
Dude cut the reply short
Sent from my Droid Bionic using xda app-developers app
Click to expand...
Click to collapse
Thanks kartik for the thread...
Learnt some new stuff...thank you...
I would suggest u to add some ready made zips with standard updater scripts... So that people can use them for faster modding...
What say?
Sent from my GT-I9103 using xda app-developers app
bhargav143 said:
Thanks kartik for the thread...
Learnt some new stuff...thank you...
I would suggest u to add some ready made zips with standard updater scripts... So that people can use them for faster modding...
What say?
Sent from my GT-I9103 using xda app-developers app
Click to expand...
Click to collapse
Try these threads
http://forum.xda-developers.com/showthread.php?t=1561463
http://forum.xda-developers.com/showthread.php?t=732957
Hit thanks if i helped!!
Current Device : MT11i Xperia Neo V
ROM : Xperia Ultimate HD ™
Build Number : 2.0.3
Kernel : Suave Kernel
Root Status : Rooted
Bootloader : Unlocked
Previous Devices : Samsung Galaxy Y
GT-5360(Sold)
Sent from my MT11i using XDA Premium HD app
Lemme see guys will try and upload them today
Sent from my GT-I9103 using xda premium
kartiknnn said:
Dude cut the reply short
Sent from my Droid Bionic using xda app-developers app
Click to expand...
Click to collapse
dont you have your exams buddy..
Sent from my GT-I9103 using xda premium
Yup formative 2 be exact
Sent from my GT-I9103 using xda premium
Where to get the update-binary file from???
prohank said:
Where to get the update-binary file from???
Click to expand...
Click to collapse
Read the second paragraph.
Sent from my CM10.1-powered GT-I9103
2. update-binary - it is a binary which is requiered by the clockworkmod to translate the human readable format of the updater-
script to machine readable format for execution of the updater-script in our device.
Click to expand...
Click to collapse
you mean this one?
It says what it is but where to get it from?
prohank said:
you mean this one?
It says what it is but where to get it from?
Click to expand...
Click to collapse
its in any CWM zip of Galaxy R. check in Meta-info/...../Android
prohank said:
you mean this one?
It says what it is but where to get it from?
Click to expand...
Click to collapse
This:
now what is the updater-script and update-binary present in the META-INF>com>google>android in any flashable zip package
Click to expand...
Click to collapse
Sent from my CM10.1-powered GT-I9103
I'm sorry if this has been asked already but I can't find it anywhere:
I have two su.d scripts that I always was putting in /system/su.d after every rom update. But ever since I switched to SuperSU 2.76 Systemless those scripts don't work. I do use an app from Chainfire called LiveBoot that uses su.d and I noticed ever since I switched to systemless root that su.d is no longer in /system/su.d: it's in /su/su.d.
Here's my edify script for one of the flashable zips:
Code:
ui_print(" Flashing Balanced Kernel Settings ");
ui_print(" ");
show_progress(0.99, 30);
run_program("/sbin/busybox", "mount", "/su");
package_extract_dir("su", "/su");
set_perm(0, 0, 0700, "/su/su.d/ZZZ-Elite-Kernel-Settings");
show_progress(1.0, 1);
unmount("/su");
ui_print("----------------------------------------------");
ui_print("| Done!!! |");
ui_print("----------------------------------------------");
ui_print(" ");
What I've noticed is that after I flash both zips and go to the file manager in TWRP that the files are there in /su/su.d. But after it's done booting and I go look in that folder with a file explorer, they're gone. Any idea why these disappear? It seems I have to flash these on every boot. That's obviously ridiculous. I must be doing something wrong and I figure that it's related to my ignorance about systemless SuperSU.
A permissions thing maybe, this happens with me if I transfer files in TWRP then booting the device. I can`t find them in any file explorer.
It's late though, but for the guidance of other noobs like me. /su/su.d/ can't be flashed in recovery because this isn't available. For system-less roots, binaries/libraries required to start supersu daemon and to manage root permissions, don't reside in /system/bin but in /data/su.img while (at least) two files reside in boot.img i.e. boot.img/ramdisk/init.supersu.rc and boot.img/ramdisk/sbin/.*daemonsu*.sh. When ROM boots, init.supersu.rc mounts /data/su.img on /su directory and calls /sbin/*daemonsu*.sh for initial setup which starts /su/bin/daemonsu and other se-linux related stuff and then executes any scripts found in /su/su.d/ and /system/su.d.
You can find this:
Code:
mido:/ # mount | grep loop
/dev/block/loop0 on /su type ext4 (rw,seclabel,noatime,data=ordered)
So, the init.d scripts placed in /su/su.d actually reside in /data/su.img which isn't mounted in recovery mode and anything flashed to /su/su.d goes to volatile rootfs which is gone on reboot. Either mount su.img in recovery, or place this script while ROM is running or instead flash to /system/su.d which is permanent filesystem unlike rootfs (which lives in RAM). And finally don't forget to set permissions to 0700 as advised here. Another thing, mostly init.d scripts don't work with .sh extension. Avoid this too.