I went to go update mine and my girl's ROMs yesterday. Did mine with Tazz's new 2.0, and I'm loving it. I went to do hers as well and when I get into the main menu the trackball doesn't scroll up or down. It works fine when the phone is in operating mode. She is running CELBfroyo. Any suggestions? I cannot scroll around to do a wipe and flash a new rom...
I went to go update mine and my girl's ROMs yesterday. Did mine with Tazz's new 2.0, and I'm loving it. I went to do hers as well and when I get into the main menu the trackball doesn't scroll up or down. It works fine when the phone is in operating mode. She is running CELBfroyo. Any suggestions? I cannot scroll around to do a wipe and flash a new rom...
You could try cleaning the trackball with an alcohol wipe (that might work). Some also think that the trackball malfunctions due to its proximity to the USB connector at the bottom of the phone. Some users have tried to (very) gently get their trackball to move via the USB port/cable being plugged-in (although I would caution you against further damaging your USB port).
Most users end-up returning their phone to VZW for a refurb, although in the case of the user in the above post, it appears that they gave that user refurb with a wonky trackball). There is also the option of trying the ClockworkMod custom recovery since it does not use the trackball to navigate. See the above post for my further suggestions regarding this.
Good luck and bummer, dude!
The Following User Says Thank You to scary alien For This Useful Post:
Thanks guys, all great suggestions, just what I was looking for. She has the phone today so I will try when she gets home. The trackball works fine when using the phone and has worked fine before I rooted and since I rooted I have flashed maybe 3 Roms on her phone and it worked everytime. Just doesn't seem to wanna work when I go into Amon
Thanks guys, all great suggestions, just what I was looking for. She has the phone today so I will try when she gets home. The trackball works fine when using the phone and has worked fine before I rooted and since I rooted I have flashed maybe 3 Roms on her phone and it worked everytime. Just doesn't seem to wanna work when I go into Amon
iheotp,
The other day, I actually looked at Amon_RA's custom recovery source code (with the intention of possibly modifying it to use the volume up/down toggle instead).
Anyway, the way the program handles / recognizes the trackball is by looking for position changes (delta) plus/minus some unit of 3 (apparently to its last relative position?). Its possible that Amon_RA's recovery is just not as sensitive as the regular Android trackball processing code and that you might have to move it more in the up/down direction to get it to recognize that a movement has occurred.
This is just a theory, but you might want to try it out.
Device(s): Eris rooted running Cyanogen Tazz V 1.0
No Overclocking, no autokiller.
Carrier: Not Provided
Thanks: 17
Thanked 6 Times in 6 Posts
my trackball will do this too. it'll work fine when the phone is booted up/normal use. but when in recovery (amons ra) it'll be stuck in one position or be very very lazy. sometimes have to wait a few seconds, and then it kicks in. i say when in recovery wait 20-30 seconds, let the phone catch up and then the trackball usually starts to work.
If the trackball was totally dead, it wouldn't work in normal phone use.
my trackball will do this too. it'll work fine when the phone is booted up/normal use. but when in recovery (amons ra) it'll be stuck in one position or be very very lazy. sometimes have to wait a few seconds, and then it kicks in. i say when in recovery wait 20-30 seconds, let the phone catch up and then the trackball usually starts to work.
If the trackball was totally dead, it wouldn't work in normal phone use.
I don't have the code pulled-up here, but the section it was in made it seem like its not a binary operation...it has to "arrive" at a certain delta of movement to "see" the change. So, perhaps being a little patient and scrolling the trackball a little more than normal will allow those with trackball issues to actually use this in recovery...
I have tried cleaning the ball and no dice. It simply won't scroll in recovery mode. It works fine when the phone is on. And I can press it in to choose "reboot now" in recovery mode but it will not scroll, so frustrating. Is there a way for me to just re root the phone or something?
I have tried cleaning the ball and no dice. It simply won't scroll in recovery mode. It works fine when the phone is on. And I can press it in to choose "reboot now" in recovery mode but it will not scroll, so frustrating. Is there a way for me to just re root the phone or something?
iheotp:
You are not the first person to experience this - a trackball which will not work in Amon_RA (for up/down motion), but is otherwise fine in the regular OS.
Apparently there is something about the kernel in the Amon_RA recovery which is different enough that it doesn't work on some trackballs. It doesn't happen very often - you are one of the unlucky ones.
There is a way to force a ROM onto a phone like this - by using the adb command line from the PC with Amon_RA running.
It's a little complicated, and requires that you get your PC drivers set up so that you can use ADB on the PC to communicate with the phone over USB.
Charge the phone, connect USB cable to PC, boot to Amon_RA, and then start up an adb shell on the phone:
Where "romname.zip" is the actual name of your ROM file in the top-level folder of the SD card (No spaces or weird characters in the name of the file, please).
Note that that both /sbin/recovery commands will "hang" when they finish, rather than return to the command prompt. You can kill them safely by hitting Ctrl-C. Note that this will kick you out of your adb session, so you will need to start another adb session from the PC. (That is, "adb shell"). No need to repeat anything, just continue to the next command in the sequence.
But there is a small problem here - how do you know when they are finished running so you can safely hit the Ctrl-C key combination?
The easiest way to do this is to first wait until you see no further changes to the display on the Eris, then wait 2 minutes more, and then open up another command window on the PC, and run the command:
Code:
adb shell tail /cache/recovery/log
If (each instance of) the /sbin/recovery program has completed you will see that the last line in the log file (above) will say:
I:Installation complete.
That's one way. I'll admit that it probably very intimidating to someone that is new to this - but it is possible to use Amon_RA without a working trackball to:
- Do a Nandroid backup
- Wipe data/factory reset
- Flash a ROM from a zip file on the SD card.
__________________
Please don't send me PMs - post your questions so others may benefit from any answers given.
The Following 3 Users Say Thank You to erisuser1 For This Useful Post:
thanks erisuser1. I tried the usb thing and it didn't work. I will try doing the adb shell process tonight. IT does seem a little intimidating. Although first rooting my phone was intimidating as well and it went smoothly. Thanks for all your help
Hey Erisuser1. I followed your instructions and I can get the phone wiped but it is not installing the ROM. On the command screen it says /#/ sbin/recovery--wipe_data. Then nothing happens. The phone says Formatting Data...
Formatting CACHE...
And that's it. I waited for something to happen but it doesn't get past this point
Hey Erisuser1. I followed your instructions and I can get the phone wiped but it is not installing the ROM. On the command screen it says /#/ sbin/recovery--wipe_data. Then nothing happens. The phone says Formatting Data...
Formatting CACHE...
And that's it. I waited for something to happen but it doesn't get past this point
iheotp,
It sounds like you are at the point that eu1 indicated you might have to hit control-C since he indicated that the /sbin/recovery commands will "hang" when they finish.
Does this match what you are seeing? Carefully re-read his instructions...
----------------------------------------------
Note: I decided to try this stuff too ...so I've done the Nandroid backup (first command he listed) and then the "--wipe_data" command...the command did/does hang...I waited about two minutes per eu1's instructions...and then hit control-C and did the "adb shell tail /cache/recovery/log", but I don't see "I:Installation complete." in the log. Instead, I see:
Anyway, re-read his instructions carefully (you are probably safe and ready to hit control-C and do your update command as eu1 indicated (you'll have to do another "adb shell", right?)).
Also, feel free to wait until eu1 responds...(I probably would have )
This is pretty cool and is a nice option to have for those that can't use their trackball. Thanks again, eu1!
I only get the first /sbin/recovery to hang...so the second one which is what flashes the rom is not working. I am trying to flash Cyanogen Tazz-ou812.zip. I waited a good hour to see if it was loading and nothing. I did the adb shell tail /cache/recovery/log and this is what I get..
mtd:not erasing bad block at 0x03ec0000
mtd:not erasing bad block at 0x03fa0000
mtd:not erasing bad block at 0x060e0000
mtd:not erasing bad block at 0x06960000
mtd:not erasing bad block at 0x06d20000
Formatting CACHE....
mtd:not erasing bad block at 0x02840000
mtd:not erasing bad block at 0x02e40000
mtd:not erasing bad block at 0x031a0000
Fixing execute permissions for /cache
I only get the first /sbin/recovery to hang...so the second one which is what flashes the rom is not working. I am trying to flash Cyanogen Tazz-ou812.zip. I waited a good hour to see if it was loading and nothing. I did the adb shell tail /cache/recovery/log and this is what I get..
mtd:not erasing bad block at 0x03ec0000
mtd:not erasing bad block at 0x03fa0000
mtd:not erasing bad block at 0x060e0000
mtd:not erasing bad block at 0x06960000
mtd:not erasing bad block at 0x06d20000
Formatting CACHE....
mtd:not erasing bad block at 0x02840000
mtd:not erasing bad block at 0x02e40000
mtd:not erasing bad block at 0x031a0000
Fixing execute permissions for /cache
Yeah...let's wait on eu1...
I only did the Nandroid backup and the wipe--didn't flash a ROM since I got the gist of what was going on...
Not sure what those errors are all about (hopefully, not /sdcard issues)...tell you what...I'll try downloading and flashing Tazz (but I'm pretty sure we're supposed to wipe Dalvik-cache too for Froyo ROMs).
I'll get back with you and let you know how it goes (and what I see too)...hopefully, eu1 will respond before then.
I was doing all 3 codes at once so i did it individually and it worked better but still no dice. But now when I go to flash the rom, on my phone it says Installation aborted. no such file or directory. So I must be doing something wrong with the file name or something
I was doing all 3 codes at once so i did it individually and it worked better but still no dice. But now when I go to flash the rom, on my phone it says Installation aborted. no such file or directory. So I must be doing something wrong with the file name or something
Yeah, you gotta do each command separately .
Is your "Cyanogen_Tazz-_ou812.zip" file in the top-level directory of the /sdcard (i.e., its full file path should be "/sdcard/Cyanogen_Tazz-_ou812.zip")? Also, this is the filename that you will pass in the "upate_package" command, like this:
Also, the wipe commands don't take too much time (but allow for the 2+2 minute interval like eu1 suggested). The update will certainly take longer than the wipes, but probably within the 4 minutes (but check the /cache/recovery/log just to be sure).
Sounds like you are pretty close...also, I'm not 100% sure this is needed, but I'm going to also do a "/sbin/recovery --wipe_cache" to wipe my Dalvik-cache (my ROM is still downloading...so, I'm not quite there yet).
But now when I go to flash the rom, on my phone it says Installation aborted. no such file or directory. So I must be doing something wrong with the file name or something
Yes, it is a good idea to pay attention to the error messages - you can usually believe them.
The instructions that I provided can be cut-n-pasted, one line at a time, as is, with the exception of the text shown in green - the file name. Make sure you get it correct.
If it helps, (many people don't know this) there is a "paste" function available with the Windows "Command Window" - after you have copied text in your browser, right-click on the top "bar" of the Command window and choose Edit -> Paste.
It sounds like you are on the right track. I think if you re-read my original instructions very carefully, you will notice that I mentioned everything that you subsequently "discovered".
Note that if you have subsequently rebooted your phone after your last attempt, you do need to re-perform the "/sbin/recovery --wipe_data" step immediately before doing the flashing step. (The Dalvik wipe step is superfluous because the /sbin/recovery --wipe_data" step wipes everything in /data - including the Dalvik cache).
eu1
The Following User Says Thank You to erisuser1 For This Useful Post:
It's slightly off topic, but last night I unpacked Amon_RA's recovery, and fooled around to see if I could remap the key functions (using init.rc) to come up with a modded version of Amon_RA v1.6.2 that wouldn't need the trackball for scrolling.
Long story** short, no joy. I think the "setprop" method of key mapping probably only applies to the way that Dalvik apps see the keyboard. It's a dead end to me unless Amon_RA publishes his code someplace. It might be online and I didn't look for it long enough. (Koush publishes his recovery online @ github iirc).
eu1
** it had a useful side effect though - somehow I managed to lose my copy of mkbootimg (Ubuntu) during my last machine transition, and I couldn't figure out where I previously had found it on XDA... so I was forced to set up an Ubuntu VM and build the entire Froyo tree to get the toolchain components.
It's slightly off topic, but last night I unpacked Amon_RA's recovery, and fooled around to see if I could remap the key functions (using init.rc) to come up with a modded version of Amon_RA v1.6.2 that wouldn't need the trackball for scrolling.
Long story** short, no joy. I think the "setprop" method of key mapping probably only applies to the way that Dalvik apps see the keyboard. It's a dead end to me unless Amon_RA publishes his code someplace. It might be online and I didn't look for it long enough. (Koush publishes his recovery online @ github iirc).
eu1
** it had a useful side effect though - somehow I managed to lose my copy of mkbootimg (Ubuntu) during my last machine transition, and I couldn't figure out where I previously had found it on XDA... so I was forced to set up an Ubuntu VM and build the entire Froyo tree to get the toolchain components.
I searched and found the original thread on XDA that you were speaking of (I believe this is the one you meant: Need your help to get a custom recover img - xda-developers). I didn't understand it all, lol, but I downloaded the "Keycode Checker.apk" and ran it on the Eris just like GrdLock did and obviously got the same results.
If I knew how to compile the source, I do think we could use the "BACK" button (4-158-0) and the "CALL (green)" button (5-231-0) instead of the trackball (DPAD_UP or DPAD_DOWN) to navigate in Amon_RA's recovery (although exactly how the change should be made is still unclear to me...).
It would be cool to make an alternate trackball-less recovery for Eris, but your "adb" method worked wonderfully!
Alternate idea: is there a way to use your remap/init.rc method to disable the kernel's use of the trackball, at least while Amon_RA's recovery is running? If the users that report that their trackball works fine under "regular" Android but not under recovery, could it simply be a conflict of sorts? (i.e., can we give custom recovery full ownership of the trackball and possibly make it fully functional?).
Alternate idea: is there a way to use your remap/init.rc method to disable the kernel's use of the trackball, at least while Amon_RA's recovery is running? If the users that report that their trackball works fine under "regular" Android but not under recovery, could it simply be a conflict of sorts? (i.e., can we give custom recovery full ownership of the trackball and possibly make it fully functional?).
Just a thought...
Based on last night's experiments, I would guess no.
No way to know for sure unless we had the code, and if we had the code, we would just simply change it and recompile it so it would use other buttons (keycodes).
Frankly, there are about 10 different ways you can get all of this done - for instance, the OP had two phones, right? So, how about this:
- Wipe and Flash ROM of any choosing onto Eris #1
- Make a nandroid backup of this after flashing the ROM, but before booting it
- Transfer that nandroid backup to second phone's /sdcard/nandroid/HT****/ folder, and restore it using the command line
No way to know for sure unless we had the code, and if we had the code, we would just simply change it and recompile it so it would use other buttons (keycodes).
Can you point me in the direction of where to learn how to compile this (packetlss's Profile - GitHub) -- I know how to compile simple C-code, I'm just assuming that I can't just do it in Eclipse and that I'd probably have to have Ubuntu (I've got a 9.04 on a flash-drive and I could burn 10.04.1 onto a CD) with a gcc compiler (which I'm betting is standard on it). I've just never compiled a whole "tree" of code like this... Is there a "kitchen" that I need and is there a special way to prepare the .img file once its compiled for writing to the recovery partition?
I also ran the jarsigner -verify command on a ROM w/verbose mode and looked at the output. At first, it looked like it simply unzips each file in the .zip and then calculates an SHA1 digest on each file and then compares it to the manifest.
However, when I unpack the ROM manually and calculate the SHA1 checksum on a given file, I get a different value than what is published in the MANIFEST.MF for that file (and there's even a different value in the CERT.SF file). Needless to say, I'm a little confused...
More digging will resume this weekend...
Last edited by scary alien; September 2nd, 2010 at 10:27 PM.
Can you point me in the direction of where to learn how to compile this (packetlss's Profile - GitHub) -- I know how to compile simple C-code, I'm just assuming that I can't just do it in Eclipse and that I'd probably have to have Ubuntu (I've got a 9.04 on a flash-drive and I could burn 10.04.1 onto a CD) with a gcc compiler (which I'm betting is standard on it). I've just never compiled a whole "tree" of code like this...
Thank you for finding that! (sources)
Eclipse is a generic code-development IDE, but the Android plugin for it revolves around developer support for Java/Dalvik app development, not native code (ARM executables, kernels, native libs and so forth). So, you won't use Eclipse to build kernels or the Android OS tree - you'll be using conventional Unix development tools - primarily "make". (The hard part about using "make" at the top of a source tree is not typing in the command "make" - it's getting your environment set up correctly so that the build will proceed correctly).
I can only tell you part of the truth - the part that I know. It appears (from what is online at developer.android.com) that Google engineers are probably using Ubuntu 8.0.4 LTS for their development work. (I would avoid at all costs trying to set up a build environment with Cygwin. It's OK to have on your Windows PC, but don't try and build Android with it)
You can use a VM for Ubuntu, but beware - the complete source and build trees for Android are pretty large. I built the AOSP Froyo tree last night, and the git/repo databases + sources + build objects for the full Froyo tree take about 7 Gb of disk space. So, I wouldn't bother using a pre-built VM (e.g. VMware Player machine w/Ubuntu), as a lot of times they are limited to small virtual disk sizes.
(The reason that the builds are so large is that everything gets built - the emulator, the cross-compilers, all the external tools (fastboot, mkbootimg, ddms, etc) in addition to all the libraries, kernel, utilities, etc.)
You could use VirtualBox from Oracle (free) and build a Ubuntu 8.0.4LTS VM from scratch - I would configure it to use an expandable hard drive with a maximum size no smaller than 30 GB. But I'll tell you - that is only the beginning of your learning. If you pull down the packetlss sources, you will notice all the "Android.mk" files - the builds are structured in a way where they leverage the Google/Android build system - you need to integrate them into an Android build tree, and that means that some large fraction of the Android tree needs to be built first.
I spent some time about 6-8 months ago building standalone ARM executables (exploit codes), so I could point you at some instructions on how to build either static or dynamic standalone native (ARM) executables, (which turns out to be rather twisty in and of itself for static code), but so far I have only built entire Android Source trees, without trying to splice external Android project code into an Android build tree.
The thing is, to get a truly good grip on the build system for Android (the OS, not the Apps), you probably need to understand not only how the Android build tree is structured, but how to use "git" and "repo" in a fine-grained way, so that you can extract the correct revisions of code (and now there is yet another tool to be learned - "gerrit").
I'm getting close to understanding bits and pieces of it - I will give a shot at building the Amon_RA tree. (I tried a couple of things that I thought would be "obvious" tonight, but no go.)
Quote:
Originally Posted by scary alien
Is there a "kitchen" that I need and is there a special way to prepare the .img file once its compiled for writing to the recovery partition?
The android-dls.com URL you referenced below is an excellent guide. The one piece of information that it does not provide - which is critical - is the "base" or load address for the kernel, which seems to be different for every phone. For the Eris it is 0x11200000. Here's an excerpt from a script I wrote that shows the mkbootimg command line for an Eris image:
Note that Google took great pains to avoid licensing issues with Sun/Oracle - while App code is written in Java, they use their own bytecode compiler and interpreter (Dalvik) - they specifically avoided having to license Java from Sun. I am not sure whether their framework/foundation classes have any dependencies on Sun/Oracle classes. While there is no harm in using Sun/Oracle code for learning purposes, I would stick to the Android API standard, and if you can't find the functionality you need there, use the native libraries for signing/verification checks (IIRC, Android uses OpenSSL sources).
For instance, the very native code you are trying to build needs to have all that stuff in it, as it does the same verification process on the same types of files.
Quote:
Originally Posted by scary alien
I also ran the jarsigner -verify command on a ROM w/verbose mode and looked at the output. At first, it looked like it simply unzips each file in the .zip and then calculates an SHA1 digest on each file and then compares it to the manifest.
That's what the verification step does... plus one more thing: the signature file is a signature of the manifest, so the crypto sig of the manifest is checked. If it is OK, then you know the manifest has not been tampered with by anybody but the signer**, and since 100% of the files need to match the SHA1 hashes in the manifest, then you also know that none of the files have been corrupted since the signing took place.
(** Every XDA dev has a copy of the "private key" used to sign ROMs used by Amon_RA and Clockwork, so there is no guarantee of authenticity with dev ROMs - you can only be sure that your file isn't corrupted somehow)
Quote:
Originally Posted by scary alien
However, when I unpack the ROM manually and calculate the SHA1 checksum on a given file, I get a different value than what is published in the MANIFEST.MF for that file (and there's even a different value in the CERT.SF file). Needless to say, I'm a little confused...
Dunno. ??
good luck
The Following User Says Thank You to erisuser1 For This Useful Post:
Thank you for the very detailed response, I very much appreciate it. And, "wow".
I knew neither effort was going to be easy...I'm just trying to immerse myself so that I at least have an idea as to what things are and how they are related. I'll continue my education and research efforts re. both of these items (custom recovery tweak and ROM verifier via jarVerify).
Thank you again (and look for an update to my MD5 Sum app before the weekend is out ).
Thank you to Erisuser1 and Scary Alien. I couldn't have done this without you and feel so accomplished lol. Scary, my problem was that I wasn't using underscore in the command for CyanogenTazz. I read in the instructions "no spaces" and so I was just typing it in wrong. Once I did what you did, it worked perfectly. It is so nice to know that this can be done without the trackball. Again, thank you guys so much...I hope this helps others as well. Awesome work!
Thank you to Erisuser1 and Scary Alien. I couldn't have done this without you and feel so accomplished lol. Scary, my problem was that I wasn't using underscore in the command for CyanogenTazz. I read in the instructions "no spaces" and so I was just typing it in wrong. Once I did what you did, it worked perfectly. It is so nice to know that this can be done without the trackball. Again, thank you guys so much...I hope this helps others as well. Awesome work!
No problem...eu1 deserves all of the credit. At least we'll be able to direct folks with trackball problems to this thread to help them.
Yeah, I noticed when I downloaded the Tazz ROM and double-checked the MD5 sum on my PC, its filename had spaces in it. But when I downloaded it directly to my phone, the spaces were replaced with underscores (nice that its does that, but I can see how this would make things a little confusing).
Glad it worked for you...I've still got Tazz on my Eris at home from last night's fun...I'll have to play with it a bit now...
Don't forget to press the "Thanks" Buttons (Lower RH corner of our posts). Press as many of 'em as you want!
Quote:
Originally Posted by iheotp
I couldn't have done this without you and feel so accomplished lol.
You actually did something that is pretty intimidating for someone new to this - not only that, but it seems you figured out the ADB driver issues on the PC side of things without a single question about it. Props to you, too.
I'll see about getting a no-trackball version of Amon_RA (v1.6.2) for Eris built. No promises, but stay tuned.
eu1
The Following User Says Thank You to erisuser1 For This Useful Post:
Hello I am having the same problem with my trackball. It does not work in the recovery mode, but it works in the normal OS.
This is my first time rooting my phone, I followed unlockr's way of doing it. He (they) said that you need to use a custom rom to get root campabilty of apps, so here I am.
EU1, I am not very good with this technical lingo, so do you mind clarifying some things for me? Any help would be much appreciated.
Quote:
Originally Posted by erisuser1
iheotp:
Charge the phone, connect USB cable to PC, boot to Amon_RA, and then start up an adb shell on the phone:
Where "romname.zip" is the actual name of your ROM file in the top-level folder of the SD card (No spaces or weird characters in the name of the file, please).
Note that that both /sbin/recovery commands will "hang" when they finish, rather than return to the command prompt. You can kill them safely by hitting Ctrl-C. Note that this will kick you out of your adb session, so you will need to start another adb session from the PC. (That is, "adb shell"). No need to repeat anything, just continue to the next command in the sequence.
Now, I am a complete noob at this stuff, so sorry about these dumb questions....
"boot to Amon_RA, and then start up an adb shell on the phone:"
Does this mean go into cmd and type this?
Code:
cd\
cd c:\AndroidSDK\tools
adb shell
If so, this is what I get if I type
"/sbin/recovery --wipe_data" after I insert the above code I get -
Code:
# /sbin/recovery --wipe_data
/sbin/recovery --wipe_data
/sbin/recovery: not found
Sorry, I am a newb. :P
edit-
And this is what happens when I run the nandroid part.
Code:
c:\AndroidSDK\tools>adb shell
adb server is out of date. killing...
* daemon started successfully *
# nandroid-mobile.sh -b --norecovery --nocache --nomisc --nosplash1 --nosplash2
--defaultinput 1>&2
nandroid-mobile.sh -b --norecovery --nocache --nomisc --nosplash1 --nosplash2 --
defaultinput 1>&2
nandroid-mobile.sh: not found
Last edited by nooberisowner; September 6th, 2010 at 11:15 AM.
Hello I am having the same problem with my trackball. It does not work in the recovery mode, but it works in the normal OS.
This is my first time rooting my phone, I followed unlockr's way of doing it. He (they) said that you need to use a custom rom to get root campabilty of apps, so here I am.
EU1, I am not very good with this technical lingo, so do you mind clarifying some things for me? Any help would be much appreciated.
Now, I am a complete noob at this stuff, so sorry about these dumb questions....
"boot to Amon_RA, and then start up an adb shell on the phone:"
Does this mean go into cmd and type this?
Code:
cd\
cd c:\AndroidSDK\tools
adb shell
If so, this is what I get if I type
"/sbin/recovery --wipe_data" after I insert the above code I get -
Code:
# /sbin/recovery --wipe_data
/sbin/recovery --wipe_data
/sbin/recovery: not found
Sorry, I am a newb. :P
edit-
And this is what happens when I run the nandroid part.
Code:
c:\AndroidSDK\tools>adb shell
adb server is out of date. killing...
* daemon started successfully *
# nandroid-mobile.sh -b --norecovery --nocache --nomisc --nosplash1 --nosplash2
--defaultinput 1>&2
nandroid-mobile.sh -b --norecovery --nocache --nomisc --nosplash1 --nosplash2 --
defaultinput 1>&2
nandroid-mobile.sh: not found
Since you didn't provide me a link to what the "Unlockr" method is, why should I go looking for it? You expect me to be intimately familiar with it, somehow, or that I wouldn't mind just going and trying to find out what it is on my own?
If I had to guess, I would say that you applied the Root-ROM (PB00IMG.ZIP method). But, that is just a huge guess on my part. It could just be that you are running "adb shell" with the phone booted normally - that would explain your result as well.
You didn't say whether the Amon_RA recovery is even present on your phone - is it? What version? How did you install it?
Make sure you are booting into Amon_RA recovery BEFORE you do the "adb shell" thing.
You do that by powering up your phone with Vol-Up+Power (Or Vol-Down+Power, and choose Recovery from the Menu... or Send+End and choose HBOOT, and then choose Recovery).
You should see this on your screen before you start the adb shell:
eu1
Last edited by erisuser1; September 6th, 2010 at 08:53 PM.
As I said. I am new to this, so I thought Unlockr's way of rooting was the only way, but I guess not, since I have seen your post on a way of rooting done all on the droid.
So I've been through this whole post and am having similar issues. My trackball doesn't work going down, and none of the nifty tricks work. I have a 10 year old PC (that I'm trying to install the SDK on) and a Macbook which I have installed the SDK on. My phone is permanently stuck in an endless loop of the android-process-acore force closing and ultimately the whole phone crashing. I'm running a probably out of date version of Xtra Sense, and cannot navigate the Amon_RA menu. I've installed the kit, and followed an OSX conversion of eu1's instructions droid-eris[dot]com/tutorials-corner/how-to-flash-a-rom-with-amon-ra-and-a-broken-trackball/?wap2
And I literally fall apart at the simple command where it says to enable to adb shell simply enter "adb shell"
This returns: hislap-mb-c:~ dmacy$ adb shell
-bash: adb: command not found
Since this thread I think the SDK has changed and something about the adb being in a different directory or something...I'm really not familiar with command line interface systems and feel really out of my league, but if I can flash the phone it'll be fine. I figured I'd post here because this has been where the most help's been at. Perhaps someone can lend a hand to a newbie with no CLI experience (and perhaps I'm doing something wrong with the SDK)
I installed the SDK, and updated everything and installed everything that it said needed to be installed....when I opened it up I clicked on the "android" file to open up the GUI and so on....I just hit a dead stop when I get to trying to enable the adb shell....my phone is at the amon_ra menu and the phone is plugged into the computer...but it's not recognizing the command or something?
"Mini-SDK (contains adb and fastboot utilities for Windows, Mac, and Linux)"
It contains an easy to use sdk-tools.zip file that you can download and some notes and examples for using it.
That might get you past the issues you're currently having.
Let us know if that helps any .
Cheers!
By the way, on the off-chance that you have an S-OFF version of HBOOT, you'd be able to flash my trackball-optional version of Amon_RA very easily. So, if you know your HBOOT version and security, that would help us figure-out if there are other options open to you.
P.S. welcome to the AndroidForums--sorry its under these circumstances, but we're happy you signed-up nonetheless .
Last edited by scary alien; March 17th, 2012 at 09:46 PM.
Let me see if I can get the phone to stay operative long enough to find that out. How would I go about loading the different version of amon (It's been so long since I've done all this....my phone's been normal since I first rooted like a year and a half ago) Is this possible to do without the trackball, or will it still involve the sdk and adb shell. I'm gonna get on trying what you suggested and will report back if I hit another wall (which is likely! haha)
Thanks...that's good to know, but since you're S-ON, we can't use fastboot to help us here.
Let's try to get you working with adb so you can at least get a working version of Android.
Also, if you can get adb to communicate with the Amon_RA custom recovery that's running on your phone, we can push a copy of the flash_image utility and the alternate trackball recovery so we can try to flash that.
Lastly, there's this thread: Eris gets official booloader unlock support (*yawn*) which discusses some options for installing a new version of the bootloader (1.51) which might be of some help, but I think we'd want Scotty and eu1 to weigh-in on using that versus trying the other stuff we discussed above [we're not necessarily to the point of needing to use this 1.51 stuff at the moment, IMO].
I downloaded the zip, and double clicked on the adb-mac and it brings up a shell that runs through all the adb commands and whatnot, but it suddenly ends with a [PROCESS COMPLETE] And I can't interact with the shell? And when I tried doing the cd to point to the adb-mac file it says no such file
PHP Code:
-bash: cd: downloads/android-sdk/adb-mac: No such file or directory
hislap-mb-c:~ dmacy$ downloads/sdk-tools/adb-mac
Android Debug Bridge version 1.0.25
-d - directs command to the only connected USB device
returns an error if more than one USB device is present.
-e - directs command to the only running emulator.
returns an error if more than one emulator is running.
-s <serial number> - directs command to the USB device or emulator with
the given serial number. Overrides ANDROID_SERIAL
envivornment variable.
-p <product name or path> - simple product name like 'sooner', or
a relative/absolute path to a product
out directory like 'out/target/product/sooner'.
If -p is not specified, the ANDROID_PRODUCT_OUT
environment variable is used, which must
be an absolute path.
devices - list all connected devices
connect <host>:<port> - connect to a device via TCP/IP disconnect <host>:<port> - disconnect from a TCP/IP device
device commands:
adb push <local> <remote> - copy file/dir to device
adb pull <remote> <local> - copy file/dir from device
adb sync [ <directory> ] - copy host->device only if changed
(see 'adb help all')
adb shell - run remote shell interactively
adb shell <command> - run remote shell command
adb emu <command> - run emulator console command
adb logcat [ <filter-spec> ] - View device log
adb forward <local> <remote> - forward socket connections
forward specs are one of:
tcp:<port>
localabstract:<unix domain socket name>
localreserved:<unix domain socket name>
localfilesystem:<unix domain socket name>
dev:<character device name>
jdwp:<process pid> (remote only)
adb jdwp - list PIDs of processes hosting a JDWP transport
adb install [-l] [-r] <file> - push this package file to the device and install it
('-l' means forward-lock the app)
('-r' means reinstall the app, keeping its data)
adb uninstall [-k] <package> - remove this app package from the device
('-k' means keep the data and cache directories)
adb bugreport - return all information from the device
that should be included in a bug report.
adb help - show this help message
adb version - show version num
DATAOPTS:
(no option) - don't touch the data partition
-w - wipe the data partition
-d - flash the data partition
scripting:
adb wait-for-device - block until device is online
adb start-server - ensure that there is a server running
adb kill-server - kill the server if it is running
adb get-state - prints: offline | bootloader | device
adb get-serialno - prints: <serial-number>
adb status-window - continuously print device status for a specified device
adb remount - remounts the /system partition on the device read-write
adb reboot [bootloader|recovery] - reboots the device, optionally into the bootloader or recovery program
adb root - restarts the adbd daemon with root permissions
adb usb - restarts the adbd daemon listening on USB adb tcpip <port> - restarts the adbd daemon listening on TCP on the specified port
networking:
adb ppp <tty> [parameters] - Run PPP over USB.
Note: you should not automatically start a PPP connection.
<tty> refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1
[parameters] - Eg. defaultroute debug dump local notty usepeerdns
adb sync notes: adb sync [ <directory> ]
<localdir> can be interpreted in several ways:
- If <directory> is not specified, both /system and /data partitions will be updated.
- If it is "system" or "data", only the corresponding partition
is updated.
hislap-mb-c:~ dmacy$ -d
-bash: -d: command not found
hislap-mb-c:~ dmacy$ adb shell
-bash: adb: command not found
hislap-mb-c:~ dmacy$ -s
-bash: -s: command not found
hislap-mb-c:~ dmacy$ adb help
-bash: adb: command not found
hislap-mb-c:~ dmacy$
For a Mac, you'll need to start-up a Terminal session.
Then, you'll need to change to the directory/folder name ("cd <foldername>") where you downloaded the adb utilities.
Finally, when you are ready to execute a command, you'll want to prefix the adb invocation with "./".
For example:
-- Let's say you downloaded and extracted the adb utilities (i.e., from the sdk-tools.zip file) to /home/test, you would then:
- start up a Terminal session
- type cd /home/test (to change to the directory/folder where your adb-mac utility lives)
- type ./adb-mac devices (to verify you have adb connectivity)
From the first part of you session capture above, it looks like you did indeed have adb working from your "downloads/sdk-tools" folder, so you could try getting back to there and doing the "./adb-mac devices" command, for example.
Just try it again, make sure you are in the folder that contains the adb-mac utility. Also, be sure to execute adb with "./adb-mac" (without the quotes, of course).
hislap-mb-c:sdk-tools dmacy$ ./adb shell
-bash: ./adb: No such file or directory
hislap-mb-c:sdk-tools dmacy$ ./adb-mac devices
adb server is out of date. killing...
cannot bind 'tcp:5037'
ADB server didn't ACK
* failed to start daemon *
error:
hislap-mb-c:sdk-tools dmacy$
hislap-mb-c:sdk-tools dmacy$ ./adb shell
-bash: ./adb: No such file or directory
hislap-mb-c:sdk-tools dmacy$ ./adb-mac devices
adb server is out of date. killing...
cannot bind 'tcp:5037'
ADB server didn't ACK
* failed to start daemon *
error:
hislap-mb-c:sdk-tools dmacy$
Yep, it does seem like you are making progress with your last command.
I've not seen that particular error before, but I'm thinking it might be due to a security / permission error for the adb daemon on your Mac (I've seen this on my Linux laptop before). A quick Google search of that error indicates its because there's something already using port 5037 on your Mac.
Let's try killing the adb daemon just to be sure (perhaps there was an orphan one still hanging-around from your previous attempts).
./adb-mac kill-server
then try this again:
./adb-mac devices
If this doesn't work, you might try rebooting your Mac just in case there really is another orphan adb daemon that you can't obviously see and then retry the ./adb-mac devices command.
hislap-mb-c:sdk-tools dmacy$ ./adb-mac kill-server
hislap-mb-c:sdk-tools dmacy$ ./adb-mac devices
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached
HT03ZHG03372 recovery
hislap-mb-c:sdk-tools dmacy$
Oh boy, I am making progress, this is exciting...where to go from here?
Flashing Rom, Trackball not working!
...so I've done the Nandroid backup (first command he listed) and then the "--wipe_data" command...the command did/does hang...I waited about two minutes per eu1's instructions...and then hit control-C and did the "adb shell tail /cache/recovery/log", but I don't see "I:Installation complete." in the log. Instead, I see:
.
did it! :)
