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?
Related
So it's my first time to build a Xamarin APK file, and I noticed that the compression is very lacking compared to native Android APK! For example:
Xamarin Android
Xamarin APK Size: 30MB
Extracted contents of the APK: 60MB
Extracted contents compressed into ZIP file: 20MB
Native Android (same app: same assets and about the same code/logic)
Native APK Size: 20MB
Extracted contents of the APK: 59MB
Extracted contents compressed into ZIP file: 19MB
Notice how the native APK's compression is about that of the ZIP file.
Now, how do I improve Xamarin APK's compression? Can I just zip the contents then change the extension?
Thank you.
You can't never get a smaller APK file using Xamarin. Using Xamarin implies that you must use .NET libraries that are bigger in size than their counterpart in Java.
On release mode, you can generate one APK per ABI, set the linker behaviour to Link SDK Assembly only and select only the ABIs you want to distribute your app. This way you can save a few KBs.
APK Files aren't recognizable files like executable files; they won’t run on a double click. That's why we need a player/emulator like Bluestacks/Andy/Droid to play them.
So what should I do to extract all the info about an APK without installing it and running it on a device?
You can get some limited information about an APK by extracting it. An APK is essentially a zip file containing manifest, resources, assets and classes which together make up the application. Change the .apk' extension to.zip` and extract it using built-in Windows tools. Note that most contents won't be human-readable.
APK-Info
APK-Info is a Windows tool to get detailed info about an apk file.
Allows you to view:
application icon
package name
name (in all languages)
version
build number
the minimum, maximum, and target version of the SDK (Android)
supported density (DPI) and screen size
architecture (ABI)
supported textures
permissions
features
signature
OpenGL ES version
whether app supports Android TV, Wear OS, and/or Android Auto
locales
a variety of hashes (MD2, MD4, MD5, SHA1, SHA256, SHA384, SHA512)
and a lot of other information
Using
You can open the APK file in APK-Info using one of the following methods:
Start APK-Info, and then select the APK file in the dialog.
Open the APK file by clicking on the open button in the dialog.
Drag the APK file to APK-Info.exe or its shortcut.
Drag the APK file into the running APK-Info window.
Open the APK file by double-clicking, after installing APK-Info, as a program for opening APK files (via explorer or attached .cmd file).
https://github.com/Enyby/APK-Info
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
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.
I'm creating a software that will guide the user through a few steps, to publish an android application (APK file).
The way I am doing this, is that the APK file is already compiled, and all I need to do is replace an XML file in the package, and that will change the behaviour of the application. My big problem now, is that unpacking the apk file, and doing any tiny text edit, and then packing it again, breaks the signature and prevents the application from running on any device, giving a message that the signature is incorrect.
How can I solve this? I want to safely open the APK, write something in a text file, and close it again. Note that this operation will be done on the user's computer (after he purchases our application) so we're look for a command-line tool with no special requirements like JDK.
Any help?
Ok I reached the best "tested" solution - I'm posting it here to save other developers hours of googling. The only downside is that I will require the customer to install JDK on his machine, unfortunately. The reason is because I did not find any apk-signing tool that works purely on windows, without relying on JDK.
I have my android application created using Air, so this makes things easy for me - all of the air files are treated as resource assets. So have your APK archive file ready.
Once you have your modifications ready, put them inside a temporary folder named "assets". You will use the 7-zip command line tool (free: http://sourceforge.net/projects/sevenzip/) to update the contents of your apk. To have it working with your apk you will have to rename your apk's extension to zip - don't worry, you'll change it back later.
Now from a .bat file (or directly in the command prompt) from the location containing both your apk file (zip extensioned) and your assets folder, you'll call: 7za u APK-file.zip assets
Now your apk file is updated. Rename it back to .apk extension
Now you'll use the signAPK tool from here https://code.google.com/p/signapk/ and note that this is the only step requiring JDK installed. It also assumes that you have your key files ready (replace the dummy ones included in the package). Extract the file contents and call: java -jar signapk.jar key.x509.pem key.pk8 [android_app].apk [signed_android_app].apk
At the very end, you may find your signed apk file size drammatically increased. So you need to use the android's zipAlign tool: (darn, can't post the link since new users can only post a maximum of two hyperlinks)
you will be calling the command: zipAlign -c 4 [signed_android_app].apk
And voila! That's the route I'm taking.
If someone finds a way to do the signing process without relying on JDK (assuming the key files are ready) please share.
How can I solve this?
You don't. If you modify an APK file, by any means, it must be re-signed.
Android apk files must be signed. That signature proves that the contents of the apk have NOT BEEN MODIFIED from what was initially published. (Which is exactly what you are doing.) The signature at the same time, also proves who the author is.
So in a normal signed apk file:
You know who the author is. (Even if it's not something you as a human can understand.)
You know the contents were put there by the author, and not modified since.
This is a key security measure built into Android, is there for very good reason, and cannot be overcome. It prevents things like viruses from being embedded inside innocent apk files.