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!
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
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
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.
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider. I've used the latest apktool (2.3.4) to unpack and repack the apk. I'm replacing it from TWRP and I checked that it has the same owner and rights. And after rebooting the device never finishes booting up (stuck at Samsung logo and blue led).
If I boot back to recovery and put back the original framework-res.apk the system boots fine.
What else do I need to do to make it accept the modified framework?
hey
Are you ONLY modifying the apk?
I would say there is a lot of things to check. It could be that the apk is being rejected by your handling of it. Compare both versions by 7zip lz4 without extracting. Try and use the best tools during the process.
Also more than likely you're conflicting with a service or permission that a perfect apk can't fix.
Have you tried a search in your ROM to see if any files might be associated with the result you want?
Stuff like...
com.android.location.provider.jar
com.android.location.provider.odex
com.android.location.provider.xml
Try doing all the work from your phone without any windows apps. FX explorer and symlink the apk.
Now that everything I said was probably wrong, someone else can tell you how. I'd try fx and symlink, though. It may just align the planets for you
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
I'm replacing the original framework-res.apk from TWRP, by cat-ing the modified apk over the original, and I've double checked that the ownership and permissions are unchanged.
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
@wirespot - Did you ever solve the problem you described in this thread?
Not really. My last attempt was to use Runtime Resource Overlays (RROs) to override certain framework values in order to allow org.microg.nlp to run side by side with Google's service.
I will provide them below but it ultimately didn't work. The RRO apk was installed correctly, I could access the NLP settings in the system settings but the main app still could not detect or connect to the service and none of the apps that use location would work.
If anybody else wants to build or use the RRO apk I'm attaching the relevant files as well as the apk. Please note that the built apk only has "org.microg.nlp" as service in arrays.xml (but I provide an arrays.xml with all three services).
apktool.yml is provided as txt file because it wouldn't let me upload it otherwise, remove the .txt. It's used if you build the package with apktool. Remember that you'll also have to generate your own certificate and sign the package in order to install it.
Also some links that may help:
https://forum.xda-developers.com/t/guide-how-to-make-gsis-overlay-file-for-your-phone.3878974/
https://github.com/ReinhardStrauch/framework-res-overlay-sample
https://android.stackexchange.com/questions/110927/how-to-mount-system-rewritable-or-read-only-rw-ro
https://source.android.com/devices/architecture/rros#configuring-overlays
https://source.android.com/devices/automotive/hmi/car_ui/appendix
https://source.android.com/devices/automotive/hmi/car_ui/rro#step_6_dump_the_idmap
https://dzone.com/articles/customizing-android-devices-using-the-runtime-reso
https://dzone.com/articles/android-solution-install-parse-1
https://stackoverflow.com/questions...s-not-recognized-internal-or-external-command
https://github.com/lineageos4microg/android_prebuilts_prebuiltapks/issues/22
wirespot said:
I guess I can try using another unpack/repack tool and see if it turns out any better, but I've been told that apktool is as good as it gets.
Click to expand...
Click to collapse
For decompiling and building Android Oreo, I prefer version 2.3.1 of APKTool to other versions of APKTools.
wirespot said:
I'm only modifying one XML resource file, but I don't know what else apktool is doing to the apk.
...
Perhaps it's because the ROM expects the apk to be signed with a certain key? I don't suppose that the key used by Samsung is available somewhere inside the ROM is it?
Click to expand...
Click to collapse
wirespot said:
Hi, I'm trying to modify /system/framework/framework-res.apk (on the stock Samsung Oreo ROM), more exactly config_locationProviderPackageNames in res/values/arrays.xml so that I can add org.microg.nlp as location provider.
What else do I need to do to make it accept the modified framework?
Click to expand...
Click to collapse
I have not tried modifying framework-res.apk of a Samsung Android Oreo nor have I particularly tried the location services mod you are attempting (though I might get around to trying it someday) and do not know if it is valid to to accomplish what you want with it, but believe that the process should be similar to modding the file on LG Android Oreo. I shall try to guide you to how to prepare a framework-res.apk that is proper.
To answer your question about expecting a certain key. The answer to that is that that is usually the case. The signing scheme checks on system apps; however is usually not as thorough as non-system apps. framework-res.apk is also special in that it is not a running app and is instead used as a cache of system resources and system meta information. In the past, before Android Oreo, a rebuilt framework-res.apk may be made to work simply by including original signature files (META-INF) and corresponding AndroidManfest.xml file from the original framework-res.apk into the rebuilt fraemwork-res.apk file. The system would evaluate these files, and pass a check for valid platform signature. With Android Oreo, it appears that there is an additional check that was not present in the past; my best guess is that the system is checking for the V2 signing scheme signing block within the V2 Signing Scheme APK file structure. The check does not, however, thoroughly validate the signing block information.
Your mod seems rather simple and, given your previous posts, would only involve a modification to framework-res.apk "resources.arsc" member file (which contains the compiled "res/values/arrays.xml" file). If the rebuilt "resources.arsc" can be used to update ("Update" is an actual ZIP archive operation) the original framework-res.apk's member file, the updated framework-res.apk should work (and remained zip-aligned if originally zip-aligned), so long as the packed file size of the updated member file is less than or equal to the packed size of the original member file, plus up to 4 bytes depending on proximity to the next member file data if original framework-res.apk is zip-aligned as expected. If the packed modified member file(s) are larger, the original APK file structure would likely not be preserved, and a different method might have to be used. Also note that 7-Zip is not reasonable software to use for this, despite it being included with many tools on XDA to modify APK files; the software has had a history of rearranging unnecessarily zip file table entries when a change is made to an archive. Use a different tool that does not do this, such as WinRAR (I have tested version 5.61).
For normal apps, one may not copy over "resources.arsc" or resources from two different app builds and have things work correctly when the app runs; one would also need to make corresponding changes in the *.dex APK member files. framework-res.apk, not being an app the runs, has no corresponding *.dex files, and one need not worry about corrupting the relationship between the *.dex files and the resource files because none exists to corrupt.
If I downgraded to 16GB S5 and need "optimizing" size of apk files, what are the best ways to delete unused arm8, x86, x64 libs from apk?
I remember myself for S4 Android 5 using either 7-zip or winrar to delete unused lib folders and 95% of apk worked like a charm, only few didn't.
Can I still do these with modern apk on Android 6 (those which fits and not module-based apk of course)? Because I tried one and it says something abou Synthaxis error while analyzing package.
Of course you can remove originally bundled libs from an APK but that requires to recompile the APK, too: simply deleting these libs from the APK isn't enough.
OK, the full answer is to use MT Manager for that or its analog which will sign the package. Archieve managers don't do that and that is mandatory since quite some time.
MT Manager lets do everything withing a phone without moving apk to PC: Open it, delete all folders in lib directory except matching your CPU architecture (7a=32 bit ARM, 8=64 bit ARM), then Optimize with zip-align and Sign it.
Just delete the files and folders you want and then re-sign the apk using apksigner: https://developer.android.com/studio/command-line/apksigner