[How To] Deodex Your Device [Tutorial] - Captivate Android Development

​How To Deodex Your Device Tutorial
What is odexing?
What is deodexing?
Why you may consider deodexing over odexing.
Disclaimer: This tutorial is meant as a guide for education purposes only. If you decide to take the initiative to perform a deodexing operation on your device a family member’s device or a friend’s device – you (the surgeon) assume all responsibility for you own actions. In other words… Your problems are your own… Read before dissecting!
What is Odexing? – Within the Android Operating System applications come in the form of .APK packages compiled with .odex files that work with the primary application. Odex files are compiled with portions of the main application manifests and hold partial instructions for how this application will boot, how it will run and how it will act within the entire file structure. These odex files hold instruction for an application to pre-boot, pre-launch and how the service (if any) will function. Some assumptions are that the speed of the file system and application will be increased by way of pre launching the application prior to usage. My thoughts on this are that battery usage and memory are also being consumed while you may not even draw on that particular application. Simply put, the Odex file holds a set of functioning instructions for the application it belongs with. Think of it as sort of a pre-buffer and caching at the same time.
What is Deodexing? – Deodexing is the process of removing the child instruction file from the parent file and importing all the information that has been removed from the odex file into the APK. Full freedom to perform on its own without the aid of little odex.
Why may you consider deodexing a file system over having an odexed file structure? – Application modifying can be near impossible with many instructions for a single application existing in various places of the file structure. Consolidating all the functions of an APK in a single location will help to simplify the process.
Are you ready to become deodexed…?
So, get your scalpel ready and let’s begin…
This process will be described working within a Windows environment.
You will need to have a few things in order before we begin:
1) A Rooted phone – (A Must)
2) A working Windows workstation or desktop
3) xUltimate Utility v2.2.1 (see the link from my prior post to download the tool)
http://forum.xda-developers.com/showpost.php?p=12024563&postcount=126
4) Developers SDK toolkit – or – the ability to run adb commands
5) A little time to burn
Let’s get started:
1) Assuming that you have already downloaded xUtility v2.2.1 – unzip the package to a directory you can easily access.
2) Make sure to put your device in debugging mode and plug the USB cable from the PC into your device.
3) You can run the Test.exe to verify that the xUtility sees your device, but it’s not necessary and may cause a doubling effect with adb so that your device won’t be seen – so just execute the Main.exe and wait for the device to communicate with the application.
4) Once your device has been read by the xUtility, answer the questions in the prompts according to your make and model. (You do not need to upgrade to a newer version of xUtility because this is the newer version – regardless of what the application states)
5) Execute Action 1 then follow the instruction at the prompts
6) Execute Action 2 then follow the instruction at the prompts
*Note: For any reason the process fails to begin or hangs during the process – verify that there is only one instance of adb running on your PC or this could result in issues.
*Note: If issues occur, you can always perform an adb pull to the origi_app directory (within xUtility) and then the origin_frame directory (within xUtility)
*Note: This could take some time depending on the size of the directories
7) When the migration is complete - perform Action 3 in xUtility - This will perform the deodexing of the application APKs.
8) When the Application Deodexing is complete - perform Action 4 in xUtility - This will perform the deodexing of the framework APKs. (Mainly Java Files)
9) For safety purposes – backup the files in both the origin_app and the origin_frame directories and put them in a safe place just in case.
10) Close the prompt for xUtility – the process should be complete.
11) Exit debugging mode with your device and enter into mass storage mode. You will need to remove the USB cable before performing this, then plug the USB cable back in once the mode shift has occurred.
11) You should now see your device in Windows as a mass storage drive.
12) Go into the xUtility directory and copy the 2 folders named – “done_app” and “done_frame” to the root of your internal SDCard.
13) Get your command prompt open and get ready to type some code
Just my preference - Prior to migration of the deodexed files I chose to wipe the dalvik-cache from my device to ensure no rouge variant cached instructions would be present after the next boot. – You could CWM into the next soft boot and perform a dalvik wipe if you choose.
At The Command Prompt: Code Below:
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# cp /sdcard/done_app/* /system/app/
# cp /sdcard/done_frame/* /system/framework/
# rm /system/app/*.odex
# rm /system/framework/*.odex
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
After your device reboots it will take longer than usual to load the new file settings – so be patient and don’t panic.
You now have a deodexed device!
If you found this tutorial useful and helpful or you just enjoy reading my posts Show your gratitude by hitting that thanks button on this post.
All the best
Peace-
Liv33viL

Might want to point out that this is completely useless for anyone on a custom ROM.

MikeyMike01 said:
Might want to point out that this is completely useless for anyone on a custom ROM.
Click to expand...
Click to collapse
Might want to say why?

MikeyMike01 said:
Might want to point out that this is completely useless for anyone on a custom ROM.
Click to expand...
Click to collapse
If they knew enough to flash a custom ROM then they should know if the ROM that they flashed was deodexed or not if posted by the developer.
Then they wouldn't be on this thread reading this post unless they wanted a bit of an education on the topic.
Hence making your remark quite pointless!

Liv33viL said:
If they knew enough to flash a custom ROM then they should know if the ROM that they flashed was deodexed or not if posted by the developer.
Click to expand...
Click to collapse
O ye of far too much faith.

opcow said:
O ye of far too much faith.
Click to expand...
Click to collapse
agreed. so many people dont even bother to read the OP on a rom thread and ask if feature X exists, when its clearly labeled as such in the OP

not something I'd be willing to do regardless if my phone has a deodexed rom or not. seems a lot could go wrong if you made a slight mistake especially with running commands on your phone.
but at least I now know what deodexing is now

bunnsguy said:
not something I'd be willing to do regardless if my phone has a deodexed rom or not. seems a lot could go wrong if you made a slight mistake especially with running commands on your phone.
but at least I now know what deodexing is now
Click to expand...
Click to collapse
Yep, didn't know what it was.

You Take Your Shots When the Opportunity Presents Itself
opcow said:
O ye of far too much faith.
Click to expand...
Click to collapse
Yeah, I guess I was reaching on that statement... anticipating the best - but real world scenarios prevail!
What can I say... I prefer to be an eternal optimist.
But the statement was written to read "they should know" like as in if you lick the inside of a freezer door... "you should know" that it is highly likely that one would remain there until the thaw...minus a few layers of skin of course
Basically I got the idea to write this tutorial when reading a few threads whereas many users wanted to make some cosmetic mods to their devices, but really didn't want to jump out of their factory installed file systems. I noticed a few theme developers creating a skin pack for certain features, such as lock screens, docks, etc... and it required a deodexed file system. Many people didn't understand or even know what deodexed meant, let alone some never even heard of the word.
I posted in one of the threads that If I were feeling ambitious that I would create an educational tutorial and guidelines to perform the operation if one was interested... after getting injected with some knowledge.
You Take Your Shots When the Opportunity Presents Itself
Education = Key
Key = Knowledge
Knowledge = Insight
Insight leads to Applied Knowledge
Applied Knowledge = Power
Peace-

