Database Info

Simple (not one-click) root for stock ROM & kernel

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.

[How-To](UPDATED 11/1/10)Working Marketplace in 2.2 Emulator (no system.img)(ROOTED)

This all started out as an experiment to get my nandroid system.img file running in the adb emulator. Well sadly I haven't been able to do that (yet) but I have found something useful. I've Seen several people all over asking how to get a working marketplace app in 2.2 on the adb emulator. After a lot of researching (and trial and error) I've managed to get one. Here are the steps I've taken. (Steps 5 and 6 optional, you can just use the included build.prop if you prefer)
1) Create an avd running 2.2 (froyo,plenty of places explain how to do this so I won't)
2) Download the file (attached below, root files included)
3) Unzip to a location that's easy to remember and find.
4) Load your emulated phone (allow it to load fully)
5) enter this command in a command prompt/terminal window (make sure you "cd" to the directory where you extracted the files)
Code:
adb pull /system/build.prop
6) Remove or comment "ro.config.nocheckin=yes" (no quotes, might be able to just change it to "no" but I haven't tried it that way)
7) enter these commands
Winblows (I mean windows)
Code:
adb remount
adb push build.prop /system/build.prop
adb install GoogleServicesFramework.apk
adb install Vending.apk
adb install Gmail.apk (optional but sometimes signing in here lets the market sign in)
adb shell rm /system/app/SdkSetup.apk
Linux
Code:
adb remount
adb push ./build.prop /system/build.prop
adb install ./GoogleServicesFramework.apk
adb install ./Vending.apk
adb install ./Gmail.apk
adb shell rm /system/app/SdkSetup.apk
8) Sign in. If it works you're done if not reboot and try again, sometimes it takes 3 or 4 reboots to set. If your emulated phone has a data signal from your computer (you'll see a 3G and network icon in the notification area) just wait for it to sign in. The cancel button should grey out within a minute. If it says it can't connect restart the emulator and try again, be patient.
There is a known bug that not all apps show up in the marketplace. I'm not sure why so if someone here knows how to fix that by all means leave a post and let me know. If I see it I'll add it to the first post (provided it works of course )
Edit: Working on getting root on the emulator (just for the hell of it). So far I have su in the xbin directory and superuser.apk installed. Not 100% sure what else I need to do to get the su requests to go through though, I'll probably PM a more experienced member and post back when I have more. Got root? I do (got it working.) Here are the steps you need to take.
Rooting the standard android image on the emulator
1) Open a command prompt (cd to the directoy where you extracted the files)
2) enter these commands
Code:
adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock03 /system
adb push su /system/xbin/su
adb shell chmod 06755 /system
adb shell chmod 06755 /system/xbin/su
adb install superuser.apk
That's it! You now have a rooted, market-enabled android emulator.
New! N00b-friendly method
1) create your avd
2) download the emulator files archive attached to this post
3) extract somewhere easy to find
4) open command prompt/terminal and cd to the extracted location
5) start your avd
6) Run your script (windows.bat or linux.sh)
7) sign into market and enjoy root!
Note:
You may have to chmod su again upon restarting the emulator.
To get root back simply run the re-root script for your OS (bat for windows,sh for linux)
To install busybox simply run the re-root script, it will automatically install if you're using the script to install on a new avd.

Post 2
[reserved for updates, explanations, pictures, present/future tweaks in progress, etc]
Pictures:
Superuser list,Marketplace (I like solitaire><), Terminal with su permissions, and re-rooted Terminal​
{
"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"
}
Tweaks:
1: root (done!)
2: busybox (done!)

Wow nice....

Thank you the root resets after reboot, working on making it stick but its not hard to do it again, just start with the "-wipe-data" command and redo the root, market works after reboot though. Still working on getting a dumped system.img to boot, ill post that in its own thread when i get it. Glad you like this.
Sent from my ROOTED T-Mobile myTouch 3G Slide using XDA App
Edit: see first post on how to get root back,no data-wipe!

so cool!! Good job man!

Thanks ^_^ let me know if you find any problems that I haven't already mentioned and I'll see if I can fix them or if they're just an emulator quirk.

Sorry for the double post but I wanted to let you all know busybox is now included! Installation can be performed through scripts (included in the "Emulator Files.rar" archive) or manually. If you wish to do it manually simply open the script in a text editor to see what's going on and enter the commands in a command prompt/terminal window.

