Will android odex improve app or system launch speed? - android

When we install an apk on Android,system will get the classes.dex out of the apk file,optimize it with dexopt tool and generate another .dex file stored in /data/dalvik-cache.
Now if we use dexopt-wrappter tool to optimize the apk first to generate the odex file,and then delete the classes.dex from apk file,and then push the apk file(without classes.dex) and the odex file into /data/app.
Will the second way be faster than the first way when launching this app?
If all apks in this system have been optimized with the second way,will it be faster when launching the system?
I know the .dex files in /data/dalvik-cache/ are the same as files generating by the second way.I just wonder that will it be faster when launching with the second way.Because original Android system apps have been all optimized with the second way.

Related

Custom build process (manually assembling apk)

I want to set up a custom build process for our android game. In short our build process works like that: In first stage we build game code into binary blob and in second stage our tool packs code binary blob and assets and make a final package. This works for consoles and PC and we want the same also for android.
Till now I tried to make a apk with android studio, disassemble it with apktool, add assets, pack it again with same tool, realign it with zipalign and sign it with apksigner. I had to manually enter asset files into apktool.yml file to include it into packaging process.
This process produced apk that was almost 20% bigger compared to apk built with assets that were added via gradle. I assume that some files were differently compressed. And the most important part game crashed at statup.
What is the best way to achieve build process described above? First to compile game code to binary blob and assemble code and assets to apk in later stage? Or to add assets to existing apk as I tried before?

Manually packaging an apk file

Is there a way to manually repackage an apk (that will successfully run on a real device). While we can use any zip tool to unpack our apk files, the reverse is not possible (due to some app signing issues and such ) so I'm wondering how to go about doing this. I don't want to build an apk (which would involve compling Java classes , resources etc). I just want to be able to create an apk file ( that will run on a device) manually (command line is ok), provided that I already have all the necessary files.
Thank you

Changing resources in a standard Android app from firmware

I am trying to modify an APK which came with my official firmware.
Actually only some resources should be modified (sounds should be replaced with silent files).
I moved APK and ODEX to backup folder, unzipped APK on a PC, modified files, zipped APK with 7Zip again and placed it into /system/app folder with corresponding permissions. After a reboot Camera application disappeared from everywhere.
Ok, I copied ODEX file back to /system/app, rebooted, and application appeared, but trying to run it makes it crash.
APK file has no DEX inside.
I thought that ODEX file contains code only and shouldn't be re-created.
What I was doing wrong and how to do it right?
You can't modify apk's without signing them again. The Android system will notice that the apk has been tampered with and refuse to load it. You could sign it with your own key, but then your signature wont match the official signature for that package name and that will prevent you from getting any updates for that application as long as your modified apk is installed. Also if that application is relying on being signed with the same certificates as other applications from the same manufacturer it wont work correctly.
You can read about signing android applications in the official documentation
Why do you want to do this?

Can I sign an APK after odexing it?

Are these two ways equal and correct?
Method 1:
Odex the APK to a .apk and a .odex
Sign the .apk file produced in step 1
Method 2:
Sign the APK
Odex the APK to a .apk and a .odex
First you need to understand working of .apk and .odex file.
.Odex file:
Odex file is 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.
Android Application come in packages with the extension .apk. These application packages, or APKs contain certain .odex files whose supposed function is to save space.
These ‘odex’ files are actually collections of parts of an application that are optimized before booting.
It also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.
How it work:-
Android OS uses a Java-based virtual machine for running applications, called the Dalvik Virtual Machine. A deodexed, or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it.
Android applies this technique by default to all the system applications.
Now, when an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
You can find some information Here and
Here is one StackOverFlow question may helpful to you.

Where did the code in apk file go after installed from Market?

This is a very interesting thing. I have an APK file, com.company.app.apk. When installed to an emulator by using Eclipse, by using the following code to get the apk's file name:
String fileName = activity.getPackageManager().getApplicationInfo(
activity.getPackageName(), PackageManager.GET_META_DATA).publicSourceDir;
I get a pathname like this com.company.app-1.apk. The file size is the same as the apk file I built.
Now when I publish this app to Market, and install it to a real device (Android 2.3), the same code returned a pathname like this: com.company.app-2.zip. Note that the file extension has changed to .zip and, most importantly, the file size is significantly smaller than the original size.
Now if I transfer these two files to my PC and use WinZip to open them, I found one really interesting thing:
The one installed on emulator by Eclipse has exactly the same stuff as I expected. Namely: the code ('com' folder), the resource ('res' folder), the signature ('META-INF' folder), the assets ('assets' folder), and the manifest file (AndroidManifest.xml). However, the one installed on a real device by Market has only two parts: the resource, and the manifest file.
Question: I think when installed from Market, the .apk file is split into two (or more) files. One file is pointed to by ApplicationInfo.publicSourceDir, which contains only the resource. How can I get the pathname to the other file(s)?
ADDED: I have two versions of the same app, one is paid using Google's Vendor Licensing Service, the other is free. The above mentioned phenomenon happens only to the paid version. Why?
Correction: When I said the 'com' folder exists in the installed apk file in the first case, I should be more clear. The code per se, the *.java files, are not in the 'com' folder. As a matter of fact, the 'com' folder contains only a few garbage files that were inadvertently left there during the build process. If not for those garbage files, I don't think the 'com' folder would be there in the first place.
I think you are not right. The market works in the following way: you choose an application and push a button to install it. After that market sends the intent to gtalk service to install the application. This service downloads apk file that you've uploaded to the market and when finishes it installs this apk. Just during the installation can some changes happen. It seems to me that from the application during the installation classes.dex file is extracted and from this file optimized dex (.odex) is produced and put in the separate directory. That's why you see the difference in the files.
Ok, here is what I've found out, in case this helps someone out there:
When Market installs the free version of my app, the apk file is installed to /data/app/com.company.app.apk, the file content is exactly the same as I built it, same file size, same everything.
For the paid version that uses Market Vendor Licensing, the apk file itself is installed to /data/app-private/com.company.app.apk. This is the same file as I released. However, the resources are extracted and installed to another file /data/app/com.company.app.zip, note the file extension. This zip file contains only resources, so it's significantly smaller. But the .apk file in /data/app-private has everything, so the file size is the same as I built it.
ApplicationInfo.publicSourceDir always points to the file in /data/app, so it's /data/app/com.company.app.zip in the paid version's case, and /data/app/com.company.app.apk for the free version. For the paid version, I obtained the pathname from publicSourceDir, then replace.app with app-private, and replace .zip with .apk to get the original file.
If I install the apk directly to an emulator, then there is only one file and is always installed under /data/app.

Categories

Resources