Very interesting, I learned a thing or two but of course the guys who really should be reading this are the ones that wont :/
Sent from my SGH-I897 using XDA App

Glad to have another resource just in case I ever decide to start developing my own custom ROM.
Herp derp Captivate XDA app.

Fantastic! - Glad to see an interest in some of the nuances of this file structure.
Peace-

A Common Philosophy
Liv33viL said:
Yeah, I guess I was reaching on that statement... anticipating the best - but real world scenarios prevail!
What can I say... I prefer to be an eternal optimist.
But the statement was written to read "they should know" like as in if you lick the inside of a freezer door... "you should know" that it is highly likely that one would remain there until the thaw...minus a few layers of skin of course
Basically I got the idea to write this tutorial when reading a few threads whereas many users wanted to make some cosmetic mods to their devices, but really didn't want to jump out of their factory installed file systems. I noticed a few theme developers creating a skin pack for certain features, such as lock screens, docks, etc... and it required a deodexed file system. Many people didn't understand or even know what deodexed meant, let alone some never even heard of the word.
I posted in one of the threads that If I were feeling ambitious that I would create an educational tutorial and guidelines to perform the operation if one was interested... after getting injected with some knowledge.
You Take Your Shots When the Opportunity Presents Itself
Education = Key
Key = Knowledge
Knowledge = Insight
Insight leads to Applied Knowledge
Applied Knowledge = Power
Peace-
Click to expand...
Click to collapse
I Agree with you on this.....WELL SAID! And Thank You for the time invested on a great tutorial/ lesson. I too learned a thing or two.

I would like to add four lines of code to the set of commands you type in adb shell
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# cp /sdcard/done_app/* /system/app/
# cp /sdcard/done_frame/* /system/framework/
# rm /system/app/*.odex
# rm /system/framework/*.odex
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
The reason for these additional commands is that when any files get moved to /sdcard, and directories under it, the ownership of the files becomes system.sdcard_rw and the permissions for the files become rwxrwxr-x. When these files are copied back to their original subdirectories under /system, they retain the new ownership and permissions. The original proper ownership and permission for the files before any changes were made was root.root and rw-r--r--. The four commands I added restores them to that original state, and therefore does not create any unintentional security risk. If anyone has already done the procedure. They can fix the files by doing just this in an adb shell.
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*[/COLOR]
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot

ytt3r said:
Very interesting, I learned a thing or two but of course the guys who really should be reading this are the ones that wont :/
Sent from my SGH-I897 using XDA App
Click to expand...
Click to collapse
This statement kind of worries me coming from a developer. Haha.

Wisdom
AA “Information is not knowledge.”

whiteguypl said:
This statement kind of worries me coming from a developer. Haha.
Click to expand...
Click to collapse
I thought the same thing when I saw it.

[OP] Edit: See Edit Tag in OP For Details
rajendra82 said:
I would like to add four lines of code to the set of commands you type in adb shell
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# cp /sdcard/done_app/* /system/app/
# cp /sdcard/done_frame/* /system/framework/
# rm /system/app/*.odex
# rm /system/framework/*.odex
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
The reason for these additional commands is that when any files get moved to /sdcard, and directories under it, the ownership of the files becomes system.sdcard_rw and the permissions for the files become rwxrwxr-x. When these files are copied back to their original subdirectories under /system, they retain the new ownership and permissions. The original proper ownership and permission for the files before any changes were made was root.root and rw-r--r--. The four commands I added restores them to that original state, and therefore does not create any unintentional security risk. If anyone has already done the procedure. They can fix the files by doing just this in an adb shell.
adb shell
# su
# stop
# mount -o rw,remount -t ext4 /dev/block/mmcblk1p21 /system
# chmod 644 /system/app/*
# chown root.root /system/app/*
# chmod 644 /system/framework/*
# chown root.root /system/framework/*[/COLOR]
# mount -o ro,remount -t ext4 /dev/block/mmcblk1p21 /system
# reboot
Click to expand...
Click to collapse
Raj, thank you for providing the additional lines of code. Yes, you are absolutely correct. It was very late.... uhm very early in the AM when I was was proofreading and it didn't pop out at me then. Now, it pops.
The OP now reflects the additions and credit was given to you for the additions in the edit.
Thank you again my friend.
Peace-

This is the tutorial that I'm looking for. I already ask many times how to deodex my captivate but nobody answer it until I find this thread. Two thumbs up.
ps: could you add a video tutorial? I think a video is more informative for me because I don't have any experience with adb so that I little bit confuse if there is a command line using adb.

max_82 said:
This is the tutorial that I'm looking for. I already ask many times how to deodex my captivate but nobody answer it until I find this thread. Two thumbs up.
Click to expand...
Click to collapse
Fantastic Max!
Glad you finally found what you were looking for!
Peace-

Related

cross device link ERROR!!!!