I'm not able to make this work, not with a toolkit downloaded yesterday anyway.
Pulling of build.prop works, but pushing fails with a directory related error.
"adb shell" followed by "cd /system" and "ls -l" gives a list of files that does not include build.prop, neither as a file nor as a directory.
"ls -l build.prop" works though, and lists a file with 0644 permissions.
Install of all apks different from Gmail fails, with an error that says that those apks are already installed. Uninstalling them through adb doesn't work, netting instead a simple generic error.
Does anyone know whether I'm doing something wrong or Google has modified the emulator images so to render the Market workaround unusable? If so, where could I download an earlier version of the 2.2 system image?
Many thanks
Rocco

I actually had this issue as well. Try re-making the avd, worked for me. You could also try running the scripts to install, might work. If it doesnt post back and ill post the system.img from my sdk.
Sent from my ROOTED T-Mobile myTouch 3G Slide using XDA App

I have the same problem as ropi. Remade the avd several times with different properties, still no go.
I would really appreciate it if someone could upload a fully set-up avd somewhere.

I'll try again late this afternoon (I'm on CEST). Hope it works. If not, I'd be happy too if some kind soul would upload a link to a working avd
Thanks for the kind help
Rocco

I have no idea why people are having so many problems :/. I had the problem and once I remade the avd it went away. Try starting with the -partition-size 96 option and see if that helps. If not here are the files, just extract to your avd directory, it has the ini and img files you need and it's already setup. Just run re-root to get root back and sign into market and you're good to go.
http://hotfile.com/dl/79959332/3efbade/froyo-avd.rar.html
Edit: I just downloaded the latest revision and everything seems to be working fine :/ As I've said before try starting with -partition-size 96 and also try using the scripts I've provided. That should fix the issues, but if it doesn't there's always the hotfile link I've provided (or if you're just lazy lol)
Edit 2: also,just thought of this, make sure before you push the build.prop you adb remount. Pulling will work fine without doing that but pushing won't. No one said if they had done this and still received the errors so I'm trying to cover all bases. If remount fails try the adb shell mount command posted on the first page.

Thanks dbzfanatic, that avd worked great.

Glad it worked for ya. Let us know how everything works.
Sent from my ROOTED T-Mobile myTouch 3G Slide using XDA App

A lot of apps can not be found in the Market ... I cannot find Lookout....

Yeah, I've mentioned that,firs post. It's a known bug. Nothing I can do to fix it at the moment. You could download the apk on your phone then pull it then install it in the emulator. Bit of a roundabout way of doing things but it's all we can do on the emulator for the time being, at least from what I know.

Ok after a bit of poking around (sorry it took so long) I found out a bit about the market. It seems it's not just your region that it uses to show apps but things like your carrier, presence/absence of a SIM card, Android version, etc. It uses the filters to choose which apps to show and which to exclude (not showing an American user Japanese apps, not showing someone on Verizon T-Mobile apps, etc) so this explains part of the problem. I also found out that the SIM card and IMEI numbers were(are?) hard-coded into the emulator binary, changing these may allow us to see a few more apps. I looked through the binary file a bit and didn't find anything but I'll look more closely in a bit (new job, yay <- read as "groan"). I don't know how to emulate or spoof a carrier so that will still cut us back on some of the apps being seen. If anyone knows how to do this please post here and let us know! It would also be beneficial if a user who has already modified their IMEI and SIM numbers in the emulator to compare the apps list to the one you see in the standard, non-modded emulator binary and let us know if there is a difference or not. The more apps we can see in the marketplace the better!

Just wanted to confirm that I've tried Market Enabler a few days ago and it doesn't seem to work.

Alright thanks for the feedback. Ill keep working on it.
Sent from my ROOTED T-Mobile myTouch 3G Slide using XDA App

Despite several tries, I've so far been unsuccessful in using this method to install the marketplace on a 2.2 avd. Many thanks for having provided ready-made avds, then!
I've been able to install marketplace on the Galaxy Tab images provided by Samsung, though!
Keep up the good work

[Q] Any suggestions on how to regain root after the OTA ICS update using Linux?

Any suggestions on how to regain root after the OTA ICS update using Linux? I've read through various posts scattered about the innerwebs regarding how using Windows but I'm a stubborn Linux user. I've downloaded the A2_ICS_Root Zip and explored the contents but not sure how to properly utilize them. I've rooted the phone in the past manually using Android SDK, Linux Terminal, push/adb shell commands and Motofail but of course lost root with the ICS update. If I don't get an answer I may attempt to follow some of the scripting used for Droid/Razors post ICS, of course tailored a bit. Although my Superuser app is still showing it's pretty much useless, like others with the same issue I've read about, it's still written into the system but no longer rooted. I've tested phone access in terminal but get the R/W error message ... no permission, etc. So ... I thought maybe folks here may have an answer for us semi skilled Linux users.

