Related
Update: One click root has been using this "simple" method since version 2.2.7. If you're rooting your phone for the first time, please try that first. Consider this thread to be purely informational for those who want step-by-step details of how the process works.
I've been suspicious of the joeykrim root method since it was first posted at SDX. I finally got my Epic yesterday and confirmed that is, indeed unnecessary. I don't fault joeykrim though, he ported the working root method from the Moment to the Epic without actually having access to an Epic himself.
Anyways, the joeykrim root method is unnecessarilly complex becuase it works around an RFS permissions bug which loses the setuid bit on the Moment. It appears the Galaxy S phones have this bug fixed, which is why the root methods on the I9000, Vibrant, Captivate, Fascinate, etc., are much simpler.
So, for the simple root:
First, make sure joeykrim root is not installed.
Upgrade to DI18 (not strictly necessary, but you'll want to do it).
Setup a working adb from the Android SDK and whatever drivers are necessary for your platform.
Download rageagainstthecage-arm5.bin from the C skills blog (link removed due to my newbieness) or from any of the one-click root packages.
Download su-2.3.6.1-ef-signed.zip and extract "system/bin/su" and "system/app/Superuser.apk" to a temporary directory you'll be working from.
Enable USB debugging on your phone and connect it to your computer.
Now, open a command prompt/shell on your computer and cd to the appropriate temporary directory. Run:
Code:
adb push rageagainstthecage-arm5.bin /data/local/tmp
adb shell chmod 755 /data/local/tmp/rageagainstthecage-arm5.bin
adb shell /data/local/tmp/rageagainstthecage-arm5.bin
and confirm you have a working root shell. Then continue with:
Code:
adb push su /system/xbin
adb shell chmod 4755 /system/xbin/su
adb install Superuser.apk
That's it! You should have a working root via su & the Superuser package. At least, I did.
Note that the preceeding steps installs Superuser.apk to /data, which is what I prefer to do. This means if you do a "Factory data reset" su will be temporarilly broken until you reinstall the Superuser.apk package. Since installing the package itself doesn't require root, this is easily done after a /data reset.
Also note that I did not perform a /system remount-rw anywhere. At least on my Epic, /system appears to always be mounted read-write so it's an unnecessary step. It's actually the "joeykrim-root.sh" script that remounts /system read-only during the boot process, which is why folks who don't use root kernels have run into this problem before. I'm not sure why joeykrim's script does that, I guess he probably assumed /system is mounted read-only by default. There's arguments that /system should be read-only, but I didn't touch it in case some Samsung stuff depends on it being read-write.
Finally, if you're already rooted via joeykrim or are running a root kernel, there's nothing really to be gained by doing this. I'm just throwing this out there as I perfer to make the minimum invasive changes possible to obtain root.
Wow, that was really informative. To check for Super user you:
Type: adb shell
then type: SU
You should get a # sign if you have root. Correct?
In the original Noobln post method would the Epic keep root even after a wipe therefore not needing to re-apply the superuser apk again? That might be a reason why folks would want to go the more invasive route (considering rooters seems to change ROMS fairly often which requires wipes sometimes). Either way, keeping a copy of the apk file on your SD card is no big deal.
mkasick said:
Also note that I did not perform a /system remount-rw anywhere. At least on my Epic, /system appears to always be mounted read-write so it's an unnecessary step. It's actually the "joeykrim-root.sh" script that remounts /system read-only during the boot process, which is why folks who don't use root kernels have run into this problem before. I'm not sure why joeykrim's script does that, I guess he probably assumed /system is mounted read-only by default. There's arguments that /system should be read-only, but I didn't touch it in case some Samsung stuff depends on it being read-write.
Click to expand...
Click to collapse
This explains a lot of problems! thanks
EDIT- another noob question- why do you prefer to have superuser installed to /system/data- why not put it in /system/app? Also if I want to install busybox where is the best location to put it?
ZenInsight said:
Wow, that was really informative. To check for Super user you:
Type: adb shell
then type: SU
You should get a # sign if you have root. Correct?
Click to expand...
Click to collapse
Once you run rageagainstthecage-arm5.bin, you should get a root-shell automatically every time you run "adb shell" after until you reboot the phone. Yes, you can tell it's a root shell since it uses the "#" prompt. This is the important part to check, since if the exploit doesn't work, you'll have to run it again. But I haven't seen it not work.
After su is installed and you reboot, your steps are correct: run "adb shell", run "su", then you'll be prompted on the phone scren to authorize access and once you allow it you'll end up with a "#" prompt.
ZenInsight said:
In the original Noobln post method would the Epic keep root even after a wipe therefore not needing to re-apply the superuser apk again?
Click to expand...
Click to collapse
noobnl installs Superuser.apk to /system, you can do that here too. Just replace the "adb install Superuser.apk" step with "adb push Superuser.apk /system/app". It's independent of the joeykrim scripts.
With my captivate we have many update.zip root methods to choose from. Any chance this will be coming to the epic? Have a friend with an epic and command lines would be too much and one click didn't work.
Sent from my SAMSUNG-SGH-I897 using XDA App
jimmyz said:
why do you prefer to have superuser installed to /system/data- why not put it in /system/app?
Click to expand...
Click to collapse
I prefer to keep consistent with the idea that user-installed applications go in /data, and stock-installed-and-unmodified applications remain in /system/app. This way, upgrading Superuser.apk doesn't require a root-shell/root-explorer, you can remove it or upgrade it the way you do with any user installed application--adb install, side-loading via an sdcard, or downloading it from the market.
Plus, in general I prefer to keep my /system as untouched as possible. For example, I don't remove stock apps either. The "su" binary has to be installed in /system to persist after a /data wipe, and busybox is best installed to /system so it's in PATH (haven't looked into modifying the default PATH yet). Otherwise I try to keep /system alone.
jimmyz said:
Also if I want to install busybox where is the best location to put it?
Click to expand...
Click to collapse
Android's default PATH provides four places for busybox to be installed: /sbin, /system/bin, /system/sbin, and /system/xbin. /sbin is part of the initramfs, in other words it's controlled by the kernel you're running. You can install busybox to any of the three /system/*bin directories, but I prefer /system/xbin.
In the traditional Unix conventions, "/usr/bin" is for user-runnable stock-installed programs, and "/usr/sbin" is for root-requiring (superuser-runnable) stock-installed programs. "xbin" isn't part of the standard convention, but I'd guess it's intended for "extra binaries" that are not part of the stock installation (much like /usr/local/bin), thus it seems like an appropriate location for a user-added "su" and "busybox" programs.
The second reason is that "xbin" is relatively empty, so if you want to create the applet symlinks (i.e., so that you can call "cp" instead of "buybox cp") it won't overwrite the stock toolbox symlinks. Also, since "xbin" is last on the default PATH, any programs provided by both toolbox and busybox will default to the toolbox version--which would be important for stock system scripts that might run into compatibility issues if they were to use the busybox versions instead.
To install busybox, grab a copy of the binary from somewhere (one click packages, a copy of stericson.busybox.apk, etc.). Then, once rooted run:
Code:
adb push busybox /data/local/tmp
adb shell
su # Authorize on phone screen
cat /data/local/tmp/busybox > /system/xbin/busybox
chown root.shell /system/xbin/busybox
chmod 755 /system/xbin/busybox
rm /data/local/tmp/busybox
/system/xbin/busybox --install -s /system/xbin
jhnstn00 said:
With my captivate we have many update.zip root methods to choose from. Any chance this will be coming to the epic?
Click to expand...
Click to collapse
I don't believe so. The I9000/Vibrant/Captivate have recoveries that don't check the signature of update.zip (as I understand, or maybe they do but only require test keys) which makes rooting-via-recovery possible. Unfortuntaely the Epic and Fascinate do perform signature checks, so we can't enable root via stock-recovery.
That said, the Fascinate one-click methods should also work on the Epic. Although depending on why your friend couldn't get the Epic one-click to work, the Fascinate one may not work either.
mkasick said:
I prefer to keep consistent with the idea that user-installed applications go in /data, and stock-installed-and-unmodified applications remain in /system/app. This way, upgrading Superuser.apk doesn't require a root-shell/root-explorer, you can remove it or upgrade it the way you do with any user installed application--adb install, side-loading via an sdcard, or downloading it from the market.
Plus, in general I prefer to keep my /system as untouched as possible. For example, I don't remove stock apps either. The "su" binary has to be installed in /system to persist after a /data wipe, and busybox is best installed to /system so it's in PATH (haven't looked into modifying the default PATH yet). Otherwise I try to keep /system alone.
Android's default PATH provides four places for busybox to be installed: /sbin, /system/bin, /system/sbin, and /system/xbin. /sbin is part of the initramfs, in other words it's controlled by the kernel you're running. You can install busybox to any of the three /system/*bin directories, but I prefer /system/xbin.
In the traditional Unix conventions, "/usr/bin" is for user-runnable stock-installed programs, and "/usr/sbin" is for root-requiring (superuser-runnable) stock-installed programs. "xbin" isn't part of the standard convention, but I'd guess it's intended for "extra binaries" that are not part of the stock installation (much like /usr/local/bin), thus it seems like an appropriate location for a user-added "su" and "busybox" programs.
The second reason is that "xbin" is relatively empty, so if you want to create the applet symlinks (i.e., so that you can call "cp" instead of "buybox cp") it won't overwrite the stock toolbox symlinks. Also, since "xbin" is last on the default PATH, any programs provided by both toolbox and busybox will default to the toolbox version--which would be important for stock system scripts that might run into compatibility issues if they were to use the busybox versions instead.
To install busybox, grab a copy of the binary from somewhere (one click packages, a copy of stericson.busybox.apk, etc.). Then, once rooted run:
Code:
adb push busybox /data/local/tmp
adb shell
su # Authorize on phone screen
cat /data/local/tmp/busybox > /system/xbin/busybox
chown root.shell /system/xbin/busybox
chmod 755 /system/xbin/busybox
rm /data/local/tmp/busybox
/system/xbin/busybox --install -s /system/xbin
Click to expand...
Click to collapse
You sir are a true gentleman! Thank you for the informative answers- its great to have you over here! I have one more question- why can't I usually push directly to /system ?
jimmyz said:
why can't I usually push directly to /system ?
Click to expand...
Click to collapse
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
mkasick said:
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
Click to expand...
Click to collapse
I am learning a lot!!! Could you take a look at koush's kernel here, with it I noticed that when using adb I got the # prompt right away and was able to push to /system- maybe he was able to figure out the config settings? Once again thanks!!!
one more ? (feel free to ignore this one) what actually happens when you do
Code:
adb shell /data/local/tmp/rageagainstthecage-arm5.bin
and how does that give you permanent root?
mkasick said:
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
Click to expand...
Click to collapse
It is indeed a config option in default.prop. However, this is in the initramfs and you can't change it on the fly, so you need to rebuild the kernel to change it. With some work you can modify the stock kernel to do it, but I personally haven't tried it.
Sent from my Epic 4G using XDA App
Thank you, this worked perfectly for me, running stock DI18 ROM that I flashed tonight!!! I confirmed by installing the wireless tethering pre-9 apk, and successfully ran the wireless tethering without any errors.
Quick question: do we need to do this after root or is it not needed?
NEEDED?? ===> SuperUser App to help with Security Concerns for the Epic - h**p://forum.sdx-developers.com/epic-development/superuser-app-to-help-with-security-concerns/
Also, Titanium Backup failed to work - it gave an error of denied root access, and said busybox was not installed. What needs to be done to make it work? Do I need to install clockwork mod (not exactly sure what it does though) or a custom ROM?
AndroidSPCS said:
Quick question: do we need to do this after root or is it not needed?
Click to expand...
Click to collapse
Not sure exactly what you're asking. This is an alternative to the joeykrim-based one-click roots and rooted kernels. If you already have one of those this isn't really necessary.
AndroidSPCS said:
NEEDED?? ===> SuperUser App
Click to expand...
Click to collapse
Yes, the su binary used here requires the Supruser appto be installed to authorize su requests. Otherwise they'll always be denied. Other su binaries might not require it, but then all apps have root access which isn't really a good thing.
AndroidSPCS said:
Also, Titanium Backup failed to work - it gave an error of denied root access, and said busybox was not installed. What needs to be done to make it work?
Click to expand...
Click to collapse
Did you authorize Titanium Backup when the Superuser prompt came up (requies the Superuser app to be instald too)?
Titanium Backup has an option to download and install it's preferred version of busybox. Follow the prompts to do that.
mkasick said:
Not sure exactly what you're asking. This is an alternative to the joeykrim-based one-click roots and rooted kernels. If you already have one of those this isn't really necessary.
Click to expand...
Click to collapse
Thanks, actually this was referring to the thread where the instructions for going to adb shell or terminal and typing in the following commands:
adb shell
su
mount -t rfs -o remount,rw /dev/block/stl9 /system
cp /system/bin/su /system/bin/jk-su
exit
Yes, the su binary used here requires the Supruser appto be installed to authorize su requests. Otherwise they'll always be denied. Other su binaries might not require it, but then all apps have root access which isn't really a good thing.
Click to expand...
Click to collapse
Yes same as above, the question is not whether we need SU app (I know we do), but whether we needed to type the additional commands:
adb shell
su
mount -t rfs -o remount,rw /dev/block/stl9 /system
cp /system/bin/su /system/bin/jk-su
exit
What do these commands do? It seems to me my Superuser app is working fine with wifi tether - popping up with allow / disable permission boxes, etc. Do these commands add something else to Superuser?
Did you authorize Titanium Backup when the Superuser prompt came up (requies the Superuser app to be instald too)?
Titanium Backup has an option to download and install it's preferred version of busybox. Follow the prompts to do that.
Click to expand...
Click to collapse
There was no Superuser prompt during the install of the app, nor anytime when it said it had a failure with root access. However there is an option to install BusyBox, which I have not done yet, because I am not sure what busybox is, or what it does. I'd like to find out why I need it and what it does, so I can feel comfortable with installing it.
Thanks again.
echo "root::0:0:root:/data/local:/system/bin/sh" > /etc/passwd
echo "root::0:" > /etc/group
you need to do that in a shell to make sure su works properly.
I'm updating the one click root right now to be less silly.
http://forum.xda-developers.com/showpost.php?p=8543226&postcount=455
I just cleaned up the one click root to not do many of the silly things joeykrim's root does. It also means your system will be mounted as rw after a reboot and it won't overwrite your su with jk-su every boot (no more modified playlogo).
Cleaned up all the old stuff from the root so it should work fine even if you were using one of the older one clicks. I made sure su works, incl titanium backup.
I'm still installing superuser.apk to /system/app because I think it belongs there.
Thanks for doing the footwork, mkasick!
Firon said:
http://forum.xda-developers.com/showpost.php?p=8543226&postcount=455
I just cleaned up the one click root to not do many of the silly things joeykrim's root does. It also means your system will be mounted as rw after a reboot and it won't overwrite your su with jk-su every boot (no more modified playlogo).
Cleaned up all the old stuff from the root so it should work fine even if you were using one of the older one clicks. I made sure su works, incl titanium backup.
I'm still installing superuser.apk to /system/app because I think it belongs there.
Thanks for doing the footwork, mkasick!
Click to expand...
Click to collapse
Firon- why are these lines still needed?
Code:
adb push playlogo /system/bin/playlogo
what is playlogo? Does this just put the stock one back in case you used the joeykrim method in the past?
Code:
adb push remount /system/xbin/remount
Are the remount scripts still needed?
Code:
adb shell ln -s /system/xbin/su /system/bin/su
why is this link needed? why cant su just be in xbin
thanks in advance!
Code:
jimmyz said:
Firon- why are these lines still needed?
Code:
adb push playlogo /system/bin/playlogo
what is playlogo? Does this just put the stock one back in case you used the joeykrim method in the past?
Click to expand...
Click to collapse
This is just pushing the stock playlogo, since joeykrim's method overwrites it with some custom script.
Code:
adb push remount /system/xbin/remount
Are the remount scripts still needed?
Click to expand...
Click to collapse
The script allows you to easily remount system as ro or rw at will. Why not?
Code:
adb shell ln -s /system/xbin/su /system/bin/su
why is this link needed? why cant su just be in xbin
Click to expand...
Click to collapse
I don't know if any apps depend on it being in a particular location. It is in xbin, but I'm also linking it to /system/bin to be safe.
AndroidSPCS said:
What do these commands do? It seems to me my Superuser app is working fine with wifi tether - popping up with allow / disable permission boxes, etc. Do these commands add something else to Superuser?
Click to expand...
Click to collapse
These commands were necessary to get Superuser working with the old joeykrim root method. They're not necessary with this method (or the newly released one-click). In other words, if wifi-tethering is already working for you, nothing further is needed to be done.
AndroidSPCS said:
There was no Superuser prompt during the install of the app, nor anytime when it said it had a failure with root access.
Click to expand...
Click to collapse
I don't actually use TitaniumBackup. I'm not sure why its superuser-requirements would be different from other apps, but I guess it is. The new one-click appears to address this.
AndroidSPCS said:
However there is an option to install BusyBox, which I have not done yet, because I am not sure what busybox is, or what it does. I'd like to find out why I need it and what it does, so I can feel comfortable with installing it.
Click to expand...
Click to collapse
Busybox is a suite of "familar" Unix command-line utilites (things like cp (copy), mv (move), ls (list), etc.). It targets embedded platforms by being very featureful, yet relatively small. It's installed and used on a wide variety of embedded devices including wireless routers, print servers, phones, even televisions.
Oddly enough, Android does not include busybox by default. Instead it comes with it's own utility-programs-package called "toolbox" that isn't nearly as featureful, and quickly becomes a pain to use. Some programs, like TitaniumBackup depend on busybox programs/features, and thus require it's installation. It's safe.
The only problem with busybox is that there's not one single version of it. There's multiple builds of it from the same source code with different sets of features turned on and off. In the past, some folks had a version of busybox installed that didn't contain all the features necessary to support TitaniumBackup, so they added the option to install their own version. It's installed in a separate location, so it won't overwrite any version you do have installed, and it's safe to do. But if you've already installed another version of busybox that does work, then it may be unnecessary.
I did the Jokeyrim method a few days ago. I installed a new kernal and now a new ROM. All seems ok, but ow when I do the "whoami" command in adb shell I get whoami not found. I don't think I'm really rooted anymore. Any attempt to reinstall the Jokeyrim root script results in failure (mostly "device not found" errors). When in adb shell, most commands I type now are either "not found" or "permission denied", so I'm not confident that I'm really rooted now.
Since I have / had Jokeyrim installed, how can I "uninstall" it so that I can use this method of rooting instead? BTW, the newest Clockworkmod is installed and working.
Do I need to flash to stock first? Sorry, but I'm a VERY STOOPID NOOB.
On my newly compiled Android 2.2.2 build, whenever i type "su" in the terminal it says:
link_image[2033]: failed to link su
CANNOT LINK EXECUTABLE
I tried everything possible, I have busybox working, but not su. I have the su binary in the /bin folder and correctly symlinked to the /xbin folder and the permissions correctly applied in the update-script but it still will not execute. Any solutions?
Anyone.. (bumped because of massive amount of threads created each day in this section..)
Having recently bought an ePad V2, it was my first introduction to Android. Therefore having rooted, upgraded firmware, etc I've hit the same issue in trying to get Root Explorer working.
I've found a potential fix at h**p://zenpad.doubtechdotcom/?p=50 but haven't had chance to give it a go yet. You'll have to fill in the gaps of the URL as this is my first post and won't let me give external links.
Ignore my last post as I sorted my problem (originally being unable to mount R/W in RootExplorer). Here's what I did:
1. Uninstalled RootExplorer and Superuser.
2. Unrooted using Universal AndRoot.
3. Rooted NOT installing SuperUser.
4. Installed Busybox Installer from Market (noob fail as I never installed it before!).
5. Installed Busybox.
6. Installed latest version of RootExplorer.
Now I can mount R/W in RootExplorer and therefore I'm guessing my SU problem has gone away.
** NOT Android 4.3 compatible!!! Term-init is recommended for now!!!
**Note...this is only for those who do not have init.d support...if you are using custom kernels (cyanogen mod original kernel etc.) that already supports init.d, you shouldn't run this......but if you accidentally ran this, it is ok...won't mess up anything...
{
"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"
}
v1.0
init.d support through an app!!!
What is init.d:
the_scotsman (Moderator Liaison Admin / Moderator Committee / XDA News Writer) said:
Init.d plays an important role in the world of Android development and customization It allows users to install scripts and mods to be run at boot—everything from battery tweaks to performance tweaks. It essentially opens the door to a world of mods only possible through the Init.d process, which in turn is usually only available on custom kernels.
Click to expand...
Click to collapse
But how?
Concept:
I have recently learnt some linux scripting and was searching for a method to enable init.d scripts support for my phone which has a stock kernel. Inspired by this thread by iridaki, I finally managed to get init.d working in my phone!!! However, I thought of the other users who still do not have a proper custom recovery...how are they gonna flash zip packages? And if it has to be done manually, it requires a lot of typing, changing file permissions etc....a very tedious process...
Therefore, I've decided to come up with a script to automate this process!!! *Drum rolls*...lol
BUT now, with the aid of Androguide.fr (creator of Pimp My ROM), we managed to integrate the script into an app to save the hassle of typing commands in terminal emulator! With just a button click, the commands will be carried out! With just a button click, the app will verify whether is there init.d support or not!
Do I have init.d support?:
Well, here is a way to test:
1. Download the file from here: View attachment 1612958
2. Extract the file, you will get a file named 00test. DO NOT flash!
3. Paste it into /etc/init.d. If there is no init.d folder, most probably you DO NOT have init.d support. However, if you still wanna try, just create the folder named "init.d"
4. Change the permissions of the init.d folder and 00test into rwxrwxrwx.
5. Reboot.
6. If you see a file named Test.log in /data, you have init.d support. If not, you will have to run Uni-init, Term-init or Zip-init.
Features:
- Utilises install-recovery.sh (if your kernel supports that, but of course, but most do...) to enable init.d scripts (busybox run-parts required)
- Will add lines in install-recovery.sh if it already exists (will not replace install-recovery.sh because certain apps such as Link2SD requires that to work), creates it if it doesn't
- Creates the init.d folder with correct permissions
- Adds 2 init.d scripts: one for testing (shows time of execution), another to ensure that the scripts in init.d folder always have the correct permissions
- Adds sysinit in /system/bin, will add the required lines if it already exists
- Deletes duplicate files and lines to ensure the least of errors
Requirements:
- a rooted phone of course...
- busybox with required applets (especially run-parts), if not sure what is this, just install this by Stericson: Link and please reboot after installing before running this script......use "normal install" method, don't use "smart install"...
Instructions:
1. Download the apk.
2. Install the apk like any normal app.
3. Launch the app.
4. The rest are pretty self-explanatory...
5. You can uninstall the app after that...
Screenshots:
**To check whether init.d is really working or not, reboot your phone and navigate to /data...you should find a Test.log in there...If it is present, congrats, you have a WORKING init.d support!
Download:
If you have already read all the instructions and understand them, then click here to download:
Uni-init v1.0.apk
Credits:
Thanks to:
Androguide.fr for the android app base!
Donators (big thank you! ):
@bigknowz
Feel free to posts questions below...I will try my best to help......By the way, those who used the app and found that it works, please leave a post here, stating you phone model, android version and ROM...thanks! but don't just leave comnents saying 'it doesn't work' etc...give more details if possible...
Please don't mirror / modify my work, ask for permissions first...
**UPDATE: v3 is out now! Android 4.3 compatible!
**Term-init is also used in Droid Manager!!!**
**Featured in the XDA News Portal: Init.d Support for Any Rooted Phone (Thanks to the_scotsman!)
Hi guys...as stated in the title above, I have created a script to be ran in terminal emulator so that it will enable the support of init.d scripts!!!
**Note...this is only for those who do not have init.d support...if you are using custom kernels (cyanogen mod original kernel etc.) that already supports init.d, you shouldn't run this......but if you accidentally ran this, it is ok...won't mess up anything...
init.d support through terminal emulator!!!
What is init.d:
the_scotsman (Moderator Liaison Admin / Moderator Committee / XDA News Writer) said:
Init.d plays an important role in the world of Android development and customization It allows users to install scripts and mods to be run at boot—everything from battery tweaks to performance tweaks. It essentially opens the door to a world of mods only possible through the Init.d process, which in turn is usually only available on custom kernels.
Click to expand...
Click to collapse
But how?
Concept:
I have recently learnt some linux scripting and was searching for a method to enable init.d scripts support for my phone which has a stock kernel. Inspired by this thread by iridaki, I finally managed to get init.d working in my phone!!! However, I thought of the other users who still do not have a proper custom recovery...how are they gonna flash zip packages? And if it has to be done manually, it requires a lot of typing, changing file permissions etc....a very tedious process...
Therefore, I've decided to come up with a script to automate this process!!! *Drum rolls*...lol
Do I have init.d support?:
Well, here is a way to test:
1. Download the file from here: View attachment test_initd.zip
2. Extract the file, you will get a file named 00test. DO NOT flash!
3. Paste it into /etc/init.d. If there is no init.d folder, most probably you DO NOT have init.d support. However, if you still wanna try, just create the folder named "init.d"
4. Change the permissions of the init.d folder and 00test into rwxrwxrwx.
5. Reboot.
6. If you see a file named Test.log in /data, you have init.d support. If not, you will have to run Uni-init, Term-init or Zip-init.
Features:
- Auto checks for required files [v2]
- Utilises install-recovery.sh (if your kernel supports that, but of course, but most do...) to enable init.d scripts (busybox run-parts required)
- Will move install-recovery.sh to install-recovery-2.sh if it already exists and call it from the main install-recovery.sh (will not replace install-recovery.sh because certain apps such as Link2SD requires that to work), creates it if it doesn't [v3]
- If Superuser is using install-recovery.sh, will use install-recovery-2.sh instead [v3]
- Creates the init.d folder with correct permissions
- Adds 2 init.d scripts: one for testing (shows time of execution [v2]), another to ensure that the scripts in init.d folder always have the correct permissions
- Adds sysinit in /system/bin, will add the required lines if it already exists. This is for utilising a similar method to enabling init.d in AOSP ROMs
Requirements:
- a rooted phone of course...
- busybox with required applets (especially run-parts), if not sure what is this, just install this by Stericson: Link and please reboot after installing before running this script......use "normal install" method, don't use "smart install"...
- terminal emulator such as this: Link
Instructions:
1. Download the file.
2. Place it in the root of your sdcard directory.
3. Launch terminal emulator.
4. Type: su
5. Grant SuperUser access if prompted
6. Type: sh /sdcard/term-init.sh
7. The script will run and follow the instructions! As simple as that...
**To check whether init.d is working or not, reboot your phone and navigate to /data...you should find a Test.log in there...If it is present, congrats, you have init.d support!
Download:
If you have already read all the instructions and understand them, then click here to download:
term-init.sh v3
Feel free to posts questions below...I will try my best to help......By the way, those who used my script and found that it works, please leave a post here, stating you phone model, android version and ROM...thanks! but don't just leave comnents saying 'it doesn't work' etc...give more details and screenshots if possible...
Please don't mirror / modify my work, ask for permissions first...
Source code & changelog: https://github.com/Ryuinferno/Term-init
** NOT Android 4.3 compatible!!! Term-init is recommended for now!!!
**Note...this is only for those who do not have init.d support...if you are using custom kernels (cyanogen mod original kernel etc.) that already supports init.d, you shouldn't run this......but if you accidentally ran this, it is ok...won't mess up anything...
As Term-init does not work for certain people, I have came up with a CWM flashable zip:
init.d support through CWM!!!
What is init.d:
the_scotsman (Moderator Liaison Admin / Moderator Committee / XDA News Writer) said:
Init.d plays an important role in the world of Android development and customization It allows users to install scripts and mods to be run at boot—everything from battery tweaks to performance tweaks. It essentially opens the door to a world of mods only possible through the Init.d process, which in turn is usually only available on custom kernels.
Click to expand...
Click to collapse
Do I have init.d support?:
Well, here is a way to test:
1. Download the file from here: test_initd.zip
2. Extract the file, you will get a file named 00test. DO NOT flash!
3. Paste it into /etc/init.d. If there is no init.d folder, most probably you DO NOT have init.d support. However, if you still wanna try, just create the folder named "init.d"
4. Change the permissions of the init.d folder and 00test into rwxrwxrwx.
5. Reboot.
6. If you see a file named Test.log in /data, you have init.d support. If not, you will have to run Uni-init, Term-init or Zip-init.
Features:
- Utilises install-recovery.sh (if your kernel supports that, but of course, but most do...) to enable init.d scripts (busybox run-parts required)
- Will add lines in install-recovery.sh if it already exists (will not replace install-recovery.sh because certain apps such as Link2SD requires that to work), creates it if it doesn't
- Creates the init.d folder with correct permissions
- Adds 2 init.d scripts: one for testing, another to ensure that the scripts in init.d folder always have the correct permissions
- Adds sysinit in /system/bin, will add the required lines if it already exists
- Deletes duplicate files and lines to ensure the least of errors
Requirements:
- a rooted phone of course...
- busybox with required applets (especially run-parts), if not sure what is this, just install this by Stericson: Link and please reboot after installing before running this script......use "normal install" method, don't use "smart install"...
- a working CWM custom recovery
Instructions:
1. Download the file.
2. Flash zip-init.zip thorough CWM.
3. Reboot and you are done!
**If you get a status 0 error in CWM, please replace the update-binary in zip-init.zip with a working update-binary of your phone (just extract it from any CWM zip meant for your phone)...
**To check whether init.d is working or not, reboot your phone and navigate to /data...you should find a Test.log in there...If it is present, congrats, you have init.d support!
Download:
If you have already read all the instructions and understand them, then click here to download:
zip-init.zip v2
Feel free to posts questions below...I will try my best to help......By the way, those who used my mod and found that it works, please leave a post here, stating you phone model, android version and ROM...thanks! but don't just leave comnents saying 'it doesn't work' etc...give more details and screenshots if possible...
Please don't mirror / modify my work, ask for permissions first...
Troubleshooting
Troubleshooting:
**CWM might warn something about disable recovery flash when using this mod, it is just a false positive, please DO NOT select yes or else it won't work anymore**
If you have already applied the script but there is no /data/Test.log, please refer the steps below:
1. Check whether have you installed busybox properly, especially run-parts. REBOOT after installing, then only apply this script.
2. If you are using the busybox installer by Stericson, please use "normal installation method", NOT "smart installation method".
3. Check whether are these files present with the correct permissions (please change if the permissions are wrong):
- /system/bin/sysint (rwxr-xr-x) [owner: root (0), group: shell (2000)]
- /system/etc/init.d (rwxrwxrwx) [owner: root (0), group: root (0)]
- /system/etc/init.d/00test (rwxrwxrwx) [owner: root (0), group: root (0)]
-/system/etc/init.d/08setperm (rwxrwxrwx) [owner: root (0), group: root (0)]
- /system/etc/install-recovery.sh (rwxr-xr-x) [owner: root (0), group: root (0)]
- /system/etc/install-recovery-2.sh (rwxr-xr-x) [owner: root (0), group: root (0)] (may or may not be present)
4. Check whether you have run-parts installed. Go to /system/xbin, you should be able to find a fine named "run-parts"
5. Check whether you have these lines in /system/etc/install-recovery.sh (if not, please add them in manually (using Root Explorer or keep the EOL in Unix format...Google about it), remember to leave an EMPTY line at the end of the file)
Code:
# init.d support
busybox run-parts /system/etc/init.d/
6. If all the above are still not helping, please download this: run-parts.zip and extract it (DO NOT flash it). Place the file named "run-parts" in /system/xbin. Change permissions to rwxrwxrwx, owner to root (o) and group to shell (2000). Reboot and check /data again.
7. Still fails? Check your /init.rc for any lines containing "install-recovery"...if there are none, this method won't work...so use the Script Manager method.
8. Use this as a last resort: Download Script Manager from Play Store: Link. Then navigate to /etc/install-recovery.sh, select it and run as root and at boot (select the skull and gear icon).
9. If all the above are not working, and the "install-recovery" line is present, then please paste the contents of your /etc/install-recovery.sh and /etc/install-recovery-2.sh if present somewhere (like http://pastebin.com and after applying the mod of course) here for me to debug. Take a screenshot of the output after running Term-init and post here, along with your ROM version, android version and name of device.
ace 5830i stock rom
Ryuinferno said:
Hi guys...as stated in the title above, I have created a script to be ran in terminal emulator so that it will enable the support of init.d scripts!!!
Term-init --> init.d support through terminal emulator!!!
But how?
Concept:
I have recently learnt some linux scripting and was searching for a method to enable init.d scripts support for my phone which has a stock kernel. Inspired by this thread by iridaki, I finally managed to get init.d working in my phone!!! However, I thought of the other users who still do not have a proper custom recovery...how are they gonna flash zip packages? And if it has to be done manually, it requires a lot of typing, changing file permissions etc....a very tedious process...
Therefore, I've decided to come up with a script to automate this process!!! *Drum rolls*...lol
Features:
- Utilises install-recovery.sh to enable init.d scripts (busybox run-parts required)
- Will add lines in install-recovery.sh if it already exists (will not replace install-recovery.sh because certain apps such as Link2SD requires that to work), creates it if it doesn't
- Creates the init.d folder with correct permissions
- Adds 2 init.d scripts: one for testing, another to ensure that the scripts in init.d folder always have the correct permissions
- Adds sysint in /system/bin, will add the required lines if it already exists
- Deletes duplicate files and lines to ensure the least of errors
Requirements:
- busybox with required applets (especially run-parts), if not sure what is this, just install this by Stericson: BusyBox
- terminal emulator such as this
Instructions:
1. Download the file.
2. Place it in the root of your sdcard directory.
3. Launch terminal emulator.
4. Type: su
5. Grant SuperUser access if prompted
6. Type: sh /sdcard/term-init.sh
7. The script will run and follow the instructions! As simple as that...
Example:
**To check whether init.d is working or not, reboot your phone and navigate to /data...you should find a Test.log in there...If it is present, congrats, you have init.d support!
Download:
If you have already read all the instructions and understand them, then click here to download:
term-init.sh
Feel free to posts questions below...I will try my best to help...
Hit the thanks button if you liked my work...it gives me a boost!
Please don't mirror / modify my work, ask for permissions first...
Click to expand...
Click to collapse
its not working
ranjitkhera said:
its not working
Click to expand...
Click to collapse
Well, are the all the files present? Did you follow all the steps? I suggest you to reinstall busybox by using the link I gave...then attempt this again...
This mod work on MIUI UK official for desire s
Tested with v6 supercharger by zep
Thanks a lot
Sent from my HTC Desire S using xda app-developers app
Hi ,
I use an Motoluxe xt615 , i Fllow your guide step by step . But nothing.
The Phone Restarts an in /data is no Test.log
Busybox install Terminal install . Terminal say all is ok but the test.log fails. After Reboot i cant find it.
Sorry for my bad Englisch
hexer7568 said:
Hi ,
I use an Motoluxe xt615 , i Fllow your guide step by step . But nothing.
The Phone Restarts an in /data is no Test.log
Busybox install Terminal install . Terminal say all is ok but the test.log fails. After Reboot i cant find it.
Sorry for my bad Englisch
Click to expand...
Click to collapse
Ok...let me interpret...you installed busybox by using the link I gave, then you ran this in terminal emulator right? Can you please give me a screenshot of your terminal emulator running this script? Thanks...
Ryuinferno said:
Ok...let me interpret...you installed busybox by using the link I gave, then you ran this in terminal emulator right? Can you please give me a screenshot of your terminal emulator running this script? Thanks...
Click to expand...
Click to collapse
how can i make this???
ah ok
http://s1.directupload.net/file/d/3042/ofxoh9z3_png.htm
Err...run the script in terminal emulator, when it finished running, take a screenshot...
Ryuinferno said:
Err...run the script in terminal emulator, when it finished running, take a screenshot...
Click to expand...
Click to collapse
http://s1.directupload.net/file/d/3042/ofxoh9z3_png.htm
hexer7568 said:
how can i make this???
ah ok
http://s1.directupload.net/file/d/3042/ofxoh9z3_png.htm
Click to expand...
Click to collapse
Ok...by looking at your first few lines...I saw that su permissions for terminal emulator are not granted properly...and my script seems to be only running in the surface (only shows the text)...did you reboot after installing busybox? And by the way, please check your /system/etc...is there a init.d folder and a file named "install-recovery.sh"? And what andriod version are you using?
P.s. A working example should be like my screenshot on the first page...the first few lines in your screenshot should not appear...
Ok...I will include a flashable zip soon...cause terminal emulator does not seem to work with some...
Ryuinferno said:
Ok...by looking at your first few lines...I saw that su permissions for terminal emulator are not granted properly...and my script seems to be only running in the surface (only shows the text)...did you reboot after installing busybox? And by the way, please check your /system/etc...is there a init.d folder and a file named "install-recovery.sh"? And what andriod version are you using?
P.s. A working example should be like my screenshot on the first page...the first few lines in your screenshot should not appear...
Click to expand...
Click to collapse
1 Reboot after busybox install no
2, no
3. no
That's why...the script did not have the correct permissions to run...did you grant terminal emulator su access when you type "su"? Try installing busybox again, reboot, run the script and reboot again...
Ryuinferno said:
That's why...the script did not have the correct permissions to run...did you grant terminal emulator su access when you type "su"? Try installing busybox again, reboot, run the script and reboot again...
Click to expand...
Click to collapse
When i type su , the first massage is "log_write: cannot open Device" , then after this massage i have su
When you type "su" for the first time after installing terminal emulator, a pop up will appear, asking you to grant or deny superuser access...did that happen?
Ryuinferno said:
When you type "su" for the first time after installing terminal emulator, a pop up will appear, asking you to grant or deny superuser access...did that happen?
Click to expand...
Click to collapse
i install emulator new, and i lock that
Ok..seems that the su access in your terminal emulator is not working well, so I will upload a cwm zip soon...wait for that...
i ported a LeWa OS ROM for my device and everything seemed to work perfectly, booted up without hassle, apps working, and everything was fine. not until i came to the point where i have to check the root capability. it seems like the /system partition was locked as read-only. i pre-rooted the rom with supersu and su binaries properly placed just like i do with other roms i ported. but this one is different. even on adb, the su isn't responding. although the request is showing on the phone and i click on grant, still there is no su response or whatsoever, that is why i cant remount it as rw.
so i was wondering if there is something i have to port from stock boot.img to port boot.img to permanently mount /system partition in RW capability.
i hope anyone can help me
How about making an insecure kernel so you can access root without requesting su?
xlSKYFiRElx said:
i ported a LeWa OS ROM for my device and everything seemed to work perfectly, booted up without hassle, apps working, and everything was fine. not until i came to the point where i have to check the root capability. it seems like the /system partition was locked as read-only. i pre-rooted the rom with supersu and su binaries properly placed just like i do with other roms i ported. but this one is different. even on adb, the su isn't responding. although the request is showing on the phone and i click on grant, still there is no su response or whatsoever, that is why i cant remount it as rw.
so i was wondering if there is something i have to port from stock boot.img to port boot.img to permanently mount /system partition in RW capability.
i hope anyone can help me
Click to expand...
Click to collapse
Download SuperSU and reinstall its binaries again.
Or you can try adbd Insecure app (not free)
janekmuric said:
Download SuperSU and reinstall its binaries again.
Or you can try adbd Insecure app (not free)
Click to expand...
Click to collapse
supersu or any of its binaries cannot help me. as every app that request root privileges hangs when grant permission is given. ill try adbd insecure app. gonna throw my money to this one
xlSKYFiRElx said:
supersu or any of its binaries cannot help me. as every app that request root privileges hangs when grant permission is given. ill try adbd insecure app. gonna throw my money to this one
Click to expand...
Click to collapse
I think the adb insecure app still requires su, you can upload the boot.img and i'll make it insecure (automatically root via adb, no su required)
Oooohh
xlSKYFiRElx said:
supersu or any of its binaries cannot help me. as every app that request root privileges hangs when grant permission is given. ill try adbd insecure app. gonna throw my money to this one
Click to expand...
Click to collapse
I didn't understand you correctly. Anyways from what I understand noe you can't give root to any app at all. Try using framaroot to re-root maybe it works. You have to find out the reason it hangs. I'm placing my bet on the corrupt or bad binary.
janekmuric said:
I didn't understand you correctly. Anyways from what I understand noe you can't give root to any app at all. Try using framaroot to re-root maybe it works. You have to find out the reason it hangs. I'm placing my bet on the corrupt or bad binary.
Click to expand...
Click to collapse
He's right, redownload the binaries again, if it still hangs, it might be the ROM.
Add this to build.prop if you want root via adb:
ro.secure=0
janekmuric said:
I didn't understand you correctly. Anyways from what I understand noe you can't give root to any app at all. Try using framaroot to re-root maybe it works. You have to find out the reason it hangs. I'm placing my bet on the corrupt or bad binary.
Click to expand...
Click to collapse
3DMapPlayer said:
He's right, redownload the binaries again, if it still hangs, it might be the ROM.
Add this to build.prop if you want root via adb:
ro.secure=0
Click to expand...
Click to collapse
sorry for the confusion but here is the case, i ported this (LEWA) ROM and i pre rooted with, placed the updated su binary to /system/xbin and the latest supersu.apk to /system/app. the phone boots properly and according to the rom. i installed root checker but when it checked for root it says the root is not installed properly but the supersu dialog box is appearing and i can press the grant button and a toast appears saying that it is granted superuser permissions. i tried to re-root using framaroots barahir exploit but it said "Half-Success" because the system partition is mounted read-only.
i tried using root explorer, when i try to mount system as r/w the supersu dialog appears and i can press the grant button again, also the toast appears saying that the app is granted superuser permission but then the application (root explorer) hangs, i tried other root explorer application still the same.
so what i want to achieve is to mount /system as read-write partition
i tried using ADB, but when i try to type su everything i type reappears
example: when i type 'su' the result is like this:
Code:
what i type: su
what show: su
what i type: busybox mount
what show: busybox mount
or simply, everything i type reappears and the command is not executed.
i tried to modify boot.img by editing build.prop and setting this values
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=1
persist.mtk.aee.aed=on
ro.debuggable=1
persist.sys.usb.config=mass_storage,mtp
persist.service.acm.enable=0
ro.mount.fs=EXT4
Click to expand...
Click to collapse
and also editing init.rc and setting this values
Code:
mount yaffs2 [email protected] /system rw remount
mount ubifs [email protected] /system rw remount
but still no luck. i hope you guys understand, sorry for my crappy english. not my language
i'll try to reflash the rom so that i can supply screenshots
also, here is a copy of my boot.img
Got it!
xlSKYFiRElx said:
sorry for the confusion but here is the case, i ported this (LEWA) ROM and i pre rooted with, placed the updated su binary to /system/xbin and the latest supersu.apk to /system/app. the phone boots properly and according to the rom. i installed root checker but when it checked for root it says the root is not installed properly but the supersu dialog box is appearing and i can press the grant button and a toast appears saying that it is granted superuser permissions. i tried to re-root using framaroots barahir exploit but it said "Half-Success" because the system partition is mounted read-only.
i tried using root explorer, when i try to mount system as r/w the supersu dialog appears and i can press the grant button again, also the toast appears saying that the app is granted superuser permission but then the application (root explorer) hangs, i tried other root explorer application still the same.
so what i want to achieve is to mount /system as read-write partition
i tried using ADB, but when i try to type su everything i type reappears
example: when i type 'su' the result is like this:
Code:
what i type: su
what show: su
what i type: busybox mount
what show: busybox mount
or simply, everything i type reappears and the command is not executed.
i tried to modify boot.img by editing build.prop and setting this values
and also editing init.rc and setting this values
Code:
mount yaffs2 [email protected] /system rw remount
mount ubifs [email protected] /system rw remount
but still no luck. i hope you guys understand, sorry for my crappy english. not my language
i'll try to reflash the rom so that i can supply screenshots
also, here is a copy of my boot.img
Click to expand...
Click to collapse
Flash the attached ZIP. It will reinstall SuperSU and all needed files.
Make a Nandroid backup first!!
For Stock Lollipop:
You will need to install busybox for the init.d support on your phone. Follow these instructions:
http://forum.xda-developers.com/showpost.php?p=32716412&postcount=2
The guide provides a test script that you need to flash to ensure it works properly. Once you install init.d and it is working properly push the file below
For Custom Roms:
Typically init.d and busybox are included. If it doesn’t support it then install using the method above. If it does support init.d and already has busybox push the file below. I would download the test script above just to make sure the init.d works properly.
The Viper4Android script file contains the following:
Code:
#!/system/bin/sh
/system/xbin/supolicy --live "allow mediaserver mediaserver_tmpfs:file { read write execute };"
Resource:
http://forum.xda-developers.com/showpost.php?p=60672119&postcount=18334
Push file to system/etc/init.d folder and set the right permissions (rwx-rwx-rwx). Remove the .txt at the end of the file.
The second file you will need to edit. Its the init.qcom.post_boot.sh. This is needed so the Viper4Android script continues to work after reboots. Open the file using ES File Explorer or something equivalent. The file is system/etc. Open init.qcom.post_boot.sh and scroll all the way to the end and add the following three lines. Make sure there is a empty line at the end.
Code:
# init.d support
run-parts /system/etc/init.d/
Download Viper4Android:
http://vipersaudio.com/blog/?page_id=48
Follow app installation instructions
Enjoy!!!
Here is a material dark one.
http://forum.xda-developers.com/showthread.php?t=3190352
Sent from my EVO using Tapatalk
Hi
The Viper4Android script doesnt work for me.
Tried to execute it manually through terminal and i get "Failure".
Can you help me out on that ? Am i missing out someting ?
PS : I had installed viper4android and even installed driver yet i see driver status abnormal and on every reboot it asks me to install driver again.
Thanks
SG
I don't get it. I followed all the instructions, I have init.d (kernel auditor confirms it), my device is rooted with busybox installed and it still says that busybox "does not work."
Suggestions?