Following my previous question on how to make the weather widget work again on my Samsung Galaxy Alpha, I have researched about app reverse engineering including Java and Smali as suggested by the answer there. By following this tutorial , I was able to get to the Smali code, make a slight modification to it which I hope will resolve the javax.net.ssl.SSLException: hostname in certificate didn't match error I was getting, and then get to my modified and deodexed .apk. Essentially, the command I executed were:

7za x WeatherDaemon2014_LMR.odex.xz
oat2dex.bat WeatherDaemon2014_LMR.odex temp.dex
java -jar baksmali-2.0.3.jar -a 21 -x temp.dex -o deodex

At this point, I edited the \deodex\com\sec\android\daemonapp\ap\http\HttpClientThread.smali file. Then I executed the below, which gave me the deodexed .apk:

java -jar smali-2.0.3.jar -a 21 deodex -o classes.dex
7za u -tzip WeatherDaemon2014_LMR.apk classes.dex

I am however unfortunately getting a Class not found when unmarshalling: com.android.packageinstaller.InstallFlowAnalytics error when trying to install the modified APK. I have also tried uninstalling this system widget first with Titanium Backup, but the issue remains the same. (This actually corrupted the widget which couldn't be restored, and I had to re-flash the stock ROM to get back to the starting point.) Therefore rather than trying to install the APK, my goal is now to directly replace the WeatherDaemon2014_LMR.odex.xz file located in /system/app/WeatherDaemon2014_LMR/arm/, hence my question of how I could re-odex my APK. I have tried to follow this tutorial but am getting a only position independent executables (PIE) are supported error in step 6. Then I tried the solution here , but am getting the same error in step 5. Researching this error leads to suggestions to compile with the -fPIE option enabled, but I am unsure how and where to do this. Can anyone familiar with app reverse engineering suggest a way forward? Is there a simple way I can get to a .odex.xz file from my modified APK? Apologies if I'm missing something obvious, or if anything I said above isn't making sense, as I am still new to reverse engineering.

On an Android 9 ROM, I deodexed the services.jar and added signature spoofing support. But after deodexing, the UI is stuttery. How do I "re-odex" the services.jar, i.e extract/compile services.odex and/or services.vdex from the current services.jar?

Recently my phone shows "Android is starting Optimizing App 1 of 1" at every boot. I intercepted this and found it running dex2oat in this way

/system/bin/dex2oat --runtime-arg -classpath --runtime-arg /system/framework/XposedBridge.jar --instruction-set=arm64 --instruction-set-features=default --runtime-arg -Xnorelocate --boot-image=/system/framework/boot.art --dex-file=/data/data/com.google.android.gms/app_fb/f.apk --oat-fd=45 --oat-location=/data/data/com.google.android.gms/app_fb/f.dex --runtime-arg -Xms64m --runtime-arg -Xmx512m

I also managed to grab a copy of the APK. The original APK and DEX *disappears* after dex2oat is done. Its package ID is com.google.ccc.abuse.droidguard.droidguasso and it's only 6.5KB in size. There's not even a META-INF folder in the APK. Google shows no exact result about it. I'm afraid whether it's a malware but I can't find out anything more. Can anyone help me? I have the intercepted APK uploaded to Dropbox . Edit: Got rid of it by creating a blank *file* at /data/data/com.google.android.gms/app_fb. But I still wonder about its malice (if so).

I was looking into a couple of Android tombstones files of an old Samsung phone running Marshmallow. Found a crash in every single one with the same culprit, dex2oat. From my limited understanding it is a Compiler that takes arguments from Android Runtime and convert dex files to Android optimised ones in oat format. I ran into the same issue even if I factory reset or freezing a lot of apps. I have this device rooted and decided to take a risky step. I backed up first and deleted dex2oat from /system/bin. Then I rebooted system with risk of bricking it. So far it is working fine. Due my lack of understanding I don't know how crucial is this dex2oat to system stability and I want to know what is the impact on it.

I am looking for a proper and simple method to odex an apk file. I have an upgraded apk file from a ROM with which I want to replace an older one, and it is located in the /system-priv directory. The older apk has the .odex file, but I figured out I can't directly overwrite it since I can't use the old .odex (hence I need to odex first), lest I'll be stuck with app crashes or bootloops. I have tried searching for methods online but are not satisfactory in one of the ways: 1. This one which involves the use of a dexopt-wrapper.bin seems to be way outdated as binary is not supported, I have this error poping up: error: dexopt-wrapper error: only position independent executables (PIE) are supported. 2. The second one which is lengthy and links to other required resources are no longer there, and is somewhat not compatible with my system. 3. The only promising one which uses Auto Odexer Script, but currently I'm running issues adb and also seems it uses the same dexopt-wrapper binary which was giving me errors in terminal. There are tools/methods for doing the entire system at once, but I do not need the entire system re-odexed. I want to personally create an odexed "upgraded" .apk from the extracted ROM. # Update I upgraded the wrapper binary (now PIE) and should be compatible however still encountering this error: --- BEGIN '/sdcard/app/A.apk' (bootstrap=0) --- --- waiting for verify+opt, pid=17200 --- would reduce privs here execl(/bin/dexopt) failed: No such file or directory --- END '/sdcard/app/A.apk' --- status=0x4300, process failed 1|mido:/ # and the result is an empty .odex file in the dir. Someone to point out where I am going wrong here?

As I can run a Dex file on dalvikvm through a terminal emulator (I'm using termux or adb shell

/system/bin/dalvikvm -cp /path/to/classes.dex classname

Which runs successfully and I noticed it generated a directory oat which contains oat/arm64/classes.odex and classes.vdex file. odex is faster than Dex so can I run it directly every time without recompiling dex to odex?

As far as I understand, odexed apps come in two: the "apk" and the "odex" files, both containing different information. And I understand that the odex file has crucial information that loads first and speeds up the booting process. But I tried to deodex an odexed app with UltimateDeodexer, and it only asked me to upload the .odex file, giving me in return an .apk file. Seemed like it turned the `.odex into

.apk

`. How does that work?? Is it missing all the information from the original .apk file? Is my resulting .apk file complete, or am I supposed to do something else afterwards?

I have an **.apk** file, also comes with it two files, one **.odex** files, another **.vdex** file. The files were pulled from the **/system/app** folder of another phone. The files hierarchy on the original system is like this: `` /system/app/FM2/FM2.apk /system/app/FM2/oat/arm64/FM2.odex /system/app/FM2/oat/arm64/FM2.vdex `` What I want to do here is to **combine all these files into a single APK file**, so that I may be able to install it on other phones. (*Let's ignore for the moment that the other phone may not have the required dependency installed on it*) **So, how can I combine *.apk*, *.odex*, and *.vdex* files together into a single *.apk* file?** **P.S.** I have read some articles about using smali and baksmali to convert odex to dex and vice-versa, but I couln't find the detailed tutorial that I need. Also, these articles never talk about VDEX files, which is an issue here. **P.P.S.** Both the source and destination phones are exactly the same with Android 10, but different regions.

I am a bit confused by the effect of deodexing (or even by terminology). Based on answers to "What is the difference between odexed and deodexed roms? ": > A "deodexed" ROM is one where the .odex files have been more or less merged back into the .apk This one seems to imply that "deodexed" ROM is an odexed (thus precompiled/optimized) ROM where the .apk package contains the .odex stuff instead of it being in a separate file. However, the same answer has a seemingly opposite quote: > ROMs are typically released in deodexed form because they can be themed and modified fairly easily, whereas theming/modifying an odexed ROM is basically impossible (at best things would crash like crazy). Some people also choose to release their ROMs in odexed versions for people who would prefer the performance gains. This second quote seems to imply that the deodexed ROM does NOT have the performance gains of the odexed ROM (based on the last sentence) - I am guessing because it completely removes the .odex info for the sake of portability/theming; whereas the first quote seems to say that deodexed ROM is just as optimized as odexed, but differently packaged. Which one of these meanings is correct? What am I missing? Example: - Fission Vanilla: "ROM has root and has been deodexed, and zip alligned"

I know that .odex files are optimized .dex files. I have seen a lot of .odex files below the path /system on my phone. I am just curious if there are also .odex files for my installed apps. I searched the file system but I wasn't able to find .odex files for my installed apps. But I assume that they exist - the question is just where they are stored. BTW: My phone is a rooted Samsung Galaxy Nexus with Android 4.1.2

After each OTA Android upgrade, I get a message saying "Optimizing app x of xxx" that takes a while. The last time I upgraded, the battery ran out during the optimization process (not during the upgrade itself, which I know it's dangerous). After rebooting the phone the "optimization" process didn't carry on. So, how can I start that process by itself without upgrading anything? (my Android is already up to date).

I've asked this question before. After checking out logcat, it seems that the OS is looking for the odex files. I've checked the odex files of other system apps on my ROM, and it turns out they're ELF files. For the ones asking, these are bytecode files produced by ART (dex2oat, I'm not sure). I've observed that these files get generated on boot (Android is Starting: Optimizing App XXX of XXX). For some reason, my phone's ROM doesn't run the optimization part. Instead, the oat files are already pre-generated and stored on the system partition. As a result, the apps that I want to pre-install don't get the oat treatment and crashes when I launch them (ClassNotFoundException since the oat files don't exist.) **How do I manually run the app optimizer?** If it comes down to using the command line, how do I use dex2oat **without root access/on a Linux PC**?

What is the difference between odexed and deodexed ROMs ? Which is the standard (stock) ROMs that ship use?

I'm trying to understand a few things around how dex files are handled by android. What I do know is that an APK ships a dex file, the system gets it, optimises it at install time, and stores the resulting ODEX file (optimised dex) at /data/dalvik-cache/myOdexfile and then runs the application from there. Is that really how it works? What happens when a dex file downloads and opens a new dex file from the internet? is that optimised as well? Also - the system, afaik, keeps the original APK around, right? I think that is kept at /data/app/myAPK-1.apk. Is that used in any way by the system? When? Can you somehow manually force regeneration of the odex file from the stored APK file after installation?

I have a Google Nexus 5. Every time I do a system update, I see this message: > Android is upgrading... > Optimizing app [x] of [y] I understand that ART is compiling my apps. What I don't understand is why. What happened to the previous compilations?

I have written a script to utilize dexopt-wrapper to odex a folder of .apk's #!/bin/sh SYSAPP=/mnt/extSdCard/FilesToOdex/system/app/ SYSPRIVAPP=/mnt/extSdCard/FilesToOdex/system/priv-app/ for i1 in $SYSAPP*.apk ; do echo "Odexing $i1..." dexopt-wrapper $i1 $i1.odex done for i2 in $SYSPRIVAPP*.apk ; do echo "Odexing $i2..." dexopt-wrapper $i2 $i2.odex done for file1 in $SYSAPP*.apk.odex; do mv "$file1" "basename $file1 .apk.odex$file1.odex" done for file2 in $SYSPRIVAPP*.apk.odex; do mv "$file2" "basename $file2 .apk.odex$file2.odex" done The odexing part works, but as you can see it creates a bunch of .apk.odex files So my question is: 1. How can I setup the odexing portion to not write the files out as *.apk.odex? 2. **OR**, How can I get the mv to properly rename the *.apk.odex files to be just *.odex files? I tried: for file1 in $SYSAPP*.apk.odex; do mv "${file1}" "${file1%.odex}" done for file2 in $SYSPRIVAPP*.apk.odex; do mv "${file2}" "${file2%.odex}" done but it turned all my .apk.odex files to .apk

Is an odex file different from the dex file generated and stored in dalvik-cache? Is it faster? More optimized? Or just the same? Most people mention the benefit of improved boot speed after wiping the dalvik cache or on new boot, but no one ever discusses runtime performance of both files.

Two ringtones are extracted from Hangout.apk to */storage/ringtones* folder during some system setup phase. To analyze that, I manually deleted the ringtone files from my_files >> Ringtone. Now, no hangout ringtone in *settings->sound->ringtone*. Then, done "*Factory reset*" from settings. Now, hangout ringtones didn't restored. Now, i did "Factory reset" from recovery mode.Those hangout ringtones are restored again. That is visible through MyFiles as well as RingtoneChooser. So, it turned out that "Factory reset" is somewhat different between "recovery mode" and from "settings". I need to know when extactly does the hangouts_video_call.ogg extracted from hangout.apk? How can i find the log ? Any clue will be highly helpful.

I had a file manager provided by my manufacturer as a system app. it was odexed. i have its apk and odex file both. I installed a custom rom now and want to install that filemanager. how do i do this? how can i make a normal deodexed file from the odexd one?

I have recently got an app that permits me to view the contents of my phone memory on my rooted Samsung Galaxy Y mobile phone. In /system/app folder, I see all the system apps that came pre-installed with the phone, and also I see a .odex corresponding to every .apk file. What exactly are these files? I wanted to keep a backup of all these .apk files in my laptop, just in case. Should I backup the .odex files too? Why or Why not?