You should be able to just run the root.bat if you have the folder with all contents extracted to desktop.
Sent from my MB865 using xda premium

Aimless Rambler said:
Any suggestions on how to regain root after the OTA ICS update using Linux? I've read through various posts scattered about the innerwebs regarding how using Windows but I'm a stubborn Linux user. I've downloaded the A2_ICS_Root Zip and explored the contents but not sure how to properly utilize them. I've rooted the phone in the past manually using Android SDK, Linux Terminal, push/adb shell commands and Motofail but of course lost root with the ICS update. If I don't get an answer I may attempt to follow some of the scripting used for Droid/Razors post ICS, of course tailored a bit. Although my Superuser app is still showing it's pretty much useless, like others with the same issue I've read about, it's still written into the system but no longer rooted. I've tested phone access in terminal but get the R/W error message ... no permission, etc. So ... I thought maybe folks here may have an answer for us semi skilled Linux users.
Click to expand...
Click to collapse
Use the process and scripts I created for the leak/OTA. All you need to do is step 6 in the following link, and use the shell not the bat as others noted... if you are running linux, I am sure you already knew that.
Link:
http://forum.xda-developers.com/showthread.php?t=1779968
6) Boot into ICS, and root using the zip below, you will connect the phone to your computer and use the root.bat (unzip this folder to your desktop) for windows and root.sh for linux/mac.
The script and root files:
http://www.androidfilehost.com/main/Motorola_ATRIX_2_Developers/jimbridgman/A2_ICS_root.zip

Re-Rooted!
jimbridgman said:
Use the process and scripts I created for the leak/OTA. All you need to do is step 6 in the following link, and use the shell not the bat as others noted... if you are running linux, I am sure you already knew that.
Link:
http://forum.xda-developers.com/showthread.php?t=1779968
6) Boot into ICS, and root using the zip below, you will connect the phone to your computer and use the root.bat (unzip this folder to your desktop) for windows and root.sh for linux/mac.
The script and root files:
http://www.androidfilehost.com/main/Motorola_ATRIX_2_Developers/jimbridgman/A2_ICS_root.zip
Click to expand...
Click to collapse
Thanks Jim! I actually figured it out on my own, of course using the same zip file you provided which I had found in another thread.
I extracted the file into it's own folder, put the phone into debug mode and made sure MTP (media device) was checked, hooked to USB then ran a few checks in Terminal to make sure the device was recognized. Then I dragged "a2_ics_root.sh" into the open Terminal window and let it do its thing. I already had Superuser installed in earlier root (prior to ICS) so maybe that's why I got the "cannot stat 'su': No such file or directory cannot stat 'Superuser.apk': No such file or directory" error but then it said "You are rooted!". So to check to make sure I was actually rooted I ran the adb shell command and got this "[email protected]:/ $" then entered su, and got this "[email protected]:/ #"
Success!!

Hmm
Aimless Rambler said:
Thanks Jim! I actually figured it out on my own, of course using the same zip file you provided which I had found in another thread.
I extracted the file into it's own folder, put the phone into debug mode and made sure MTP (media device) was checked, hooked to USB then ran a few checks in Terminal to make sure the device was recognized. Then I dragged "a2_ics_root.sh" into the open Terminal window and let it do its thing. I already had Superuser installed in earlier root (prior to ICS) so maybe that's why I got the "cannot stat 'su': No such file or directory cannot stat 'Superuser.apk': No such file or directory" error but then it said "You are rooted!". So to check to make sure I was actually rooted I ran the adb shell command and got this "[email protected]:/ $" then entered su, and got this "[email protected]:/ #"
Success!!
Click to expand...
Click to collapse
Well I don't have root after all? Once unplugged from computer I ran a terminal emulator app on the phone and tried to access root but it says I don't have permission, as well as a few other apps I tried to install. Strangeness. As it looks above in quote is it just a temporary root? One thing I did notice after the OTA ICS update is that the superuser app remained. I tried a factory data reset thinking it would take it off but it didn't. Is my original rooting (GB Motofail) SU somehow stuck in perpetuity within some system file somewhere which is fouling up this root? So how would I go about a clean install of Superuser? I updated Superuser on Play Store but no difference. Hmm

