Related
I'd like to make a few changes in the services.odex file, and I want to make sure I do it correctly the first time, so I'd like to run this by everyone for comments/corrections.
So far, these are the steps that I *think* are correct:
1. Pull /system/framework/* files onto my PC.
2. On the PC, baksmali the services.odex.
3. Makes the changes to whatever .smali file I wish.
4. Rebuild services.dex via smali (using the output dir created by baksmali).
5. Insert services.dex into services.jar (using, say, WinRAR).
6. Push the new services.jar onto /sdcard and then copy it over to /system/framework dir.
7. Reboot and pray it works.
Is this correct?
---
EDIT: See my reply below for the answer.
Should I post this question over in the "Captivate Android Development" forum? Anyone?
Small bump for this post, interested in the correct procedure for this too.
[A] Here are the steps
Yeah, it took me a week of digging to find this answer.
Disclaimer:
1. Proceed at your own risk and don't blame me if you brick your phone.
2. While I've done my best to document the steps I took, there's always a chance I've mistyped something.
3. If you're unsure at any point, STOP! Re-read everything so you fully understand what you're doing.
4. Editing .odex files can be extremely tricky! All it takes is a bad edit to royally screw up your phone.
This guide assumes:
* you have a Captivate and it's running stock Eclair. (Don't know about other phones or other OSes.)
* you have rooted your phone, and have busybox & Superuser Permissions installed.
* you have adb installed and working on a PC.
* you have baksmali and smali installed and working on a PC (along with Java).
* you have downloaded the utility "dexopt-wrapper". (Do a search - you'll find it.)
* you know what the BOOTCLASSPATH value is for your phone. (Hint: It's in /init.rc)
* you have made a complete backup of your phone! (Yes, if something goes wrong, it's much nicer to be able to restore files from a recent backup than to have to wipe the phone and start from scratch again.)
- I highly recommend you install ROM Manager w/ ClockworkMod. (And don't delete /sdcard/update.zip)
Notations:
When you see a line beginning with >, that's a command to be executed on the PC.
When you see a line beginning with #, that's a command to be executed on the phone.
Ready? Here we go:
put the dexopt-wrapper onto your phone.
> adb push dexopt-wrapper /sdcard
copy all of the /system/framework files onto your PC.
> adb pull /system/framework
let's pretend you want to change something in services.odex.
decompile the .odex file
> baksmali -x services.odex -o services.out
now edit whatever .smali file you want in the services.out folder.
rebuild the classes.dex file for services.odex.
> smali -o classes.dex services.out
now put classes.dex into services.jar (I used WinRAR, but other ZIP utilities should work.)
put the new .jar file onto your phone.
> adb push services.jar /sdcard
> adb shell
become super user
# su
put the dexopt-wrapper utility into the bin folder with the correct permissions. (you only need to do this once, obviously.)
# cd /system/bin
# busybox cp /sdcard/dexopt-wrapper .
# busybox chmod 755 dexopt-wrapper
# cd /sdcard
create a new .odex file from the new .jar file
# dexopt-wrapper services.jar new.odex [BOOTCLASSPATH]
yes, fill in the value of BOOTCLASSPATH, without the []
here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
hint: the file size of the new.odex file should not change!
# busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
now replace the old .odex file with the new .odex file.
# cd /system/framework
# busybox cp /sdcard/new.odex services.odex
# busybox chmod 644 services.odex
and you're done.
# sync
# reboot
Now, if all goes well, your phone should reboot normally.
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
software_samurai said:
Yeah, it took me a week of digging to find this answer.
Disclaimer:
1. Proceed at your own risk and don't blame me if you brick your phone.
2. While I've done my best to document the steps I took, there's always a chance I've mistyped something.
3. If you're unsure at any point, STOP! Re-read everything so you fully understand what you're doing.
4. Editing .odex files can be extremely tricky! All it takes is a bad edit to royally screw up your phone.
This guide assumes:
* you have a Captivate and it's running stock Eclair. (Don't know about other phones or other OSes.)
* you have rooted your phone, and have busybox & Superuser Permissions installed.
* you have adb installed and working on a PC.
* you have baksmali and smali installed and working on a PC (along with Java).
* you have downloaded the utility "dexopt-wrapper". (Do a search - you'll find it.)
* you know what the BOOTCLASSPATH value is for your phone. (Hint: It's in /init.rc)
* you have made a complete backup of your phone! (Yes, if something goes wrong, it's much nicer to be able to restore files from a recent backup than to have to wipe the phone and start from scratch again.)
- I highly recommend you install ROM Manager w/ ClockworkMod. (And don't delete /sdcard/update.zip)
Notations:
When you see a line beginning with >, that's a command to be executed on the PC.
When you see a line beginning with #, that's a command to be executed on the phone.
Ready? Here we go:
put the dexopt-wrapper onto your phone.
> adb push dexopt-wrapper /sdcard
copy all of the /system/framework files onto your PC.
> adb pull /system/framework
let's pretend you want to change something in services.odex.
decompile the .odex file
> baksmali -x services.odex -o services.out
now edit whatever .smali file you want in the services.out folder.
rebuild the classes.dex file for services.odex.
> smali -o classes.dex services.out
now put classes.dex into services.jar (I used WinRAR, but other ZIP utilities should work.)
put the new .jar file onto your phone.
> adb push services.jar /sdcard
> adb shell
become super user
# su
put the dexopt-wrapper utility into the bin folder with the correct permissions. (you only need to do this once, obviously.)
# cd /system/bin
# busybox cp /sdcard/dexopt-wrapper .
# busybox chmod 755 dexopt-wrapper
# cd /sdcard
create a new .odex file from the new .jar file
# dexopt-wrapper services.jar new.odex [BOOTCLASSPATH]
yes, fill in the value of BOOTCLASSPATH, without the []
here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
hint: the file size of the new.odex file should not change!
# busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
now replace the old .odex file with the new .odex file.
# cd /system/framework
# busybox cp /sdcard/new.odex services.odex
# busybox chmod 644 services.odex
and you're done.
# sync
# reboot
Now, if all goes well, your phone should reboot normally.
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
Click to expand...
Click to collapse
Thanks, was really useful for me
awsome thx
super thanks for guide
Strange... all thanks but nothing to add?
I had to install the new Android SDK r16 because of buggy "adb" executable (my fault).
http://developer.android.com/sdk/index.html
Newest version smali/baksmali v1.3.0 has been used.
Helpfull page:
http://code.google.com/p/smali/wiki/DeodexInstructions
Copied whole "/system/framework" to my current working folder (reason in command below).
Code:
baksmali -c /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar -a 10 -x Mms.odex -o Mms.out
Already had to put "BOOTCLASSPATH" in this command with "-c" option, else I would get an error stating. "Error occured while loading boot class path files.".
With new baksmali you have to put in the Android SDK api-level with option "-a" of the current Android OS you're working on. For Gingerbread numbers 10-13 work, but 14 (ICS) doesn't work anymore.
Api levels are stated right at the beginning on each "Android X.X Platform" links on the left side of Android SDK page (mentioned above).
For the most part this guide was perfect, but since a lot has been updated I felt this guide needed a minor update too!
to get quicker answers to non-captivate specific questions (without a week of searching) ask android software questions in the XDA > Android OS > fourms instead of the XDA>Captivate fourms.
the Captivate forums are not a frequent stop for experienced programmers and developers to find and answer these type of questions.
software_samurai said:
Yeah, it took me a week of digging to find this answer.
Disclaimer:
1. Proceed at your own risk and don't blame me if you brick your phone.
2. While I've done my best to document the steps I took, there's always a chance I've mistyped something.
3. If you're unsure at any point, STOP! Re-read everything so you fully understand what you're doing.
4. Editing .odex files can be extremely tricky! All it takes is a bad edit to royally screw up your phone.
This guide assumes:
* you have a Captivate and it's running stock Eclair. (Don't know about other phones or other OSes.)
* you have rooted your phone, and have busybox & Superuser Permissions installed.
* you have adb installed and working on a PC.
* you have baksmali and smali installed and working on a PC (along with Java).
* you have downloaded the utility "dexopt-wrapper". (Do a search - you'll find it.)
* you know what the BOOTCLASSPATH value is for your phone. (Hint: It's in /init.rc)
* you have made a complete backup of your phone! (Yes, if something goes wrong, it's much nicer to be able to restore files from a recent backup than to have to wipe the phone and start from scratch again.)
- I highly recommend you install ROM Manager w/ ClockworkMod. (And don't delete /sdcard/update.zip)
Notations:
When you see a line beginning with >, that's a command to be executed on the PC.
When you see a line beginning with #, that's a command to be executed on the phone.
Ready? Here we go:
put the dexopt-wrapper onto your phone.
> adb push dexopt-wrapper /sdcard
copy all of the /system/framework files onto your PC.
> adb pull /system/framework
let's pretend you want to change something in services.odex.
decompile the .odex file
> baksmali -x services.odex -o services.out
now edit whatever .smali file you want in the services.out folder.
rebuild the classes.dex file for services.odex.
> smali -o classes.dex services.out
now put classes.dex into services.jar (I used WinRAR, but other ZIP utilities should work.)
put the new .jar file onto your phone.
> adb push services.jar /sdcard
> adb shell
become super user
# su
put the dexopt-wrapper utility into the bin folder with the correct permissions. (you only need to do this once, obviously.)
# cd /system/bin
# busybox cp /sdcard/dexopt-wrapper .
# busybox chmod 755 dexopt-wrapper
# cd /sdcard
create a new .odex file from the new .jar file
# dexopt-wrapper services.jar new.odex [BOOTCLASSPATH]
yes, fill in the value of BOOTCLASSPATH, without the []
here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
hint: the file size of the new.odex file should not change!
# busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
now replace the old .odex file with the new .odex file.
# cd /system/framework
# busybox cp /sdcard/new.odex services.odex
# busybox chmod 644 services.odex
and you're done.
# sync
# reboot
Now, if all goes well, your phone should reboot normally.
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
Click to expand...
Click to collapse
excuse me, where to find the "dexopt_wrapper"? i can't find it anywhere!
Search with Google. You'll find it that way.
Daniel D. said:
Search with Google. You'll find it that way.
Click to expand...
Click to collapse
i found a dexopt in my /system/bin directory. 9.63k
is it the dexopt-wrapper i needed?
if it is, should i rename it to 'dexopter-wrapper' to use it?
software_samurai said:
Yeah, it took me a week of digging to find this answer.
Disclaimer:
1. Proceed at your own risk and don't blame me if you brick your phone.
2. While I've done my best to document the steps I took, there's always a chance I've mistyped something.
3. If you're unsure at any point, STOP! Re-read everything so you fully understand what you're doing.
4. Editing .odex files can be extremely tricky! All it takes is a bad edit to royally screw up your phone.
This guide assumes:
* you have a Captivate and it's running stock Eclair. (Don't know about other phones or other OSes.)
* you have rooted your phone, and have busybox & Superuser Permissions installed.
* you have adb installed and working on a PC.
* you have baksmali and smali installed and working on a PC (along with Java).
* you have downloaded the utility "dexopt-wrapper". (Do a search - you'll find it.)
* you know what the BOOTCLASSPATH value is for your phone. (Hint: It's in /init.rc)
* you have made a complete backup of your phone! (Yes, if something goes wrong, it's much nicer to be able to restore files from a recent backup than to have to wipe the phone and start from scratch again.)
- I highly recommend you install ROM Manager w/ ClockworkMod. (And don't delete /sdcard/update.zip)
Notations:
When you see a line beginning with >, that's a command to be executed on the PC.
When you see a line beginning with #, that's a command to be executed on the phone.
Ready? Here we go:
put the dexopt-wrapper onto your phone.
> adb push dexopt-wrapper /sdcard
copy all of the /system/framework files onto your PC.
> adb pull /system/framework
let's pretend you want to change something in services.odex.
decompile the .odex file
> baksmali -x services.odex -o services.out
now edit whatever .smali file you want in the services.out folder.
rebuild the classes.dex file for services.odex.
> smali -o classes.dex services.out
now put classes.dex into services.jar (I used WinRAR, but other ZIP utilities should work.)
put the new .jar file onto your phone.
> adb push services.jar /sdcard
> adb shell
become super user
# su
put the dexopt-wrapper utility into the bin folder with the correct permissions. (you only need to do this once, obviously.)
# cd /system/bin
# busybox cp /sdcard/dexopt-wrapper .
# busybox chmod 755 dexopt-wrapper
# cd /sdcard
create a new .odex file from the new .jar file
# dexopt-wrapper services.jar new.odex [BOOTCLASSPATH]
yes, fill in the value of BOOTCLASSPATH, without the []
here's the "special sauce": copy over the "signature" from the current .odex file into the new .odex file. do NOT continue until this command succeeds!
hint: the file size of the new.odex file should not change!
# busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
now replace the old .odex file with the new .odex file.
# cd /system/framework
# busybox cp /sdcard/new.odex services.odex
# busybox chmod 644 services.odex
and you're done.
# sync
# reboot
Now, if all goes well, your phone should reboot normally.
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
Click to expand...
Click to collapse
very well written guide for begginers, all other guides i tried were so confusing. thanks
software_samurai said:
However, if something has not gone well, you'll hear the bootup sounds, but the screen will be "stuck" on the first white logo screen. That means the new .odex file was not accepted. What to do? Well, first, (and with all do respect) Don't Panic! Plug in the USB line and issue:
> adb reboot recovery
That should drop you into the recovery. "Apply Updates" and that will get you into ClockworkMod. Then you can restore the /system files from your full backup (the one you did RIGHT BEFORE doing any of this, right?) and be back up and running in just a few minutes. (Yeah, I had to do this many times. It's scary the first time, but you get use to it after a while.)
Good luck!
Click to expand...
Click to collapse
If you backup the original services.odex before you replace it with the modified one then if you get stuck in a bootloop you can just use adb shell commands to copy it back and then do adb reboot. This worked for me anyways. Faster then doing a full restore.
Of course you should still to a backup beforehand.
Since I was looking to be able to update my phone, I had to remove the WebtopMod. Since the previous instructions required me to root my phone to remove it, which was counterproductive because it would mean loosing the ability to update anyway. I looked through the WebtopMod installation scripts and came up with this guide to remove it:
View attachment WebtopModRemoveGuideNoRoot.txt
Note: I've attached the guide in a separate file, because the forum is stupid and thinks that exe, bak, odex, apk, and dex are valid TLD's and says I can't post external links. If I ever get "approximately eight" posts I'll put it in this post.
If you don't have the original backup files, look in page 3 of the howto post for removing it with root. (Thanks, MotoAtrixFan for posting it and twoeleven99 for alerting me to this)
Happy Updating!
eliplan312 said:
Since I was looking to be able to update my phone, I had to remove the WebtopMod. Since the previous instructions required me to root my phone to remove it, which was counterproductive because it would mean loosing the ability to update anyway. I looked through the WebtopMod installation scripts and came up with this guide to remove it:
View attachment 556542
Note: I've attached the guide in a separate file, because the forum is stupid and thinks that exe, bak, odex, apk, and dex are valid TLD's and says I can't post external links. If I ever get "approximately eight" posts I'll put it in this post.
If you don't have the original backup files, look in page 3 of the howto post for removing it with root. (Thanks, MotoAtrixFan for posting it and twoeleven99 for alerting me to this)
Happy Updating!
Click to expand...
Click to collapse
you can update even if you are rooted you cant update only when you modify the /system or some apps
went step by step through your guide and I still cannot update - the apply_patch_check still fails at DockProvider.apk - aside from reflashing the stock SBF, what do you recommend?
Try this
Try setting the phone to usb mass storage mode and replacing the files in the WebtopModBackup folder on the sd/media area with these: View attachment WebtopModBackup.zip
The files in the archive worked for me, not sure why it wouldn't work. If those don't work for you, please post the console log.
eliplan312 said:
Try setting the phone to usb mass storage mode and replacing the files in the WebtopModBackup folder on the sd/media area with these: View attachment 556596
The files in the archive worked for me, not sure why it wouldn't work. If those don't work for you, please post the console log.
Click to expand...
Click to collapse
Thanks, but something appears to be totally screwed up on my DockProvider and DockService applications on Titanium Backup - they are listed at the bottom with grey slashes through them. The crazy part is.... it works with the webtop hack, but the update doesn't see the correct files, so something is obviously messed up.
Now, by putting the files from the WebtopModBackup on the phone, shouldn't that fix the issue? Then perform the steps in your text doc? I can't believe I'll have to SBF stock in order to fix the stupid DockProvider and DockService!!
What I meant was, replace the files in the WebtopModBackup folder with the stuff in the archive, then re-do the instruction in the text file.
I'm sorry but your instructions aren't working for me. I've followed your instructions very carefully but when I get to the command
cd /mnt/sdcard/WebtopModBackup
I get a directory not found error.
I can change to /mnt/sdcard but when I type 'ls' nothing appears. The directory is empty.
What am I doing wrong?
One thing I've noticed is that when I enter the 'adb.exe shell ./data/local/tmp/psneuter' command, the phone appears to dismount and remount and then when I go into the shell the '/mnt/sdcard' directory is empty.
Yeah I'm also having that problem....I'm trying to push the backup files into the correct folder. However, when I get a read-only error, so from what I read I'm supposed to reboot into recovery mode. When I try to do this the recovery console says e: can't open/cache/recovery/command and I can't connect to my phone. Any help?
To start I want to say Thank you to the OP for posting this. But there are a few errors, so I hope I can help.
To anyone having issues with this, there are a few things that you must have to make this work.
Note this only works for AT&T Atrix as I do not have a Bell Atrix
#1; THE 1st PART DOES NOT WORK if you performed the update. You should be rooted. You can check to see if you updated by pressing menu --> settings --> about phone and your Build version says something like OLYFR_U4_1.5.7 it will not work, you need to skip down to my next post of my coding since you should already be rooted. The 1st part of this uses the method that made rooting possible, since that was removed with the update, it no longer applies. So if you are updated, you should already be rooted and can skip a few steps
#2; You must have a folder called WebTopModBackup with the .bak files in it on the internal memory (not your memory card but the fake internal one). Open the app called Files, select Internal phone storage, select the WebTopModBackup folder and make sure you see the following files, if not you need to get them
Code:
DockProvider.apk.bak
DockProvider.odex.bak
DockService.apk.bak
DockService.odex.bak
PortalApp.apk.bak
PortalApp.odex.bak
#3; Do not mount your sdcard. When you plug in your USB cable to the compter, pull down the drop menu, select the USB connection and make sure None is selected; then press ok. If one of the other options are selected, select None press ok and wait for 30 seconds for the internal and external cards to mount. @Phazoni more than likely this is your issue
#4; USB debugging must be turned on. Press menu --> settings --> applications --> development --> and check USB debugging if not checked
#5; Make sure you have at least 50% battery, just in case
#6; During the steps you mount (make it editable) the /system folder where the files are, if you get a read-only error you did not do step
mount -o rw,remount /dev/block/mmcblk0p12 /system
correctly or your phone is somehow not rooted.
Click to expand...
Click to collapse
Ok now let's look at the code in the OP
Code:
adb.exe push psneuter /data/local/tmp
adb.exe shell chmod 755 /data/local/tmp/psneuter
adb.exe shell ./data/local/tmp/psneuter
adb.exe shell
adb.exe push is the command to copy a file to your phone; so we are making a copy of psneuter and putting it on the phone.
adb.exe shell chmod 755 this gives premission to the phone to use the psneuter file
adb.exe shell ./ this makes the psneuter file run and creates a fake root
adb.exe shell this should really be typed as adb shell but whatever. This takes you into the phone's system to edit the files. While in adb, the line should start with a # if it is a $ then psneuter did not work. Just to try, type su and see if the $ changes to a # if it does continue
Code:
cd /mnt/sdcard/WebtopModBackup
This command takes you to the location of your backup, remeber step 2 & 3, if this folder is empty and you cannot get to it, you have an issue there
Code:
mv DockProvider.apk.bak DockProvider.apk
mv DockProvider.odex.bak DockProvider.odex
mv DockService.apk.bak DockService.apk
mv DockService.odex.bak DockService.odex
mv PortalApp.apk.bak PortalApp.apk
mv PortalApp.odex.bak PortalApp.odex
Personally this is not the best way to do this (rename the files by making copies and then making more copies), but not my code. The mv command moves a file. In this case you are only using it to rename the files removing the .bak from the end. See my code at the bottom
Code:
mount -o rw,remount /dev/block/mmcblk0p12 /system
This mounts the /system folder so you can edit the system files
Code:
cp DockProvider.apk /system/app/
cp DockProvider.odex /system/app/
cp DockService.apk /system/app/
cp DockService.odex /system/app/
cp PortalApp.apk /system/app/
cp PortalApp.odex /system/app/
This code copies the files into the original locations as the correct name. This assumes you are still in the folder where the backups are. If this fails, the /system folder is not mounted, the files are missing or you are in a different folder. This is also missing the chmod /system/app/* coding. I will cover that below
Code:
rm /data/dalvik-cache/[email protected]*.dex
rm /data/dalvik-cache/[email protected]*.dex
rm /data/dalvik-cache/[email protected]*.odex
rm /data/dalvik-cache/[email protected]*.odex
rm is the command to remove/delete a file, running these 4 commands will remove the system cache and will most likely cause your phone to reboot before the next step; that is ok.
Code:
reboot now
This reboots the phone and removes the temp root.
Click to expand...
Click to collapse
See my next post for my coding
AGAIN
Note this only works for AT&T Atrix as I do not have a Bell Atrix
#1; THE 1st PART DOES NOT WORK if you performed the update. You should be rooted. You can check to see if you updated by pressing menu --> settings --> about phone and your Build version says something like OLYFR_U4_1.5.7 it will not work, you need to skip down to my next post of my coding since you should already be rooted. The 1st part of this uses the method that made rooting possible, since that was removed with the update, it no longer applies. So if you are updated, you should already be rooted and can skip a few steps
#2; You must have a folder called WebTopModBackup with the .bak files in it on the internal memory (not your memory card but the fake internal one). Open the app called Files, select Internal phone storage, select the WebTopModBackup folder and make sure you see the following files, if not you need to get them
Code:
DockProvider.apk.bak
DockProvider.odex.bak
DockService.apk.bak
DockService.odex.bak
PortalApp.apk.bak
PortalApp.odex.bak
#3; Do not mount your sdcard. When you plug in your USB cable to the compter, pull down the drop menu, select the USB connection and make sure None is selected; then press ok. If one of the other options are selected, select None press ok and wait for 30 seconds for the internal and external cards to mount. @Phazoni more than likely this is your issue
#4; USB debugging must be turned on. Press menu --> settings --> applications --> development --> and check USB debugging if not checked
#5; Make sure you have at least 50% battery, just in case
#6; During the steps you mount (make it editable) the /system folder where the files are, if you get a read-only error you did not do step
mount -o rw,remount /dev/block/mmcblk0p12 /system
correctly or your phone is somehow not rooted.
Click to expand...
Click to collapse
NOW for my recommended coding
After you follow my 6 steps above do the following
#1. on your compter press start --> run --> Type cmd this will open the command prompt for windows. Then navigate to the folder where the original WebTopMod files are located.
#2a. If are rooted jump down to step 4
#2. If you are not rooted and have not updated your phone type the following letter for letter
Code:
adb push psneuter /data/local/tmp
adb shell
You will now be in the ADB shell.
#3. You should see a $ so type the following
Code:
chmod 755 /data/local/tmp/psneuter
./data/local/tmp/psneuter
#4 This will kick you out of ADB, wait for it and when it does count to 30 for adb to reset. Now type the following:
Code:
adb shell
#5. You should see the # sign, if you see $ type su to change it since you should be rooted either by rooting the phone or using steps 1-3 above for pre-update.
Code:
mount -o rw,remount /dev/block/mmcblk0p12 /system
cp /mnt/sdcard/WebtopModBackupDockProvider.apk.bak /system/app/DockProvider.apk
cp /mnt/sdcard/WebtopModBackupDockProvider.odex.bak /system/app/DockProvider.odex
cp /mnt/sdcard/WebtopModBackupDockService.apk.bak /system/app/DockService.apk
cp /mnt/sdcard/WebtopModBackupDockService.odex.bak /system/app/DockService.odex
cp /mnt/sdcard/WebtopModBackupPortalApp.apk.bak /system/app/PortalApp.apk
cp /mnt/sdcard/WebtopModBackupPortalApp.odex.bak /system/app/PortalApp.odex
chmod 644 /system/app/*
rm /data/dalvik-cache/[email protected]*.dex
rm /data/dalvik-cache/[email protected]*.dex
rm /data/dalvik-cache/[email protected]*.odex
rm /data/dalvik-cache/[email protected]*.odex
reboot now
This
1. mounts the /system folder so you can replace the files then
2. renames nd copies the back-up files to the original locations in one step
3. Then the chmod 644 command sets the correct premissions for the files so they work,
4. clears the cache and
5. reboots the phone.
Click to expand...
Click to collapse
I hope this helps anyone stuck
I wanted to use USB Tunnel to share my PC's internet connection with the phone, but I got the error:
Code:
- exec '/system/bin/sh' failed: No such file or directory (2) -
I tried to install other APK's through ADB and they also failed, so I googled this error and I saw that the main issue is a failing ADB Shell. I tried to open Shell and I got the same error. The difference between me and the other users is that my phone is booting as usual, USB Mass Storage works, the phone is detected by fastboot- and adb devices commands and everything is working as intended, except for installing APKs through ADB/opening Shell.
Here is my phone's current config:
MeDroidMod 1.4.4 w/ HWA
Latest Tiamat kernel
TexasICE HBOOT w/ 210/8/218 partition layout
4GB microSD card...I don't know the filesystem but it's definitely NOT ext4, so there's not A2SD for me (I think it's FAT or FAT32)
ClockWorkMod Recovery
gnexus47 said:
I wanted to use USB Tunnel to share my PC's internet connection with the phone, but I got the error:
Code:
- exec '/system/bin/sh' failed: No such file or directory (2) -
I tried to install other APK's through ADB and they also failed, so I googled this error and I saw that the main issue is a failing ADB Shell. I tried to open Shell and I got the same error. The difference between me and the other users is that my phone is booting as usual, USB Mass Storage works, the phone is detected by fastboot- and adb devices commands and everything is working as intended, except for installing APKs through ADB/opening Shell.
Here is my phone's current config:
MeDroidMod 1.4.4 w/ HWA
Latest Tiamat kernel
TexasICE HBOOT w/ 210/8/218 partition layout
4GB microSD card...I don't know the filesystem but it's definitely NOT ext4, so there's not A2SD for me (I think it's FAT or FAT32)
ClockWorkMod Recovery
Click to expand...
Click to collapse
Which adb commands did you use? Can you list the commands here that you had used? It could be that you didn't issue su command to get superuser rights?
you don't need to be in Shell to push apk
put the apk on your C: drive
open command window and navigate to the folder you have adb/fastboot in--normally tools of your sdk
then:
type adb devices--then
1. adb remount
2. adb push C:/CalendarGoogle.apk /system/app/CalendarGoogle.apk
3. adb push C:/CalendarProvider.apk /system/app/CalendarProvider.apk
4. adb shell
7. chmod 777 system/app/CalendarGoogle.apk
11. chmod 777 system/app/CalendarProvider.apk
12. exit
13. Reboot
use the apk name of whatever you are flashing in place of mine and your chmod may not be exactly like mine--
ADB Shell
rugmankc said:
you don't need to be in Shell to push apk
put the apk on your C: drive
open command window and navigate to the folder you have adb/fastboot in--normally tools of your sdk
then:
type adb devices--then
1. adb remount
2. adb push C:/CalendarGoogle.apk /system/app/CalendarGoogle.apk
3. adb push C:/CalendarProvider.apk /system/app/CalendarProvider.apk
4. adb shell
7. chmod 777 system/app/CalendarGoogle.apk
11. chmod 777 system/app/CalendarProvider.apk
12. exit
13. Reboot
use the apk name of whatever you are flashing in place of mine and your chmod may not be exactly like mine--
Click to expand...
Click to collapse
I don't use ADB Shell to push APK's. That's just another thing which doesn't work.
@taodan: I only use: adb install xxxxx.apk.
A work around is to mount the sdcard and drag and drop the apks to the sdcard. Then install using your favorite file manager.
evilkorn said:
A work around is to mount the sdcard and drag and drop the apks to the sdcard. Then install using your favorite file manager.
Click to expand...
Click to collapse
that will work too, i've used root explorer to copy paste from sdcard to correct file location. prefer adb. set your permissions after
did you try adb remount first, not sure if that would help
what i was saying is you don't need to type adb shell. assuming you are doing this from a pc command terminal window.
you can use the commands I gave above to push apk. i think when you push it copies apk to phone leaving apk on pc also. install actually moves it to phone--as i understand it
here is some links and info that might help.*
http://www.talkandroid.com/guides/beginner/install-apk-files-on-android/#.T2-cdaJST3U
http://www.brighthub.com/mobile/google-android/articles/37151.aspx
also, have you ever had luck installing/pushing apk's. you may not have the correct environmental path on pc or are typing incorrect path in your command line
you can google environmental path editing for android and get examples of how to do it--i am not even sure mine is set right since I still have to type the full path in command window to use adb
sorry if this is old news just trying to find your problem
Hello guys, i have a bit of a problem here.
Earlier last August I had a family friend root my HTC One for me, load up a few roms, and told me to test some out. Months and months later, I have some knowledge of ADB, test out tons of roms, and love my phone.
The issue is I STILL have these 3 roms on my phone, and I cannot for the life of me get rid of them!
now it's hard to explain exactly whats up, but I will do my best!
In recovery, which is currently CWM v 6.0.4.6, I hit -> install zip, choose zip from /sdcard and at the very bottom of the list I have
ARHD 12, Trickdroid, and ViperOne
I can NEVER find these with any explorer, cannot search for them, or find them anywhere on my device. Does anyone have any idea what I can do?
Also to help clarify, if I download a rom in say google chrome, I need to hit /0/ after I hit "choose zip from /sdcard" in order to find it under downloads.
Any help would be awesome. Sorry if this is in the wrong area, I don't post often.
katsock said:
In recovery, which is currently CWM v 6.0.4.6, I hit -> install zip, choose zip from /sdcard and at the very bottom of the list I have
ARHD 12, Trickdroid, and ViperOne
I can NEVER find these with any explorer, cannot search for them, or find them anywhere on my device. Does anyone have any idea what I can do?
Click to expand...
Click to collapse
I think the files are located in /data/media. You can find them with a root explorer (if not running as root, /data will just appear empty). Or you can use ADB (not a terminal emulator on your phone, that won't work). To see these files, you type:
Code:
adb shell ls /mnt/shell/emulated
To delete a file, you type:
Code:
adb shell rm "/mnt/shell/emulated/Some-Rom.zip"
FYI, /sdcard another directory, which links to another directory, etc., with the final location being /data/media/0. Most file-type data is stored in /data/media, but the files outside "0" aren't meant to be accessed directly. But since we still need access at times for various reasons, if you're using the ADB shell, you can see the contents of this folder by using the "magic" path "/mnt/shell/emulated".
fenstre said:
I think the files are located in /data/media. You can find them with a root explorer (if not running as root, /data will just appear empty). Or you can use ADB (not a terminal emulator on your phone, that won't work). To see these files, you type:
Code:
adb shell ls /mnt/shell/emulated
To delete a file, you type:
Code:
adb shell rm "/mnt/shell/emulated/Some-Rom.zip"
FYI, /sdcard another directory, which links to another directory, etc., with the final location being /data/media/0. Most file-type data is stored in /data/media, but the files outside "0" aren't meant to be accessed directly. But since we still need access at times for various reasons, if you're using the ADB shell, you can see the contents of this folder by using the "magic" path "/mnt/shell/emulated".
Click to expand...
Click to collapse
Thanks so much! it was in data/media! thank god I could stop going through each and every folder. I just got about 3 gigs back that I thought were filled up forever!
Previously I could just plug my phone into my computer and run "adb pull -a /sdcard ." (Android 8) But that command doesn't work anymore now that I have a Pixel 5a with Android 11, it's filled with errors, such as:
Code:
adb: error: failed to copy '/sdcard/Android/data/com.alltrails.alltrails/files/tiles/tile_cache.db-wal' to './sdcard/Android/data/com.alltrails.alltrails/files/tiles/tile_cache.db-wal': remote open failed: Permission denied
This is some random app file, and I'm sure there are others too with weird permissions which cause adb to quit as soon as it has the error.
I've read that I could use a command like this:
Code:
adb exec-out "tar -ch sdcard | gzip" > sdcard_backup.tar.gz
but this just produces a corrupted archive because "tar" can't read all of the files either and so the error messages get inserted into the archive.
Any other ideas to simply get a full backup of /sdcard? Thanks
scarlion said:
Previously I could just plug my phone into my computer and run "adb pull -a /sdcard ." (Android 8) But that command doesn't work anymore now that I have a Pixel 5a with Android 11, it's filled with errors, such as:
Code:
adb: error: failed to copy '/sdcard/Android/data/com.alltrails.alltrails/files/tiles/tile_cache.db-wal' to './sdcard/Android/data/com.alltrails.alltrails/files/tiles/tile_cache.db-wal': remote open failed: Permission denied
This is some random app file, and I'm sure there are others too with weird permissions which cause adb to quit as soon as it has the error.
I've read that I could use a command like this:
Code:
adb exec-out "tar -ch sdcard | gzip" > sdcard_backup.tar.gz
but this just produces a corrupted archive because "tar" can't read all of the files either and so the error messages get inserted into the archive.
Any other ideas to simply get a full backup of /sdcard? Thanks
Click to expand...
Click to collapse
I'm guessing that you're not rooted. That means that you probably won't be able to access most (if not all) of Android/data due to scoped storage restrictions.
If you change the tar command to
tar -chzf sdcard_backup.tar.gz sdcard
you should at least split out the errors from the data. The z option tells tar to compress the output using gzip. No need to explicitly pipe it through an external gzip program. f tells it that the next string is the output file name.
For the full tar manual see
GNU tar 1.34
GNU tar 1.34
www.gnu.org
A good file explorer should be able to get access to the restricted directories so you could use that to copy the data from there. I'm not sure about restoring in this case though since permissions may not be properly preserved.
If you are rooted then you can use tar to grab everything. There are options to preserve permissions but I would use the /data/media/0 path for that (path may not be correct. I'm going by memory since I'm not currently rooted and can't see the necessary directory structures).
I'll follow up here eventually once I do root, hopefully in a few days.