Coupla comments.
First, if this works, the immediate benefit will go to the devs: they will be able to unpack the contents of the Verizon .zip file and use them to release ROMs incorporating the latest and greatest (or bug fixes) from HTC/Big Red. After that happens, of course, the benefit will go the wider community - mostly folks who have already rooted, or who hold off installing the OTA in order to root
and then get the benefit of the bugfixes/enhancements in the OTA software in a few days time.
What it will not do, though, is let non-rooters get the OTA update quicker. Why? Because the OTA delivers the .zip file into the /cache directory on the phone... and you need to have root privilege to do that. Sure, non-rooters can assemble the URL, and download the .zip file from Google's servers... but if they are not root, there's no way for them to stuff it into the right place on the phone or twiddle a couple of magic bits that make the phone recognize that it's there when the phone reboots. So, they will still need to wait around to get the OTA. If you are planning on staying "factory", and just want to help out, then: Thank you, your assistance is appreciated! But if you are helping because you think it will help others get the OTA a few days earlier - you're barking up the wrong tree.
Second, the savvy devs can certainly do this as well - they just need to roll their phones back to 1.5, get the OTA download, boot into recovery, and re-flash one of their saved ROMs to overwrite the OTA. So, eventually, folks with the right skills will get this job done. Having more people attempting it will get it done earlier, though; so please help out if you are inclined.
Third, it appears that some folks who are trying to set this up on the SDK computer are not too familiar with the command line, whether that is on a PC, Mac, or Linux. To those folks: thank you for your generousity. Setting up the SDK is a bit time consuming, and if you don't have a lot of experience doing this sort of thing, it can be confusing, and easy to mis-interpret what you are seeing - which results in it not working and frustration.
There are a couple of common mis-steps that I see in some of the posts above; if you are having trouble getting things going, check these things first. I'll give an outline first, and then more detail after the outline. [
Note: experienced users will already know all this stuff - this is for folks having troubles. ]
1) Connectivity to the phone; do you have it?
2) PATH setup issues.
3) Not understanding what ">" does on the command line.
OK, here goes
1) Connectivity issues.
If you are connected to the phone with the USB cable, and you have successfully installed the SDK and the device driver, and have enabled USB debugging on the phone, you should be able to check to see if you are successfully connected to the phone by typing the command:
adb devices
at the command line prompt. (And of course, hitting the enter key after you've typed it in
).
If things are not set up correctly, you might see the adb command report strange messages like "waiting on the phone", et cetera.
If everything is set up correctly, the above command should display your phone's identifier, which starts with "HT", and is composed of upper-case letters and digits (mine is 12 characters long, and starts with "HT9A"). Get this working before you experiment with "adb logcat".
If you can't get this working, the things to check are the
driver install, the toggle state of the USB debugging setting on your phone (Settings...Applications...Development...USB debugging). Probably it is also a good idea to turn on the "Stay awake" toggle in that same menu as well.
Note that if you run the "adb logcat" command without redirecting it's output to a file using the "> filename.txt" technique, you should see it displaying all sorts of things as you remain connected with the USB cable and fool with different apps on your phone. Seeing this happening should convince you that adb is communicating with the phone correctly before you begin accepting the OTA update. (Hit Control-C to stop the "adb" command when trying this.)
(2) PATH setup issues.
A couple of folks have reported that they installed the SDK, but got messages like "not found" (Unix/Mac) or "Command or Program Not Found" (Windows). This has nothing to do with the SDK - it's the way that command shells work in Unix (including Mac Terminal) and also in Windows "cmd" or "command" windows. There is a list of folders (directories) that are searched every time you enter a command - if the folder containing the SDK command "adb" (on Windows, it will be "adb.exe") is not in that list, then you'll get something similar to the above error message: "command not found".
You can fix this up by following the instructions in Step #2 of the
Android SDK Install Instructions
Alternatively, if the current directory is in your PATH, (symbolically represented by the component "."), instead of fixing up your PATH environment variable, you can just "CD" to the tools folder of the SDK and run the adb command.
3) Not understanding what ">" does on the command line.
One or two folks said something like "it just sits there", or "the command wasn't found, but it produced the file logcat_accept.txt anyway"
What is going on is that the ">" character on the command line you entered causes any output from the adb program to be captured onto a file, rather than being displayed on your screen.
Normally, the "adb logcat" command will just continue to run forever unless you kill it (Control-C), or if the PC loses connection to the phone (for instance, if the phone reboots to start the OTA install, or if you yanked the USB cable out). So, yeah: if you run
adb logcat > logcat_accept.txt
and you "don't see anything happening" - that's normal! Believe me, there is lots of output piling up inside that file... and "adb logcat" will not stop running until you interrupt it (Control-C), or the phone reboots.
As for the person that wrote (paraphrased) "the SDK didn't install correctly, but I got a file anyway, I'll just point out that you could type anything as a command, such as
there_is_no_such_command > logcat_accept.txt
and it will produce a zero-length file in the current directory.
Finally, note that there is nothing special about the file name "logcat_accept.txt" - you can name it anything you want, but it is a good idea to use a .txt extension so that it will be recognized by your OS as a "plain text" file.
Hope this helps someone
eu1