I have looked and looked but im still having problems. im trying to use a mv /sdcard Camera.apk /system/app/ command to try to move a modded Camera.apk to the /system/app/ folder , but i keep getting a cross-device link. ive mounted it over again but still the same thing. Please help if this is even possible. thanks
Bump bump bump
I don't even know why I"m answering but ...
/system is not writable
unless you use something like this :
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
Please people please use the search fonction.
dixxa said:
I don't even know why I"m answering but ...
/system is not writable
unless you use something like this :
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
Please people please use the search fonction.
Click to expand...
Click to collapse
I have done that command several times both to /system and to /sdcard. But asoon as i do mv /sdcard/(file) /system/app/ it gives me that error!!!!!!
Any solutions to this?
move it using root explorer or some file manager that allows you to write in the system... thats what i do...
barger01 said:
I have looked and looked but im still having problems. im trying to use a mv /sdcard Camera.apk /system/app/ command to try to move a modded Camera.apk to the /system/app/ folder , but i keep getting a cross-device link. ive mounted it over again but still the same thing. Please help if this is even possible. thanks
Click to expand...
Click to collapse
It means that you can't create a hard link on one device (filesystem) that refers to a file on a different filesystem.
The mv command does NOT MOVE THE DATA!!! It moves the HARDLINK TO THE DATA.
Consider yourself fortunate that you have a SANE VERSION of the mv command that doesn't try anyway -- some old versions will actually TRY to do this, which will result in a hard link that points to NOTHING, and the original data being INACCESSIBLE.
If you want to move the file to a different filesystem, you need to use the "cp" command. Copy the file to create a SECOND COPY of it on a different filesystem, and then DELETE the OLD one with the "rm" command.
A simple move command:
Code:
#!/bin/bash
if ( cp "$1" "$2" ); then
rm -f "$1"
fi
You will note that the "cp" command returns true or false depending on the successful completion of the copy, therefore the original will only be removed IF the file copied successfully.
This script can be copied into some place referenced by the PATH variable and set executable.
lbcoder said:
It means that you can't create a hard link on one device (filesystem) that refers to a file on a different filesystem.
The mv command does NOT MOVE THE DATA!!! It moves the HARDLINK TO THE DATA.
Consider yourself fortunate that you have a SANE VERSION of the mv command that doesn't try anyway -- some old versions will actually TRY to do this, which will result in a hard link that points to NOTHING, and the original data being INACCESSIBLE.
If you want to move the file to a different filesystem, you need to use the "cp" command. Copy the file to create a SECOND COPY of it on a different filesystem, and then DELETE the OLD one with the "rm" command.
A simple move command:
Code:
#!/bin/bash
if ( cp "$1" "$2" ); then
rm -f "$1"
fi
You will note that the "cp" command returns true or false depending on the successful completion of the copy, therefore the original will only be removed IF the file copied successfully.
This script can be copied into some place referenced by the PATH variable and set executable.
Click to expand...
Click to collapse
Maybe I'm reviving a dead thread, but lbcoder really deserved appreciation. I was stuck at the exact same issue with mv on my Moto Defy, and you saved the day. Thanks!
I agree - thank you lbcoder!
Just use dd if=/.... of=/.....
sony66 said:
Just use dd if=/.... of=/.....
Click to expand...
Click to collapse
dd never desapoints !
Thanks!
lbcoder said:
The mv command does NOT MOVE THE DATA!!! It moves the HARDLINK TO THE DATA.
Click to expand...
Click to collapse
Thanks! Useful even for some of us not-so-n00bs on Linux -- I never knew that.
I tried to copy and not move and ended up with the same error
Code:
:/data/sdext3/WhatsApp/ModsBackup/com.whatsapp #
cp files databases shared_prefs /data/data/com
cp: Skipped dir '/data/data/com.whatsapp/files': Cross-device link
cp: Skipped dir '/data/data/com.whatsapp/databases': Cross-device link
cp: Skipped dir '/data/data/com.whatsapp/shared_prefs': Cross-device link
apparently the advice given by one of our members was the one I found on stack exchange with the same wording
here
solution is not cp instead of mv because
mv hard links and across devices it is not possible.
the BusyBox version of copy worked for me to copy across different devices
it sounds like even cp from android shell behaves much like mv
Code:
busybox cp -rvf files databases shared_prefs targetdir

[GUIDE] ADB Workshop and Guide for everyone

