Related
This will NOT work in CM5.0b4 as JIT has been disabled entirely
It seems like a lot of people are constantly pulling/editing/pushing build.conf in order to turn JIT on and off, so I threw together a short script to toggle it on and off.
It's nothing elaborate, but it gets the job done. This is meant to work with the build.prop that comes stock with cyanogenmod 5.0b2 but will most likely work with other build.props that have JIT.
Steps to run the script:
1) Download jit.txt, rename it jit.sh
2) If you downloaded from your computer, run "adb push jit.sh /sdcard" or mount your device and copy to your sdcard.
3) In terminal on Nexus One:
$ su
# sh /sdcard/jit.sh
JIT toggled ON
JIT enabled upon reboot
#
You can also set it up in GScript or GScript Lite so you can add an icon on your homescreen to toggle JIT more easily:
1) From command line: mv /sdcard/jit.sh /sdcard/gscript/jit.sh
2) Open GScript
3) Go to Menu->Add Script
4) Go to "Load file"
5) Select jit.sh
Then to make an icon on your homescreen:
1) Long press homescreen
2) Select Shortcuts
3) Select GScript(Lite)
4) Select jit
You must reboot for the changes to take effect after running the script. If you prefer, simply put "reboot" (without quotes) on it's own line at the end of the script and it will reboot automatically. Only do this after you have confirmed that the script works for you.
If you are using Windows, make sure you use the attached jit.txt rather than copying the code from this post. Copying/pasting the code will not work because of Windows CR/LF line breaks.
Code:
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
if grep -q fast /system/build.prop ; then
sed -i s/=int:fast/=int:jit/ /system/build.prop
echo "JIT toggled ON"
echo "JIT enabled upon reboot"
else
sed -i s/=int:jit/=int:fast/ /system/build.prop
echo "JIT toggled OFF"
echo "JIT disabled upon reboot"
fi
exit
mhaedo said:
It seems like a lot of people are constantly pulling/editing/pushing build.conf in order to turn JIT on and off, so I threw together a short script to toggle it on and off.
It's nothing elaborate, but it gets the job done. This is meant to work with the build.prop that comes stock with cyanogenmod 5.0b2.
Simply push the script to your phone (sdcard, or wherever you please) and run it. For example, put the quoted text into a file called jit.sh, push it to the root of your sdcard, and run "sh /sdcard/jit.sh" from a terminal. You can also set it up in GScript or GScript Lite so you can add an icon on your homescreen to toggle JIT more easily.
You must reboot for the changes to take effect.
Click to expand...
Click to collapse
Nice - been looking for just this, thanks. As a bit of a n00b, any idea why this doesn't seem to run in GScript Lite? I get the SU request OK, but then nothing - don't see the echo'd text at all, nowt. Running CM5b2 .29 kernel.
Ive installed pauls modaco patch wil this turn jlt off? its annoying me
Thanks for this script !
I just pull, nano, and push it back.
I don't think It's 100% stable.
push/pull? Shoot, I just use vi on build.prop from betterterminal. Don't have to mess with adb at all
Since you need to reboot anyway, couldn't we just put "reboot" in place of "exit"? I'm assuming that's not part of the script to save, since you have "fi" at the end of it. Personally, what I did is save 2 versions of build.prop to my sdcard and then built gscripts to swap 'em out. lol A little more crude, but just as effective.
when i try to run the jit.sh file in terminal i get:
failed: no such file or directoryk3 on /system : not found
sdcard/jit.sh : 13: syntax error: end of file unexpected (expecting 'then")
am i completely retarded?
trisl said:
Nice - been looking for just this, thanks. As a bit of a n00b, any idea why this doesn't seem to run in GScript Lite? I get the SU request OK, but then nothing - don't see the echo'd text at all, nowt. Running CM5b2 .29 kernel.
Click to expand...
Click to collapse
Yeah, I had the same problem. Remove the su request from superuser.apk. Then, run any script that requires root. Click remember, and allow. It will not work at this point. Back out to the homescreen with the back button, then go back into GScript Lite and run it again. It should work this time.
Guitarfreak26 said:
Ive installed pauls modaco patch wil this turn jlt off? its annoying me
Click to expand...
Click to collapse
Not sure. I would assume so, never seen the build.prop that's used but I don't see why it would be any different.
Mi|enko said:
Since you need to reboot anyway, couldn't we just put "reboot" in place of "exit"? I'm assuming that's not part of the script to save, since you have "fi" at the end of it. Personally, what I did is save 2 versions of build.prop to my sdcard and then built gscripts to swap 'em out. lol A little more crude, but just as effective.
Click to expand...
Click to collapse
That would be more efficient, but I just enjoy clicking my icon a few times and toggling it on and off Don't ask me why.
[email protected] said:
push/pull? Shoot, I just use vi on build.prop from betterterminal. Don't have to mess with adb at all
Click to expand...
Click to collapse
How would I do that? I have betterterminal emulator pro..
Four Fourty Four said:
How would I do that? I have betterterminal emulator pro..
Click to expand...
Click to collapse
$ su
# vi /system/build.prop
Proceed to edit (man vi, google vi). Bit of a pain in the ass though if you switch back and forth frequently.
mhaedo said:
$ su
# vi /system/build.prop
Proceed to edit (man vi, google vi). Bit of a pain in the ass though if you switch back and forth frequently.
Click to expand...
Click to collapse
Don't forget, you need to remount /system as rw also. it is a tiny bit of a pain, but I don't see much of a reason to switch back and forth all the time. Thus far I have yet to have any problems with JIT.
[email protected] said:
Don't forget, you need to remount /system as rw also. it is a tiny bit of a pain, but I don't see much of a reason to switch back and forth all the time. Thus far I have yet to have any problems with JIT.
Click to expand...
Click to collapse
The only time I consistently have problems with JIT is when tethering. Otherwise, I have yet to have any issues. I tether frequently, hence the script.
BTW, thanks for Apps2SD(2) and OpenOverclocker. They were very helpful to me at one point.
blakestimac said:
when i try to run the jit.sh file in terminal i get:
failed: no such file or directoryk3 on /system : not found
sdcard/jit.sh : 13: syntax error: end of file unexpected (expecting 'then")
am i completely retarded?
Click to expand...
Click to collapse
+1
I'm getting this message also.
blakestimac said:
when i try to run the jit.sh file in terminal i get:
failed: no such file or directoryk3 on /system : not found
sdcard/jit.sh : 13: syntax error: end of file unexpected (expecting 'then")
am i completely retarded?
Click to expand...
Click to collapse
Hm, strange. I can't duplicate this error. The steps I take are as follows:
1) Cut/paste the quoted code in the original post and save it in a document called jit.sh
2) On computer, adb push jit.sh /sdcard
3) In terminal on Nexus One:
$ cd sdcard
$ su
# sh jit.sh
JIT toggled ON
JIT enabled upon reboot
#
I'm sorry I can't be more help, but I'm not sure why you'd see that error.
mhaedo said:
Hm, strange. I can't duplicate this error. The steps I take are as follows:
1) Cut/paste the quoted code in the original post and save it in a document called jit.sh
2) On computer, adb push jit.sh /sdcard
3) In terminal on Nexus One:
$ cd sdcard
$ su
# sh jit.sh
JIT toggled ON
JIT enabled upon reboot
#
I'm sorry I can't be more help, but I'm not sure why you'd see that error.
Click to expand...
Click to collapse
Ok, I didn't do the whole adb push thing, I just copied it to my SDcard root from windows. Is that the problem?
BoostedSR20 said:
Ok, I didn't do the whole adb push thing, I just copied it to my SDcard root from windows. Is that the problem?
Click to expand...
Click to collapse
Ah, it's the line breaks. Windows uses a pair of CR and LF characters to terminate lines. Unix based system use an LF character only.
You can get a utility to convert the line breaks to unix style line breaks. I'm sure it will come in handy. I'll also upload the jit.sh with proper line breaks to the original post.
BoostedSR20 said:
Ok, I didn't do the whole adb push thing, I just copied it to my SDcard root from windows. Is that the problem?
Click to expand...
Click to collapse
Just tried pushing it to the sdcard, that went thru ok.
Still cant get it to run, same error. I've tried your command in the OP, and the what you wrote out a couple posts up. Same error on each one.
mhaedo said:
Ah, it's the line breaks. Windows uses a pair of CR and LF characters to terminate lines. Unix based system use an LF character only.
You can get a utility to convert the line breaks to unix style line breaks. I'm sure it will come in handy. I'll also upload the jit.sh with proper line breaks to the original post.
Click to expand...
Click to collapse
Ahhh, so it had to do with me making the file in the Windows Notepad. Got it..
Current Status 7/14
Without the NAND being unlocked, we are unable to re-write to the recovery partition. Other than that everything is working good. Unlocked NAND=One Click Root!
This method is directly based on the new root process for the Eris released on xda.
Original thread can be found here
The following information is taken directly from the thread mentioned above with some small modifications by me for the Incredible.
Big thanks to tereg for the toolkit and the guys who rooted the EVO with a file write/chmod race condition exploit that gave me the idea for this.
jcase noticed that a race isn't actually nessisary to exploit the chmod 777 on the file I've been working with, simplifying the script alot.
I used the files from the adb development pack that Tereg put together. Download them here. You don't need them for this root process as long as you have a working adb install.
You will need adb access. Install the android sdk for your platform (macos, windows, linux) get it for your OS here.
If you don't know how to install the sdk, search xda, there are a ton of howtos for that.
Files to download:
hack-v5-DINC.zip
A ROM file
Android SKD (skip if you have a working adb)
Instructions for linux/OSX.
Have adb in your path, or move the files contained in hack-v5-DINC.zip into your sdk/tools directory so your pushes will work properly.
FOR ALL OS's Make sure your phone has Applications->Development->USB Debugging turned on.
Do NOT have your phone in Disk Drive Mode, have it in Charge Only.
Open a terminal window in your /tools/ directory. Type this at the prompt.
Code:
sh runinlinux.sh
This will take a few minutes, follow the instructions on your screen.
If you get adb: command not found, edit runinlinux.sh and change every
Code:
#/bin/bash
adb push flash_image /data/local/
adb push recovery.img /data/local/
adb push testfile /data/local/
etc...
to
Code:
./adb push flash_image /data/local/
./adb push recovery.img /data/local/
./adb push testfile /data/local/
etc...
Instructions for windows (thanks tereg!)
Download the hack.zip file and extract it to the desktop. So, you have a folder on the desktop called hack. I would recommend moving or copying those files (EDIT: that are contained in the hack folder) to the C:\android-sdk-windows\tools folder. Why? Because the script runs "adb ____" commands, and unless you've set up adb to be able to run anywhere within the command prompt, the script won't run. So, it will universally work if the files in the hack folder are placed in C:\android-sdk-windows\tools
So, open a command prompt by pressing WindowsKey+R, or going to Start-Run (in WinXP) and typing
Code:
cmd
in the text box there and press OK
If you are in Windows Vista/Windows 7, go to the Start Menu, then type in
Code:
cmd
in the search bar in the lower right-hand corner of the start menu and press enter, and locate Command Prompt in the search results, or go to Start -> All Programs -> Accessories -> Command Prompt
Type
Code:
cd C:\android-sdk-windows\tools
and press enter
Now, I recommend pushing the ROM you want to flash to the SD card now.
Code:
adb push ROM.zip /sdcard
Then, type
Code:
runindos.bat
to execute the script.
You might have to run it 2 or 3 times for it to work. If it fails, just reboot the phone normally, then run
Code:
runindos.bat
again once the phone is booted back up and you're ready.
----------(Thanks again tereg!)
It will scan for a long time, give it at least 5 minutes. If it doesn't come back after 5 minutes cntrl +c to stop it, start the process again. MOST PEOPLE HAVE TO RUN THIS AT LEAST TWICE!
If your device reboots into a new screen with options on it, you now have root in recovery mode. At this point you will be flashing your Incredible's brains, so YOUR PHONE WILL BE BLANK AFTER LOADING A NEW ROM! All of your apps/numbers will be gone from the phone.
I suggest a nand backup first.
Download and copy one of these ROM's to your sdcard as update.zip and flash it with flash zip from sdcard by selecting "Install zip from sdcard".
The first boot after loading a new ROM takes quite a while to show any activity to the screen. Give it a good 5 minutes before you start wondering if it's ever going to come back.
---
runinlinux.sh
---
Code:
#/bin/bash
adb push recovery.img /data/local/
adb push flash_image /data/local/
adb shell chmod 777 /data/local/recovery.img
adb shell chmod 777 /data/local/flash_image
adb shell rm /data/local/rights/mid.txt
adb shell ln -s /dev/mtd/mtd1 /data/local/rights/mid.txt
echo "Files copied and permissions set, rebooting HTC Andriod 2.1"
adb reboot
echo "Your phone will now reboot into normal mode, then reboot into recovery mode. If it does not reboot the second time, wait 10 minutes and manually reboot and begin again."
echo "Your phone is now rebooting in Rooted Recovery mode, do a backup and load your ROMs"
adb wait-for-device
adb shell /data/local/flash_image recovery /data/local/recovery.img
adb reboot recovery
---
runindos.bat
---
Code:
@echo off
adb push recovery.img /data/local/
adb push flash_image /data/local/
adb shell chmod 777 /data/local/recovery.img
adb shell chmod 777 /data/local/flash_image
adb shell rm /data/local/rights/mid.txt
adb shell ln -s /dev/mtd/mtd1 /data/local/rights/mid.txt
echo "Files copied and permissions set, rebooting HTC Andriod 2.1"
echo "Your phone will now reboot into normal mode, then reboot into recovery mode. If it does not reboot the second time, wait 10 minutes and manually reboot and begin again."
adb reboot
adb wait-for-device
echo "Your phone is now rebooting in Rooted Recovery mode, do a backup and load your ROMs"
adb shell /data/local/flash_image recovery /data/local/recovery.img
adb reboot recovery
This thread is intended to be an think-tank, similar to the one on the eris forums where I got the idea from. Let the ideas flow!
has this been tested to work on the INC? if not why has this been posted.
outsid0r said:
has this been tested to work on the INC? if not why has this been posted.
Click to expand...
Click to collapse
uhm....do you read?
"This thread is intended to be an think-tank, similar to the one on the eris forums where I got the idea from. Let the ideas flow!"
no. this is not working yet. thats why the title even has {development} in it. the process is almost working, and this is a develpoment thread to work out the issue-which is also in big letters at the top...see where it says
"Without the NAND being unlocked, we are unable to re-write to the recovery partition. Other than that everything is working good. Unlocked NAND=One Click Root!"
So once we solve a much more difficult problem, the less difficult will be easier.
Makes sense.
We already know how to unlock the nand vs the exploit posted last night...also unrevoked will have it done In a few days anyway
Sent from my HTC Incredible using the XDA App
adrynalyne said:
So once we solve a much more difficult problem, the less difficult will be easier.
Makes sense.
Click to expand...
Click to collapse
the difficult problem has already been solved. the unrEVOked team already has the NAND unlocked. now its whether they want to share and make it a true one-click root method, or if they are going to keep it a secret and keep koush's clockworkmod recovery as the only possibility. this tool still uses the clockworkmod recovery, but after a NAND unlock your given the option to change. since koush is working for them too, im starting to think more and more that they are going to keep the monopoly.
im hoping that they will just incorporate their NAND unlock method into this root process. they can even re-lock it after the process is done as they do in their re-flash tool to preserve the monopoly, but a true one-click root is now possible with their co-operation. ive messaged them asking if they want to help out. we will see soon enough, so cross your fingers!
they can even re-lock it after the process is done as they do in their re-flash tool to preserve the monopoly
Click to expand...
Click to collapse
You just lost a ton of respect from me, and I suspect more than a few others. Talk about biting the hand that feeds you.
adrynalyne said:
You just lost a ton of respect from me, and I suspect more than a few others. Talk about biting the hand that feeds you.
Click to expand...
Click to collapse
So I see we have this starting up again....shakes head at OP..
@adrynalyne best to just ignore these people...its not like the winmo days is it man? Le sighe
Good advice, you are right. I will ignore this stuff in the future.
No, not like the winmo days at all. I've never seen so much anomisity and jealousy in a community before like there is for Android.
All I can say is we already intended to release this method, we were making a pretty robust obfuscation for it. But again the community has jumped before thinking and posted the bug for HTC to fix. There might not be any root's left after this one is burnt. Which it now is. Our tool will be released as is soon enough.
We don't care to create a monopoly, we happily work with others that ASK. Those that just jump and tell the world all the secrets we don't want plugged are just stupid, plain and simple.
adrynalyne said:
You just lost a ton of respect from me, and I suspect more than a few others. Talk about biting the hand that feeds you.
Click to expand...
Click to collapse
LOL Whatever, it isnt like respect from you is something anyone cares about. I like someone with the nerve to speak the truth no matter how unpopular it might be.
outsid0r said:
has this been tested to work on the INC? if not why has this been posted.
Click to expand...
Click to collapse
Please read. Think tank! I applaud this dude for trying. More than many others do here!
fader01 said:
LOL Whatever, it isnt like respect from you is something anyone cares about. I like someone with the nerve to speak the truth no matter how untrue it might be.
Click to expand...
Click to collapse
Fixed that for ya.
adrynalyne said:
You just lost a ton of respect from me, and I suspect more than a few others. Talk about biting the hand that feeds you.
Click to expand...
Click to collapse
Shadowmite said:
All I can say is we already intended to release this method, we were making a pretty robust obfuscation for it. But again the community has jumped before thinking and posted the bug for HTC to fix. There might not be any root's left after this one is burnt. Which it now is. Our tool will be released as is soon enough.
We don't care to create a monopoly, we happily work with others that ASK. Those that just jump and tell the world all the secrets we don't want plugged are just stupid, plain and simple.
Click to expand...
Click to collapse
it seems like my comment was taken the wrong way.
for one, clockworkmod recovery is the only one that works on the DINC AFAIK, amon_ras isnt working on here either.
the monopoly is basically a monopoly because of the lack of other available options, not necessarily because its enforced.
i apologize if it came off the wrong way or insulted anyone with the preceding comments.
i meant this thread as a co-operative think-tank, it wasnt my intention to start a big ordeal.
adrynalyne said:
Good advice, you are right. I will ignore this stuff in the future.
No, not like the winmo days at all. I've never seen so much anomisity and jealousy in a community before like there is for Android.
Click to expand...
Click to collapse
@adrynalyne yeah its a real rough community at times, but what ya gonna do right...its hard for me to ignore them at times too
@shadowmite. thanks for your guys hard work....the ignorant ones are everywhere nowadays, hope they don't get you guys down.
Cheers!
Shadowmite said:
All I can say is we already intended to release this method, we were making a pretty robust obfuscation for it. But again the community has jumped before thinking and posted the bug for HTC to fix. There might not be any root's left after this one is burnt. Which it now is. Our tool will be released as is soon enough.
We don't care to create a monopoly, we happily work with others that ASK. Those that just jump and tell the world all the secrets we don't want plugged are just stupid, plain and simple.
Click to expand...
Click to collapse
hmm. well i guess thats what happens when people try to help out the community...maybe next time i just wont do anything... :/
and FYI...i did contact you. i sent you a PM earlier today.
this method has been used on the EVO and hasnt been plugged, and its been in the works on the Eris-also an HTC phone- for quite a long time, and in the same way this is...a co-operative community effort to make the phone the best that it can be.And its still not been plugged.
id worry less about HTC plugging the exploits and more about getting the exploits available to the public.
Correct, you are not the original one leaking the method. But my point is devs capable of finding things like this should be capable of thinking about it being plugged. HTC fixed our recovery hold in the next OTA. Now it's quite possible nand and this root will be patched also. we have NO OTHER WAYS IN... Thats it. besides some VERY complicated exploits we are OUT after the next ota.
I got your pm's, but only after you posted this.
It's a moot point, our one click root is due out in a few minutes. we were going to further lengths to protect the method, but it's out anyway at this point.
Shadowmite said:
Correct, you are not the original one leaking the method. But my point is devs capable of finding things like this should be capable of thinking about it being plugged. HTC fixed our recovery hold in the next OTA. Now it's quite possible nand and this root will be patched also. we have NO OTHER WAYS IN... Thats it. besides some VERY complicated exploits we are OUT after the next ota.
I got your pm's, but only after you posted this.
It's a moot point, our one click root is due out in a few minutes. we were going to further lengths to protect the method, but it's out anyway at this point.
Click to expand...
Click to collapse
well i apologize for the fact that i may/may not have ruined your chances to make a big announcement for your release, but IMO its kinda bs that you keep the info on lockdown. the whole point of android is that its open. a select amount of people shouldnt consider themselves the gatekeepers of important information.
ban_dover said:
well i apologize for the fact that i may/may not have ruined your chances to make a big announcement for your release, but IMO its kinda bs that you keep the info on lockdown. the whole point of android is that its open. a select amount of people shouldnt consider themselves the gatekeepers of important information.
Click to expand...
Click to collapse
From our wiki, which you appearently haven't read:
http://unrevoked.com/rootwiki/doku.php/public/unrevoked2
That doesn't seem fair! Android is about open source.
In some senses, we agree; but at times, a tradeoff needs to be made. Releasing the source code for this, we believe, would compromise the greater ability to unlock devices like these in the future. Given the choice between sacrificing the liberty of running code on our handsets and the liberty of reading the code by which we unlock it, we feel that the millions of handsets are more important. It is unfortunate that we must make such a choice, and we look forward to the day in the future that no such decision need be made.
Click to expand...
Click to collapse
Shadowmite said:
From our wiki, which you appearently haven't read:
Click to expand...
Click to collapse
already read it.
i dont take my opinions from things i read. i take the information and draw my own conclusions. and in this case my conclusion is that, while i can see your point i still disagree.
If you are looking for how to get back to stock Bell, go HERE.
Disclaimer: I have not tested this on anything but my phone. This is a development section of a hacking website. Make backups. Know what you are doing.
Credits:
Brut.all for apktool
edgan for 2nd-init
designgears for aroot inspiration.
xda for being a source of info.
Requirements:
Windows 7 or Ubuntu 10.10+ (10.10 and 11.04 tested)
Java installed. (For applymods, it uses apktool)
Running Phone, not in recovery mode, etc.
Tips:
Don't factory reset please if something goes wrong, it just erases your personal settings, it doesn't write to the system partition. It also deletes your data partition, making it harder to get back to stock.
Early usb mode, turn your phone on while holding down the lower volume button, when it says fastboot, release and press volume down repeatedly until it says early usb enumeration, then press up volume. It takes 30 seconds or so before adb is ready.
Version 9:
Download it here.
What's new:
Added support for 2nd-int (WIP, tested on stock Bell only)
shsu updated to allow a super user to become a super user, acts like sh in that case.
fixed linux install_recovery.sh and uninstall_recovery.sh scripts to use shsu instead of remaining using su. Ditto with ApplyMods.sh
Boot animation now smaller, using jpegs instead of png files, no difference in appearance.
Version 8:
Download it here.
What's new:
Added full phone backup and full restore phone options to the menu. It will download a backup if there is none found.
root script more universal, tries psneuter first, then gingerbreak.
Early usb recovery updated, now uses a tmpfs for system, also mounts /sdcard and /sdcard-ext.
Deodexed French 2.1.1 files incorporated.
Misc fixes
Version 7:
What's new:
New Menu script for windows and linux in the top folder, double click Menu and enter options.
ApplyMods and other scripts updated to use /data/local/tmp/system, this means I can update system.tar.gz and add folders to be copied into system.
Early USB enumeration recovery option. (experimental but useful as is)
Fixed bugs in windows scripts. Can't get user input from bat file while in a parenthesis block apparently.
Bloat backed up to sdcard now
root and unroot scripts updated with more prompts for rebooting phone.
Version 6:
What's new:
Support for Telstra 1.4.2.
ApplyMods can create signed update.zips now, Create_update.bat updated. both using basic ready made scripts in main bin folder instead of creating them on the fly, CR LF issues.
Updated root and unroot scripts, more fool proofing, has to be Bell stock firmware (psneuter doesn't work on telstra).
Includes basic boot animation, and mod for Bell apn on telstra firmware. (Have to reset to default under access point names in settings.)
transparent status bar, yellow tinted white for text color, matches front buttons somewhat.
Version 5.1:
Features:
Works under Linux and Windows 7
Includes root and no ads scripts
Patch system for applying modifications.
What's new:
New scripts for doing mods, fixes issues with patch 9 images.
Updated root and unroot scripts, more fool proofing.
New RestoreSystemPartition script
Custom apktool for more [hopefully] bug free installations.
How to use:
Extract archive, keeping folder structure intact.
run a command prompt/terminal (There is a link to one in the windows folder)
run root.bat or root.sh from the linux or windows folders, depending on which one you are using.
Turn the phone off after that is done and turn it back on again.
The rest of the scripts shouldn't be run with psneuter affecting the phone.
run ApplyMods.bat (.sh) [OPTIONAL] This applies webtop hack and translucent status bar, translucent notification drop down, etc. Select update system.tar.gz.
run install_bell_deodex.bat or .sh
System image of stock Bell.
Mirror of above
Cheers!
Very nice! Looks good!
Will try this when I get home
Sent from my Motorola Olympus
So what is the benefit of this? Will I be able to theme my device with some of the themes that are available? Or should I play it safe and wait for a bell. Sbf to leak before I try anything and brick my phone again lol thanks in advance
EDIT: i see that you have included soft_brick.bat is it the same as this one http://forum.xda-developers.com/showthread.php?t=982859 because that one did not work for me thanks again
Sent from my MB860 using XDA Premium App
cool, i'll try this tomorrow when i don't still have a ****load to do and only 5 hours to sleep
nice to see a Bell dev here!
Also I just wanted to say major props for the crazy awesome idea of doing over-the-air download and installation. Really smart and original.
Atrices, just so you know
NFHimself said:
Hi,
(What is the plural of Atrix?)
Click to expand...
Click to collapse
Can I run this on my mac? Sorry relatively new to adb
Sent from my Motorola Olympus
you could run it on a mac, just had to edit the script a bit.
Hi,
So what is the benefit of this? Will I be able to theme my device with some of the themes that are available? Or should I play it safe and wait for a bell. Sbf to leak before I try anything and brick my phone again lol thanks in advance
Click to expand...
Click to collapse
I wouldn't try theming with ATT files, I would take what was done to them and apply them myself to the deodexed files here. There may or may not be differences that are not obvious. I am never really sure if there is any benefit to this stuff, it's fun to do, about it.
EDIT: i see that you have included soft_brick.bat is it the same as this one http://forum.xda-developers.com/showthread.php?t=982859 because that one did not work for me thanks again
Click to expand...
Click to collapse
The soft_brick.bat script is specific to the folders I am using for transferring data to /system/app and /system/framework. It tries to get root via psneuter, mounts system read write, deletes dalvik-cache files, and tries to copy the files already on the phone to the right folders. It could be that just one file caused the phone to crash mid copy and copying it again will fix things. This avoids trying to do a usb data transfer of all the files which you don't have time to do otherwise. I was also thinking that install-recovery.sh would be a good place to do this, (and then clobber it later with the init.d hack) but I couldn't find setprop and I wasn't in need enough to select a file to use as a semaphore.
Can I run this on my mac? Sorry relatively new to adb
Click to expand...
Click to collapse
It would be easier to do it all from a sh script really, and that would likely be more compatible with a Mac.
Also I just wanted to say major props for the crazy awesome idea of doing over-the-air download and installation. Really smart and original.
Click to expand...
Click to collapse
Thanks!
Cheers!
maledyris said:
Atrices, just so you know
Click to expand...
Click to collapse
Thanks, a lot, really, 10 chars..
How do I recover from a softbrick from this? Thanks.
Before anything is done, all the files are extracted to /data/local/tmp/app and /data/local/tmp/framework. If you run into problems put the phone into fastboot/early usb enumeration mode (see here) and run soft_brick.bat (.sh for linux)
Quote:
A soft brick, in this case, is when you make a bad edit to your framework files and the phone won't fully boot and starts flashing a red LED at you.
There is one catch, you only get about 1-2min to do all of this before the phone reboots on its own. If that happens, do SuperOneClick steps again and continue where you left off. Better yet, build a script to do it all for you
Power off your device
Enter Fastboot:
Hold Volume down + power until you see Fastboot at the top left
Use volume down to scroll down to "Early USB Enumeration" (only shows one item at a time, if you pass it, keep going down, up selects)
Press Volume up to select
This is the message I get when i run the batch file.
This is of course when invoking Early USB Enumeration.
Wait for the count down to finish ...
'TIMEOUT' is not recognized as an internal or external command,
operable program or batch file.
clearing Dalvik cache..
rm failed for /data/dalvik-cache/[email protected]*.dex, No such file or directory
rm failed for /data/dalvik-cache/[email protected]*.dex, No such file or director
y
rm failed for /data/dalvik-cache/[email protected]*.odex, No such file or directory
rm failed for /data/dalvik-cache/[email protected]*.odex, No such file or directo
ry
reinstalling apps
cp: cannot stat '/data/local/tmp/app/*': No such file or directory
reinstalling framework..
cp: cannot stat '/data/local/tmp/framework/*': No such file or directory
done.
The timeout message means you are running a version of windows without timeout, see adeo thread.
The lines for rm just mean there are no files to delete in the Dalvik-cache, which is normal, you should see that the second time around.
The cp lines are saying that there are no files in /data/local/tmp/app (/framework).
So, that's unusual, in order to get soft bricked using my script you would to have copied files from /data/local/tmp to /system, and if you are bricked would be unable to delete the files afterword.
sequence:
cd /system
cp /data/local/tmp/app/* app/
sync
reboot now
**brick**
So, how are the /data/local/tmp/app files being deleted?
No clue. I'm not sure what to do here? Is my phone permanently bricked? Any other way to recover from this? The one thing that could have gone wrong is I tried installing from my behind my works firewall. Maybe I could not download the proper files.
No, you are soft bricked, you only made a change (that I know of) in system files.
Were you rooted before you tried this?
If you copy the soft_brick.bat files and change the last line to be adb.exe shell ls -R /data/local/tmp, what do you get?
Basically, it sounds like to need to get the files copied over to data/local/tmp, how they are missing/inaccessible is odd. So, create a script to copy the files over bit by bit, might take a while but it should be able to be done.
EDIT:
Do this:
from command prompt:
adb.exe shell ./data/local/tmp/psneuter
wait a few seconds
type this:
adb shell ls -l -R /data/local/tmp
if psneuter fails, it isn't in /data/local/tmp, which is also odd.
I was rooted before this. So I should attempt all these commands while Early USB Enumeration right? That doesn't give me much time Lol.
OK, here's the output.
C:\bell_deodex>adb.exe shell ./data/local/tmp/psneuter
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
property service neutered.
killing adbd. (should restart in a second or two)
C:\bell_deodex>adb shell ls -l -R /data/local/tmp
/data/local/tmp:
-rwxr-xr-x root root 585731 2011-01-09 02:02 psneuter
-rw-r--r-- mot_tcmd mot_tcmd 4 2011-03-30 21:00 ap_tcmd.pid
C:\bell_deodex>^A
And sorry to be a pain. How would I create the script? What are the files that need to be copied? Are they included in your script?
[Project dormant unless someone else picks it up]
NOTE: This is a chroot for the Webtop, not the Android+VNC chroot method.
Hi everyone, this is my first guide (I'm not sure I can call it that yet, or if this is in the right section) so bear with me.
I tried the Debian chroot guide (http://forum.xda-developers.com/showthread.php?t=1093790), and I really liked the idea, but I had too many apt-get issues and it often crashed my Webtop, so I tried building my own Ubuntu Lucid chroot using rootstock, but internet didn't work.
I later saw this: http://forum.xda-developers.com/showthread.php?t=1184161, but the links were dead and the scripts it referenced were out of date. I'll sort of combine the two guides here since Backtrack actually works surprisingly well.
Just on a side note though, I haven't fully tested the Backtrack tools, but the only thing I haven't found to work are the wireless tools.
Let's start!
Required:
-Rooted Atrix (with Blur based ROM)
-LXTerminal installed on Webtop
-Enough free space (around 4 GB just for room)
-7-Zip
-Some Linux/Unix distro native or in a VM
1. Install the easy-signed.zip from the Debian chroot guide:
http://forum.xda-developers.com/showthread.php?t=1093790
but the other files aren't needed.
Make a folder called WebTopMOD (case-sensitive) on either external or internal memory for later.
2. Look here for reference: http://forum.xda-developers.com/showthread.php?t=1184161, but the links are dead. Active links are here:
Part 1: http://www.mediafire.com/?x9cgxzdx84vc6uj
Part 2: http://www.mediafire.com/?xaoidipkg1o7vgo
Part 3: http://www.mediafire.com/?po3nznbxgvdipur
Use 7-Zip to uncompress the three files (called bt.7z.001,002,003) and you'll get a bt.img.
Full bt.img in a zip:
DL from Mega or from Google Drive
3. The image isn't usable in this state yet, since the image is formatted with ext2, and we need ext3.
Copy the image over to your Linux VM or computer on a easy-to-find directory, and open up a Terminal window (usually CTRL+ALT+T).
In Terminal, type this in:
Code:
cd <directory where you put bt.img>
mkdir tmp tmpbt
sudo mount -o loop bt.img tmpbt
dd if=/dev/zero of=linuxdisk count=0 bs=1MB seek=4096 (This is the size of the chroot image you want, in MB)
mkfs.ext3 linuxdisk (just type y when it asks)
sudo mount -o loop linuxdisk tmp
sudo cp -rf tmpbt/* tmp
sudo umount tmp
sudo umount tmpbt
[Sorry, made a mistake twice] Copy the newly made linuxdisk file to a directory named WebTopMOD on your internal memory or sdcard-ext (folder and file names are case-sensitive).
4. Start Webtop, then open LXTerminal, then start the chroot by typing in:
Code:
/usr/sbin/linux
and after it loads for a bit, you'll get an xterm window with the shell for Backtrack!
If you want to quit the Gnome session, closing xterm doesn't work, since by issuing the commands to kill the webtop processes, it also kills the webtop window manager, and if you do close it there's some kind of weird glitch with a small popup window constantly disappearing and reappearing. (It'll be a WIP for now I guess, the only full solution is to reboot your Atrix). It seems to have to do with the way the linux command mounts the chroot disk under loop50, I'll try and make something to fix this later.
-----------------Extras moved below-----------------------
Pictures:
Chromium Running
BT Desktop (Gnome)
BT Desktop with AIW
THANKS TO:
k.taylor89 for the original Backtop Method
SystemR89 for the Debian chroot and scripts to make this work
The original developers of the Backtop chroot image
And any others I may have forgotten!
Extras:
If you want a GUI (Gnome):
k.taylor89 said:
You first need to kill off all the webtop crap do this by typing the following in xterm.
"ps ax|grep awn|awk '{print $1}'|xargs kill"
"ps ax|grep panel|awk '{print $1}'|xargs kill"
Then start gnome by typing "gnome-session" in xterm.
Click to expand...
Click to collapse
If you want to take it step further and start Gnome after bootup, this isn't a full solution yet but you could edit your start-oshwt-1.sh and 2 scripts so that the chroot automatically starts on bootup without anything else in Webtop, and from there start gnome-session. I'm testing that now.
Installing Apps:
Since this is based off of Ubuntu Lucid, you can install anything from the Lucid repos, you just have to fix the sources list since the Backtrack sources don't seem to work.
Code:
sudo cp /etc/apt/sources.list /etc/apt/sources.list.old (Backup just in case)
sudo nano -w /etc/apt/sources.list
Comment out (#) any line with the backtrack servers, and uncomment any line with the Ubuntu repos.
Press Control+X, Y, then Enter, then run apt-get update to update the repos.
Apps like Chromium install and run without a hassle (just run apt-get install chromium-browser), but I actually get the error "Bus error" for some reason when Chromium remains idle, it seems to be an unsolved bug in the version of Chromium for armel devices in the Lucid repos, if anyone else has a fix, please do tell.
First.
I think its only for lapdock ..........
3n3rg1c said:
First.
I think its only for lapdock ..........
Click to expand...
Click to collapse
Oh sorry yeah I forgot to mention that. I mean I guess if you have the mod that lets you use Webtop anywhere, that'll work too.
Hi,
The "Part 3: http://www.mediafire.com/?po3nznbxgvdipu" doesn't work.
Could you fix it.
Thank you.
sintoo said:
Hi,
The "Part 3: http://www.mediafire.com/?po3nznbxgvdipu" doesn't work.
Could you fix it.
Thank you.
Click to expand...
Click to collapse
Oh sorry I copied the link incorrectly, updated in OP.
i've gotten it running on my ubuntop model, when i ran it from the terminal it would not give me any issues when closing it back up. is there a way to only launch the gnome panel? running: gnome-panel in the terminal didn't work
etruj said:
i've gotten it running on my ubuntop model, when i ran it from the terminal it would not give me any issues when closing it back up. is there a way to only launch the gnome panel? running: gnome-panel in the terminal didn't work
Click to expand...
Click to collapse
I'm not sure if there is a way to start just gnome panel because of the way the chroot is implemented, since to run gnome-panel, an X session must already be running within the chroot and I need to figure that out.
My first two times i lUnched the session the wallpaper would flicker and then just the panels would come up. Now i get hit with the errors and loop pop ups. Maybe there is a way to launch the session then kill everything but the panel?
Sent from my MB860 using xda app-developers app
etruj said:
My first two times i lUnched the session the wallpaper would flicker and then just the panels would come up. Now i get hit with the errors and loop pop ups. Maybe there is a way to launch the session then kill everything but the panel?
Sent from my MB860 using xda app-developers app
Click to expand...
Click to collapse
The workaround I found worked so far was to modify the start-oshwt-2 script so that it would run a very slightly modified version of the script that automatically starts gnome-session (gnome-panel alone is really stubborn, still haven't figured that out) and doesn't start whatever window manager in WebTop to avoid flickering errors and panel only errors (but of course you don't have access to anything from the actual WebTop, but you could also have start-oshwt open a Terminal window from WebTop too).
Can you attach the script?
Sent from my MB860 using xda app-developers app
etruj said:
Can you attach the script?
Sent from my MB860 using xda app-developers app
Click to expand...
Click to collapse
Just rename it to linux, and copy it to wherever you like on your Atrix. You can also copy it to a directory within your terminal path.
This isn't my script, it's from the Debian chroot, just modified to automatically start gnome-session (credit to SystemR89)
You might need to chmod +x the file.
Also, if you want to start it automatically from start-oshwt-2.sh, make sure you copy the file to a directory within the terminal path, and add the line
Code:
sfalv -i "linux"
and comment out any other line that starts a different X window manager.
running "sudo gnome-panel" gives me the panel while staying inside the original ubuntop. i think i can just swap out that one line in your script to get it working. thanks! also noticed my chrome crashes after a few minutes, ill post the error code and screen grabs soon but was wondering if you ever experienced anything like it?
etruj said:
running "sudo gnome-panel" gives me the panel while staying inside the original ubuntop. i think i can just swap out that one line in your script to get it working. thanks! also noticed my chrome crashes after a few minutes, ill post the error code and screen grabs soon but was wondering if you ever experienced anything like it?
Click to expand...
Click to collapse
Yes, in fact. It's a bus error, and I tried to fix it, but the fix doesn't work (and it only seems to affect Chromium).
Sorry for bumping such an old thread, but I was wondering if anyone wanted to take this project over, since I don't have an Atrix anymore and don't have anything to work with.
Thanks.
Hello folks!
Its been a while since i posted here - i havent been flashing roms for an age (kids etc got in the way!)
Anyway, i've picked up a Pixel 4 XL, and it was running a custom ROM, i'm trying to move back to stock and have been able to follow all the guides i've found up to using the 'fastboot flashall' in shell.
The command works and delivers the
Bootloader Version...:
Baseband Version.....:
Serial Number........:
values, but then errors out with the following error "fastboot: error: ANDROID_PRODUCT_OUT not set"
I'm stumped what that means and how to fix. I'm doing all of this on my Pixelbook, and have updated fastboot and adb as per the initial steps for flashing.
Can anyone shed any light on what i still need to do to get flashall to work as expected?
Thanks in advance if you are able to help out!
ptm
Welcome Back
Could you post the exact command you are using for fastboot flash please? It sounds like fastboot is not finding the files to flash. Usually, depending on the configuration of the fastboot install, it's easier to place the firmware in the same directory as the fastboot binary.
Thanks! It turns out i've missed this place!
So the firmware files are all on the chromebook and I've used 'shell' to navigate to where I've unzipped. Here's the command line with the command i'm using: "[email protected] ~/Downloads/ota_file $ fastboot flashall"
Before trying a full flash, i was trying to sideload the OTA as per instructions here https://developers.google.com/android/ota#instructions but moving the file from my pixelbook to the 4XL fails at 47% every time.
So i reverted to a full flash as per these instructions - https://developers.google.com/android/images and that is where i'm coming a cropper with the 'not set' error.
Thanks for your help!
ktmom said:
Welcome Back
Could you post the exact command you are using for fastboot flash please? It sounds like fastboot is not finding the files to flash. Usually, depending on the configuration of the fastboot install, it's easier to place the firmware in the same directory as the fastboot binary.
Click to expand...
Click to collapse
I thinnk you may be merging several approaches.
You are using the full factory image downloaded from the https://developers.google.com/android/images page, right? Then, once downloaded, you are unzipping the file and cd into the new directory (from the unzip). The command then should be
Code:
./flash-all.sh
As far as the OTA install is concerned, you are using the command
Code:
adb sideload "ota_file.zip"
, and at 47%, what happens that it appears to fail? My memory on my P3XL is at that point it takes awhile.
If you are using a C to C switch to an A to C cable and try it. You'll want to remove the wipe from the flash-all before you flash the full image and it's the flash all you should be using to flash.
Yeah i think you're right - so now just concentrating on the Full Flash method shown on the Google Developers page, and yes doing it exactly as you'd described.
Ok - using
Code:
./flash-all.sh
now returns the error
Code:
bash: ./flash-all.sh: Permission denied
I have tried to prefix './flash-all.sh' with 'Fastboot' but no dice here either. Is that required at all?
ktmom said:
I thinnk you may be merging several approaches.
You are using the full factory image downloaded from the https://developers.google.com/android/images page, right? Then, once downloaded, you are unzipping the file and cd into the new directory (from the unzip). The command then should be
Code:
./flash-all.sh
As far as the OTA install is concerned, you are using the command
Code:
adb sideload "ota_file.zip"
, and at 47%, what happens that it appears to fail? My memory on my P3XL is at that point it takes awhile.
Click to expand...
Click to collapse
ptm said:
Yeah i think you're right - so now just concentrating on the Full Flash method shown on the Google Developers page, and yes doing it exactly as you'd described.
Ok - using
Code:
./flash-all.sh
now returns the error
Code:
bash: ./flash-all.sh: Permission denied
I have tried to prefix './flash-all.sh' with 'Fastboot' but no dice here either. Is that required at all?
Click to expand...
Click to collapse
You need to give the "flash-all.sh" script execution rights (that is why the permission denied error). Use this code:
Code:
chmod +x ./flash-all.sh
You may need super user/root rights:
Code:
sudo chmod +x ./flash-all.sh
The "flash-all.sh" script is a stand-alone script that sequentially flashes the entire factory package. As was mentioned in another repsonse in this thread, in cases where you want to update, but not lose your installed user apps and data, you would edit the script and remove the "-w" augment. In this case, you are returning to stock and you should perform the wipe (-w).
The dot slash (./) that preceeds the flash-all.sh tells the bash interpreter (what runs commands you give) that the file is right here, in this directory.
The flash-all.sh is a standalone script (series of written instructions) and calls fastboot from within it.
Thanks for sticking with me on this ktmom!
OK, i've used both
Code:
chmod +x ./flash-all.sh
and
Code:
sudo chmod +x ./flash-all.sh
but still getting the permission denied error when i launch ./flash-all.sh
I'll do a screencast vid walking through the entire process i'm following, so that you can see what i'm up too and in case it gives any further clues for a solution.
Thanks again!
ktmom said:
You need to give the "flash-all.sh" script execution rights (that is why the permission denied error). Use this code:
Code:
chmod +x ./flash-all.sh
You may need super user/root rights:
Code:
sudo chmod +x ./flash-all.sh
The "flash-all.sh" script is a stand-alone script that sequentially flashes the entire factory package. As was mentioned in another repsonse in this thread, in cases where you want to update, but not lose your installed user apps and data, you would edit the script and remove the "-w" augment. In this case, you are returning to stock and you should perform the wipe (-w).
The dot slash (./) that preceeds the flash-all.sh tells the bash interpreter (what runs commands you give) that the file is right here, in this directory.
The flash-all.sh is a standalone script (series of written instructions) and calls fastboot from within it.
Click to expand...
Click to collapse
@ptm, No worries, I'll do my best to help. I'm typing this on a chromebook that I also use to fastboot to a P3XL.
Edit 1:
Just to make sure:
1) The bootloader is unlocked?
2) "fastboot devices" returns the serial number of your device?
3) you are running ./flash-all.sh command as root or as the default user? In other words, the same way that fastboot devices returns the serial number. Either sudo fastboot devices or just fastboot devices.
4) if you enter the linux command: ls -al flash-all.sh do you get something like:
-rwxr-xr-x. 1 chronos chronos 957 Jul 18 2019 flash-all.sh
In this example -rwxr-xr-x is depicting the file permissions where there are three groupings; owner group everyone else. The first rwx means read, write and execute permissions for the file owner. Others in the same group and everyone else has read and execute permissions. Execute (x) is required in order for a script to run. If your file does not have three x so that all three groups have permission to execute it, then we need to revisit that.
Edit 2:
Another thought that could be affecting you is ADB and Fastboot are old. in your crosh shell, type:
Code:
[email protected] ~ $ adb --version
Android Debug Bridge version 1.0.41
Version 29.0.5-5949299
[email protected] ~ $ fastboot --version
fastboot version 29.0.5-5949299
Installed as /usr/local/bin/fastboot
If either returns a version older than the output above, then the easy way to update these is to use the script on Nathan Chance's Githuib. This might look a little overwhelming but it's pretty easy. I suggest you read the page, but the operative information is in section 4. Run the setup script:
To install, run
Code:
curl -s https://raw.githubusercontent.com/nathanchance/chromeos-adb-fastboot/master/install.sh | bash
in your shell prompt.
This script very nicely updates your ADB/Fastboot to the newest version which will be required for your P4XL
Are you guys sure you aren't making it too hard? You don't have to give any commands to install the full image. Download the full image and put it into an empty folder, go ahead and extract it in that folder. Create another new folder, Copy everything into it so you still have the full image in the first folder. Now download the tools and put those into a folder and extract them in that folder. Take the entire contents of that folder and add it to the folder you copied the extracted image into. What you should have now is one folder that still has the full extracted image, one that has the full extracted tools, and one that has both. If you have not already done so the phone should have debugging enabled and oem should be on. Go ahead and put it into bootloader mode and plug it in, type cmd in the path bar of the folder with both tools and image and check devices which will tell you if the tools can see the phone. If you get your serial the tools can see the phone. If you're going to wipe you can go ahead and click the flash-all and it will start the process, you do not give any commands. If you don't want to wipe the edit the flash-all to remove the-w, save it, and click on it. Again, no command is given, you just click and the flash-all does the rest.
Edit... And dont forget, A to C, not the provided C to C.
krabman said:
Are you guys sure you aren't making it too hard? You don't have to give any commands to install the full image. Download the full image and put it into an empty folder, go ahead and extract it in that folder. Create another new folder, Copy everything into it so you still have the full image in the first folder. Now download the tools and put those into a folder and extract them in that folder. Take the entire contents of that folder and add it to the folder you copied the extracted image into. What you should have now is one folder that still has the full extracted image, one that has the full extracted tools, and one that has both. If you have not already done so the phone should have debugging enabled and oem should be on. Go ahead and put it into bootloader mode and plug it in, type cmd in the path bar of the folder with both tools and image and check devices which will tell you if the tools can see the phone. If you get your serial the tools can see the phone. If you're going to wipe you can go ahead and click the flash-all and it will start the process, you do not give any commands. If you don't want to wipe the edit the flash-all to remove the-w, save it, and click on it. Again, no command is given, you just click and the flash-all does the rest.
Edit... And dont forget, A to C, not the provided C to C.
Click to expand...
Click to collapse
What Tools do you need to do this?
Same page as the images, scroll up from them and in the description of the process they have a link to the platform tools.
@krabman, Since this is using a chromebook, not a PC, things are flakier than normal. I just replicated the problems experienced by @ptm and some of it is due to old ADB/Fastboot as described in my previous post. Some is because ChromeOS made a change in an update that mounts nearly all of the partitions noexec, which means scripts can not execute and give the reported, "no permissions" error. There is a workaround since /usr/local is mounted executable. It's also possible to remount a partition with exec permissions.
@ptm, as the easiest route, I suggest making sure the ABD is current using the script I linked yesterday, and then going back to the OTA sideload method. I tanked my phone for a few hours yesterday trying to make fastboot get through the entire system image. I finally resorted to my full ubuntu install on my chromebook.
airmaxx23 said:
What Tools do you need to do this?
Click to expand...
Click to collapse
A general Fastboot/ADB tutorial is available here. If you are not using a chromebook, this thread's discussion will just add confusion.
If you are using a chromebook, then you need to enter a crosh shell, make sure adb and fastboot are updated as described in an earlier post and read the rest of the information I posted about the associated problems.
My understanding is the sh should flash on chrome with the latest tools as I described and you use the bat for PC. If the device is down he would have nothing to lose trying, if not I'd be leery of trying it since a partial flash will definitely result in a softie. Of course the possibility that I don't fully understand it may explain my puzzlement.
ktmom said:
A general Fastboot/ADB tutorial is available here. If you are not using a chromebook, this thread's discussion will just add confusion.
If you are using a chromebook, then you need to enter a crosh shell, make sure adb and fastboot are updated as described in an earlier post and read the rest of the information I posted about the associated problems.
Click to expand...
Click to collapse
Thanks, I know how to use ADB on the PC but I have a ChromeBook that I'd like to use as well. I already have it in Developer Mode.
I got it working, I just to run the script to update ADB and Fastboot.
airmaxx23 said:
Thanks, I know how to use ADB on the PC but I have a ChromeBook that I'd like to use as well. I already have it in Developer Mode.
When I open a Crosh Window, type shell, then adb devices my Pixel 4 XL shows up but I get: no permissions; see [http://developer.android.com/tools/device.html]
Click to expand...
Click to collapse
My bet is your ADB/fastboot are to old. Go back to post 9 and read the lower portion under edit2. You should also read forward from that point as there are additional issues that ChromeOS introduced with the noexec mounting of partitions. It will mean that without a workaround, you can not execute the flash-all.sh.
ktmom said:
My bet is your ADB/fastboot are to old. Go back to post 9 and read the lower portion under edit2. You should also read forward from that point as there are additional issues that ChromeOS introduced with the noexec mounting of partitions. It will mean that without a workaround, you can not execute the flash-all.sh.
Click to expand...
Click to collapse
Hey there,
SO i decided to try the OTA sideload method on a friends PC - i got the following response through CMD prompt
Code:
C:\Users\LYALL\Downloads>adb sideload ota-file.zip
Total xfer: 1.00x 1
However the phone is reporting a failure verifying the file signature and giving
Code:
E: Error code: 21
What do you think is causing that? I saw that Google has a new browser based flash tool to allow for AOSP builds to flash - would using that work better for me do you think?
ptm
ptm said:
Hey there,
SO i decided to try the OTA sideload method on a friends PC - i got the following response through CMD prompt
Code:
C:\Users\LYALL\Downloads>adb sideload ota-file.zip
Total xfer: 1.00x 1
However the phone is reporting a failure verifying the file signature and giving
Code:
E: Error code: 21
What do you think is causing that? I saw that Google has a new browser based flash tool to allow for AOSP builds to flash - would using that work better for me do you think?
ptm
Click to expand...
Click to collapse
Make sure you have downloaded the correct OTA and for crosshatch coral. Use the sha256 checksum provided in the download page and ensure the file is not corrupted. I check the integrity of the file before using it especially if I've moved it since the last verification.
You are rebooting to recovery (not rescue mode) and using the OTA sideload action from *within* recovery, before using the adb command, right?
The Google update and repair tool is an option.
ktmom said:
Make sure you have downloaded the correct OTA and for crosshatch. Use the sha256 checksum provided in the download page and ensure the file is not corrupted. I check the integrity of the file before using it especially if I've moved it since the last verification.
You are rebooting to recovery (not rescue mode) and using the OTA sideload action from *within* recovery, before using the adb command, right?
The Google update and repair tool is an option.
Click to expand...
Click to collapse
I think Pixel 4 XL is Coral, not Crosshatch.
I have downloaded the OTA file thats third from the bottom on this page (https://developers.google.com/android/ota) which is the rom number - 10.0.0 (QQ1B.200105.004, Jan 2020).
Yes, followed the instructions and booted to recovery, selected 'update from adb' from within recovery and then checked
Code:
adb devices
to ensure it showed 'sideload'. I then ran the command
Code:
adb sideload ota_file.zip
The transfer seemed to work fine, but then i got the error above showing on the device.
I cant seem to use the Google update and repair tool, as I'm in the UK and it says its not supported.
I can get it working with a VPN but the carrier i'm on doesnt show, although i do have the option of selecting 'other' as the carrier - I'm happy to give that a go, but wanted to get your thoughts on it first. Will selecting carrier as 'other' work ok for a UK based phone?
ptm