Hey, guys. I noticed ICS comes with a shell tool called "toolbox" (or maybe it's just my ROM). The traditional tool, called Busybox, is also installed. This tool is much more powerful--if basic shell commands like "mv" don't work properly, toolbox is probably to blame.
Or my system, the shell is mksh and the toolbox tools are installed in /system/bin and busybox is in /system/xbin. Is this the same on all ICS ROMs?
The command to modify the system path so the busybox tools are called preferentially to the toolbox tools is the following:
sed '/: place customisations above this line/i\PATH="/system/xbin:$PATH"' -i /etc/mkshrc
Like I said, I'm assuming my ROM is the same as other ROMs. But the point is to find the shell init file and add PATH="/system/xbin:$PATH" to it. As usual, make a system backup before making changes like this.
In this vein, does anybody know how to change the root user's shell? The "chsh" command doesn't exist on Android, nor does /etc/passwd.
What ROM are you using ?
IceColdSandwich (mostly based on AOKP) - http://forum.xda-developers.com/showthread.php?t=1450962
But is the shell and unix toolchain not common to all ICS builds? I don't know why AOKP and or the makers of this build would have chosen to use tools that are so obviously inferior to the more common tools.
To see which environment/toolchain you are using, check out the symlinks for some shell commands:
# ls -l `which mv`
To see if you have busybox installed:
# which busybox
To test it:
# busybox ls /system
To find which file configures your PATH (determines which executables get called):
# grep -r PATH= /etc
If you find a shell init file, you can edit and add the directory you want to the front of the path:
PATH="/directory/containing/busybox:$PATH"
fenstre said:
Hey, guys. I noticed ICS comes with a shell tool called "toolbox" (or maybe it's just my ROM). The traditional tool, called Busybox, is also installed. This tool is much more powerful--if basic shell commands like "mv" don't work properly, toolbox is probably to blame.
Or my system, the shell is mksh and the toolbox tools are installed in /system/bin and busybox is in /system/xbin. Is this the same on all ICS ROMs?
The command to modify the system path so the busybox tools are called preferentially to the toolbox tools is the following:
sed '/: place customisations above this line/i\PATH="/system/xbin:$PATH"' -i /etc/mkshrc
Like I said, I'm assuming my ROM is the same as other ROMs. But the point is to find the shell init file and add PATH="/system/xbin:$PATH" to it. As usual, make a system backup before making changes like this.
In this vein, does anybody know how to change the root user's shell? The "chsh" command doesn't exist on Android, nor does /etc/passwd.
Click to expand...
Click to collapse
You can just change the symlinks, with a quick shell script, run from the directory that has everything simlinked to toolbox
Something like:
for i in `busybox --list`
do
mv $i $i.android
ln -s `which busybox` $i
done
I still don't know the usefulness of busybox
:banghead:
Sent from my Xperia Live with WALKMAN using xda app-developers app
Related
Hey everyone,
wesgarner said:
Zip Align reduces the amount of RAM used during processing running for a major speed increase in running the apps: http://developer.android.com/guide/developing/tools/zipalign.html
Click to expand...
Click to collapse
I had been messing about with a script to pull apks off my phone, zipalign them and then push them back, but then I saw wesgarner's CM build with a binary and script for use on your phone. I don't really want to mess round with flashing a ROM just for that though, so I've ripped them out and uploaded them below. Another reason is I want to run this manually (with GScript) rather than on boot (as it does in wesgarner's ROM).
I take no credit for this, the binary and script were both taken from wesgarner's CM buiild.
To "install" this, just adb push the two files in the zip below onto your phone with:
Code:
adb shell mount -o remount,rw /system
adb push zipalign /system/bin
adb push zipalign_apks /system/sd/zipalign_apks.sh
adb shell chmod 755 /system/bin/zipalign /system/sd/zipalign_apks.sh
adb shell mount -o remount,ro /system
Then anytime you want to run the script just do:
Code:
adb shell sh /system/sd/zipalign_apks.sh
Or in terminal:
Code:
su
sh /system/sd/zipalign_apks.sh
Has been tested on CM 4.2.7.1
ZipAlign
senab said:
Hey everyone,
I had been messing about with a script to pull apks off my phone, zipalign them and then push them back, but then I saw wesgarner's CM build with a binary and script for use on your phone. I don't really want to mess round with flashing a ROM just for that though, so I've ripped them out and uploaded them below. Another reason is I want to run this manually (with GScript) rather than on boot (as it does in wesgarner's ROM).
I take no credit for this, the binary and script were both taken from wesgarner's CM buiild.
To "install" this, just adb push the two files in the zip below onto your phone with:
Code:
adb shell mount -o remount,rw /system
adb push zipalign /system/bin
adb push zipalign_apks.sh /system/sd
adb shell chmod 755 /system/bin/zipalign /system/sd/zipalign_apks.sh
adb shell mount -o remount,ro /system
Then anytime you want to run the script just do:
Code:
adb shell /system/sd/zipalign_apks.sh
Or in terminal:
Code:
su
sh /system/sd/zipalign_apks.sh
Has been tested on CM 4.2.7.1
Click to expand...
Click to collapse
i do not even know what zipalign does .. but i did add this to my script
# lucid -z
so .. what does it do exactly?
Sweet... Thanks...
I was surprised that more than half of the Apps I have were already ZipAligned...
LucidREM said:
i do not even know what zipalign does .. but i did add this to my script
# lucid -z
so .. what does it do exactly?
Click to expand...
Click to collapse
APKs (as you probably already know) are just zip files. zipalign simply aligns the APK on 4-byte boundaries which Android is more efficient wrt memory access.
You can read more from Jean-Baptiste Queru at http://android-developers.blogspot.com/2009/09/zipalign-easy-optimization.html
Vermithrax said:
Sweet... Thanks...
I was surprised that more than half of the Apps I have were already ZipAligned...
Click to expand...
Click to collapse
Since the 1.6 SDK was released, the ADT does this automatically on APK export. Therefore any app which has been updated since ~September (and was developed using the ADT Eclipse plugin) will be zipalign'd. I was more surprised that 12 out of the 43 apps on my phone weren't aligned!
ZipAlign
senab said:
APKs (as you probably already know) are just zip files. zipalign simply aligns the APK on 4-byte boundaries which Android is more much efficient wrt memory access.
You can read more from Jean-Baptiste Queru at http://android-developers.blogspot.com/2009/09/zipalign-easy-optimization.html
Click to expand...
Click to collapse
that's awesome .. thanks for the link .. i hadn't read about that
Thanks much for this!
Here is a simple gscript to install zipalign after a wipe or new build flash.
You must first create directory /sdcard/zipalign and place zipalign from the zip in the OP there. Path to the file should now be /sdcard/zipalign/zipalign.
Place this script in your gscript folder (after removing .txt from the name) and load it in gscript with su permissions.
I also find it easier to run the script in the zip from the OP in Gscript as well. Instead of placing it in /system/sd run this (assumes zipalign_apks.sh is at root of C:\)
Code:
adb remount
adb push C:\zipalign_apks.sh /sdcard/gscript/zipalign_apks.sh
Then just load it into Gsrcipt with su permissions as with the other script.
Easiest of all may just be to use the commands within Lucid's script. But, I'm comfortable with Gscript, and I can make it 2 clicks away.
EDIT: First execution, you may want to run the original way, because guess what? Gscript isn't zipaligned. But it worked fine just the same.
worked great thanks.
Thanks. I didn't want to flash whole ROM to zipalign apps, so script was very handy.
Actually I've zipaligned only 2 apps, one of them was everybody loved Linda
so anyone wanna bless me with a terminal code to install the script?
garz said:
so anyone wanna bless me with a terminal code to install the script?
Click to expand...
Click to collapse
Read, its on the first post....xD
ZipAlign
garz said:
so anyone wanna bless me with a terminal code to install the script?
Click to expand...
Click to collapse
# lucid -z
yeah so su? then #lucid -z? cause that did nothing for me...
LucidREM said:
i do not even know what zipalign does .. but i did add this to my script
# lucid -z
so .. what does it do exactly?
Click to expand...
Click to collapse
I put a quick explanation of my script on my ROM page: here ya go (rough explanation)
Zip Align reduces the amount of RAM used during processing running for a major speed increase in dex-opt and running the apps, along with the RAM hack and a CC (or your userinit) boots speeds incredibly and better usability of apps (boot and system) in Android: http://developer.android.com/guide/d.../zipalign.html
Most developers have not used this yet (CM does ZipAlign his apps), but this does for the system apps provided from the now old Google Apps
Click to expand...
Click to collapse
senab said:
Since the 1.6 SDK was released, the ADT does this automatically on APK export. Therefore any app which has been updated since ~September (and was developed using the ADT Eclipse plugin) will be zipalign'd. I was more surprised that 12 out of the 43 apps on my phone weren't aligned!
Click to expand...
Click to collapse
Agreed. The Market won't let non-zipaligned apps be uploaded.
AndroidAppCritic said:
Agreed. The Market won't let non-zipaligned apps be uploaded.
Click to expand...
Click to collapse
it will really, it doesn't detect the diff
Also, SDK4 didn't really include an enforced ZipAlign like SDK5 (eclair) does
Plus I built the ZipAlign from source from eclair - so this script may not update them all perfectly
garz said:
yeah so su? then #lucid -z? cause that did nothing for me...
Click to expand...
Click to collapse
Unzip the files to your SD Card, then:
Code:
su
mount -o remount,rw /system
mv /sdcard/zipalign /system/bin
mv /sdcard/zipalign_apks /system/sd/zipalign_apks.sh
chmod 755 /system/bin/zipalign /system/sd/zipalign_apks.sh
mount -o remount,ro /system
Post deleted becoz it was redundant
can someone make a script for windows or a bat file that can zipalign a batch of apks? I am not that ofay with line commands and when i create a new theme (which i often do), i then have to go and zipalign every single apk i have altered 1 at a time..... i do:
Code:
zipalign -f -v 4 E:\app\theapp.apk E:\app\theapp.apk.out
senab said:
Unzip the files to your SD Card, then:
Code:
su
mount -o remount,rw /system
cp /sdcard/zipalign /system/bin
cp /sdcard/zipalign_apks.sh /system/sd
chmod 755 /system/bin/zipalign /system/sd/zipalign_apks.sh
mount -o remount,ro /system
Click to expand...
Click to collapse
This isnt working for me bc of the .sh after zipalign_apks .. do i rename the zipalign_apks to zipalign_apks.sh after unzipping?
edit:that worked THANKS!
Most Android ROMs use toolbox as primary binary with symlinks in /system/bin and /system/xbin. The problem with toolbox is that it sucks. On some ROMs it's even so limited that it does not even allow for --prefix
Busybox is a great replacement for toolbox, but in order to use it, you have to call it using 'busybox cmd'. I would much rather use it by calling 'cmd' but this would execute toolbox instead of busybox.
Most would think the command 'busybox --install' would fix this, but it does'nt. It tries to install links at /bin and /sbin.
The script below will replace any toolbox links in /system/bin and /system/xbin that is supported by the busybox version installed on the Android device running the script. This will make busybox the default binary when executing regular commands without adding 'busybox' at the beginning of the command.
For an example 'ls' instead of 'busybox ls'
Download as an update.zip
v1.3.0 (Nov 17, 2012) (MD5: c233964f0f62a16d7376739041e8b250) - busybox_installer.zip (Only for ArmV7 devices)
v1.3.0 (Nov 17, 2012) (MD5: e921a6c4119644a18d4feea565824ab1) - busybox_installer-nobin (Without binaries)
busybox.sh
Code:
#!/sbin/sh
for cmd in test find basename readlink ln rm; do
eval export "_$cmd=\"/sbin/busybox $cmd\""
done
_busybox=$($_find /system -type f -name "busybox")
_toolbox=$($_find /system -type f -name "toolbox")
if $_test -e "$_busybox" && $_test -e "$_toolbox"; then
sToolboxList="watchprops wipe vmstat date uptime reboot getevent getprop setprop id iftop ioctl ionice log lsof nandread newfs_msdos notify ps r schedtop sendevent setconsole setprop sleep smd start stop top"
sBusyboxList="`$_busybox --list`"
for applet in $sBusyboxList; do
if $_test -L /system/bin/$applet; then
if $_test "`$_basename $($_readlink -f /system/bin/$applet)`" = "toolbox"; then
$_ln -sf $_busybox /system/bin/$applet
if $_test -L /system/xbin/$applet; then
$_rm -rf /system/xbin/$applet
fi
fi
elif $_test -L /system/xbin/$applet; then
if $_test "`$_basename $($_readlink -f /system/xbin/$applet)`" = "toolbox"; then
$_ln -sf $_busybox /system/xbin/$applet
fi
elif ! $_test -e /system/bin/$applet && ! $_test -e /system/xbin/$applet; then
$_ln -sf $_busybox /system/bin/$applet
fi
done
for applet in $sToolboxList; do
$_ln -sf $_toolbox /system/bin/$applet
done
fi
Toolbox install links
watchprops, wipe, vmstat, date, uptime, reboot, getevent, getprop, setprop, id, iftop, ioctl, ionice, log, lsof, nandread, newfs_msdos, notify, ps, r, su, schedtop, sendevent, setconsole, setprop, sleep, smd, start, stop, top
Busybox install links
Whatever the currently installed busybox supports that is not in the list of toolbox install links
Change log
Dec 10 2011, 21:39 UTC:
The script will now leave skip replacing /system/bin/reboot as it needs to be pointed at toolbox
Dec 11 2011, 10:08 UTC:
Added an update zip that will configure busybox and it provides an extended 1.4MB binary instead of the regular 480KB most ROM's provide
Dec 12 2011, 09:25 UTC:
Added new busybox build (1.20.0.git 2011-12-11) since there was problem with the old one for some people
Added more busybox search dirs (/system/sbin and /sbin)
Added Toolbox install to make sure that some android specific links uses toolbox instead of busybox. See list above.
Jun 27 2012, 13:45 UTC:
Better Busybox and Toolbox search
Added symlink check to make sure that busybox only replaces toolbox links and not things like "sh -> mksh"
Nov 17 2012, 10:30 UTC:
Added a custom toolbox binary to the ArmV7 installer
Added latest CM9 busybox binary to the ArmV7 binary
Added an auto search function to locate the binaries on the device
Fixed both installers to work with newer devices that uses EXT4 file system
Thanks, dk_zero-cool. I've been looking for a guide to installing BusyBox, since I can only find an add-supported installer in the Android Market.
Thanks, nice job!!
Ran the script, worked and did fine....ONE BIG ISSUE....now if you have any script or app that relies on the "reboot" function, it no longer works. For example, rom manager & bootstrapper will not boot into recovery. I even open up terminal and typed:
Code:
$ su
# reboot
...and nothing...does the reboot in /bin need to not be linked to busybox?
KMDonlon said:
Ran the script, worked and did fine....ONE BIG ISSUE....now if you have any script or app that relies on the "reboot" function, it no longer works. For example, rom manager & bootstrapper will not boot into recovery. I even open up terminal and typed:
Code:
$ su
# reboot
...and nothing...does the reboot in /bin need to not be linked to busybox?
Click to expand...
Click to collapse
Try to relink it back to toolbox and then I will update the script to leave reboot alone.
1: mount -o remount,rw /system
2: rm -r /system/bin/reboot
3: ln -s /system/bin/toolbox /system/bin/reboot
Great! Will try again!
Cool... can I steal this?
I'd implement it with a busybox install script
I'm not a super expert on the subject but is /system/sbin a possible location?
zeppelinrox said:
Cool... can I steal this?
I'd implement it with a busybox install script
I'm not a super expert on the subject but is /system/sbin a possible location?
Click to expand...
Click to collapse
You can use this as you like.
And you can type "echo $PATH" in an adb shell, if /system/sbin is there, then it will work. But why? /system/xbin is usually the default dir for placing busybox, otherwise /system/bin. And you will have to change the script since it will only check in /system/bin and /system/xbin
All times in my scripts report UTC time instead of system time, I am sure there is one other applet in /bin that was linked to toolbox that is now linked to busybox and reporting the date wrong or at least the date/time that busybox says (UTC time).
KMDonlon said:
All times in my scripts report UTC time instead of system time, I am sure there is one other applet in /bin that was linked to toolbox that is now linked to busybox and reporting the date wrong or at least the date/time that busybox says (UTC time).
Click to expand...
Click to collapse
Do the same as before, only this time replace 'reboot' with 'date'
This must be a setting in the busybox compile menu. A new binary might fix this because busybox should be able to display system time. But for now point date back to toolbox and it will work for you.
Yup, did what you just said and all is fine. Thanks! Is there a way you can implement the reboot and date applet ignore in the script within the .zip you made.... I think it will save users some headaches.
dk_zero-cool said:
You can use this as you like.
And you can type "echo $PATH" in an adb shell, if /system/sbin is there, then it will work. But why? /system/xbin is usually the default dir for placing busybox, otherwise /system/bin. And you will have to change the script since it will only check in /system/bin and /system/xbin
Click to expand...
Click to collapse
Well bb is sometimes installed elsewhere.
At first SuperCharger only looked in those 2 locations and stopped when it wasn't found.
What would happen if there was a second version elsewhere?
I suppose it wouldn't matter because of the symlinks.
KMDonlon said:
Yup, did what you just said and all is fine. Thanks! Is there a way you can implement the reboot and date applet ignore in the script within the .zip you made.... I think it will save users some headaches.
Click to expand...
Click to collapse
The reboot fix is already in the zip file.
The date fix I don't want in it, I would much rather fix busybox to work properly.
I'm currently looking at that.
zeppelinrox said:
Well bb is sometimes installed elsewhere.
At first SuperCharger only looked in those 2 locations and stopped when it wasn't found.
What would happen if there was a second version elsewhere?
I suppose it wouldn't matter because of the symlinks.
Click to expand...
Click to collapse
No that does not mater because of the symlinks.
That's why I referrer to the complete path, f.eks, "/system/xbin/busybox" and not just the binary name "busybox".
I am going to try your binary for Busybox and see, I am currently using JRummy's BB installer which installed v1.19.3 which is about 1.06MB....
EDIT: Just flashed the .zip, my phone will not boot past the logo....did a battery pull several times and can't get into CWR....SBF time
KMDonlon said:
I am going to try your binary for Busybox and see, I am currently using JRummy's BB installer which installed v1.19.3 which is about 1.06MB....
EDIT: Just flashed the .zip, my phone will not boot past the logo....did a battery pull several times and can't get into CWR....SBF time
Click to expand...
Click to collapse
Put in your USB cable, open a terminal/console on your computer and try "adb logcat" to see what it says when it stops booting.
You must of cause have adb installed on your computer, and USB drivers if you use windows, which I don't and cant help with.
Already reflashed phone back....sorry, no logcat....
Do it again...
C'mon take one for the team... hehe...
LMFAO!!!! Sorry dude, I ain't gonna do it....will let some other poor soul ....I got honey do's today, it's Sunday!!
Whatever it was I can't recreate it. Works fine when I flash the damn thing.
Here's a thought.....make a script that reverses the toolbox links, I can undo it and try to flash again....I was unable to manually install your busybox version so I think some other toolbox applet is causing me trouble.....
Having cross compiled an arm bash, I wanted to get rid of the limited ash shell. While trying to switch sh to bash, I've turned all the ramdisk scripts inside out, grepping the hell out of them, switching things like services and init scripts. But apparenty nothing I did switched the default shell.
I've even found the PS1 var in /system/etc/mkshrc and tried changing the shell there.
But I'm still missing the actual location where it gets set. Short of swapping out the file, replacing it with a bash softlink, I cant think of anything else. Does anyone know where the shell gets set?
I suspect it's hardcoded. For example, the following can be found in adb's service.c:
Code:
#if ADB_HOST
#define SHELL_COMMAND "/bin/sh"
#define ALTERNATE_SHELL_COMMAND ""
#else
#define SHELL_COMMAND "/system/bin/sh"
#define ALTERNATE_SHELL_COMMAND "/sbin/sh"
#endif
On most android systems, /system/bin/sh is the shell run when the system is booted, and that's usually a symbolic link to /system/bin/mksh. So, perhaps just change the symlink to point to something else.
Isnt that the code for adb's default shell? I dont mind adb having ash as default, since one can easily exec 'adb shell bash' and start with bash.
On the Desire, the bootup shell had kernel level binaries in /sbin/sh. The system shell could be easily switched.
garyd9 said:
I suspect it's hardcoded. For example, the following can be found in adb's service.c:
Code:
#if ADB_HOST
#define SHELL_COMMAND "/bin/sh"
#define ALTERNATE_SHELL_COMMAND ""
#else
#define SHELL_COMMAND "/system/bin/sh"
#define ALTERNATE_SHELL_COMMAND "/sbin/sh"
#endif
On most android systems, /system/bin/sh is the shell run when the system is booted, and that's usually a symbolic link to /system/bin/mksh. So, perhaps just change the symlink to point to something else.
Click to expand...
Click to collapse
How dependent is the ROM on the existing shell? I attempted to (I just created a new ROM to flash with these changes) to just remove the mksh and replace it with bash. Naturally (and as I was expecting) this did not work.
Here is what I think. You are right, but also wrong.
My thoughts are that that mksh is hard coded like you have said but the symbolic link is the other way around, mksh(parent) is symlinked to sh(child). sh without the symbolic link doesn't exist.
Replacing mksh with bash causes complete catastrophic failure ROM does not boot and all hell breaks loose. Reflash back to previous LOL. That being said, symlinking bash binary to sh also doesn't work, because the system is reading from hardcode mksh first and foremost and then sh beyond that.
replacing the mksh with bash and renaming bash to mksh also doesn't work (in an attempt to satisfy the existence of a required system file)
Apart from rebuilding the entire ROM from sources with everything patched to utilise the bash shell, I can't see this being an achievable goal.
May I ask why you want to specificially utilise the bash shell over sh? I know that this is much closer to native linux and it probably has some functionality benefits and syntax serendipities (no I am not trying to be funny - I am just stupid and cannot think of the right wording to use right now so that will do).....but is there something that you are trying to do within the sh shell environment that you cannot do that you know you can do with bash?
Jarmezrocks said:
May I ask why you want to specificially utilise the bash shell over sh? I know that this is much closer to native linux and it probably has some functionality benefits and syntax serendipities (no I am not trying to be funny - I am just stupid and cannot think of the right wording to use right now so that will do).....but is there something that you are trying to do within the sh shell environment that you cannot do that you know you can do with bash?
Click to expand...
Click to collapse
Apart from the obvious advantages of bash completion, coloured shell output in ls, grep and others, and the init scripts?
ash interpretation of shell scripts is a bit different from bash. Try nesting more than two levels of loops, and it makes it jargon.
Droidzone said:
coloured shell output in ls
Click to expand...
Click to collapse
That's got absolutely nothing to do with the shell. ls is not a shell built-in. Install BusyBox and alias ls to 'busybox ls --color=auto' in mkshrc, just like CM's bashrc does.
Same with grep, except BusyBox does not provide a colour option for its grep, so I guess that's out.
As for init.d scripts: just change the scripts' shebangs to use bash? Ubuntu has dash as its default /bin/sh as it's able to run init.d scripts (provided that they don't have bashisms) quicker than bash would.
Sent from my GT-I9300 using Tapatalk 2
qwerty12 said:
That's got absolutely nothing to do with the shell. ls is not a shell built-in. Install BusyBox and alias ls to 'busybox ls --color=auto' in mkshrc, just like CM's bashrc does.
Same with grep, except BusyBox does not provide a colour option for its grep, so I guess that's out.
Sent from my GT-I9300 using Tapatalk 2
Click to expand...
Click to collapse
dircolors needs an initialization script, and .bashrc was the easiest way I could find (short of using ramdisk scripts).
As per the manpages, dircolors has two formats-one for bourne and another for csh. So you need either of these as default shell to init .dircolors. If you dont need customization, it doesnt matter.
As for init.d scripts: just change the scripts' shebangs to use bash?
Click to expand...
Click to collapse
Yup.
Big Thanks: original [email protected] [http://classic.cx/android/dexo-universal-odex-tool/]
ADVANTAGES & DISADVANTANGES OF RE-ODEX
Advantages:
-All needed things are in one apk, so modding/theming is (better) possible
-Needs less space on /system
Disavantages:
-Needs more space on /data
-Is not so stable than a odexed rom
-Slower on first boot(because a odexed rom has already execute ready .odex files, a deodexed rom needs to generate dalvik cache)
===============================================
First step, please make a nandroid if you are unsure of what you are doing.
Second step, install busybox if it is not already installed. Either from the app or
from the binary I included (ie, adb shell busybox –install /system/xbin/)
Third step, push the four files zip, zipalign, dexo and dexopt-wrapper to /system/bin/
Fourth step, give the three files executable permissions (ie, chmod 755 zip zipalign dexo dexopt-wrapper)
Fifth step, run it!
Once the script is done, your phone will reboot. Your device will appear to be “frozen” until it reboots. That is ok.
Then all you will have to do is run:
adb pull /system/framework # JUST INCASE...YOU CAN SKIP THIS STEP.
adb pull /system/app # JUST INCASE...YOU CAN SKIP THIS STEP.
You are now done! The tool will automatically remove the classes.dex from your files as well as zipalign them. So you are optimized and ready to go.
Sample Terminal/Command prompt session. Basically you can copy and paste, ignoring the text after the # of course:
# Commands on Host computer
cd Downloads/universal-odex # change to the location you unzipped the odex tool.
adb remount
adb push dexo /system/bin/
adb push dexopt-wrapper /system/bin/
adb push zip /system/xbin/
adb push zipalign /system/xbin
adb push busybox /system/xbin # you may or may not already have busybox installed, but this will ensure that you have the correct applets installed
# Commands in ADB SHELL
adb shell # you just entered your Device’s shell
chmod 755 /system/bin/dexo /system/bin/dexopt-wrapper /system/xbin/zip /system/xbin/zipalign /system/xbin/busybox
busybox –install /system/xbin # maybe fail in this step..but it seems okay,go to the next step anyway.
dexo # this will be the last command before your exit adb shell and your device reboots
# The “dexo” command executes SUPER fast. It should be done within 30s-1m, depending on ROM and device
# Commands on Host computer
cd Desktop
mkdir framework
mkdir app
adb pull /system/framework framework
adb pull /system/app app
# Rejoice.
If it doesn’t work for you, then you did something wrong. This is version 3.1 of the script and I’d like to think that I’ve fool-proofed it pretty well.
If you have any questions, comments, or suggestions, please post here.
Exclusive to theMikMik.
Tommy
enjoy the possibilities…
FILES_NEEDED:
View attachment re_odex_needed.tar.gz
Bro, you mean de-odex instead of re-odex??
Or even re-de-odex lol
Sent from my Nexus 7 using Tapatalk 2
kingCV said:
Bro, you mean de-odex instead of re-odex??
Click to expand...
Click to collapse
yesyes..
Well currently i am using jackpal.androidterm emulator and always needed to type 2 commands bf new entriws would be allowed.
Namely the following commands. 1. startup su by running su command. 2. mounting r/o to r/w of /system mount blabla.
Well here comes in my helpfull hint (^o^)
go into settings menu and alter the startup command send to shell into this line of text.
su && busybox mount -o remount,rw /system
now ur emulator will always start with su approved (#) and /system
running as r/w mounted. u could add more commands as long as u
add these symbols btween commands && . take note there aint spaces inbetween or it wont work.
ohh and easy command help for terminal u get by typing the next
line of text. replace the COMMAND with desired item.
busybox COMMAND --help
use the busybox command on its own to see commands it can use..
hope helps someone who wanna know more about busybox and terminal emulator commands.
And if u wanna use bash scripts just add it to the startup command.
su && busybox mount -o remount,rw /system && bash
u need bash installed of course, and i used an alternate path so the program stays clean. i used /data/local/foldername to store my bash, busybox, android toolbox so they wouldnt get corrupted. the android toolbox i found in my /system/bin and i put bash and busybox into /system/xbin and all seems to work fine.
Sent from my GT-P3110 using XDA Free mobile app