This workshop was held in #android-learning on irc.freenode.net by XDA Member Adrynalyne. All credit to him for this guide, I simply am taking it and turning it into a guide. Here we go!
You can find the raw IRC log here
Good evening folks, and welcome to my ADB workshop. This is by no means a full explanation on the subject, but more of a crash course to help folks get up to speed, and get more from their devices. There may be some things you already know here, so please be patient and respect those who do not.
Reference Files
http://adrynalyne.us/files/How to install adb.pdf
http://adrynalyne.us/files/Using ADB.pdf
So, lets just start with the basics.
What is ADB?
ADB stands for the android debugging bridge and is used for testing and debugging purposes by developers.
However, we like to get more out of our devices, and its a great way to fix things.
Knowing adb can mean the difference between a paperweight and a working phone.
So, to start with, we will look at installing ADB.
Generally speaking, the Sun/Oracle JDK is required to run all SDK functions.
ADB is but one tool in the SDK arsenal.
So, we begin by downloading and installing the JDK. This can be found here:
https://cds.sun.com/is-bin/[email protected]_Developer
Choose your OS, download and install. I recommend that 64 bit users use the regular x86/32 bit version as well.
Moving ahead, we download the Windows sdk from here:
http://dl.google.com/android/installer_r08-windows.exe
Due to already installing JDK, you won't be stopped by the install process.
Now, if you notice, I installed it to:
C:\android-sdk-windows
I did this because it makes things easier when setting up path variables.
I encourage everyone to do the same, but obviously it is not required.
So, this SDK is handy, but is only good up to 2.2. We want the latest and greatest! (Well I do)
So, we navigate to:
C:\android-sdk-windows\
and we run SDK Manager.exe
If you notice in your PDF file for installing adb, you will notice that you can update, and I made a choice not to include earlier sdk versions.
I won't go into full detail on that, but depending on the version of SDK you have, 8 or 9, it WILL make a difference in using adb.
By default, for version 8 adb.exe resides in C:\android-sdk-windows\tools
By default, for version 9 adb.exe resides in C:\android-sdk-windows\platform-tools
We will assume version 9 in this guide
Really, the SDK is installed and adb is usable right now, but in my humble opinion, its not enough
I like the ability to use adb in ANY directory on my machine.
To do this, we edit Windows's environment variables.
Specifically, the system path.
To do this, we click on start, or the orb (depending on OS), and right click on Computer, left clicking on properties in the menu.
If its windows XP, I believe it brings you into advanced system properties immediatly. Vista and 7 need a second step.
On the left hand side, as you notice I have highlighted in the pdf, left click advanced system settings.
Under advanced tab, we left click environment variables...
There are two boxes here.
We are concerned with system variables, however.
So we scroll down the list and highlight path and click edit.
Ignoring all the extra stuff in here, make sure you are at the end of the line, and type
Code:
;C:\android-sdk-windows\platform-tools
The semicolon allows us to separate it
from the previous path statement.
Click ok all the way out.
We now have ADB setup globally. We can use cmd.exe (I use powershell) and no matter what directory we are in, adb is recognized.
If it is not, make certain you entered the path into system variables, and made no typos.
If you installed to a different location, you will need to adjust the path accordingly.
This concludes the section on installing the Android SDK to use ADB.
This next section will be on using ADB, so please open that pdf now.
Now, this applies to any OS, not just Windows.
Well, with the exception of the USB drivers.
I will not go too much into that, but if you take a look at the PDF, it goes through installing usb drivers for the sdk, and how to download them.
Fiarly straightforward, in that rspect.
Now, to setup our phones to use with the SDK and ADB, we must change some settings.
First, we go to menu softkey, then settings.
We scroll down to Applications and tap it.
Under Development, we will check Enable USB Debugging. Please note the SGS phones are different in this respect.
The USB cable must be unplugged before enabling or disabling this setting.
Once this is done, we are now ready to play with adb
One quick note: If you get device not found/conencted, please reboot your phone. DJ05 has a quirk in it where ADBD randomly crashes on boot.
A reboot will fix this
ADBD= ADB Daemon
Ok, continuing on.
Lets look at installing applications. This is also known as sideloading.
Unlike installing from the SD card, it does not require unknown sources to be enabled.
The command for this is
Code:
adb install packagename
This assumes that you are working from the directory where the file is located.
This will install the application to /data/app.
It will also show sometimes useful errors if install fails.
That is not something you will see from the Android GUI.
Now, a lot of us have probably deleted files with apps like Root Explorer. While this isn't really a bad thing, it leaves behind databases and data for the application removed.
This is where the 0kb applicaiton entries come from.
If you take that application entry name, you can uninstall the extra data via adb.
First we go to the adb shell which logs into the phone.
Code:
adb shell
If we end up with a $, we will want admin rights, in many cases. This is not one of them, I don't beleive.
To get admin rights, you want to type
Code:
su
Look at your phone if this is the first time, it may prompt you to allow access. Else you will get permission denied.
If you are not rooted, this will not work either.
Ok, now that we are logged in, we will type
Code:
pm uninstall packagename
where packagename is the name of the 0kb listing.
Now this seems like a pain in the a** and I agree.
HOWEVER
There will be a time where Manage applications crashes when you try to uninstall it from the phone. In this case, a factory reset, or this method is the only effective way to fix the problem.
Moving on.
How many of us have removed system applications or renamed them? Did you know that you can simply disable them from the system?
Code:
adb shell
su
pm disable appllicationname
This will disable it, and the system will ignore it.
This can be seen as safer than deleting or renaming things, but your mileage may vary.
On the other hand, you can also re-enable these applications.
Code:
adb shell
su
pm enable applicationname
Please note: Not all applications will properly re-enable. I believe a factory reset or reinstall of said application will fix the issue.
Also, application names are absolutely case sensitive.
*nix based Operating Systems see the letter 'a' and 'A' as two different things.
when you log into adb shell, you are playing by android rules
Ok, a lot of us tweak and mod our phones and turning off the device to get to clockwork recovery, or battery pulls, or multiple button holds to get into Download mode are troublesome and annoying at best.
ADB can help us here.
Here, we do not need to be logged into the shell
If we want to merely reboot the phone:
Code:
adb reboot
If we want to go to recovery (works well with voodoo5)
Code:
adb reboot recovery
If we want to go to Download Mode because we need Odin, heaven forbid:
Code:
adb reboot download
Its instant. No waiting on animations or anything else.
Its also handy if Android has locked up, but yet still works in adb.
I for one hate taking my case off to battery pull.
So now we move on to pushing and pulling files.
Sometimes, I don't feel like mounting my sd card to copy a file over to my phone.
I can use this command to push a file straight to my sd card:
Code:
adb push filename /pathtodirectoryonphone
So for instance, if I have test.txt that I want to send, I would type:
Code:
adb push test.txt /sdcard/
and there it goes.
Ok moving on
Pushing files can be done to any directory, however, some are protected.
For instance, /system is going to give you a permission denied or a read only filesystem error.
To get around this, the easiest thing to do is push the file to your sdcard, then log into the shell:
Code:
adb shell
Code:
su
We will then mount the system as writable
Code:
mount -o rw,remount /dev/block/stl9 /system
Then we can use something like
Code:
cp /sdcard/test.txt /system/app/test.txt
cp stands for copy
and it requires the path of the file and destination path. The name of the file is optional
When you copy it, you can rename it to whatever you like.
For instance, if we wanted to backup a file
Code:
cp /sdcard/test.txt /sdcard/backuptest.txt
Now, lets assume you do not have busybox installed.
You non rooted users will not.
Then you must use a slightly more complicated command called dd
This is used like this:
Code:
dd if=/sdcard/test.txt of=/system/app/test.txt
if is for inputfile
of= output file
Not every user friendly, but probably one of the safer copy commands.
Ok, moving on to pulling files.
Lets say you want to get a file from your phone, to modify, backup, etc.
To do this, we simply use adb in this manner:
Code:
adb pull /pathtofile/filename destinationname
For instance, if I wanted to backup ADW launcher in system/app
I would do this
Code:
adb pull /system/app/ADWLaucnher.apk ADWLauncher.apk
And it will pull the file from the phone and put it in the current directory.
Like above, you can specifcy where it goes.
pushing files to the sdcard, it seems prudent to talk about changing permissions.
sdcards are typically fat32, which destroys permisisons, and Android is heavily permission based.
So if you push an application to your sd card, then try to copy it to /system/app/ bad things are going to happen, or the app may not even show up.
So in that case, we use something called chmod.
This is used in this manner
Code:
adb shell
su
chmod 755 /pathtoapplication/applicationname
Keep in mind
you dont want to do this while its still on your sd card.
an example
Code:
adb shell
su
chmod 755 /system/app/ADWLauncher.apk
755 is good for applications and script files.
Just a couple more topics to cover.
Lets go over deleting files.
This becomes especially handy for removing rogue applications.
To do this, we must be in the adb shell.
Code:
adb shell
su
rm /system/app/ADWLauncher.apk
You may need to remount system as writable with:
Code:
mount -o rw,remount /dev/block/stl9 /system
That applies when using chmod as well.
So what I did above was delete ADW Launcher from system/app
However, what if I wanted to delete the entire contents of a directory?
Same thing as before, except
Code:
adb shell
rm -f /data/dalvik-cache/*.*
I just cleared my dalvik-cache with that command
very quick, very effective.
If you just tried that, please reboot your phone now
Ok....this leaves us with the final topic: logcat
logcat allows us to log what the OS is doing, and possibly delve information for when things are not working
its quite simple Reading it is another.
To use logcat
Code:
adb shell
logcat
To logcat to a certain file do
Code:
adb shell
logcat > /sdcard/logcat.txt
Now we let the log settle down to a reasonable amount of data coming in and not a wall of scrolling, then start the app in question. When it gives an error, we hit ctrl-C and kill the adb shell session.
This should have captured enough data to see the error. Now, I prepared an example. A user came to me on IRC, and Google Maps was force closing. Clearing data didnt fix it, Clearing dalvik-cache, and fix permissions did not fix it. In this case, the user did not know how to use adb So I had him grab an app called alogcat from the market and email me the log. This is also a very valid method.
this file explains what the problem was, and highlights what to look for as an example.
http://adrynalyne.us/files/logcat.pdf
___________________________________________________________________
This concludes the guide from Adrynalyne, there will be more workshops such as this one in irc.freenode.net #android-learning.
Thanks to everyone in #samsung-fascinate !
Reserved for possible extension of topic
Great, saves a lot of questions/answers & search
Every new user should read this!!
Thread stuck as valuable reference thread
Just to add, if I may, a little about the permissions...
============================================================
File permissions for Unix... which Android is based, just so those who tinker with the file permissions may know what they are getting into.
============================================================
Use the chmod command to set file permissions.
The chmod command uses a three-digit code as an argument.
The three digits of the chmod code set permissions for these groups in this order:
1.Owner (you)
2.Group (a group of other users that you set up)
3.World (anyone else browsing around on the file system)
Each digit of this code sets permissions for one of these groups as follows. Read is 4. Write is 2. Execute is 1.
The sums of these numbers give combinations of these permissions:
0 = no permissions whatsoever; this person cannot read, write, or execute the file
1 = execute only
2 = write only
3 = write and execute (1+2)
4 = read only
5 = read and execute (4+1)
6 = read and write (4+2)
7 = read and write and execute (4+2+1)
Chmod commands on file apple.txt (use wildcards to include more files)
Command Purpose
chmod 700 apple.txt Only you can read, write to, or execute apple.txt
chmod 777 apple.txt Everybody can read, write to, or execute apple.txt
chmod 744 apple.txt Only you can read, write to, or execute apple.txt Everybody can read apple.txt;
chmod 444 apple.txt You can only read apple.txt, as everyone else.
Detecting File Permissions
You can use the ls command with the -l option to show the file permissions set. For example, for apple.txt, I can do this:
$ ls -l apple.txt
-rwxr--r-- 1 december december 81 Feb 12 12:45 apple.txt
$
The sequence -rwxr--r-- tells the permissions set for the file apple.txt. The first - tells that apple.txt is a file. The next three letters, rwx, show that the owner has read, write, and execute permissions. Then the next three symbols, r--, show that the group permissions are read only. The final three symbols, r--, show that the world permissions are read only.
Compliments and full credit from:
http://www.december.com/unix/ref/chmod.html
Amazing thread just what I needed lol thanks!
cooolone2 said:
Just to add, if I may, a little about the permissions...
============================================================
File permissions for Unix... which Android is based, just so those who tinker with the file permissions may know what they are getting into.
============================================================
Use the chmod command to set file permissions.
The chmod command uses a three-digit code as an argument.
The three digits of the chmod code set permissions for these groups in this order:
1.Owner (you)
2.Group (a group of other users that you set up)
3.World (anyone else browsing around on the file system)
Each digit of this code sets permissions for one of these groups as follows. Read is 4. Write is 2. Execute is 1.
The sums of these numbers give combinations of these permissions:
0 = no permissions whatsoever; this person cannot read, write, or execute the file
1 = execute only
2 = write only
3 = write and execute (1+2)
4 = read only
5 = read and execute (4+1)
6 = read and write (4+2)
7 = read and write and execute (4+2+1)
Chmod commands on file apple.txt (use wildcards to include more files)
Command Purpose
chmod 700 apple.txt Only you can read, write to, or execute apple.txt
chmod 777 apple.txt Everybody can read, write to, or execute apple.txt
chmod 744 apple.txt Only you can read, write to, or execute apple.txt Everybody can read apple.txt;
chmod 444 apple.txt You can only read apple.txt, as everyone else.
Detecting File Permissions
You can use the ls command with the -l option to show the file permissions set. For example, for apple.txt, I can do this:
$ ls -l apple.txt
-rwxr--r-- 1 december december 81 Feb 12 12:45 apple.txt
$
The sequence -rwxr--r-- tells the permissions set for the file apple.txt. The first - tells that apple.txt is a file. The next three letters, rwx, show that the owner has read, write, and execute permissions. Then the next three symbols, r--, show that the group permissions are read only. The final three symbols, r--, show that the world permissions are read only.
Compliments and full credit from:
http://www.december.com/unix/ref/chmod.html
Click to expand...
Click to collapse
Thanks! Added
ih4ckback said:
Amazing thread just what I needed lol thanks!
Click to expand...
Click to collapse
Thanks, all goes to Adrynalyne
Thanks for the guide. Helped me pick out the stupid stupid mistakes I was making...so just a problem. I'm able to use fastboot easily but I seem to be unable to use ADB still on my windows 7. It says there are no devices and I'm dang well sure I have USB debugging on. Is it because Windows 7 is missing drivers for the nexus one or something else?
wonderful guide. I would like to add it to the guides thread.
Really awesome work, thumbs up.
But we should also take a guide on installing adb with Ubuntu/Linux, which isn't a very difficult thing...
mm7490 said:
Really awesome work, thumbs up.
But we should also take a guide on installing adb with Ubuntu/Linux, which isn't a very difficult thing...
Click to expand...
Click to collapse
If I got time tomorrow I could do that. I work primarily in Linux also
Sent from my Samsung Fascinate using Tapatalk Pro
This is good but I have a problem, when I try to remove an .apk file from /system/app it fails and says 'rm failed, Directory not empty'
I have followed exact instructions many time but never succeeded :s any help!!
(I am runnging these commands in device mod)
when I am in recovery mod I get this prompt ~ # and I am not able to enter su mod. how to get rid of this??
Well when the $ changes to # it means you have SU access
mustafa.aziz said:
This is good but I have a problem, when I try to remove an .apk file from /system/app it fails and says 'rm failed, Directory not empty'
Click to expand...
Click to collapse
Please give us the exact command(s) you entered
Here are the commands I entered after adb shell;
su
mount -o rw,remount /dev/block/stl9 /system
rm /system/app/mytouchmusic-signed.apk
exact message returned is 'rm failed for mytouchmusic-signed.apk, Directory not empty'
mustafa.aziz said:
Here are the commands I entered after adb shell;
su
mount -o rw,remount /dev/block/stl9 /system
rm /system/app/mytouchmusic-signed.apk
exact message returned is 'rm failed for mytouchmusic-signed.apk, Directory not empty'
Click to expand...
Click to collapse
Ok i think you need to do a recursive force delete which should be rf but i am not too sure! could somebody please confirm/ correct this?
Well, I don't think so ^^ As he doesn't want to erase a whole directory, but only a file.
What surprises me the most is the returned message... You're trying to delete an apk, and it says it's a directory :/
Could you please give us the output of this :
Code:
su
mount -o rw,remount /dev/block/stl9 /system
ls -l /system/app/mytouch*
Perhaps you don't even need the su and mount lines, but I'm not sure about that, and that can't harm your system ^^
Khoral said:
Well, I don't think so ^^ As he doesn't want to erase a whole directory, but only a file.
Click to expand...
Click to collapse
I know he doesn't want to delete a whole directory, but since the apk isn't compressed perhaps android looks at is as a directory and not a file? i don't know since what was returned suggested that it was a directory i presumed it was a directory! :S
mustafa.aziz said:
Here are the commands I entered after adb shell;
su
mount -o rw,remount /dev/block/stl9 /system
rm /system/app/mytouchmusic-signed.apk
exact message returned is 'rm failed for mytouchmusic-signed.apk, Directory not empty'
Click to expand...
Click to collapse
rm -rf /blah/blah
here is your desired output:
sh-3.2# su
su
sh-3.2# mount -o rw,remount /dev/block/stl9 /system
mount -o rw,remount /dev/block/stl9 /system
sh-3.2# ls -l /system/app/mytouch*
ls -l /system/app/mytouch*
-rw-r--r-- root root 299838 2008-08-01 18:00 mytouchmusic-signed.apk
sh-3.2#

[DEV] Insecure ADB for iconia

with insecure adb you don't have to su everytime you use adb shell and you can adb remount (to remount rw your system).
You can't use the original zip (or apk) created by Paul for the ARC or SG2 because that adbd doesn't run on our device. I managed to patch the original iconia's adbd so it allows to run insecure even when our default.prop value is ro.secure=1.
Credits go to Paul O'Brien for the original hack.
Unpack the zip: http://xda.richardtrip.org/Acer/adbd/r1-insecure-iconia-a500.zip
Code:
adb push adbd /data/local/
adb push busybox /data/local/
adb push install-recovery.sh /data/local/
adb shell
su
mount -o remount,rw /dev/block/mmcblk0p3 /system
cat /data/local/busybox>/system/xbin/busybox
chmod 4755 /system/xbin/busybox
busybox --install -s /system/xbin/
mkdir /system/mcr/
cp /data/local/adbd /system/mcr/
cp /data/local/install-recovery.sh /system/etc/
chmod 4755 /system/etc/install-recovery.sh
chmod 4755 /system/mcr/adbd
rm /data/local/adbd
rm /data/local/busybox
rm /data/local/install-recovery.sh
mount -o remount,ro /dev/block/mmcblk0p3 /system
reboot
im kinda new to android. can you more detailed discribe what i should do with that. I need to remount /system to rw and i think with using this il can do it
richardtrip said:
with insecure adb you don't have to su everytime you use adb shell and you can adb remount (to remount rw your system).
You can't use the original zip (or apk) created by Paul for the ARC or SG2 because that adbd doesn't run on our device. I managed to patch the original iconia's adbd so it allows to run insecure even when our default.prop value is ro.secure=1.
Credits go to Paul O'Brien for the original hack.
Unpack the zip: http://xda.richardtrip.org/Acer/adbd/r1-insecure-iconia-a500.zip
Click to expand...
Click to collapse
Thank you so much!! =D
Worth mentioning that if you have already installed busybox (such as when initially rooting the device) you can skip those parts. Great job, and nice instructions - very detailed - should avoid too many silly questions. This will make things much easier to manage via the PC.
You should make huge red letters that tell everyone that this will finally allow them to use Droid Explorer and have full access to their internal & external storage from the PC now. This is the best thing that has happened for this device since getting root!!!
Glebaka said:
im kinda new to android. can you more detailed discribe what i should do with that. I need to remount /system to rw and i think with using this il can do it
Click to expand...
Click to collapse
Others may disagree with me, and I'm not really trying to sound rude but... if you have to ask you probably shouldn't be using this. Get more familiar with Android architecture and adb before doing it.
If for no other reason than the "INSECURE" part of it. That has ramifications and adds risk that users should be aware of when they do it. Probably minor risk, but being in security as I am, any risk is something to be mitigated.
cybermage1 said:
Others may disagree with me, and I'm not really trying to sound rude but... if you have to ask you probably shouldn't be using this. Get more familiar with Android architecture and adb before doing it.
If for no other reason than the "INSECURE" part of it. That has ramifications and adds risk that users should be aware of when they do it. Probably minor risk, but being in security as I am, any risk is something to be mitigated.
Click to expand...
Click to collapse
Yeah, the risk is that with this changed you now have root access from adb shells, without having to enter su. The tablet still needs to be physically connected to the pc to be vulnerable, and if you are in security you should know that there is no risk greater than allowing your devices to enter other people's hands. All this really does is make it easier to do things that you can already do via the pc/adb shell.
The only thing I used to regret for getting Iconia A500 was that there weren't many patches/fixes around. Now I am glad as you have given us more and more valuable things. Thanks Richard.
Can this be applied to 3.1, or is an update required?
+1 on that would be great if there was a flashable zip for 3.1
It's a trivial matter now, since Vache released a build with insecure boot, I suppose if you wanted to use another ROM you might be able to get his boot.img (or ask him to provide a zImage of the kernel to be injected in the boot.img of the rom of your choosing). I'm happy with his rom, so I don't need this right now.

[Solved] Is there an advantage with S-Off against mounting to rw and chmod 777?

Hi everybody!
Yesterday i came across S-OFF. From what i was able to find, S-OFF has two main advantages: 1.) Grant full NAND access, so you can write to /boot, /recovery and /system while in full booted mode. And secondly; allows unsigned fastboot flashing.
Now my question regards the first point; write access to all directories during full boot. Yesterday i was in need of write access to /system directory (actually just for creating a symlink). What i did - when got the "write-only permission" prompt at first try - i remounted system partition via terminal and then chmodded system directory:
Code:
/$ su
su
/# grep " /system " /proc/mounts | awk '{system("mount -o rw,remount -t "$3" "$1" "$2)}'
/# chmod -R 777 system
Afterwards i had write permissions to the system directory while i've been in full boot mode.
So my question is: If i'm not interested in unsigned fastboot flashing, nor in locking the bootloader etc, but only in having full access to all system directories - is my approach posted above giving me the same permissions, as S-OFF would do, or would S-OFF gimme any advantages?
My Phone:
*Nexus One on GRK39F Stock ROM,
*rooted (with "Superboot for Nexus One" by Madaco),
*su version 3 (by ChainsDD http://forum.xda-developers.com/showthread.php?t=682828)
Many thanks in advanced!
Cheers, Stephan
Update: @Mod/Admin: Sorry for posting to the wrong section. When i was looking at the section titles before posting this, i read Q&A as FAQ; donno why. I just realized the sticked thread at top of this section, thus recognized i posted to the wrong section. If you'd be so kind to move the thread to the approciated section, rather than closing it, i'd be thankful and promise to take more care about sticking to the board rules in the future. Thanks and kind regards!
I think you are mixing up a few things:
1) Nexus One's come with a partially unlockable bootloader. When you execute the "fastboot oem unlock" command, you are able to flash the /system, /boot, and /recovery partitions with unsigned images via the fastboot command. (So, essentially, you can give yourself root access once you are unlocked, and can write to the /system partition while booted normally.)
2) With S-OFF, you are able to flash ALL of the partitions of the N1 with unsigned images via fastboot, including radio, hboot, sp1custom and splash.
3) If you are rooted, you have write access to the system partition (the same as the above two).
So, to answer your question, having an unlocked bootloader, or S-OFF, or root: they all give you the same ability when it comes to the /system partition.
P.S. If you rooted with "Superboot for Nexus One" by Madaco, then you already unlocked your bootloader...
Hi Efrant!
Thanks for your answer, eventhough i'm even more confused now. ^^ You say
efrant said:
having an unlocked bootloader, or S-OFF, or root: they all give you the same ability when it comes to the /system partition.
Click to expand...
Click to collapse
But "Root" alone, on Android, does not necessarily gives you permissions to write to system directories. As long as a partition is mounted read only, you will - regardless you have userid 0 - get a "read-only file system" error prompt when trying to write to it. Or how comes
Code:
[U][B]whoami: unknown uid 10063 :[/B][/U]
issuing
[B]$ ls /data/app[/B]
returns
[B]opendir failed, Permission denied[/B]
issuing
[B]$ cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
returns
[B]cp -s -P /system/xbin/busybox /system/bin/busybox: Read-only file system[/B]
Code:
[U][B]whoami: unknown uid 0 :[/B][/U]
issuing
[B]$ su
# ls /data/app[/B]
returns directory listing
[B]namespace.apk
...[/B]
issuing
[B]$ su
# cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
returns
[B]cp -s -P /system/xbin/busybox /system/bin/busybox: Read-only file system[/B]
Code:
[U][B]whoami: unknown uid 0 :[/B][/U]
but issuing
[B]$ su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod -R 777
# cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
will finally create the symlink
For me, that doesn't look like i'm having same access to system directories whether for reading, nor for writing and that - even when logging in as userid 0 ?!
PS: And yes, you're right; i unlocked the bootloader (the very first day i bought my Nexus).
Bexton said:
Hi Efrant!
Thanks for your answer, eventhough i'm even more confused now.
But "Root" alone, on Android, does not necessarily gives you permissions to write to system directories. As long as a partition is mounted read only, you will - regardless you have userid 0 - get a "read-only file system" error prompt when trying to write to it.
Click to expand...
Click to collapse
Yes, but once you have root access, you can mount the system partition as r/w, without any other permissions/etc. All I was saying was that when you have root, you can write to the system. Of course I didn't spell it out step by step, i.e., by mounting the system as r/w, changing directory to the system, etc.
P.S. If you use a root file explorer (like Root Explorer for example, it make the process much easier).
Okay, i got it! Thanks!
So the bottom line: @secuflag has no effect on read and write permissions for the file system.
PS: Sometimes i'm using "root apps" (such as sysroot file explorer eg). But some things can not be done by apps. Plus, i think for a lot of tasks - if you're familar with linux - the command line is also much more comfortable and faster. But thanks for your tip (and help) anyway.
Bexton said:
So the bottom line: @secuflag has no effect on read and write permissions for the file system.
Click to expand...
Click to collapse
Correct (on Nexus 1s)
Sent from my Nexus One using Tapatalk
Here is a new safe way to get S_OFF for your N1. For me the only real advantage was getting rid of the ugly padlock image during boot, and customizing the initial splash image.
http://forum.xda-developers.com/showthread.php?t=1270589
garrettc67 said:
Here is a new safe way to get S_OFF for your N1. For me the only real advantage was getting rid of the ugly padlock image during boot, and customizing the initial splash image.
http://forum.xda-developers.com/showthread.php?t=1270589
Click to expand...
Click to collapse
Keep in mind that what you are linking to is not "true" S-OFF (i.e., setting secu_flag=0, like what you get when using an XTC clip or something similar). The radio is still S-ON.
efrant said:
Keep in mind that what you are linking to is not "true" S-OFF (i.e., setting secu_flag=0, like what you get when using an XTC clip or something similar). The radio is still S-ON.
Click to expand...
Click to collapse
Yes, very true. But for what I wanted it's OK. I'm very lucky that this method turned up on the same day that my new XTC Clip arrived, since it fried itself when I plugged-in the battery and I was about as depressed as a geek could be

Manually Deodex Any S5830 Rom !!!

After i succesfull deodex my stock rom i've decided to share my experience with ya'll people ...
Here we go :
1. You must be rooted !!!
2. Download -> xUltimate
3. Unzip xUltimate v2.2, and launch "Main.exe"
4. Now xUltimate should recognize the phone and make a connection. You now should see a list of options.
5. Run option 1. After option 1 is done, run option 2.
6. Now these well take a while. Run option 3
7. IMPORTANT: After you have run option 3, you MUST navigate to the xUltimate folder and find "origi_frame" folder, and delete "guava.odex". It's a bad file, and interferes with deodexing process.
8. Now run option 4, and wait.
9. Exit xUltimate, and put the phone in USB mass storage then copy "done_frame", and "done_app" to the root of the sdcard then put the phone in PC mode.
10. Open a command prompt, and do the following:
Code:
adb shell
su
stop
mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
busybox cp /sdcard/done_app/* /system/app/
busybox cp /sdcard/done_frame/* /system/framework/
rm /system/app/*.odex
rm /system/framework/*.odex
mount -o ro,remount -t ext3 /dev/block/mmcblk1p21 /system
reboot
After phone is boot, reboot again in CWM and Wipe Dalvin Cache, reboot and ENJOY !!!
Notice : The boot will take a little bit longer than normal (2-4 seconds +)
P.S. For step 7 ... there is no guava.odex, don't worry about, continue to next step !
Credits :
Rainabba, Mike919, toxman, teenfaces, Xeudoxus !
Fisrt post ! Good work dude!!
You must have adb (by installing android sdk, platform-tools, install usb driver too) and jdk to do this if anyone is wondering.
kevinlekiller said:
You must have adb (by installing android sdk, platform-tools, install usb driver too) and jdk to do this if anyone is wondering.
Click to expand...
Click to collapse
I assumed that those who want to deodex their rom already knew that, anyway, thanx for reply
Nice tutorial!
Sent from my GT-S5830 using xda premium
Thanks y'all, I will also post other tutorials if i discover something interesting !
I know this question is stupid, but what's the difference between odexed and deodexed rom?
Yesterday I was trying to figure out how to deodex and today you make a tutorial, lol
Thanks.
excellent!! could create one of how to add cf-root and menu extended to create custom roms, is the last thing I need to learn to develop roms
tazlooney89 said:
excellent!! could create one of how to add cf-root and menu extended to create custom roms, is the last thing I need to learn to develop roms
Click to expand...
Click to collapse
Cf root xd to easy
Its in th .zip self
Just extract look in folder and place them where they belong
Sent from my GT-S5830 using xda premium
thanks dude!
now i can get pdroid running on stock rom *_*
Great tutorial thanks!
It would be great if you show how to enable CRT animation in any stock rom ang make grouping widgets in menu.
P4qui7o said:
After i succesfull deodex my stock rom i've decided to share my experience with ya'll people ...
Here we go :
1. You must be rooted !!!
2. Download -> xUltimate
3. Unzip xUltimate v2.2, and launch "Main.exe"
4. Now xUltimate should recognize the phone and make a connection. You now should see a list of options.
5. Run option 1. After option 1 is done, run option 2.
6. Now these well take a while. Run option 3
7. IMPORTANT: After you have run option 3, you MUST navigate to the xUltimate folder and find "origi_frame" folder, and delete "guava.odex". It's a bad file, and interferes with deodexing process.
8. Now run option 4, and wait.
9. Exit xUltimate, and put the phone in USB mass storage then copy "done_frame", and "done_app" to the root of the sdcard then put the phone in PC mode.
10. Open a command prompt, and do the following:
Code:
adb shell
su
stop
mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
busybox cp /sdcard/done_app/* /system/app/
busybox cp /sdcard/done_frame/* /system/framework/
rm /system/app/*.odex
rm /system/framework/*.odex
mount -o ro,remount -t ext3 /dev/block/mmcblk1p21 /system
reboot
After phone is boot, reboot again in CWM and Wipe Dalvin Cache, reboot and ENJOY !!!
Notice : The boot will take a little bit longer than normal (2-4 seconds +)
P.S. For step 7 ... there is no guava.odex, don't worry about, continue to next step !
Credits :
Rainabba, Mike919, toxman, teenfaces, Xeudoxus !
Click to expand...
Click to collapse
Superb Tutorial Dude...
I am currently testing @Jusadas latest "Carbon Sunday Beta1" rom... It is fully odexed & so far is bug free (Totally)...... I would like to try & DeOdex the rom so that PDroid & Patch can be implemented...
I Know that PDroid framework has now been ported for Odexed roms, but when I flash the Odexed version I get stuck at Android txt during boot...
Will report back if your technique works...
Stay Breezy n Be Lucky...
Pe"ACE"...
Thanx man what a great work , i actually look for deodexing method coz i want to translate an odexed rom but i has to be deodexed first
I'll give it a shot !
Excellent guide!!!
Will try it tmw
Thanks =)
Sent from my GT-P6800 using xda premium
Well the title says manually deodex. But this uses the tool. To manually do it you need to decompile each app individually and then edit it.
Btw, nice giude..
TeamCooper Developer
TheMyth Developer
www.teamcooper.net
ERROR!
Tried this on my stock ddkq8 gingerbread 2.3.6 rom. But whenever I run this line: busybox cp /sdcard/done_app/* /system/app/
it says cp: No space left on device.
and my phone bricks.
It seems that the command does not overwrite the files in /system/app and thus the error.
BTW what do you mean by pc mode?
PLS reply!
galaxyace152 said:
Tried this on my stock ddkq8 gingerbread 2.3.6 rom. But whenever I run this line: busybox cp /sdcard/done_app/* /system/app/
it says cp: No space left on device.
and my phone bricks.
It seems that the command does not overwrite the files in /system/app and thus the error.
BTW what do you mean by pc mode?
PLS reply!
Click to expand...
Click to collapse
Before "10. Open a command prompt, and do the following:"
Just delete some apps to make 40 mb free in system !
That's how i did and work's
Use Root Explorer or something
shaaan said:
Well the title says manually deodex. But this uses the tool. To manually do it you need to decompile each app individually and then edit it.
Btw, nice giude..
TeamCooper Developer
TheMyth Developer
www.teamcooper.net
Click to expand...
Click to collapse
Developer Talking
---------- Post added at 08:57 PM ---------- Previous post was at 08:56 PM ----------
Stuck on boot loop! :| And yes, I wiped everything. Nice tutorial BTW, appreciate it.
EDIT: Never mind. Sorted it.
C:\android-sdk-windows\platform-tools>adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
$ su
su
# stop
stop
# mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
# busybox cp /sdcard/done_app/* /system/app/
busybox cp /sdcard/done_app/* /system/app/
cp: can't stat '/sdcard/done_app/*': No such file or directory
# busybox cp /sdcard/done_frame/* /system/framework/
busybox cp /sdcard/done_frame/* /system/framework/
cp: can't stat '/sdcard/done_frame/*': No such file or directory
# rm /system/app/*.odex
rm /system/app/*.odex
# rm /system/framework/*.odex
rm /system/framework/*.odex
# mount -o ro,remount -t ext3 /dev/block/mmcblk1p21 /system
mount -o ro,remount -t ext3 /dev/block/mmcblk1p21 /system
# reboot
reboot
C:\android-sdk-windows\platform-tools>
how come mine is like this...? anyone can help me...? plz
after that my phone cant start...it stuck on the galaxy ace screen...???

Categories

Resources