Modify file .apk in HandHeld/HH
With application apkeditor and dalvik byte code
Related
Hi there,
I has disassembled an odex file and changed something. As I understand I can't make it an odex again but I must make a dex file and put this with the filename classes.dex in the apk file.
Can I just put it in the apk file and just sign the package again or do I need first to convert the binary xml files from the apk to normal files and then pack the apk file back?
Thanks
Hey folks,
Okay so I have the HTC_IME_JONASI file installed and I see it in the setting but I am having trouble changing the keyboard colors, Can anyone walk me through this or direct me to a link where I can do this?
Thanks In Advance Folks!
afaik you would need to modify it before pushing it over to the phone
unless its something different than just a themed ime
(this should be in Q&A btw)
You have to do this
1. change the file extension from .apk to .zip
2. extract the contents of the .zip file to a directory, if you use winrar or 7zip or similar, you usually can just right click on the file, then it will extract to "xxxxxx\" where xxxxx would just be the name of the file and a directory where that file is located will be created.
3. Go to the directory that was just created and then go to the RES folder
4. Scan through the different folders within RES and find the files you will need to change
5. Download GIMP (free) or acquire Photoshop (ripoff price)
6. Use GIMP or photoshop to edit your .png files, then save to same directory
7. Do this for all files needed, also read up on .9.png files, if you don't edit them properly before sending them back to your phone, your keys might be coming out looking stretched.
8. Once you edit all files, and also note that some files might exist in other directories that are the same as in another. Same filename, check the dimensions (pixels example 54 x 47) and if they are the same just copy then paste it over from the other directory and overwrite that file that wasn't edited, that way you don't have to do it twice
9. Use your program 7zip or winrar or similar and compress the files again. Easy way is to go back to the root of the folder where it shows all the files you extracted within the folder you created, select all files in that folder, right click, then choose add to archive, and make sure you create a zip. Change the file extension from .zip to .apk
10. Push to phone and pray it looks right.
Can i manually deodex the framework and apps by deleting each individual .odex file?
Smonic said:
Can i manually deodex the framework and apps by deleting each individual .odex file?
Click to expand...
Click to collapse
No, u need some soft to do so. Deodexing add the .odex content files into your compressed .apk (correct me if i'm wrong ^^)
Zipalign deodex files make them reading faster by your OS
All of your apps on your device are packaged as .apk files; these files are compiled from google source code and can interchangeably be viewed/thought of as a compressed folder (like a .zip or a .rar); and all of your framework components (well most…) are packaged as .jar files which literally stands for Java Archive (so again this can be compared to a .zip or a .rar).
When the android OS want’s to run your apps or utilize its framework components, it has to parse (read/interpret) the compressed data held within your .apk and/or.jar files. What the odex file structure aims to do, is to expedited this process by utilizing another file (.odex file) to compliment every.apk file (and .jar file); the odex file, includes the most critical data in an uncompressed format so the android os can quickly interpret that important information before parsing through the rest of the data held within the compressed .apk files (and .jar files). So subsequently, in an .odex file structure the .apk & .jar files don’t include all of the applications/framework-components data; Essentially, two files are acting as one; for your apps there are .apk files + their corresponding .odex file and for your framework components there are .jar files + their corresponding .odex file. This works nicely as an optimized file structure, except in the circumstance when the user want’s to theme; theming requires a modification to your .apks; the image files (.pngs) held within the pngs are replaced with different ones. However it is impossible to theme an application if it exists as two files. So that is why it is said you need to be DeOdexed in order to theme; DeOdexing is the process of re-bundling that uncompressed critical data (.odex files) back into your compressed .apk (& .jar) files, so that now all of the data is included in the .apk files necessary to run your applications without the presence of .odex files; in addition all the data is now included within the .jar files necessary to utilize your framework components without .odex files. In a DeOdexed file structure, there are no odex files present.
Click to expand...
Click to collapse
Source : http://www.wugfresh.com/guides/deodex/
I don't think so.... but if yes, then it'll be very hard!
When dealing with custom ROMs the terms ‘odexed’, ‘deodexed’ and ‘zipaligned’ are encountered quite often. In this tutorial we will explain what they mean and how they can affect your device.
In Short:
Odex files:
-Pre-optimized parts of application or library.
Deodexing:
- the process of combining .odex and .apk files in order to have the full code of the application in one place.
Zipalign:
- archive alignment tool used to optimize apk packages.
In Details:
Dex files:
Dalvik EXecutable (DEX) is a home-grown Android format used in Dalvik virtual machine. It does not use the same java bytecode instructions. Dalvik opcodes are designed to support the Java language, however compiling code to Dalvik bytecode written in other languages is possible. Android comes with a disassembler called dexdump.
Jar files:
Java ARchive (JAR) is an archive file format used to aggregate many Java class files and associated metadata and other resources (text, images, settings etc) into one file to distribute application software or libraries on the Java platform. In Android the difference is that JAR files instead of Java class files contain classes.dex file which contains the Dalvik bytecode. In Android you wil find those mostly in /system/framework.
Apk files:
Application package file(APK) is the file format used to distribute and install applications onto Google’s Android operating system. Apk files are ZIP file formatted packages based on the JAR file format, with .apk file extensions. An APK file normally contains
META-INF folder – contains manifest file, certificate and signature
res folder – not compiled resources
assets folder – more raw resources
resources.arsc – pre-compiled resources
AndroidManifest.xml – Android specific manifest file in binary xml
classes.dex – the java classes compiled in a DEX file.
Note that in Odexed ROMs classes.dex can be missing in APK and JAR files.
BOOTCLASSPATH:
BOOTCLASSPATH is a list of the jars/apk from which classes can be loaded, in addition to the main apk/jar that is loaded. Normally Android has 5 JAR files in it’s base BOOTCLASSPATH – core.jar, ext.jar, framework.jar, android.policy.jar and services.jar. However, some APK files have more dependencies on additional jar or apks files. Google maps for example needs com.google.android.maps.jar. To check your BOOTCLASSPATH you can type: ‘adb shell set’;
Odex files:
Odex file is actually the extracted and optimized DEX file(classes.dex) from APK or JAR files. An ODEX file has dependencies on every file in the BOOTCLASSPATH that is loaded when it is generated. The odex file is only valid when used with these exact BOOTCLASSPATH files. dalvik enforces this by storing a checksum of each file that the odex file is dependent on, and ensuring that the checksum for each file matches when the odex file is loaded.
Deodexing:
- the process of reassembling ODEX files in DEX(classes.dex) and place them pack in the respective APK and JAR files.
Android Applications Startup Process :
When an application is started on first use if no ODEX file is found, classes.dex is optimized by the package manager(PM) and saved in /data/dalvik-cache.
Odexed ROMs
In these ROMs you will have ODEX files for most APK and JAR files in /system/framework and /system/app and also the classes.dex in APK and JAR files will be missing.
pros::laugh::laugh::laugh:
Speed up loading as odex is uncompressed and already optimized
saves space as no need to put optimized dex in dalvik-cache (already have the ODEX file in /system/framework or /system/app)
Hard to hack/decompile as data is separated
cons::crying::crying::crying::crying:
cannot do modifications to apks or jars
cannot do theming
cannot change BOOTCLASSPATH if system libraries are affected
DeOdexed ROMs:
In these ROMs you will have classes.dex file in all APK and JAR files.
Pros::laugh:
can do modifications to apks
can do theming
can change/add/remove libraries and thus recompile all the current apks with the new implementation
Cons::crying:
slower loading but just the one time when a modification is done or dalvik-cache cleaned(wiped).
need to put optimized dex in dalvik-cache
easer to decompile an app
Zipalign:
- archive alignment tool used to optimize apk packages. Basically the data in the APK package is being read by many process (app itself , installer, home app, system server, etc.). If every process knows where to look for its data it wont need to unpack the whole APK. Zipaligned APKs are done in such a way so all uncompressed data starts with a particular alignment(on 4 byte boundaries) relative to the start of the file.
THANK ME IF THIS INFO HELPED YOU
.......:laugh::laugh:
Helpful thanks!
Sent from my Desire HD using xda app-developers app
finally i understand , but is there a little more explanation for zipalign just to make sure wt i understood is right
It is good to mention at least the source ESPECIALLY when you copy/paste
http://andwise.net/?p=419
thank you!
cyanidekiller said:
When dealing with custom ROMs the terms ‘odexed’, ‘deodexed’ and ‘zipaligned’ are encountered quite often. In this tutorial we will explain what they mean and how they can affect your device.
In Short:
Odex files:
-Pre-optimized parts of application or library.
Deodexing:
- the process of combining .odex and .apk files in order to have the full code of the application in one place.
Zipalign:
- archive alignment tool used to optimize apk packages.
In Details:
Dex files:
Dalvik EXecutable (DEX) is a home-grown Android format used in Dalvik virtual machine. It does not use the same java bytecode instructions. Dalvik opcodes are designed to support the Java language, however compiling code to Dalvik bytecode written in other languages is possible. Android comes with a disassembler called dexdump.
Jar files:
Java ARchive (JAR) is an archive file format used to aggregate many Java class files and associated metadata and other resources (text, images, settings etc) into one file to distribute application software or libraries on the Java platform. In Android the difference is that JAR files instead of Java class files contain classes.dex file which contains the Dalvik bytecode. In Android you wil find those mostly in /system/framework.
Apk files:
Application package file(APK) is the file format used to distribute and install applications onto Google’s Android operating system. Apk files are ZIP file formatted packages based on the JAR file format, with .apk file extensions. An APK file normally contains
META-INF folder – contains manifest file, certificate and signature
res folder – not compiled resources
assets folder – more raw resources
resources.arsc – pre-compiled resources
AndroidManifest.xml – Android specific manifest file in binary xml
classes.dex – the java classes compiled in a DEX file.
Note that in Odexed ROMs classes.dex can be missing in APK and JAR files.
BOOTCLASSPATH:
BOOTCLASSPATH is a list of the jars/apk from which classes can be loaded, in addition to the main apk/jar that is loaded. Normally Android has 5 JAR files in it’s base BOOTCLASSPATH – core.jar, ext.jar, framework.jar, android.policy.jar and services.jar. However, some APK files have more dependencies on additional jar or apks files. Google maps for example needs com.google.android.maps.jar. To check your BOOTCLASSPATH you can type: ‘adb shell set’;
Odex files:
Odex file is actually the extracted and optimized DEX file(classes.dex) from APK or JAR files. An ODEX file has dependencies on every file in the BOOTCLASSPATH that is loaded when it is generated. The odex file is only valid when used with these exact BOOTCLASSPATH files. dalvik enforces this by storing a checksum of each file that the odex file is dependent on, and ensuring that the checksum for each file matches when the odex file is loaded.
Deodexing:
- the process of reassembling ODEX files in DEX(classes.dex) and place them pack in the respective APK and JAR files.
Android Applications Startup Process :
When an application is started on first use if no ODEX file is found, classes.dex is optimized by the package manager(PM) and saved in /data/dalvik-cache.
Odexed ROMs
In these ROMs you will have ODEX files for most APK and JAR files in /system/framework and /system/app and also the classes.dex in APK and JAR files will be missing.
pros::laugh::laugh::laugh:
Speed up loading as odex is uncompressed and already optimized
saves space as no need to put optimized dex in dalvik-cache (already have the ODEX file in /system/framework or /system/app)
Hard to hack/decompile as data is separated
cons::crying::crying::crying::crying:
cannot do modifications to apks or jars
cannot do theming
cannot change BOOTCLASSPATH if system libraries are affected
DeOdexed ROMs:
In these ROMs you will have classes.dex file in all APK and JAR files.
Pros::laugh:
can do modifications to apks
can do theming
can change/add/remove libraries and thus recompile all the current apks with the new implementation
Cons::crying:
slower loading but just the one time when a modification is done or dalvik-cache cleaned(wiped).
need to put optimized dex in dalvik-cache
easer to decompile an app
Zipalign:
- archive alignment tool used to optimize apk packages. Basically the data in the APK package is being read by many process (app itself , installer, home app, system server, etc.). If every process knows where to look for its data it wont need to unpack the whole APK. Zipaligned APKs are done in such a way so all uncompressed data starts with a particular alignment(on 4 byte boundaries) relative to the start of the file.
THANK ME IF THIS INFO HELPED YOU
.......:laugh::laugh:
Click to expand...
Click to collapse
andwise said:
It is good to mention at least the source ESPECIALLY when you copy/paste
http://andwise.net/?p=419
Click to expand...
Click to collapse
andwise said:
It is good to mention at least the source ESPECIALLY when you copy/paste
http://andwise.net/?p=419
thank you!
Click to expand...
Click to collapse
Well its almost ten years since I posted this. I do not know exactly about my thought process back then and why I posted this, but I am sorry for not mentioning the original source.
*ALWAYS HAVE A BACK~UP
DONT BLAME ME IF YOU MESS UP*
things needed
apktool mobile
root explorer
zarchiver
920 text editor
first
copy the .jar file to the apktool folder where you decompile and recompile things
next
using zarchiver...
go to the .jar file in the apktool folder
VIEW the files inside
*IMPORTANT*
VIEW ONLY ....DON'T EXTRACT
when you get inside the .jar file you will see two files inside
~Meta-inf
~classes.dex
copy classes.dex
paste it in the apktool folder
now
using apktool..
decompile classes.dex
you will get classes_dex folder as result
delete classes.dex file that you have in the apktool mobile
edit necessary files using 920 text editor
after editing desired files
recompile the classes_dex
if successful.
you will get classes.dex file
using zarchiver again
view .jar files inside
this time delete the classes.dex file inside
then add the NEW classes.dex you have compiled
finally push the new .jar file to your system/framework using root explorer
DONE