update on strange problem
Aimless Rambler said:
Well I don't have root after all? Once unplugged from computer I ran a terminal emulator app on the phone and tried to access root but it says I don't have permission, as well as a few other apps I tried to install. Strangeness. As it looks above in quote is it just a temporary root? One thing I did notice after the OTA ICS update is that the superuser app remained. I tried a factory data reset thinking it would take it off but it didn't. Is my original rooting (GB Motofail) SU somehow stuck in perpetuity within some system file somewhere which is fouling up this root? So how would I go about a clean install of Superuser? I updated Superuser on Play Store but no difference. Hmm
Click to expand...
Click to collapse
First of all I apologize for all this confusion with replies to my own questions but I don't know any other way to relay the information. I'm troubleshooting as I go and hope it helps define what the issue may be and maybe a fix haha! Okay!! So I get root access easy as pie in terminal, no issues whatsoever, so I did a little searching and this is what I've found. The problem seems to be su is listed twice within my system folder (see below).
PROBLEM
[email protected]:/system/app # ls
Superuser.apk <<< is listed in the right location
# cd ..
[email protected]:/system #
[email protected]:/system/bin #
su <<< is listed here
[email protected]:/system/xbin #
su <<< is also listed here?
That can't be right? Shouldn't it only be in the /bin folder? Having downloaded the A2 ICS Root zip file I explored the Windows root.bat file in a text editor and saw that SU is suppose to install to /bin. So how the heck did it get in 2 different locations? ha!!! I'm guessing this would cause some issue but before I go deleting the extra file I thought I should inquire first. Haha!
Doh!!!! I know it's got to be something I did!

Aimless Rambler said:
First of all I apologize for all this confusion with replies to my own questions but I don't know any other way to relay the information. I'm troubleshooting as I go and hope it helps define what the issue may be and maybe a fix haha! Okay!! So I get root access easy as pie in terminal, no issues whatsoever, so I did a little searching and this is what I've found. The problem seems to be su is listed twice within my system folder (see below).
PROBLEM
[email protected]:/system/app # ls
Superuser.apk <<< is listed in the right location
# cd ..
[email protected]:/system #
[email protected]:/system/bin #
su <<< is listed here
[email protected]:/system/xbin #
su <<< is also listed here?
That can't be right? Shouldn't it only be in the /bin folder? Having downloaded the A2 ICS Root zip file I explored the Windows root.bat file in a text editor and saw that SU is suppose to install to /bin. So how the heck did it get in 2 different locations? ha!!! I'm guessing this would cause some issue but before I go deleting the extra file I thought I should inquire first. Haha!
Doh!!!! I know it's got to be something I did!
Click to expand...
Click to collapse
That is completely correct. The su in /system/xbin is a link to /system/bin/su. And that is correct, and how it should be.
Please explain your issue in more detail as I am not fully understanding what is not working.

