[How-TO] Proper Dexopting order - G1 Android Development

This is just a hint about how to properly run dexopt-wrapper so that you can do it for framework too. I learned this by checking logcat.
I first started creating odexes back with JF's builds when we thought that odexes were the reason ion builds were so fast. Although that was eventually proven wrong, there are two latent benefits to having odexed apps; decreased usage of dalvik-cache (thus, more space in /data) and decreased first-boot time after a wipe.
The disadvantage of odexed apps is that, unless the classes.dex is kept inside the .jar or .apk, the app and framework are bound to each other (though an odexed framework can still be used under a full set of non-odexed apks, but not the other way around). This removes mix-and match, and it was the reason why I was waiting for a more current hero-dump that didn't have all it's apps and frameworks odexed.
One problem I've seen with roms that try using odexes is that the classes.dex is left inside the apk. I don't know yet whether this is intentional or not, but removing the .dex saves space (as it's no longer needed), but it won't ever be as small as just keeping it inside the apk (because inside, it's compressed), but having it both inside the apk and outside in dalvik-cache is redundant, i feel. Donut does a much better job at this, but I feel there's still room for improvement (why not use the largely unused /cache partition?).
Another problem I've seen is that roms that do have properly odexed app folders don't also odex the framework, and that's a biggie. Most of framework is nothing but dalvik executables, and their caches write about 15 MB to /data. To preserve space in data, I think these are a priority. I feel that whether or not /app is odexed is of less concern than not odexing framework, since it's immovable. The reason people don't odex frameworks, though, is because things just seem to break right afterwards. The problem is that regular odexing scripts just take an alphabetical aproach to dexopt-wrapper, but, looking at logcat, one realizes that there's actually an order on which this should be done.
First, we have to do (in order) what I call the "Core framework":
core.jar
then ext.jar
then framework.jar
then android.policy.jar
then services.jar
Secondly, we get into what I call the "Secondary Framework", it's basically all the frameworks that haven't been odexed yet, and order doesn't seem to matter anymore after that, so you can do it alphabetically, however, looking at logcat, dalvik vm does it in this order:
com.android.im.plugin.jar
com.google.android.gtalkservice.jar
android.test.runner.jar
com.google.android.maps.jar
android.awt.jar
svc.jar
pm.jar
monkey.jar
input.jar
ime.jar
framework-tests.jar
Be careful that your script doesn't try to create odexes for apks inside framework, as they have no classes.dex, but the wrapper will still create an .odex for it and cause problems.
last, you dexopt-wrapper /app folder, this is important, if you do app first, you'll get Android Runtime start problems because the dalvik code is not unprotected, so it wont pass verification (an odexed framework is, in a sense, a different version than a non-odexed).
After you get all your odexes. You can just go adb pull /system or adb pull /system/framework/*.odex and pull /system/app/*.odex and use those odexes to re-pack your build, removing classes.dex from inside apks and jars, and packing the odexes along with them.
Also, be sure that if you want to keep an app's ability to be upgraded, don't odex it (actually, don't even have it in /system, toss it to /data/app)

more proper
To make sure to stay current when new builds are released, and so you don't have to sort through logcat. Open up your init.rc and look for the line BOOTCLASSPATH and manually odex them first in that order. For ease of use you can use the attached scripts for ease of use.
Edit)
I'm posting from my phone so I can't upload...
(For framework)
for i in /system/framework/*.jar
do
odex=`echo $i | sed -e 's/.jar/.odex/g'`
echo "dexopt-wrapper $i $odex"
dexopt-wrapper $i $odex
done
(For system/app)
for i in /system/app/*.apk
do
odex=`echo $i | sed -e 's/.apk/.odex/g'`
echo "dexopt-wrapper $i $odex"
dexopt-wrapper $i $odex
done

Related

Porting Hero Parts

Well I dont know if someone else is working on this..so MODs spare with me. if someone is then close this thread. Moving on.
I've actually ported the Official Hero Camera/Camcorder (the one used from the Speedup Hero thread) to JF1.5 and it worked. A
LL FILES CAN BE FOUND IN HAYKURO'S HERO ROM(http://forum.xda-developers.com/showthread.php?t=521059) EXCEPT HTCCAMERA.APK WHICH I POSTED LINK FOR.
REMOVE CAMERA.APK FROM YOUR BUILD FIRST!!!!
NOTE: Installing the HTC Camera will also remove the old Gallery app with the old Camera, So HTC Gallery has to be ported.
PUSH THESE FILES TO THE FOLLOWING PLACES. THERE ALSO FOUND IN THE EXACT LOCATION FROM HERO. HTCCAMERA.APK IS FROM TEHSEANO'S SPEEDUP FOLDER
# NECESSARY FILES
Code:
SYSTEM - FRAMEWORK FOLDER
i.) com.htc.android.pimlib.jar
ii.) com.htc.framework.jar
iii.) com.htc.resources.apk
iv.)com.htc.android.easopen.jar (Dont know if needed but still ported it)
v.) ime.jar(Cant say if needed, it already has But still can have differencs)
SYSTEM - ETC - PERMISSIONS FOLDER
i.) platform.xml (MUST BE REPLACED VERY IMPORTANT FOR HTC APP FRAMEWORK)
II.) com.htc.framework.xml(Not sure if needed but doesn't kill to port)
SYSTEM - APP FOLDER
i.) HTCCamera.apk(FOUND HERE TEHSEANO:http://forum.xda-developers.com/showthread.php?t=521421)
SYSTEM - LIB FOLDER
i.) libcamera.so
ii.) libcameraservice.so
iii.) libqcamera.so
iv.) libcamerahal.so
v.) libc.so(dont know if needed)
HTCALBUM (Gallery) [So cant say these libraries are complete files needed]
Code:
SYSTEM - APP FOLDER
i.) HTCAlbum.apk
SYSTEM - LIB FOLDER
i.) libexif_htcalbum.so
Known Issues
1.the camera is now affected by the auto rotate sensor so when holding the phone upright, the camera is rotated oddly. (but have taken the pic, the pic is upright how its suppose in the gallery)
2. the shutter sound can't be shut off. Even with the option unclicked in the menu it still sounds off, although if I have read correctly, this is a Google bad in Android & not the actual app.
3. clicking the icon on the bottom (the gallery icon I'm guessing?) causes a force close
AS YOU CAN SEE I CANT ALL CREDIT FOR THIS BECAUSE I USED SANGEET.003 THREAD AS REFERENCE(http://forum.xda-developers.com/showthread.php?t=515840)
WILL TRY OTHER BUILDS WITH MY SPARE G1 AND TRY DIFFERENT APPS/WIDGETS..HELP IS APPRECIATED
CREDIT GOES TO HAYKURO,SANGEET,TEHSEANO, JF, IF I FORGOT YOU THEN PM ME AND ILL ADD
see if you can port the browser with flash, that would be a nice addition
I just posted a thread with the opposite in mind, but the same search for matching files. I am trying to find what files go to what apps so I can remove them to make rosie work even faster. you might check out my thread to see if any of those apps are on your list or vice versa.
http://forum.xda-developers.com/showthread.php?p=3883770#post3883770
Darkrift said:
I just posted a thread with the opposite in mind, but the same search for matching files. I am trying to find what files go to what apps so I can remove them to make rosie work even faster. you might check out my thread to see if any of those apps are on your list or vice versa.
http://forum.xda-developers.com/showthread.php?p=3883770#post3883770
Click to expand...
Click to collapse
will do...reading now
Anyway to have Rosie on Roger's?
Hmm if I have this correct then you and I are trying to do teh same thing =). I'm trying to find all teh necessary files to port the HtcMusic.apk from Rosie to Ion and in doing so I hope to extend this to other apps as well (possible get widgets too, dunno if it works that way though).
thelamacmdr said:
Hmm if I have this correct then you and I are trying to do teh same thing =). I'm trying to find all teh necessary files to port the HtcMusic.apk from Rosie to Ion and in doing so I hope to extend this to other apps as well (possible get widgets too, dunno if it works that way though).
Click to expand...
Click to collapse
i think music app you will also need the .odex file. i think for everything you will need the files i posted as necessary for theme to work because it has to deal with htc framework.
try these:
libm.so
libmedia.so
libmedia_jni.so
libmediaplayerservice.so
Try to port the Twitter widget .
defconoi said:
see if you can port the browser with flash, that would be a nice addition
Click to expand...
Click to collapse
oh crap does it really have flash player
This sounds like a wonderful idea. I'd love to see some of the widgets that rosie have come to the other roms. I hope this plan stays in motion!
is there a reason why my gallery isnt there and wont work when i click on the gallery icon on the camera screen?
superg05 said:
oh crap does it really have flash player
Click to expand...
Click to collapse
yeah just to give you a visual.... went to adobe on the browser to check...
How about the twitter widget.. i'd love it!
doubleokneegro said:
yeah just to give you a visual.... went to adobe on the browser to check...
Click to expand...
Click to collapse
we must port this at the least over, any idea what dependencies/libs it needs to work on 1.5 ?
hmm all the libraries wont fit on /system we may need to use the alternate spl...
maybe we can just symlink the individual files wherever we have space on the device
i highly doubt the widgets can be ported over.
the widgets were designed specifically for the Rosie UI.
as you all know Rosie, is just a fancy home replacement, similar to aHome, or Open Home.
remember before 1.5 when each of these had there on specific widgets.
well this works the same way.
regardless, good luck.
Porting the Hero Browser to DudeOfLife 1.2b
I am trying to port over the browser with flash, I spent a few hrs on it but gotta go to sleep, here is my progress...
Ok basically I moved the old framework to .bak files and copied over the htc framework from the hero rom and created symlinks to /cache/lib and /cache/framework and I still seem to be missing some libraries that I have symlinked. Note dont do any of this unless what you know what your doing, because it will cause your phone to constantly cycle while trying to load some libraries I am missing...
Here is the error im getting because im missing something:
D/dalvikvm( 137): Trying to load lib /system/lib/libwebcore.so 0x0
I/dalvikvm( 137): Unable to dlopen(/system/lib/libwebcore.so): Cannot find library
W/dalvikvm( 137): Exception Ljava/lang/UnsatisfiedLinkError; thrown during Landroid/webkit/WebViewCore;.<clinit>
D/AndroidRuntime( 137): Shutting down VM
And below is commands I used to symlink these libraries/apks because there isnt enough space in /system so I decided to use the 66 meg free on /cache
Of course you will have to adb push or cp your files from the hero rom thats either on your pc or on a sdcard
Code:
cd /system/framework/
busybox mv com.htc.framework.jar com.htc.framework.jar.bak
busybox mv com.htc.resources.apk com.htc.resources.apk.bak
ln -s /cache/framework/com.htc.framework.jar com.htc.framework.jar
ln -s /cache/framework/com.htc.resources.apk com.htc.resources.apk
cd /system/lib/
busybox mv libwebcore.so libwebcore.so.bak
busybox mv browsertestplugin.so browsertestplugin.so.bak
ln -s /cache/lib/libflashlite.so libflashlite.so
ln -s /cache/lib/libwebcore.so libwebcore.so
ln -s /cache/lib/browsertestplugin.so browsertestplugin.so
And of course the Browser.apk needs to be copied from Hero to /system/app
What libs am I missing?
Ok its 4:45 in the morning in Colorado, and im too tired to go on, if someone can continue where I left off and possibly suprise me in the morning with the browser ported that would be great!
Peace
defcon
Porting the Hero Browser to DudeOfLife 1.2b
I am trying to port over the browser with flash to dudes rom, I spent a few hrs on it but gotta go to sleep, here is my progress...
Ok basically I moved the old framework to .bak files and copied over the htc framework from the hero rom and created symlinks to /cache/lib and /cache/framework and I still seem to be missing some libraries that I have symlinked. Note dont do any of this unless what you know what your doing, because it will cause your phone to constantly cycle while trying to load some libraries I am missing...
Here is the error im getting because im missing something:
D/dalvikvm( 137): Trying to load lib /system/lib/libwebcore.so 0x0
I/dalvikvm( 137): Unable to dlopen(/system/lib/libwebcore.so): Cannot find library
W/dalvikvm( 137): Exception Ljava/lang/UnsatisfiedLinkError; thrown during Landroid/webkit/WebViewCore;.<clinit>
D/AndroidRuntime( 137): Shutting down VM
And below is commands I used to symlink these libraries/apks because there isnt enough space in /system so I decided to use the 66 meg free on /cache
Of course you will have to adb push or cp your files from the hero rom thats either on your pc or on a sdcard
Code:
cd /system/framework/
busybox mv com.htc.framework.jar com.htc.framework.jar.bak
busybox mv com.htc.resources.apk com.htc.resources.apk.bak
ln -s /cache/framework/com.htc.framework.jar com.htc.framework.jar
ln -s /cache/framework/com.htc.resources.apk com.htc.resources.apk
cd /system/lib/
busybox mv libwebcore.so libwebcore.so.bak
busybox mv browsertestplugin.so browsertestplugin.so.bak
ln -s /cache/lib/libflashlite.so libflashlite.so
ln -s /cache/lib/libwebcore.so libwebcore.so
ln -s /cache/lib/browsertestplugin.so browsertestplugin.so
Oh and dont forget to push the Browser.apk over
What libs am I missing?
Ok its 4:45 in the morning in Colorado, and im too tired to go on, if someone can continue where I left off and possibly suprise me in the morning with the browser ported that would be great!
Peace
defcon
In the hero rom there's a FlashPlayer.apk, you might need to port that over too for it to work
im really interested in getting this camera and camcorder to work correctly. what files do i move over to get the gallery back? because its kinda pointless to take pictures and videos if you cant send them anywhere? i tried doing it twice and i noticed that the gallery folders werent in the HTCCAMERA.apk so anyone have an idea? and flash would be nasty

Need someone to compile an APK for me

Alright, so I decompiled the apk, edited the XML files I needed to. And now it won't compile. Keeps throwing java errors. Would someone be so kind to compile this for me?
This is a System APK so it needs to be compiled and signed. If you're curious or it needs extra files pulled from somewhere, it's the SystemUI.apk in the CM7 Droid nightly build 88.
Thanks!!
Here's what I need compiled:
http://mikelierman.com/SystemUI.apk.zip
0vermind said:
Alright, so I decompiled the apk, edited the XML files I needed to. And now it won't compile. Keeps throwing java errors. Would someone be so kind to compile this for me?
This is a System APK so it needs to be compiled and signed. If you're curious or it needs extra files pulled from somewhere, it's the SystemUI.apk in the CM7 Droid nightly build 88.
Thanks!!
Here's what I need compiled:
http://mikelierman.com/SystemUI.apk.zip
Click to expand...
Click to collapse
What did you use to decompile it? APK Manager from this thread?
http://forum.xda-developers.com/showthread.php?t=695701
Oh and once you compile it, you don't have to sign it because is a system app and not a regular app.
0vermind said:
Alright, so I decompiled the apk, edited the XML files I needed to. And now it won't compile. Keeps throwing java errors. Would someone be so kind to compile this for me?
This is a System APK so it needs to be compiled and signed. If you're curious or it needs extra files pulled from somewhere, it's the SystemUI.apk in the CM7 Droid nightly build 88.
Click to expand...
Click to collapse
What errors are you getting from apktool? It's going to be hard for someone else to compile an apk that has not been decoded by them and not knowing what files have been changed. Letting us know at least what .png or .xml files were modified would be a start but will work best if we could just figure out why you aren't able to build with your modifications.
The first thing I noticed from the zip you attached is that it's missing the apktool.yml file that should get created a package is decoded. Second, make sure to pull /system/framework/framework-res.apk so resources can be decoded/built properly. If you are using APK Manager, use option 10 to decode with framework-res.apk. If you are just using apktool run the command "apktool if framework-res.apk" before decoding.
mazdarider23 said:
Oh and once you compile it, you don't have to sign it because is a system app and not a regular app.
Click to expand...
Click to collapse
SystemUI.apk actually does get signed using the platform key. The easiest way to do so in my opinion is to use ZipSigner 2 on your phone. Also, once you've placed the modified SystemUI.apk into /system/app make sure it's permissions are rw-r--r--(chmod 644 /system/app/SystemUI.apk) and it's owner:group is root:root(chown 0:0 /system/app/SystemUI.apk). Next reboot to recovery, wipe dalvik-cache and cache, then reboot.
MongooseHelix said:
What errors are you getting from apktool? It's going to be hard for someone else to compile an apk that has not been decoded by them and not knowing what files have been changed. Letting us know at least what .png or .xml files were modified would be a start but will work best if we could just figure out why you aren't able to build with your modifications.
The first thing I noticed from the zip you attached is that it's missing the apktool.yml file that should get created a package is decoded. Second, make sure to pull /system/framework/framework-res.apk so resources can be decoded/built properly. If you are using APK Manager, use option 10 to decode with framework-res.apk. If you are just using apktool run the command "apktool if framework-res.apk" before decoding.
SystemUI.apk actually does get signed using the platform key. The easiest way to do so in my opinion is to use ZipSigner 2 on your phone. Also, once you've placed the modified SystemUI.apk into /system/app make sure it's permissions are rw-r--r--(chmod 644 /system/app/SystemUI.apk) and it's owner:group is root:root(chown 0:0 /system/app/SystemUI.apk). Next reboot to recovery, wipe dalvik-cache and cache, then reboot.
Click to expand...
Click to collapse
Well I'm glad you told me because little old me has been modifying system apps since the days of the nexus one and I've yet to sign one....I think is all depends on who's doing the modification...hahahaha....Good luck 0vermind on finding someone to compiling your systemui.apk!
mazdarider23 said:
Well I'm glad you told me because little old me has been modifying system apps since the days of the nexus one and I've yet to sign one....I think is all depends on who's doing the modification...hahahaha....Good luck 0vermind on finding someone to compiling your systemui.apk!
Click to expand...
Click to collapse
I'm not quite sure what to make of that comment...I certainly wasn't trying to step on your toes so I apologize if it came across that way. Just wanted to help avoid and rule out any issues that might come up. With APK Manager or by using 7zip, you can move the manifest and/or META-INF folder containing the signature from the original but to imply that system apps are not signed is incorrect.
I also think it is important that those messing with system apps understand that there are different keys used to sign apps. For anybody reading this that wants to figure out how certain packages are signed, here's a bit of an explanation. If we extract SystemUI.apk, we see a directory called META-INF. This holds the key/signature info. The key's serial number can be determined with the following command:
Code:
keytool -printcert -v -file SystemUI/META-INF/CERT.RSA | grep SerialNumber
You can check other apks/jars and noticing which have matching serial numbers, meaning they are signed with the same key...
platform key - SystemUI.apk, Settings.apk, Phone.apk, etc
shared key - Contacts.apk, UserDictionaryProvider.apk, etc
test key - Calendar.apk, DeskClock.apk, etc
google proprietary key - Vending.apk, Talk.apk, etc (including some market user apps like Maps, VoiceSearch, Docs)
MongooseHelix said:
I'm not quite sure what to make of that comment...I certainly wasn't trying to step on your toes so I apologize if it came across that way. Just wanted to help avoid and rule out any issues that might come up. With APK Manager or by using 7zip, you can move the manifest and/or META-INF folder containing the signature from the original but to imply that system apps are not signed is incorrect.
I also think it is important that those messing with system apps understand that there are different keys used to sign apps. For anybody reading this that wants to figure out how certain packages are signed, here's a bit of an explanation. If we extract SystemUI.apk, we see a directory called META-INF. This holds the key/signature info. The key's serial number can be determined with the following command:
Code:
keytool -printcert -v -file SystemUI/META-INF/CERT.RSA | grep SerialNumber
You can check other apks/jars and noticing which have matching serial numbers, meaning they are signed with the same key...
platform key - SystemUI.apk, Settings.apk, Phone.apk, etc
shared key - Contacts.apk, UserDictionaryProvider.apk, etc
test key - Calendar.apk, DeskClock.apk, etc
google proprietary key - Vending.apk, Talk.apk, etc (including some market user apps like Maps, VoiceSearch, Docs)
Click to expand...
Click to collapse
Thanks, I didn't know this! I'm glad there's people like you and mazdarider23 on this forum that know **** like this!!!

[SCRIPT] Repack multiple APKs with proper compression settings (and other stuff!)

Hi Guys,
I was speaking to baadnwz a couple of weeks ago and i asked him which script he used to properly pack all the APKs in his ROM. He told me he used no script, just repacked the APKs he thought were most relevant.
I figured it couldn't be too hard to write something that took an APK, extracted it somewhere, then repacked it with the proper compression, so i wrote one. baadnwz then challenged me to make it work for multiple APKs, so he can just run it against a folder full of them like a lazy asshole. i went one better, and made a script that you could run against a ROM folder structure, it will search out all APKs, repack them, and copy them back into place. HOT!
because this uses recursion and functions to make it easier to write (and because i'm generally comfortable in it), i have written it in VBScript. So this means it won't work on linux as far as i know, sorry. Feel free to convert it or whatevs
WHAT DOES IT DO??????//
1. finds an APK
2. unpacks it in a folder
3. optimises the PNGs (if you want it to)
4. repacks all files as deflate except a blacklist of filetypes*
5. repacks the blacklisted filetypes* as STORE
6. zipaligns the new APK
7. copies it back to the original location, overwriting the original APK
8. finds the next APK, and repeat from step 2
* the blacklisted file types are easily editable. just find the STOREFileNames variable. by default the filetypes are:
"*.arsc", "*.m10", "*.png", "*.wav", "*.ogg", "*.mp4", "*.jpl", "*.jpeg", "*.gif","*.mp2", "*.mp3", _
"*.aac","*.mpg", "*.mpeg", "*.mid", "*.midi", "*.smf", "*.jet","*.rtttl", "*.imy", "*.xmf", _
"*.m4a","*.m4v", "*.3gp", "*.3gpp", "*.3g2", "*.3gpp2", "*.amr", "*.awb", "*.wma", "*.wmv", _
"*.so", "*.dat", "*.bin"
WHY DO YOU WANT THIS??
If certain filetypes in the APK are compressed as STORE (which means they aren't compressed at all), then Android can use them directly. If they are stored as DEFLATE (like all other file types should be), then Android must first decompress the APK somewhere. This means slower apps, more cache, and it's just not how things are supposed to be done. This script makes sure that all files inside all APKs are stored as they should be, and it will optimise PNG files and zipalign the final APK as it goes.
This script is really meant for ROM chefs to run against their ROMs before releasing them, but if you (a mere user) have a ROM that your chef hasn't run this script on, then you can extract the ROM, run the script on it, then recompress the ROM and flash it.
HOW DOES IT DO IT?????///////
It uses the command line version of 7-Zip. Download it from here:
http://7-zip.org/download.html
It uses zipalign.exe from the android SDK. if you don't know where this comes from.. maybe you shouldn't be using this script
It uses a cool OptiPNG utility to optimise the PNGs if you want it to. This slows the processing down a lot.. but it's up to you if you wanna do it. You'll need to download the utility from here:
http://optipng.sourceforge.net/
WHAT DO I HAVE TO DO TO MAKE IT WORK//////?
Grab the script, put it in the same folder as the root of your ROM (the script will repack all APKs in the subfolders from where it's sitting, including the APKs in the folder the script is in).
open up the script, there are 5 variables you MUST verify, most likely you will have to change them.. unless you put things on a D and E drive and your name is Nick..
tempAPKextract = "E:\Temp\tempAPKExtract"
tempAPKBuild = "E:\Temp\tempAPKBuild"
sevenZipLoc = """D:\nick\android\7za\7za.exe"""
zipAlignLoc = """D:\nick\android\android-sdk-windows\tools\zipalign.exe"""
optiPNGLoc = """D:\android\7-zipA\ROM\optipng.exe"""
the first two temp ones can be anywhere.. just make sure at least the sub folders up to "tempAPK..." exist (eg in this case the E:\Temp folder must already be there)
the next three are the locations of the tools required for the script to work, edit to please!
Run the script. If you have set verboseOutput to true (it's false by default), then I would highly recommend you run the script from the commandline with the command:
cscript fixAllAPKs.vbs
anyways, hope it's useful to you.
DOWNLOAD
CHANGELOG????/
v1.5.1 - cleaned up some code, added in verboseOutput so you can watch the progress as it's fixing (must run as cscript!)
v1.5 - added OptiPNG to the script, enabled by default. Quite slow. Added some more file types.
v1.4.3 - added more file types to STORE, thanks gtg465x
v1.4.1 - minor code clean up, fixed some comments.
v1.4 - fixed the problem where the script wouldn't fix any APKs in the root folder that the script was in
v1.3 - almost doubled the speed of the script. fixed some naughty bugs
edit: nevermind
not from what i've been told. if it's not compressed, the android system doesn't have to explicitly decompress it somewhere when it wants to use it, it can just pick it straight out of the APK.
omniwolf said:
not from what i've been told. if it's not compressed, the android system doesn't have to explicitly decompress it somewhere when it wants to use it, it can just pick it straight out of the APK.
Click to expand...
Click to collapse
Good man. Here are all of the files blacklisted by the default Android Asset Packaging Tool (aapt) if you want to include them.
{
".jpg", ".jpeg", ".png", ".gif",
".wav", ".mp2", ".mp3", ".ogg", ".aac",
".mpg", ".mpeg", ".mid", ".midi", ".smf", ".jet",
".rtttl", ".imy", ".xmf", ".mp4", ".m4a",
".m4v", ".3gp", ".3gpp", ".3g2", ".3gpp2",
".amr", ".awb", ".wma", ".wmv"
};
cool, thanks for the info. i've added the missing ones in and uploaded a new version.
cheers!
Nice work.
Suggestion or maybe a challenge for Ver 2:
Given a definition of what languages the user defines, can you repack including only those languages. This would include both drawables and layout language folders.
Removing languages not only speeds up the rom but reduces the apk size which for Sense 3.0 is becoming challenging for many older (> 1 year) devices.
Thanks for your contributions to XDA.
Also need to add .so to the blacklist. Ran into a problem with that the other day.
Here's mine.
It synchronizes with our SVN repository and builds the rom. Any commits which were made are automatically turned into a new ClockWorkMod flashable package.
Code:
#! /bin/sh
#This is the repository Directory, change to match your setup
Repo="~/TeamKomin/trunk"
#This is the Final folder, this is where the file will end up
Output="~/Desktop"
#synchronize SVN repository
svn update "$Repo"
#remove temp folder if exist
test -e "$Output/tmp/" && rm -Rf "$Output/tmp/"
#make new temp folder
mkdir "$Output/tmp/"
#copy repository to temp folder
cp -rf "$Repo/data" "$Output/tmp/"
cp -rf "$Repo/META-INF" "$Output/tmp/"
cp -rf "$Repo/system" "$Output/tmp/"
cp -rf "$Repo/updates" "$Output/tmp/"
#clear SVN folders to reduce size
find "$Output/tmp/" -name ".svn" -type d -exec rm -rf {} \;
cd "$Output/tmp"
#remove old files if there
test -e "$Output/AndromedaRepo.zip" && rm -f "$Output/AndromedaRepo.zip"
#zip up a new Andromeda3 version
zip -r "$Output"/AndromedaRepo.zip ./*
#done
I've also got a version which uses the Expect command to log into our SFTP server and update the files.teamkomin.com website... I'm not posting that here though as it contains security sensitive information.
Using this method, all members work on the ROM as though it were on the phone... This script packages it. No need to package or unpackage the entire thing.
myn said:
Nice work.
Suggestion or maybe a challenge for Ver 2:
Given a definition of what languages the user defines, can you repack including only those languages. This would include both drawables and layout language folders.
Removing languages not only speeds up the rom but reduces the apk size which for Sense 3.0 is becoming challenging for many older (> 1 year) devices.
Click to expand...
Click to collapse
ok, sounds like a good idea. i'm not actually a ROM developer, so i don't know the ins and outs of the various files. any hints on which files i exclude for various languages? just having a vague look around i see in framework-res.apk there's some raw-ar, raw-cs, raw-en-GB folders, are these the ones you're saying i can strip out?
this will obviously be a lot easier if i can do it programmatically, do you know the rules?
Also need to add .so to the blacklist. Ran into a problem with that the other day.
Click to expand...
Click to collapse
ok cool, added it in and uploaded 1.4.3. thanks dude.
Here's mine.
It synchronizes with our SVN repository and builds the rom. Any commits which were made are automatically turned into a new ClockWorkMod flashable package.
I've also got a version which uses the Expect command to log into our SFTP server and update the files.teamkomin.com website... I'm not posting that here though as it contains security sensitive information.
Using this method, all members work on the ROM as though it were on the phone... This script packages it. No need to package or unpackage the entire thing.
Click to expand...
Click to collapse
ok cool. does this actually repack and zip align the APKs though? this looks like it just takes care of the overall ROM zip structure, not the APKs within..? maybe your script could call mine.. if there was a vbs parser for linux
omniwolf said:
ok, sounds like a good idea. i'm not actually a ROM developer, so i don't know the ins and outs of the various files. any hints on which files i exclude for various languages? just having a vague look around i see in framework-res.apk there's some raw-ar, raw-cs, raw-en-GB folders, are these the ones you're saying i can strip out?
this will obviously be a lot easier if i can do it programmatically, do you know the rules?
ok cool, added it in and uploaded 1.4.3. thanks dude.
ok cool. does this actually repack and zip align the APKs though? this looks like it just takes care of the overall ROM zip structure, not the APKs within..? maybe your script could call mine.. if there was a vbs parser for linux
Click to expand...
Click to collapse
We keep the APKs on the server for ease of use. It makes it easier to reference a single file for testing that way.
http://www.jsware.net/jsware/vblinux.php5
vbscript on linux with wine!
Got error on line 118 - WshShell.Run
Anything else shall I edit apart of 4 paths? I have 64-bit OS if that matters.
I just realized how much easier this would be on linux...
Code:
#! /bin/bash
OutDir=~/Desktop/newRom
InDir=~/Desktop/myRom
zipAlign=/home/adam/code/android-sdk-linux_x86/tools/zipalign
TempDIr=~/Desktop/TempDir
FIFO=~/Desktop/temp1234
realign="apk dll whatever files"
#set things up
rm -Rf "$OutDir"
mkdir "$OutDir"
rm "$FIFO"
mkfifo "$FIFO"
#Move to dir and start script
cd InDir
#Spawn another process to write to the fifo object
find `pwd`>"$FIFO" &
#read each line in the fifo
while read line
do
#get each object extension in $realign variable
for x in $realign
do
#test if the extension matches the realignment
if [ $x = ${line#*.} ]; then
#make the path in case it does not exist, could be optimized
touch "$line"
#meh... this would be the command ish...
"$zipAlign" "$line" "$temp/$line"
else
mv "$line" "$temp/$line"
fi
done
done <$FIFO
#this just removes the redundant filesystem created...
#/home/adam/desktop/out/home/adam/desktop/myrom
rm -Rf "$OutDir"
mkdir "$OutDir"
mv "$/TempDIr/$InDIr" "$OutDir"
Untested, should work with some realignment of the variables at the top.
mike1986. said:
Got error on line 118 - WshShell.Run
Anything else shall I edit apart of 4 paths? I have 64-bit OS if that matters.
Click to expand...
Click to collapse
i'd say it's a problem with your
sevenZipLoc
variable, it's the first place it gets used. my OS is 64bit too, so that shouldn't be a problem. what does your sevenZipLoc variable look like?
omniwolf said:
i'd say it's a problem with your
sevenZipLoc
variable, it's the first place it gets used. my OS is 64bit too, so that shouldn't be a problem. what does your sevenZipLoc variable look like?
Click to expand...
Click to collapse
sevenZipLoc = """C:\Program Files\7-Zip\7z.exe"""
EDIT:
It seems that I forgot to download "command version"...
Any way to add optimizing PNGs to this script as well?
williamfold said:
Any way to add optimizing PNGs to this script as well?
Click to expand...
Click to collapse
show me how to do this and i might be able to add it in..
Heres the link to the opensource OptiPNG program to optimize a PNG
http://optipng.sourceforge.net/
I hope it perfectly work
wow thanks bro, that's way i need to learn about it

[HOW-TO] Re-Odex a ROM

I made a tutorial for other devices here http://forum.xda-developers.com/showthread.php?t=1500475
Why this tutorial?
I wanted a good odexed rom, but there isn't any here. So I tried to make my own odexed rom, but it wasn't so good. So I read something about re-odexing and tried it out. I modified it a little bit and I don't know all about re-odexing, so if someone know something better, pls post it here in the thread for everyone. Im working also on this thread, so I'll try to make few things like a flashable update.zip who executes the script. English is also not my mother language, but I hope you'll understand me
What is a odexed and a deodexed rom?
When you look at a stock rom in the folder /system/app, you will see files with the ending .odex and the apks doesn't contains classes.dex files. When you look at a deodexed rom, you'll see that there are no .odex files and the apks contains classes.dex files. Basically every apk contains a classes.dex files. Then the dalvik virtual machine generates a dalvik cache based of the classes.dex file. When you load a app, it will be loaded from the the dalvik cache, not from the apk. Samsung built the odexed rom using a tool called dexopt-wrapper. This tool generates .odex files based from the classes.dex, that means it does the same job like the dalvik vm. The .odex files were pushed in the /system. The files are the replacement for the dalvik cache. Like I wrote above, apps are loading from the dalvik cache, not from apk or classes.dex file, so classes.dex are not needed anymore, so they are deleted in odexed roms. Deodexing using xUltimate means regenerating a classes.dex based from the .odex file, merging it into the apk and deleting .odex.
What are the advantages and disadvantages from a deodexed rom?
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, you have on some roms only 110/170 mb free(because a deodexed rom needs a dalvik cache for system apps and frameworks
-Is not so stable than a odexed rom(because some moves dalvik cache to a low end sdext)
-Slower on first boot(because a odexed rom has already execute ready .odex files, a deodexed rom needs to generate dalvik cache)
Why should I re-odex?
I wanted this, because I use ~100 apps and I have a slow sd card, so moving /data/app and /data/dalvik cache to sdext made my system unstables, which was needed to run ~100 apps on a deodexed rom. But when I tried it on a odexed rom, I had only to move /data/app to sdext. So I used long time Stock rooted JPU. But the system was not so fast than on any other custom rom and I hated the stock theme. So If you want more space on /data and you don't want to try out new themes, you should probably try re-odexing.
What do I need to re-odex?
-A full NANDroid Backup
-More than 30 mb free space on /system
-ADB drivers for Option 1
-Titanium Backup Pro for Option 2
How can I re-odex a Rom?
There are 2 Options to do it, but only the first does a full re-odex.
Before doing anything make sure that you have a full NANDroid Backup because you'll propably get into a bootloop.
Option 1 using dexopt-wrapper:
I used first the script from puppet13th, but I got into a bootloop. So I corrected the $BOOTCLASSPATH and corrected permissions, but I got also into a bootloop. I compared the re-odexed Kyrillos Rom v9.3 framework with the framework from JPU. The difference was that Kyrillos Rom v9.3 Framework files android.policy.jar and services.jar doesnt contained the Meta-Inf.
Step 1: Check jars
Pull all your framework .jars using this adb command to your computer
Code:
adb pull /system/framework
and open them in WinRar or sth and check that they contains the Meta-Inf folder. If some file doesnt contain a Meta-Inf folder, I attached all jars from Stock JPU, so you can add the Meta-Inf folder from them. When you are done with adding Meta-Inf Folder to one file, you can push it to the system using this adb command(services.jar is only for example, use your filename):
Code:
adb push services.jar /system/framework
Some users told me that you can re-odex the rom without being in CWM, so you can may skip Step 2, but you could get into a bootloop without Step 2, but you can try it out, there is no risk with a NANDroid backup
Step 2(optional): Reboot your phone into cwm recovery and get adb access there
I never got adb access in windows, but i got always access with linux. If you also don't get access on Linux, you should try to reboot your phone and to select then recovery in the extended power menu, this gaves me always adb access.
Step 3: run reodex script
I attached a script, which push a script and needed binaries over adb to the phone. Then it executes the pushed script, which creates odex files and removes classes.dex from apks or jars and rezipaligns apks and deletes the dalvik cache.
For windows users: double click on odex.cmd
For linux users: open a terminal and navigate to the folder which contains the unzipped attachment and run
Code:
chmod +x reodex.sh
./reodex.sh
After its finished, simply reboot and enjoy your fully re-odexed rom.
Step 4 (optional) convert /data:
I dont know if there is a better option, but after a re-odex with Option 1, my phone didnt showed the right free space on /data. So I converted /data to a other filesystem and back and then it showed the right free space.
Option 2 using Titanium Backup Pro:
You need to have Titanium Backup pro for re-odexing.
Step 1:
Select Menu -> More -> integrate sys dalvik into rom and wait until its finished. Then you should have more space on /data. I had when I tried it before 105 and after 135 mb free space on /data and 0kb free space after it on /system, so its not all.
You can also undo it. Its good when you want to try out a new theme, so you can undo and redo it using TB Pro.
Simply select Menu -> More -> Undo sys dalvik integration
and you're done.
Option 1 vs. Option 2
-Option 1 does a full re-odex, you have full free space on /data(Option 2 does only re-odex the apps, not the framework)
-Option 1 deletes classes.dex from apks and jars(against Option 2), so you have more space free on /system
-You can undo Option 2 fast, so theming/modding is also possible by undo, theme and redo it(against Option 1)
For other Phones:
If someone has a other phone, theres a chance for getting re-odex working, but I think that you should not hope that it works. You can try to put in the right $BOOTCLASSPATH. You can find the valid $BOOTCLASSPATH in /init.rc. Then replace the following characters with the $BOOTCLASSPATH in the script in the folder odex(beginning from Line 8):
Code:
BOOTCLASSPATH=replace_this_with_your_bootclasspath
cd /system/framework
for filename replace_this_with_your_bootclasspath
In the line
Code:
for filename replace_this_with_your_bootclasspath
you must replace the ":" character between framework files with a space.
For theme developers:
I dont know if it works that you use the re-odexed theme on a stock odexed theme. If it is so, you dont have to re-odex and deodex your phone, you can simply push the dexopt-wrapper binary to a folder, chmod 755 it and use it to make odex files from the needed apks and jars(all apks inside /system/framework has no odex files, so dont odex them) like this:
Code:
dexopt-wrapper /system/app/Phone.apk /mnt/sdcard/Phone.odex /system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
You can change argument 1-2, but not argument 3(its the BOOTCLASSPATH)Then you could copy all needed main apks or jars to sdcard and remove classes.dex. Then only do Step 1 from Option 1 and you should have a theme for odexed rom.
Download Links
XDA gaves me only 500 Errors when uploading was done, so I uploaded it to min.us
Framework jars from JPU
Re-Odex Script for Windows
Re-Odex Script for Linux
Credits
puppet13th for making orginal script
If I helped you, dont be shy, just press the Thanks Button under this post.
www.kingsrom.com/f8-how-to-theme-guideslinkstutorials
Oh year I didnt see any tutorial before, but his is only for Froyo sense or Gingerbread aosp, so it wont work on galaxy 3 and I also wrote my tutorial so that noobs can understand it(I hope so).
I could also post a system.img of a re-odexed Kyrillos Rom v9.3 and other Roms, but I dont know if Im allowed to do that.
TearsDontFalls said:
Oh year I didnt see any tutorial before, but his is only for Froyo sense or Gingerbread aosp, so it wont work on galaxy 3 and I also wrote my tutorial so that noobs can understand it(I hope so).
I could also post a system.img of a re-odexed Kyrillos Rom v9.3 and other Roms, but I dont know if Im allowed to do that.
Click to expand...
Click to collapse
So the re-odexed kyrillos rom v9.3 is working faster than the original kyrillos rom v9.3??
Its not generally faster, but much faster for me because I have ~100 apps and when I run these apps on kyrillos v9.3 deodexed, i must move app and dalvik-cache to sdext which made my phone laggy. With a odexed kyrillos v9.3, i have much more space free on /data, so i only must move app to sdext which is much.
I wrote also the advantages and disadvantages from a deodexed and odexed rom in my tutorial.
TearsDontFalls said:
Its not generally faster, but much faster for me because I have ~100 apps and when I run these apps on kyrillos v9.3 deodexed, i must move app and dalvik-cache to sdext which made my phone laggy. With a odexed kyrillos v9.3, i have much more space free on /data, so i only must move app to sdext which is much.
I wrote also the advantages and disadvantages from a deodexed and odexed rom in my tutorial.
Click to expand...
Click to collapse
So, in a re-odexed rom the HD2SD is not working ?
You use again froyo data2SD ?
dante_100 said:
So, in a re-odexed rom the HD2SD is not working ?
You use again froyo data2SD ?
Click to expand...
Click to collapse
As far as I understand, it works but only for data/app.
correct me if I'm wrong
Sorry, my english is not the yellow from the egg(you must not understand this).
Im using on my re-odexed rom also Hybrid Data 2 SD, I can move also move /data/dalvik-cache and any other folder to sdext, its only not needed, because I had after the re-odexing much more free space on /data, so I did moved dalvik cache back to the NAND from the sdext, before re-odexing I moved dalvik cache to sdext, becaue it was needed for running ~100 apps.
short form:Only Theming is impossible with a re-odexed rom
Hope you'll understand this now.
Edit: Can someone help me for creating a update.zip for re-odexing. It must only copy the dir odex to /data/local/tmp/odex , chmod 755 them all and execute the shell script /data/local/tmp/odex/odex
Sooo
if i get ADB access using windows i can skip step 2 in option1 right?
chandradithya said:
Sooo
if i get ADB access using windows i can skip step 2 in option1 right?
Click to expand...
Click to collapse
No. You need to reboot in cwm and try to get adb access from there. Windows adb in recovery never worked for me, you need linux to get adb access from cwm mode
Sent from my i9003 powered by Poseidon's Rom + UC kernel
Right, I tried to make a update.zip which execute the script, but i had no success, it would be great if somebody can help me.
bscraze said:
No. You need to reboot in cwm and try to get adb access from there. Windows adb in recovery never worked for me, you need linux to get adb access from cwm mode
Sent from my i9003 powered by Poseidon's Rom + UC kernel
Click to expand...
Click to collapse
ADB actually works for me, just ran cmd.exe using admin privileges and i ran the odex script it worked, odexed ALL my system files, cleared my /data/dalvik-cache/
But like TearsDontFalls said it doesn't show the free memory correctly,
Im running g3mod and im yet to try the option4 that asks you to switch file systems
And the /g3mod.log says,
st17: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
While the other partitions are all clean,
How did you got adb access in windows? Sure you was in cwm recovery while re-odexing?
Finally, someone post a guide on this. And it works! Though titanium backup never worked for me. And is it necessary to run the script on cmw? Cause I didn't done it on cmw.
Sent from my GT-I5800 using XDA App
I didn't expect that it works on a running system, but it can be so, so I'll update the guide after Christmas.
TearsDontFalls said:
How did you got adb access in windows? Sure you was in cwm recovery while re-odexing?
Click to expand...
Click to collapse
It worked perfectly for me,
I tried going to the G3 kernels recovery, ADB just wouldnt connect,
so i turned it on, Ran the script when it was in standby mode , then it gave an error at first,
Which i rectified by making the /system read or write using root explorer,
I think i ran the script using admin privileges.
Dont remember..
And g3mod.log showed me this
Code:
Checking mmcblk0p2
/dev/block/mmcblk0p2: clean, 11/125488 files, 15840/500173 blocks
Checking stl6
/dev/block/stl6: clean, 1302/13600 files, 46914/54400 blocks
Checking stl7
/dev/block/stl7 contains a file system with errors, check forced.
/dev/block/stl7: Inodes that were part of a corrupted orphan linked list found.
/dev/block/stl7: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Checking stl8
/dev/block/stl8: clean, 12/2176 files, 143/8704 blocks
Data2SD Disabled
Multi-OS Data Disabled
System detected: FROYO
System booted with Samsung Froyo kernel mode
Compcache disabled
No problems right now, But cant stop wondering why it says it is inconsistent.
I don't know why it is so, but it also doesn't show the right free space, so convert it to a other file system and then convert it back.
UNBELIEVABLE!
Finally, the first method worked for me.
Working great on HTC Amaze 4G
Thanks
heyjoe66 said:
UNBELIEVABLE!
Finally, the first method worked for me.
Working great on HTC Amaze 4G
Thanks
Click to expand...
Click to collapse
Thanks for your report. So it seems to be working on other devices, so I'll create a thread in android development.
Thanks works on sense 3.5, but I had to change Bootclasspath from the boot.img and add missing files below in odex script.
great guide
edit: now searching on how to re odex a single file.

[Q] Modifying .odex file

Is it possible to modify code in a system .odex file without de-odexing?
Here is what I've been trying, without success (Windows computer, Samsung Epic 4G Touch phone, stock ROM with 2.3.6):
On my computer, using Android Commander, I pull a .odex from /system/app to my computer. There is a corresponding .apk, but I leave that alone. I also pull the entire /system/framework folder.
On my computer, from the location containing the framework folder and the .odex file, I run "java -jar baksmali.jar --api-level 10 -d framework -x <FILE_NAME>.odex". This creates an "out" folder, with the com/android/<FILE_NAME> folder structure and the code.
I modify the code (.smali files).
I rename the original .odex file and run "java -jar smali.jar --api-level 10 out/ -o <FILE_NAME>.odex". This creates a new .odex file that, as far as I can tell, should have the updated code in it.
Using Android Commander, I push the new .odex to /system/app on my phone, change the permissions to 644, and reboot the phone.​
The changes aren't having an effect. In fact, the status bar is completely gone (the example I'm working on is a mod to the status bar in SystemUI.odex).
Any idea what I'm doing wrong?
So I'm getting the feeling that it's not possible to edit odexed apks. Is there anyway to de-odex just a single apk rather than the whole rom?
Brent212 said:
So I'm getting the feeling that it's not possible to edit odexed apks. Is there anyway to de-odex just a single apk rather than the whole rom?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1208320
Basically, no odex can be edited and put back that easy. Wrapping and Signing ODEX style is required.
Awesome! That thread's perfect. I'm hoping I can deodex, mod the code, create a classes.dex file and put it in with the .apk, zipalign it, and just replace the existing .apk and .odex with the new .apk.
That thread (http://forum.xda-developers.com/showthread.php?t=1208320) had the answers I was looking for.
The trick was to either rename the new .odex to classes.dex and put it into the .apk, and zipalign the .apk (although I have a feeling that wasn't actually necessary), or to copy the signature from the old .odex file to the new one.
Brent212 said:
That thread (http://forum.xda-developers.com/showthread.php?t=1208320) had the answers I was looking for.
The trick was to either rename the new .odex to classes.dex and put it into the .apk, and zipalign the .apk (although I have a feeling that wasn't actually necessary), or to copy the signature from the old .odex file to the new one.
Click to expand...
Click to collapse
Odex is not dex. And vice versa. Remember that. When compiling, the result is always dex. To have odex, you need to wrap it with dexopt-wrapper within your phone.
sent from my white ray using XDA App

Categories

Resources