I have a third-party apk that I'm trying to optimize, as the developer couldn't be bothered with such petty things.
The application is built with Xamarin and contains AOT assemblies. Is there a way to strip them from the apk without completely reverse-engineering the project and building it anew?
Removing AOT assemblies from an .apk is as easy as deleting them and correctly re-signing the package.
Here are the steps:
Open the .apk as zip file, delete lib\<architecture>\libaot-*.so files.
Xamarin apps include libmonodroid.so and libmonosgen-2.0.so even without AOT compilation, don't touch those.
Delete META-INF from root of the .apk.
Sign the resulting .apk using jarsigner from the JDK. If you don't have the original key, any will do, you will just lose the ability to update the app automatically.
Don't forget to align the .apk with zipalign from Android build tools.
Resulting thinner app installs and runs perfectly, but will, of course take a couple of seconds longer to launch.
Related
How could it be possible to build an AOSP app from source (using mma to build so there would only be the needed modules instead of a full system image) and have access to shared libraries?
I'm building LatinIME with some modifications.
As I wanted to easily install and debug, I changed the package name. Now I can easily install the app as user app but it can't access the .so files in system partition. If I try to install the app with original package name, it can't because of the old app installed.
library "/system/lib64/libjni_latinimegoogle.so" ("/system/lib64/libjni_latinimegoogle.so") needed or dlopened by "/system/lib64/libnativeloader.so" is not accessible for the namespace
The other way I could think of is to keep the package name as original but either create a flashable zip or copy the apk each time to system partition.
Is it possible to allow access to this file (or include it in the apk) or do I need to do this the hard way?
The easiest path is to have a copy of all needed non-public system native libraries in your APK, under lib/arm64-v8a or the other relevant ABI. libjni_latinimegoogle.so may depend on other libraries, and you must pack them with your APK, too. Make sure you use the correct versions of these libs. You can pull them from your system/lib64 via adb.
But replacing the APK in the system partition is a cleaner way to handle the situation. This does involve reboot each time, but I would probably choose this track, to avoid any possible behavioral differences between the system app and the user app.
My application's debug apk(one in bin folder) size is 25.8 MB, I'm not using proGaurd as of now, I have multiple libraries such as Facebook, Twitter, Google play services, Vuforia, and few other graphics related jars. So my problem is when I'm generating release version apk using export wizard I'm not getting correct apk file size. Everytime I generate apk for release version the size is different( like 19MB, 21MB, 23MB ,22MB,25MB). When I install this apk on device it is crashing. I have 8GB of RAM, I cleaned project before starting process, closed all running applications except eclipse , I also run CC cleaner and started eclipse from cmd prompt with 'eclipse-clean' command but still I wasn't successful to generate correct apk.
Any suggestions to solve my problems will be appreciated.
I have a native library that my project uses(for four architectures). (Note, that I did not compile them , I just got them from a third-party). Exporting a signed apk right now is a pain. I do the following:
Delete 3 of the 4 architectures from the libs folder
Export a signed package
Replace the libs folder with history
Go back to step one
Now, these steps are fairly tiresome and there is a chance of making mistakes while uploading.
Is there any simple way I can just Export 4 apks for the for 4 different architectures (in an automated way)?
I am using Eclipse
Well done for considering the user, and producing architecture specific apks, rather than bundling all architectures in a single apk with the resultant waste of filespace on already constrained devices.
Eclipse (or rather the ADT) does not have the ability to do what you want.
One answer to your problem (unfortunately adopted by many developers) is to simply give up, and just produce one apk with all architectures included. (I've even seen this happen for system apps - that by definition must know exactly what architecture they are going to run on).
An approach I've taken is to export the app from Eclipse with all architectures in it, and then to manipulate that apk using a zip tool to produce further copies with the unwanted libs deleted. You then have to resign the apk since you have changed the constituent contents.
What is the difference between the different .apk outputs when building a signed apk from IntelliJ IDEA?
When I do a signed apk build from IntelliJ Idea (13.1.2) I get three different apk files.
../myApp.apk (921 KB)
../out/production/myApp/myApp.apk (914 KB)
../out/production/myApp/myApp.unaligned.apk (1412 KB)
My guess is unaligned is non compressed and shouldn't be used in the play store. Which one should be used in the playstore?
Note: I am using proguard but not using Ant or Maven.
Use the one you find at .../out/production/Your App name/yourapp.apk
Yet again, in properties of the project you can set the custom location for your APK. But I suggest you get used to the default ones since it will be a pain to set up your path each time.
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.