Rooted again??
jimbridgman said:
That is completely correct. The su in /system/xbin is a link to /system/bin/su. And that is correct, and how it should be.
Please explain your issue in more detail as I am not fully understanding what is not working.
Click to expand...
Click to collapse
The issue was my phone was not actually rooted after running a2_ics_root.sh in Terminal (computer). I got the "cannot stat 'su': No such file or directory cannot stat 'Superuser.apk': No such file or directory" error message in terminal and also checked root by running a terminal emulator app within the phone and received the no permission message after entering su at the prompt. Once I reconnected the phone to the computer and ran the sh file again I gained temporary root. That's when I noticed su was in two different locations as I mentioned above and you subsequently replied was normal. Of course before I saw your response I had already removed (rm command) the extra su ha! After removing the su file from /xbin it alone did not fix the problem. I still could not access root. So I reran the a2_ics_root.sh in terminal (computer) and got root with no error messages and verified it with my phone's terminal app (also got the Superuser root access permission check, which I hadn't got before). No idea why this worked if su was suppose to be in two locations. As I was in the phones terminal emulator app I checked the /xbin folder and did not see it reappear yet it all seems rooted now! Ha! Gosh my brain hurts.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
remount succeeded
492 KB/s (22372 bytes in 0.044s)
3434 KB/s (397229 bytes in 0.112s)
You are rooted!

Aimless Rambler said:
The issue was my phone was not actually rooted after running a2_ics_root.sh in Terminal (computer). I got the "cannot stat 'su': No such file or directory cannot stat 'Superuser.apk': No such file or directory" error message in terminal and also checked root by running a terminal emulator app within the phone and received the no permission message after entering su at the prompt. Once I reconnected the phone to the computer and ran the sh file again I gained temporary root. That's when I noticed su was in two different locations as I mentioned above and you subsequently replied was normal. Of course before I saw your response I had already removed (rm command) the extra su ha! After removing the su file from /xbin I reran the a2_ics_root.sh in terminal (computer) and got root with no error messages and verified it with my phone's terminal app (also got the Superuser root access permission check, which I hadn't got before). No idea why this worked if su was suppose to be in two locations. As I was in the phones terminal emulator app I checked the /xbin folder and did not see it reappear yet it all seems rooted now! Ha! Gosh my brain hurts.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
remount succeeded
492 KB/s (22372 bytes in 0.044s)
3434 KB/s (397229 bytes in 0.112s)
You are rooted!
Click to expand...
Click to collapse
Did you by chance try and use some sort of root keeper before trying to do the OTA, then had these problems after the OTA was completed?
We have seen this before, and the reason you got the stat errors is because the wrong versions of the files were in /system/bin and /system/xbin. Yeah we have found that trying to use any OTA root keepers are BAD on this phone. Motorola is so anal about updates. That is why we mention to do an fxz before doing any OTA, then using the root scripts afterwards.
If you still have any more issues you might think about using the new ICS fxz in the development section and using/redoing the script from there.
P.S. I saw that you said you dragged the script into the terminal, that is a bad way to run it, BTW.... Try and open a terminal and cd into the dir that you unzipped the script in, and then into the ics_root dir and type ./root.sh and see if that works a little better next time, that might be why you only got temp root, because it was not able to find the proper su and superuser.apk to copy over with adb, I use relative paths in the script just for ease.

jimbridgman said:
Did you by chance try and use some sort of root keeper before trying to do the OTA, then had these problems after the OTA was completed?
We have seen this before, and the reason you got the stat errors is because the wrong versions of the files were in /system/bin and /system/xbin. Yeah we have found that trying to use any OTA root keepers are BAD on this phone. Motorola is so anal about updates. That is why we mention to do an fxz before doing any OTA, then using the root scripts afterwards.
If you still have any more issues you might think about using the new ICS fxz in the development section and using/redoing the script from there.
P.S. I saw that you said you dragged the script into the terminal, that is a bad way to run it, BTW.... Try and open a terminal and cd into the dir that you unzipped the script in, and then into the ics_root dir and type ./root.sh and see if that works a little better next time, that might be why you only got temp root, because it was not able to find the proper su and superuser.apk to copy over with adb, I use relative paths in the script just for ease.
Click to expand...
Click to collapse
Thanks! I'm sure I did something to cause the troubles but can't recall exactly what it was I did wrong! My brain is getting old. Ha! But to answer your question ... other than my original root (using Motofail) I've hesitated to do anything until after the ICS update. I recently bought the phone 2nd hand to replace my Samsung Captivate so I could experiment with a Lapdock (in my line of work portability and multi-role is a plus). The phone was stock when I got it. Also, I had moved the root.sh file and superuser.apk into my Android/Platform_Tools folder which is in my system path (android rules,etc), so there was some forethought prior to dragging the script into terminal. Next time I'll 'cd it like ya recommend!
Could it be there was an issue with how I did the original GB motofail root?
In any case all seems to be good now.
Thanks again!

[Q] [OUYA] SuperUser Access Help

Hi everyone, I'm trying to Install busybox,SuperUser and SU Binaries on my OUYA ...
I Have:
-ADB set up and working(wired)
-Downloded and unzipped the needed files
-Placed unzipped files in /android-sdk/platform-tools
Then i run the following commands to make sure my console is connected:
-adb kill-server
-echo 0x2836
-adb start-server
-adb devices
After 'adb devices' I see a number(My console #), which signifies my connected console...
Then i run the following commands to put SU in the proper place:
-adb shell
-su
-mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
-exit
-exit
-adb push su /sdcard/su<-----here is where i get an error (cannot stat 'su': No Such Files Or Directory :crying What am i doing wrong here/ i don't get it!...Can anyone please help me?

cronikman84 said:
Hi everyone, I'm trying to Install busybox,SuperUser and SU Binaries on my OUYA ...
I Have:
-ADB set up and working(wired)
-Downloded and unzipped the needed files
-Placed unzipped files in /android-sdk/platform-tools
Then i run the following commands to make sure my console is connected:
-adb kill-server
-echo 0x2836
-adb start-server
-adb devices
After 'adb devices' I see a number(My console #), which signifies my connected console...
Then i run the following commands to put SU in the proper place:
-adb shell
-su
-mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
-exit
-exit
-adb push su /sdcard/su<-----here is where i get an error (cannot stat 'su': No Such Files Or Directory :crying What am i doing wrong here/ i don't get it!...Can anyone please help me?
Click to expand...
Click to collapse
:good:never mind i figured it out...but when i go to Run SuperUser on the OUYA (Make > Software > SuperUser) and allow it to update, it gives me an error saying---->there was an error installing superuser. please send a log of the error to the developer. what now?

cronikman84 said:
:good:never mind i figured it out...but when i go to Run SuperUser on the OUYA (Make > Software > SuperUser) and allow it to update, it gives me an error saying---->there was an error installing superuser. please send a log of the error to the developer. what now?
Click to expand...
Click to collapse
Never mind LMAO...i got it :victory:

cronikman84 said:
Never mind LMAO...i got it :victory:
Click to expand...
Click to collapse
How'd you get it?! I'm stuck here too, thanks!

thanamesjames said:
How'd you get it?! I'm stuck here too, thanks!
Click to expand...
Click to collapse
Are you stuck at the error saying---->"there was an error installing superuser" still? cause if you are i think i can help you..., just on your ouya head over to MANAGE-SYSTEM-ADVANCED and scroll down to apps and delete the BUSYBOX FREE and SUPERUSER APPS...after that's done just repeat the commands again and reboot the system, then go click on MAKE>SOFTWARE>SUPERUSER and allow it to UPDATE but not from recovery and if that doesn't work let me know and ill tell you what to do next...BUT if your stuck at "adb push su /sdcard/su cannot stat 'su': No Such Files Or Directory" error then i can also help you...let me know, it's very simple, less than a minute

cronikman84 said:
Are you stuck at the error saying---->"there was an error installing superuser" still? cause if you are i think i can help you..., just on your ouya head over to MANAGE-SYSTEM-ADVANCED and scroll down to apps and delete the BUSYBOX FREE and SUPERUSER APPS...after that's done just repeat the commands again and reboot the system, then go click on MAKE>SOFTWARE>SUPERUSER and allow it to UPDATE but not from recovery and if that doesn't work let me know and ill tell you what to do next...BUT if your stuck at "adb push su /sdcard/su cannot stat 'su': No Such Files Or Directory" error then i can also help you...let me know, it's very simple, less than a minute
Click to expand...
Click to collapse
Hi,
I'm at the point where I've installed 'superuser' apk via adb. I've rebooted the console, gone to MAKE>SOFTWARE>SUPERUSER but when I click on 'install', I just get the error message: "There was an error installing Superuser. Please send a log to the error to the developer" but there are no logs.
Any ideas?

diazamet said:
Hi,
I'm at the point where I've installed 'superuser' apk via adb. I've rebooted the console, gone to MAKE>SOFTWARE>SUPERUSER but when I click on 'install', I just get the error message: "There was an error installing Superuser. Please send a log to the error to the developer" but there are no logs.
Any ideas?
Click to expand...
Click to collapse
yes, the best way to do it is with this tool OUYA toolbox and you can find it over here-----> http://forum.xda-developers.com/showthread.php?t=2350900 follow the instructions plug in your OUYA to your pc and download the test version of the tool, open it, click on install superuser and install it, then istall busybox and install it...then go to make- software-superuser and Update but not from recovery, then plug you OUYA back on to the pc and run the ouya toolbox program again and root(if you want to), you will be all set with SuperUser apk and busybox apk and root working perfect with no errors...

cronikman84 said:
yes, the best way to do it is with this tool OUYA toolbox and you can find it over here-----> http://forum.xda-developers.com/showthread.php?t=2350900 follow the instructions plug in your OUYA to your pc and download the test version of the tool, open it, click on install superuser and install it, then istall busybox and install it...then go to make- software-superuser and Update but not from recovery, then plug you OUYA back on to the pc and run the ouya toolbox program again and root(if you want to), you will be all set with SuperUser apk and busybox apk and root working perfect with no errors...
Click to expand...
Click to collapse
I think I might have found the issue. I think I forgot to copy the 'su' executable from /sdcard to /system/xbin. I've copied the correct 'su' executable to /system/xbin now. I'll have to test it later, I'm connected remotely at the moment so I can only do the shell stuff, I can't run Superuser.
What is the difference between the nativesu and the su copied from the attachment on this thread. There is a significant difference in size. Is the native su crippled in someway?

diazamet said:
I think I might have found the issue. I think I forgot to copy the 'su' executable from /sdcard to /system/xbin. I've copied the correct 'su' executable to /system/xbin now. I'll have to test it later, I'm connected remotely at the moment so I can only do the shell stuff, I can't run Superuser.
What is the difference between the nativesu and the su copied from the attachment on this thread. There is a significant difference in size. Is the native su crippled in someway?
Click to expand...
Click to collapse
:good: i hope you found the issue...i was having the same issue as you "There was an error installing Superuser. Please send a log to the error to the developer" and no matter what i tried it wouldn't work, so i just downloaded the OUYA toolbox test version and it took me less then 1 minutes to have superuser apk and busybox apk running and rooted, i didn't know you were connected remotely, i had mines connected straight up with the usb cable and it makes it easier for me..."What is the difference between the nativesu and the su copied from the attachment on this thread. There is a significant difference in size. Is the native su crippled in someway?" <----yes, i'm 90% sure that the native SU is crippled in some type of way, and i've heard other people confirm this.

cronikman84 said:
:good: i hope you found the issue...i was having the same issue as you "There was an error installing Superuser. Please send a log to the error to the developer" and no matter what i tried it wouldn't work, so i just downloaded the OUYA toolbox test version and it took me less then 1 minutes to have superuser apk and busybox apk running and rooted, i didn't know you were connected remotely, i had mines connected straight up with the usb cable and it makes it easier for me..."What is the difference between the nativesu and the su copied from the attachment on this thread. There is a significant difference in size. Is the native su crippled in someway?" <----yes, i'm 90% sure that the native SU is crippled in some type of way, and i've heard other people confirm this.
Click to expand...
Click to collapse
Yep. That was the problem. I guess I thought I'd copied the correct version of 'su' across without checking properly.

diazamet said:
Yep. That was the problem. I guess I thought I'd copied the correct version of 'su' across without checking properly.
Click to expand...
Click to collapse
Sweet!!...glad you got it fixed... I knew that the native SU was crippled the first time i tried it...that's why i tried the OUYA toolbox cause i knew people had success with SU on that toolbox, so i gave it a try and SU was workin...tha's how i knew something was wrong with the native SU...

I need help rooting my zte quest 5

Ok so i got a zte quest 5 (z3351s) though qlink. Not the phone i wanted but it was one i could afford. And it works very well just can't run amazon music and other apps at the same time.
But the bloatware is unreal. Used to in my galaxy s3&s4 days i could root and delete all apps i didn't need. I know i can disable them but i want them gone completely.
Majisk didnt work
Kingoroot same even used pc.
I am hoping someone knows of a way i can root this phone or at least delete all the un needed apps for example i have Google maps go (came stock) i put the org google maps which is better plus offers sat view.
Edit i did some math and converting and the useless apps 11 out of 58 come out to 349.72mb which is a lot if your phone only has 16gb of space. Also note i don't have hardly anything.
Worst case i can Hotspot to my note10+ for multitasking but not sure of data limit.

@TexasPride
a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.

I heard about adb methods but i haven't messed with it in forever since apk/ios apps came out

jwoegerbauer said:
@TexasPride
a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.
Click to expand...
Click to collapse
Are you sure it will always work?
I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb
As a result, I got my phone eternally showing the boot logo and not booting.
Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.
If you could give a link to some other method how SU could be installed, I'll give it a try of course.

vp1117 said:
Are you sure it will always work?
I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb
As a result, I got my phone eternally showing the boot logo and not booting.
Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.
If you could give a link to some other method how SU could be installed, I'll give it a try of course.
Click to expand...
Click to collapse
I spoke of SU-binary and NOT of SuperSU installer package
Example:
Code:
adb devices
adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
adb shell "chmod 0777 /sdcard/Downloads/su"
Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.

TexasPride, sorry I stepped in your thread.​
jwoegerbauer said:
I spoke of SU-binary and NOT of SuperSU installer package
Click to expand...
Click to collapse
I see. It is often mixed in numerous materials one can find in the net. Subject is SU-binary update, but the ultimate goal is to install supersu.
jwoegerbauer said:
Example:
Code:
adb devices
adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
adb shell "chmod 0777 /sdcard/Downloads/su"
Click to expand...
Click to collapse
What should be result of running this code? SU-binary located in Downloads with 777 permission? What is the practical sense/use of it?
What software/application would use SU in that location?
Sorry for my questions. I'm not arguing. I try to understand the idea.
jwoegerbauer said:
Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.
Click to expand...
Click to collapse
Somehow, with my almost zero knowledge of edify and linux command line I got the same conclusion: SuperSU zip has to be modified in order to install it via adb on devices that do not have TWRP for sideload. I failed to find any examples of SuperSU modding...

@vp1117
Answering your questions from last to first:
Installing SuperSU.zip via ADB
The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
{
"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"
}
Making use of SU-binary
The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
Running in Android via ADB a command that requires super-user ( root ) rights is done as follows
Example:
Code:
adb devices
adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"

jwoegerbauer said:
Answering your questions from last to first:
Installing SuperSU.zip via ADB
The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
Click to expand...
Click to collapse
OK. I guess, I can repack zip to tar.
Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
jwoegerbauer said:
Making use of SU-binary
The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
Running in Android via ADB a command that requires super-user ( root ) rights is done as follows
Example:
Code:
adb devices
adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"
Click to expand...
Click to collapse
Interestingly, I can execute all commands I need without having su-binary (~100 KB) uploaded to my phone. It is strange but I see #-prompt after I ran <adb shell>. This happens on my UNrooted phone, running stock ROM. I guess, it's a specifics of my phone, no need to try explain it.

I done failed trying to read i dont really understand linux all that well. But if anyone has any links so i can download it and try it

vp1117 said:
Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
Click to expand...
Click to collapse
Of course it's your decision how you transfer the SuperSU package onto phone: many ways lead to Rome.
My decision was to push SuperSU package repacked as TAR-file onto phone, extract it there, and finally run the modified update-binary.sh when phone is booted into recovery mode:
Code:
adb shell "$(cat < %supersu_dir%/update-binary.sh); echo $?"

So I rebooted to stock recovery and then uploaded following from UPDATE-SuperSU-v2.82-20170528234214.zip package to my phone's folder /tmp:
/arm64
/common
/META-INF
update-binary.sh
Here is what I got:
Z:\android\adb>adb shell "$(cat < /tmp/update-binary.sh); echo $?"
127
/system/bin/sh: #!/sbin/sh: not found
And here's what I got running same command from # command line:
# $(cat < /tmp/update-binary.sh); echo $?
/system/bin/sh: #!/sbin/sh: not found
127
In response to # ls -al /sbin I get lots of lines one of them is as follows:
lrwxrwxrwx 1 root root 7 1970-01-01 00:00 sh -> busybox
I feel that I'm doing something wrong, but what exactly?
In attached txt-file I put some more details I got in command line.

jwoegerbauer said:
... and finally run the modified update-binary.sh when phone is booted into recovery mode:
Click to expand...
Click to collapse
Am I right the only modification needed is to rename update-binary to update-binary.sh ?

@vp1117
NO.
When I said modified then I didn't mean simply rename it: The contents of original update-binary file must be rewritten / deleted in some parts. Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above. Take also note that, if device's Android isn't rooted yet, the location for unpacked SuperSU mandatory must be /data/local/tmp.
BTW:
I can see BusyBox is installed on your device's Android. Take note that BusyBox by default comes with the SU-binary. Hence your device's Android is rooted! Wondering why you waste your time with trying to completely install SuperSU from scratch?

jwoegerbauer said:
Wondering why you waste your time with trying to completely install SuperSU from scratch?
Click to expand...
Click to collapse
Good question.
Probably, because I see this when phone restarts from recovery to normal android:

jwoegerbauer said:
Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above.
Click to expand...
Click to collapse
OK, no problem, I can re-pack zip into tar.
However, what you demonstrated above was a screenshot showing update-binary.sh being inside the tar. At the same time you don't tell how update-binary.sh must be amended. Is it OK?

TexasPride​
I'm very sorry I put so much spam in your thread. Please forgive me. If I knew how to delete my posts here I would deleted them.

vp1117 said:
TexasPride​
I'm very sorry I put so much spam in your thread. Please forgive me. If I knew how to delete my posts here I would deleted them.
Click to expand...
Click to collapse
Its ok, i dont mind at all.

@TexasPride
FYI: I no longer participate this hijacked thread.