Rooting the Droid 1 - regardless of OS version
This procedure is to root a phone that is not presently rooted. If you're already rooted (by virtue of running a custom ROM or any other way) then you don't need this. It installs things (like Superuser and busybox) that your phone already has on it. Specific tools are used for specific problems. If your specific problem is not "I need to root my unrooted Droid 1" please do not use this unless you know what you're doing.
[This post is presently 7,152 words long -- almost the length of a decent Master's thesis. At this point it is no longer simply a guide, it is a introductory education. Enjoy.]
Every time a new version of Android comes out for the Droid (or really any phone) one of the first questions is always "has anybody rooted it yet"? Frequently the first success at rooting a new version of the OS involves downgrading to a prior version with some vulnerability in it, or using a tool that was made for a prior version, which will somewhat trash the current version, just to get root, and then clean up the damage afterward.
On the Droid 1 this seems particularly silly since it is wide open (presently) and therefore getting root on any Droid 1 (without destroying anything) should be pretty simple, and now is. Hopefully this guide will put an end to this issue for all time -- for the Droid 1 anyway.
What we're going to do is replace the bootloader partition with one containing SPRecovery, and then use SPRecovery to load an update.zip file that does everything else. Honestly I could do everything inside an SBF file, but then we'd be back to OS version-specific files and methods and that's what we're trying to get away from, right? Also, the SBF file and the update.zip file that I'm using for this are files that I built. The SBF contains only the recovery partition made by SirPsychoS and the update.zip contains only free programs like busybox, su, Superuser.apk, etc. I guess what I'm saying is nobody should be able to be upset with me for distributing them. If anybody is, presumably they'll PM me and let me know.
Before we get into the "how-to" we need to briefly cover something I call the Flash Recovery Service (FRS). I don't know what it's real name is or if it has a real name, but it's a function built into the OS that attempts to keep your recovery partition loaded with the "stock" image. When I first discovered this feature (while doing some troubleshooting for a couple folks here) I thought I discovered some new, sinister thing. Turns out that this feature is not unusual at all -- just that it isn't always enabled depending on what build you're running and how it got on the phone. You can read this post if you want the details.
Anyway, if your phone currently is stock (unrooted, no custom kernel/ROM/etc.) then it likely has a functioning FRS, and if it does it poses a minor trap when doing our procedure below. The procedure is designed with the assumption that you do have a functioning FRS, and will avoid the FRS flashing your recovery back to stock if you do it right. The only part of the procedure that is critical if you have a functioning FRS (and is completely unimportant if you do not) is the "catching the reboot" part. I'll highlight it again in the instructions, but I just wanted to get all this verbiage out up here so I didn't have to stick it in the body of the instructions.
Things you're going to need:
- A Windows based computer. Personally, XP would be preferred, but if it is something newer you'll probably be OK. Windows 7 has the most trouble, followed by Vista. That said, many people have no problem at all with either OS, and at this point we've got solutions to most of the issues that come up. If you're running Windows 7 you may want to go ahead and read the Frequently Encountered Issues section now (before you start the process) so if you hit any of those issues you'll already know there is a solution for it. If you don't have a Windows computer but do have a Linux box, you should be able to substitute sbf_flash for RSD Lite and use the exact same process. Follow the sbf_flash instructions on the author's page.
- RSD Lite 4.6. That's a "7 zip" file. If you have WinRAR it will unzip it no problem. If you don't have WinRAR, or anything else that will unzip a 7-zip file, WinRAR is a good choice. If that link ever dies you should have no problem finding RSD Lite 4.6 all over the place. Just so you know you're getting the exact some file and not a slightly different version or an adulterated copy, the file inside the zip is named RSDLite4.6.msi and the MD5 hash for the file is eb315e028f38b4b3244778782485cd6d.
- Either the 32-bit or 64-bit Motorola drivers as appropriate for your machine. [Here are some older versions in case the links may be useful (32-bit or 64-bit).]
- My "recovery only" SPRecovery SBF for the Droid 1. (Link)
- My "complete root" update file. (Link)
- Your phone and the micro-USB cable to connect your phone to your computer.
- Important - read this: Ideally you either understand the nuances of how Windows file extensions behave and can handle the fact that Windows hides them, or, preferably, you've just configured Windows not to hide them. This issue probably trips up as many people as the odd Windows 7 problems. If in doubt, go read my unhide file extensions guide and then come back here when you're done.
If you do not already have RSD Lite installed on your workstation, install it and the drivers now.
Most of the procedure below mirrors my "Using RSD Lite to flash an SBF file -- correctly" guide, but because we need to "catch the reboot" and because there is another task after flashing the SBF, I'm going to repeat it all here to keep you from having to switch back and forth. That also makes it easy to print it out in case you follow hardcopy instructions easier.
Standard Disclaimer: What you are about to do will void your warranty, contribute to the decline of society as we know it, and certainly corrupt your morals. There is also the slight possibility that you could damage your phone if you do it wrong -- and maybe even if you do it right. You undertake this activity with that in mind and are solely responsible for the results. That said, if you run into trouble, there are plenty of people on this forum that are always willing to lend a helping hand.
If you have any trouble during any of the procedures that follow: Come back to this post and go near the bottom and see the "Frequently Encountered Issues" (FEI) section. Most people complete this process without any issues at all. Most people that have trouble do so due to failure to properly read and follow the directions. But, some situations are just oddities that could happen to anybody that will get you stuck. The below attempts to cover both failure to follow directions and the odd stuff. If the FEI section doesn't solve your problem, post here and we'll get you taken care of. Take comfort in knowing that the two files I created for this process have not needed to be changed even once since I released them and they have been used successfully by hundreds of people. If you're having a problem, it should be fixable.
If you have any questions: please read the FAQ section below before posting your question. You'll get your answer faster and you'll save someone from having to tell you to read the FAQ.
Before getting into the procedure, I have a shameless beg. I had this in a post within the topic but realized that was stupid since it only takes about a day for any given post to be buried 4 pages deep. I've pulled it out and stuck it here until I hit my referral limit and then I'll nuke it. Thanks in advance to anybody that helps me out with the below.
Shameless beg:Brief Procedure:
If you've thought about signing up for Dropbox (it's a free service for unless you need more than 2GB - features
) please use the my "sign up" referral sign up link
to do it. When you do that, you'll get an extra 250MB added to your 2GB of free space, and so will I. I use my Dropbox account to host the files for this tutorial (and many of my other tutorials/guides), so by signing up for Dropbox using my referral link
you give me more Dropbox space to host files that help you and everyone else (and get extra free space for yourself in the process). It's a rare win-win scenario. Just a note that you (and I) don't get the free space until you actually install the Dropbox client somewhere -- just signing up isn't actually enough. I run the Dropbox client on my main PC, and then also run the free Dropbox app on my Droid. That way everything I stick in my Dropbox folder on my PC is automagically available on my Droid, and I can also sync files from my Droid back the other way as well. If you have Dropbox questions, shoot me a PM. I really like the service - I just would rather not have to move to the "pay" tier because most of my storage is used to host files for guides. Thanks!!!
The "Detailed Procedure" section further below is for most people who are completely new or pretty new to using RSD Lite to flash a SBF file and using recovery to apply an update.zip. If you've done those things 1000 times, then use this "Brief Procedure" section instead. If in doubt, use the "Detailed Procedure".
- Extract MC1_A855_1282081087_Recovery-Only_SPRecovery_0.99.3b.sbf out of MC1_A855_1282081087_Recovery-Only_SPRecovery_0.99.3b.zip.
- Copy MotoCache1_Complete_Root_v1.1-update.zip to the root of your phone's SD card and name it as update.zip.
- Boot the phone into the bootloader (dpad up).
- Flash MC1_A855_1282081087_Recovery-Only_SPRecovery_0.99.3b.sbf onto your phone. Watch for "rebooting your phone" and do dpad up before the phone boots to "catch the boot" and come right back into the bootloader.
- Let RSD Lite finish to "PASS".
- Boot into recovery. Should be SPRecovery.
- Apply update.zip.
Again, that's only for the gurus. Everybody else use "Detailed Procedure" below.
- Attach your phone to your computer.
- Unzip the SBF file that you downloaded in Step 4 of "things you're going to need" above. This will produce the file MC1_A855_1282081087_Recovery-Only_SPRecovery_0.99.3b.sbf.
- Do not unzip the MotoCache1_Complete_Root_v1.1-update.zip file that you downloaded in Step 5 of "things you're going to need". You need to copy this file to the root of your phone's SD card and then rename it to update.zip. Note: If on your computer you see the file listed as "MotoCache1_Complete_Root_v1.1-update" (no .zip on the end) then when you copy it to the phone you should name it just "update" (no ".zip"). There are several ways to do this (ADB, mount the phone's file system, etc.). Use which ever you're comfortable with. If you don't know how to do this there are tons of posts on it.
- Power down your phone normally.
- Once the phone is off, slide open the keyboard and press on the "up" direction of the directional keypad rocker (the direction toward the screen -- which could really be to the right depending on how you're holding the phone) [pic]. While holding the dpad in the up direction, simultaneously press and hold the power button of the phone. When you see the backlight of the screen come on you can release the power button and the bootloader screen should appear (it will say "Bootloader" in the upper left corner). You can release the dpad. At the bottom of the text on the screen it should say "Transfer Mode: USB" if your cable is properly connected.
- Start RSD Lite on your computer. If you're on a version of Windows newer than XP, remember to run RSD Lite as administrator by right clicking its menu choice and choosing "Run as Administrator". If you don't have such an option, you may be able to right click on the shortcut, choose "properties", and check "Run this program as Administrator" [pic].
- Hopefully the phone will be listed in the grid in the bottom half of the RSD Lite window. Give it a minute or two if it doesn't show up right away. Sometimes it takes Windows a minute (or 2 or 3) to let go of the phone and pick it back up again after rebooting into the bootloader. If after a couple minutes your phone still isn't listed in the "Model" column of the bottom section, in RSD Lite, click Config, Device Id Options, and choose "First-Come-First-ServeDeviceId Mode" and press "OK". RSD Lite may say you need to restart RSD -- if so, do so.
- Assuming that you now can see your phone listed, click the "..." button to the right of the "Filename:" box. Find the SBF file you unzipped earlier and choose it. After choosing the file the right hand File details pane will fill in.
- OK, this step is where you are going to press "Start" in RSD Lite, but don't do that yet. Before you press Start, read step 10. Step 10 has some timing sensitive tasks. If your phone has functioning FRS (discussed earlier), and you do step 10 wrong, you will have to start back over with this step as the FRS will undo the flash you just did with RSD. Once you've read Step 10 and know what you'll be doing next, go ahead and press Start.
- After clicking Start, the flashing process goes through several distinct steps. This particular SBF file is very small so it finishes pretty quickly. At some point there will be a bit of a delay with RSD Lite showing a status of "Phone: Waiting for re-enumeration". After that is when the actual flashing happens. When the flashing has completed, RSD Lite is going to issue a "reboot-bootloader" command to your phone. Unfortunately the Droid does not appear to implement the reboot-bootloader command correctly and does a normal reboot instead. If you don't "catch the boot" by holding up on the dpad key the OS will boot (and if you have functioning FRS the custom recovery you just flashed on will be put back to stock). Just before sending the reboot instruction to your phone the status in RSD Lite will change to "Phone: Phone is being rebooted". On your phone the screen will change to "SW Update Complete" (unless the message has been changed by the person who built the SBF) and your phone will reboot within a second or two. You want to be already holding the dpad key up when the phone actually reboots. If you followed the instructions for Step 9 you have pre-read this step and knew to be ready for this. If not, your phone is probably already rebooted into the OS. If you failed to catch the boot, and the OS booted, let the phone finish booting, then power it off, hold the dpad up and power it back on. After that, continue through the steps like nothing happened. If your recovery got flashed back to stock we'll know it soon enough.
- You should now be looking at the bootloader on the phone, and RSD Lite should still be saying "Phone: Phone is being rebooted". If too much time has passed RSD Lite may be saying "Please manually boot the phone". The "Progress" value on the screen will keep incrementing, and at some point before, or at, 100% the result should change to "PASS".
- Power the phone off again. With the keyboard open, press and hold the "X" key on the physical keyboard and keep it held while you power the phone on. Once the phone comes on you can release the power button, but keep the "X" button held until you see the the Motorola logo.
- When recovery starts, if you are presented with a screen with a gold colored android in the center that says "Patched by SirPsychoS (0.99.3b) on the second line of text (like this), you're in SPRecovery. If however you are presented with a screen with no text, and a graphic of a triangle with an exclamation point in it and an arrow pointing to a phone (looks like this), you're in stock recovery. If it's the latter, either you failed to catch the boot and your phone has functioning FRS (and it put your recovery back to stock) or something else odd happened (not likely). In any event, if you're in stock recovery you can't proceed so your only choice is to go back to Step 9 and try again. If you're in SPRecovery, congratulations -- move to the next step.
- In the SPRecovery menu, use the volume up/down keys to highlight "install" and use the camera button to choose it.
- Now highlight "Allow update.zip Installation" and choose it. [It will appear to do nothing -- that's normal. If you're unsure if you clicked it or not, choose it twice, it won't hurt.]
- Finally, highlight "Install /sdcard/update.zip (deprecated)" and choose it.
- The install should run to conclusion pretty quickly. When it's done it should look like this. If it does, congratulations, you're done. You're rooted with busybox, SPRecovery, and your FRS is now disabled so you won't revert back to stock recovery the next time you boot the OS. Enjoy!
Thanks to everyone who tested out these files and the procedures, and provided feedback to improve the procedures where they were at all confusing. Specific thanks to ChrisTim, Palantirion, skylordusa1, greeknasty, and 0chilly. Deepest apologies to anybody I missed.
Comments, suggestions, feedback, etc. welcome. This topic can also be used if you're having trouble. Plenty of folks are familiar with how to do all of the above, so it doesn't have to be me that helps unless you end up with a strange issue that has to do with my files specifically.
P.S. Yes, I know you can do this easier with EasyRoot and ROM Manager. If you're happy doing it that way, by all means, stick with it.
P.P.S. A question in this topic by "zero7404" illuminated that while there may be plenty of "how to" detail in this post, there's very little "why". I've added "A little about what you're doing and why" below to remedy that. It is of course optional, but the more you know, the better, right?
A little about what you're doing and why:
I assume you know why you want to root your phone or you probably wouldn't be here to find out how to do it. This section will not cover that topic. What we will cover, briefly, is why you're doing what you're doing -- and we'll discuss the typical components of rooting an Android phone in the process. This was covered very very briefly at the top [of the OP] but will be covered slightly less briefly now.
For us, the first piece of the puzzle is the recovery partition. This is an area that contains the recovery system. The recovery system is most often used to flash updates onto the phone. Normally such an update would be provided over the air (OTA) by your carrier, and after you accept it, the (recovery system of your) phone would install it. Most "stock recoveries" (which is how we refer to the original recovery system on the phone when it is new) will only install updates that have been signed by your carrier (or another trusted entity). There are various reasons for that which we shall not cover here. If we want to apply our own update (such as an update that will "root" the phone), then we've got a problem because your carrier doesn't want you to root your phone, so they certainly are not going to sign such an update, and if it's not signed, your stock recovery won't install it. So we need to replace the recovery with one that isn't quite so picky.
That's what the first part of the procedure (the part where we use RSD Lite to flash an SBF file containing nothing but a custom recovery onto the phone) does. Some pretty talented folks have written their own modified versions of the recovery system (the recovery system is open source so they had a good place to start) that ignores the signature checking and lets you flash on pretty much whatever you want. These custom recoveries enable other features too that we are not concerned with here. It is important to understand that, in order make our process work on any version of the OS (or "build" of the operating system, e.g. FRG22D) we want to replace only the recovery partition and not disturb the kernel, etc. The SBF provided in this topic does just that. It replaces your recovery system with SPRecovery, and nothing more. SPRecovery will then allow us to flash on unsigned updates which is how we'll "get root".
To "get root" on an Android phone you really only need a single file -- "su" -- with the right permissions. The operating system however isn't going to just let you put that file on there and grant those permissions, or else what point would there be in having permissions to begin with? Fortunately for us, when we boot our custom recovery, we're not running the operating system build that's on your phone, we're running the scaled back OS build that's part of recovery. And it is configured to let us have super user rights, and also happens to have access to the /system partition on your phone (which is the one we need to add our "su" file to in order to root it).
Now, if we just added su, and nothing else, we'd be rooted. Unfortunately, so would any other app that wanted to be. Any app that knew to call su to try to "get root" would succeed and every app you ever put on your phone could do anything it wanted. You probably wouldn't want that. So, the smart guys that wrote su for these phones wrote another utility called Superuser.apk. This piece allows you to review and approve (or deny) any requests for root authority, and, if you choose, it remembers your selection for next time. When an app asks su for super user rights, su first checks the database to see if the app is allowed to have those rights, and if it is, then it grants them, if it is explicitly denied to that app, it denies them, and otherwise it asks you what to do (and then denies the right if you don't respond before the timeout). Those two parts in combination provide an effective root control mechanism for the phone.
The last piece of the root puzzle is "busybox". In the Linux world (upon which Android is based) a lot of the tasks one may need to do "as root" are performed by one of dozens of external command line utilities. To save space and processing power, busybox was invented. It contains the most common of those utilities all in one executable. Then "symbolic links" (aka symlinks) are created to simulate the presence of the dozens of utilities as if each separate executable was actually present (when it is really just busybox pretending to be each of them and doing all the work). Many apps that require root will not function if busybox is not installed because they rely upon it to do what they need done. Some apps like Titanium Backup can optionally install their own copy to avoid this dependency.
While not technically part of the rooting puzzle, there is also the Flash Recovery Service (FRS). This service is installed by the OTA updates and is designed to keep your recovery partition from getting corrupted. Of course to your carrier, if you install a custom recovery, that is corrupted because it's not the one they want you to have. Each time your phone boots, FRS will check your recovery partition, and if it is "corrupted" it will attempt to flash it back to stock.
The update.zip in this procedure installs su, Superuser.apk, busybox, and disables FRS so that it all stays that way after each boot.
Frequently Encountered Issues (FEI):
Here are some tripping points and questions that have come up for fellow Droid rooters. I present them in the order they were encountered in this topic. If you have a suggestion of something to add to this list, please PM me.
When reading the situations below, pay attention to the "setup" of the situation. If it specifically says "I'm having [insert problem here] running Windows XP" then that solution may not pertain to you if you're having the same problem on Windows 7. If the setup doesn't match yours, but you can't find anything better, you may want to give it a shot, but start with the ones that match your situation most closely first.
1. I don't have a Windows box, is there a method to do the SBF portion of the procedure on Linux?
Yes - you need to grab the sbf_flash binary and put it and the SBF file on your Linux box. Then follow the instructions on the page where you grabbed sbf_flash. Since there are no drivers, etc., the Linux method is actually easier than the Windows method. I did it on my Ubuntu 10.x laptop with no trouble at all.
2. I don't have a Windows box, is there a method to do the SBF portion of the procedure on Mac?
No. In theory you could compile sbf_linux for the Mac but the source code is not available. You're going to need at least temporary access to a Linux or Windows box to do this.
3. Everything finished without error but I don't see "busybox" in my applications list or anywhere.
Busybox is a command line binary that is used by rooted apps to perform certain Linux tasks. It doesn't have an APK component and as such isn't listed in the user interface anywhere. If you want to know for sure that you have busybox, open a Terminal Emulator on your phone (from Market), or "ADB shell" into your phone and run the command "busybox". If it's installed you'll get a list of all the commands it emulates. If not, you'll either get an error like "busybox: not found", or maybe "permission denied" (if you're not su because the command interpreter tries to search for the file in places only su can get to).
4. On Windows Vista or Windows 7, when I try to run RSD Lite as administrator, the option isn't available.
There are many different ways to do this. Of course you need to have administrator rights to begin with. See if post #48 helps.
5. I'm running Windows XP and RSD Lite doesn't see my phone at all.
Since Windows XP is the most reliable Windows version for this process, the reasons for this are usually limited to one of the below:
- You forgot to install the drivers. See item #3 of "things you're going to need" at the top. If you're having trouble, be sure you're running the exact version provided by the links (version 4.6.5). Newer might work, but if you're having trouble, try those exact drivers and reboot your PC after installing them (even though it doesn't tell you to).
- You're running old versions of the drivers (read the item immediately above).
- Your phone is not in bootloader mode. Lots of folks confuse bootloader mode and recovery mode. Read step #5 of the detailed procedure carefully. It even has a picture.
- Something is flaky with your USB port. It is generally reported that you need USB 2.0 for RSD Lite to be happy. I don't have any USB 1.1 machines so I can't independently verify this. If #1-#3 don't fix you, try moving the phone to a different USB port. If your computer has ports in the front and back, move to the other set. Some laptops have one set on the side and another on the back, or some on the left and some on the right. It may take a minute for the phone to pop into the list in RSD Lite after you connect it, so give it a little time to recognize after you plug it in. If this doesn't fix you I'm afraid you'll have to try another PC.
6. I'm using Windows 7 and my phone shows up, and I can select the SBF file, but the "Start" button is grayed out.
This is a bizarre issue that is specific to Windows 7. I can't reproduce it here, but it has come up enough that it is a legit thing. Some folks have success with certain things while for others those things don't fix it, but something else does. If you try each of the items below, one should work for you.
- Try checking the "open as read only" box when you are selecting the SBF file.
- Make sure you installed the RSD Lite 4.6 that is linked to in "things you're going to need". If you're using a newer version (like 4.7) or if you're using 4.6 that you got from someplace else, and it's working, fine, but if it's not working, uninstall it and install that exact one that I've linked to. Poster "fetchman" reported in post #255 that he had this exact problem, and while the tricks in the next items below would work around it, removing RSD Lite and reinstalling the one I've linked here actually fixed it. That said, another poster says he did replace it with the exact version linked to and it still didn't fix it.
- Move the SBF file to the root of your C: drive (i.e. C:\). See if RSD Lite will enable the Start button after choosing the file when it resides here.
- Rename the SBF file to just "MC1.SBF".
- If none of those worked you can try the suggestion in post #275.
- If that didn't work you can try the suggestion in post #317 - Failed Flashing process. (0x7100).
So far doing one or more (or all) of the above has fixed or worked around this problem for everyone who has experienced it. Maybe someone who has the problem can spend some time and figure out why it happens. Jbwiden reported that simply renaming the file to have a space before the ".sbf" and then renaming it again to take the space out fixed it. Perhaps something odd is happening to the file name when the file is initially saved on a Windows 7 box (and renaming it to anything -- not just a shorter name) fixes it. I can't reproduce it so I'll have to leave it to someone who can to figure out.
7. The Linux sbf_flash tool doesn't work on my 64-bit Ubuntu box. It gives "error 16" twice and fails to detect the phone.
Poster nxmheta suggests that you:
- Make sure you're running sbf_flash using sudo
- Ensure your phone is at the bootloader (not recovery or anyplace else)
- If those fail, then perhaps this command will install the library you're missing and fix the issue: sudo apt-get install ia32-libs
8. The SBF install goes fine, but when I go to apply the update.zip file in SPRecovery I get this error:
E:No tar archives foundGo back and re-read step #14-#16 of the detailed procedure. You chose "Choose ROM from SD card" which is not the right option.
9. The SBF install goes fine, but when I go to apply the update.zip file in SPRecovery I get an error that it can't mount /sdcard (I can't reproduce -- need exact error message).
- In SPRecovery, go into "mount options" from the main menu.
- Ensure you see "Mount /sdcard". If you see "Umount /sdcard", your SD card is mounted -- choose "Umount /sdcard" to unmount it.
- Ensure you see "Enable USB Mass Storage". If you see "Disable USB Mass Storage" your mass storage is enabled, choose "Disable USB Mass Storage" to disable it.
Then try to install the update.zip again.
10. The SBF install goes fine, but when I go to apply the update.zip file in SPRecovery I get this error:
E:Can't open /sdcard/update.zipYour update.zip file is not on your SD card or is named wrong. Read step #3 of the detailed procedure carefully. You've probably named the file update.zip.zip because Windows is configured to hide your file extensions.
(No such file or directory)
For whatever reason some folks really struggle with this (I don't know why). If this is you, you could either try reconfiguring Windows not to hide file extensions (which I recommend), or you could use ADB to transfer your files (brief instructions here, use Google if that's not enough).
11. The SBF install goes fine, but when I go to apply the update.zip file in SPRecovery I get this error:
E:update.zip install blockedYou failed to perform step #15 of the detailed procedure.
12. The SBF install goes fine, but when I go to apply the update.zip file in SPRecovery I get this error:
E:signature verification failedYou have stock recovery. Either you didn't do the RSD Lite part, or you did but you let the phone reboot all the way into the OS before doing the update.zip (and FRS reverted your recovery back to stock). You have to start back over at step #4 of the detailed procedure.
13. When using RSD Lite to flash the SBF file I get this error in RSD Lite:
Failed Flashing Process; Did not re-enumerate after RAM-loader was sent...0x703EThis is almost always an issue with your USB port. Try what's mentioned in step #4 of FEI item #5 above. If none of that works you probably can't use RSD Lite on that computer.
14. I'm trying to copy the update.zip to the phone using ADB and getting this error:
'ADB' is not recognized as an internal or external command, operable program or batch file.See post #238.
15. With my phone plugged into my USB port, Windows is searching for a driver for "SE Flash OMAP3430 MI".
You forgot to install the drivers first. While there is no actual "step" number for installing them, they are item #3 in "things you're going to need" and it says this right after that section:
16. After doing this everything is great, I have root, etc., but when I try to run the app "shootme" it complains about not having root.
If you do not already have RSD Lite installed on your workstation, install it and the drivers now.
That is an issue that has been reported to the developer of the current version of Superuser. It has been out there for awhile with no updates. You might want to pop on his topic and ask him about it. He may be waiting for someone willing to work with him and give him logs and/or try test fixes for him.
17. If you are getting "Failed Flashing Process (0x7100)"
Visit this link: http://androidforums.com/droid-all-t...ml#post1274587
Frequently Asked Questions (FAQ):
1. I'm unsure if this procedure will work to root [insert build here] (e.g. FRG01B, FRG22, FRG22D, etc.).
Yes, it will work as long as the phone is a Droid 1.
2. I've read all this and it is making my eyes and brain hurt and I just want to use Easy Root or Universal Androot. Why shouldn't I?
Well, first because as of this moment they don't work on FRG22D (or else you probably wouldn't be here). Also, read post #155.
3. After doing this, won't the next OTA just wipe it all out?
No. SPRecovery will not auto-install an OTA the way the stock recovery does. If you get notified of an OTA while you are using SPRecovery, you can "accept" the OTA. The phone will boot into SPRecovery and SPRecovery will block the update. When you boot out of SPRecovery the update file will be deleted. Your carrier may attempt to push it to you again, but it will never succeed so long as you have SPRecovery.
4. Is it OK for me to put a link to this topic in my signature?
Absolutely, please do.
5. I'd like to make a custom SBF, can you tell me how you did it?
I can, but I won't. This was discussed briefly in the topic, but I'll summarize and expound just a bit here. The Droid 1 is generally regarded as unbrickable. Strictly speaking that is not true. There is one way to brick a Droid 1 (as in "useless as a brick forever", not in the "presently messed up" sense that some folks wrongly use the term) and that is to corrupt the bootloader. Generally this is a very difficult (nearly impossible) thing to do, unless you're flashing an SBF. An SBF can update pretty much anything in the phone including the bootloader. An improperly (or maliciously) made SBF can destroy your phone. Learning how to make SBF files is not impossible but to make significant changes it is somewhat difficult and requires you to already have a good bit of other knowledge. As long as learning how to make SBF's is somewhat difficult, only those who really know what they are doing are likely to attempt it, much less succeed, and the Droid 1 world will probably be a safer place for it. By way of example, if this incident had involved a malicious SBF instead of a malicious update.zip, it could have been much much worse.
6. What does it mean to "boot into the OS" on a Droid?
"OS" is an acronym for "Operating System". When we say "boot the OS" we simply mean to power the phone on and let it boot up like normal (instead of forcing it into the bootloader or to boot into recovery).
7. I'd like to contribute to support your work and/or show appreciation, how can I?
I don't expect this at all -- I do this work because for some odd reason I find it rewarding (I think maybe it's a tumor or something). That said, I know that when I get an immense benefit from something someone has done, I feel better if I can do something to show my appreciation. For example, I run ChevyNo1's kernel and when I made a suggestion on how to fix a problem his kernel was having with security options on wireless tethering, he implemented it right away and put new kernels out there. I Googled and found an old donate page for him and donated to him because it made me feel good to do so. If you're technically savvy and want to help out, you can support me by helping to support this topic (and any other topics for any other tools I release). By helping support newbies that alleviates some of my burden in doing so, thus giving me the gift of time, which I like a lot. If you just absolutely want to make a monetary donation, you can PM me and I'll tell you how (again, I don't expect it but if that's what you want to do, obviously it is appreciated -- I spend money buying test phones and such to support my work, so I'll do something useful with your donation for sure ).
8. How can I tell if my phone is rooted? [Either after doing the procedure above and not noticing anything different, or before doing it and wondering if it's already rooted.]
If you're asking this question there is a chance that you may not know what root on your phone is. If that's true, after reading this answer, jump up the page a bit and read the "A little about what you're doing and why" section". First, "rooting" your phone just means that you have the ability to run as "super user" (or "root") which generally has no restrictions on what it can do and access. By itself it doesn't provide any new features or gadgets -- your phone looks pretty much the same as it did before rooting, except for the new "Superuser" app in your launcher (which manages the table of apps that are allowed to use super user authority). Some people (mistakenly) believe that if they see the Superuser icon in their launcher, they are rooted. This is not correct. As described in more detail in the "A little about what you're doing and why" section, root is comprised of two binaries, "su", and "Superuser.apk". Even having those two binaries however is insufficient. The "su" binary also must be set to a mode of 6755 in order to confer root. When you apply an OTA, doesn't (to date) delete su or Superuser.apk, but it does reset the permissions on everything in the /system/bin folder (including "su") and when it does, the mode of su is changed to 0755 instead of 6755. If you read up on Linux permissions you'll see that is a critical difference. That first number (which we want to be "6") is what sets the suid, sgid, and sticky bits of the mode. The suid bit is the one we care about as that is the one that makes su run as root (assuming it was created by root). When the permissions get reset to 0755 then the suid bit is off, and su is run with your normal permissions - no root. So, that's why an OTA makes you "lose root" even though su and Superuser.apk are still there. It's also why certain programs will dumbly tell you "you're already rooted" when in fact you are not. They only see that su and Superuser.apk are there, but don't check the permissions of su to see that it is useless with no suid bit set in the mode. To fix this is pretty simple actually. You don't need to reinstall su, etc. Just boot up your custom recovery, do "ADB shell chmod 6755 /system/bin/su" (assuming you have ADB installed on your machine (Google it) and your root should be fixed.
OK, I got somewhat far afield there. The question was "how can I tell if my phone is rooted". So, as you can see, it's not as simple as making sure you have a Ninja or a Droid pirate skull and crossbones in your launcher. That said, here are ways to positively tell (starting with easier ways first):
- Install an application like Titanium Backup (Market) that requires root and will complain if it doesn't find it present. Installing Titanium Backup is a good idea for all rooted users anyway (it is the backup I use) so why not go ahead and do it and then you'll know if your su is working.
- Install "Terminal Emulator" (Market), open a terminal session, and type "su" and press [Enter]. If your Superuser.apk pops up and asks you to give Terminal Emulator permission to run as root, you're rooted. If your "$" prompt (in the emulator) just silently changes to a "#" then you're rooted and have previously approved Terminal Emulator to run as root.
- "ADB shell" into your phone. Unless your phone is booted to a custom recovery at the moment, your prompt should be a "$". Type "su" and press [Enter]. If your Superuser.apk pops up and asks you to give "unknown" permission to run as root, you're rooted. If your "$" prompt (in the ADB shell) just silently changes to a "#" then you're rooted and have previously approved "unknown" to run as root.
- Manually verify that su is in /system/bin or /system/xbin and has a mode of 6755 and that Superuser.apk is in /system/app or /data/app (if Superuser was installed from the Market).
9. My Superuser application icon looks like it's an old version. How do I get the one that's a Ninja?
Actually, the Ninja icon is the older Superuser and the current Superuser is the Droid pirate skull and crossbones. Here are the various Superuser icon presentations that I am aware of. The first (Ninja) is for versions prior to 2.3 (up through 2.2.x.x). The second (Droid pirate skull and crossbones) is for the various 2.3.x.x versions (prior to 2.4.x.x). The third (same icon, just a different title) is the current presentation as of this writing (2.4 and later).
[Ignore the names of the image files -- that just tells what version I captured the image from, not necessarily when that image was first used.]