I have an apk file that I did not create, which has the internal name com.android.gallery3d. However, It is not the stock app, but a modified version (2160p Player) with subtitle support, among other things. How can I change the internal name so that it is not com.android.gallery3d? It needs to be different because I can't install it because it conflicts with the existing system app. Do I need to edit the manifest and resign the apk? How do I do this? I have access to Windows and Ubuntu-based Linux.
Unpack, change, repack and resign. Use apktool or a similar tool.
Related
We have a situation that is requiring me to create a stand-alone APK that will install media files only, that can be access by other system software. On this platform, there are no concerns for file access. I only need a method for bundling the media files into an APK, so that deployment would be simple
APK stands for Android Application Package. There should be at least one activity if you would like to publish it on Google.Play.
Assuming rooted access, what's the best way to make an Android app reinstall itself using a different package name?
GameGuardian does this to avoid detection by other software. AFAIK, the normal way to do this on a PC is to
Decompile the apk using something like apktool.
Make changes in the decompiled files.
Recompile the apk and sign it.
I'm aware that the apk files for an installed app are present in /data/app and can be accessed on a rooted device. My question is, does the app need to automate all of the above steps(making apktool run, modifying decompiled files using something like sed and finding a way to sign the recompiled apk on the device) or am I missing a trick somewhere?
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.
I'm building phonegap app using phonegap-build.
I need to make some changes to the manifest of the android apk.
After i download the apk of my phonegap build, i rename it to .zip file to see the contents of the file.
When i open it, there i see the xml file there, and when i open that one, it has encoding problem.
This is what i see:
I understand it's a binary, but i need to see the content in plain english, if possible.
1) How can i encode it to see what is the content of this file properly?
2) After a change that i do on it, can i "decode" it back to binary?
So from what you wrote you wrote, you want to edit the AndroidManifest.xml from an APK file AFTER you built it, which is quite complicated. I suggest you editing the source AndroidManifest.xml and then re-building the APK. If you can't do this then please do the following.
(1) First, download and install Apktool. It is a free Android tool for decompiling and recompiling apps quickly. It provides access to .class files, resources and XML's. Here's a tutorial on how to install Apktool.
(2) Then you want to decompile your APK file (tutorial).
(3) Edit the AndroidManifest.xml file.
(4) Re-build the application (tutorial).
(5) Finally, you will have your APK file but it will be mostly useless as it is un-signed. You can't install un-signed apps as you will get an error (it may be possible to force-install it using root or adb tho) and you can't publish them. To sign it you can check out this link.
IMPORTANT INFORMATION: Your app will have to be signed with the same certificate with which it was signed the first time, otherwise it will be considered a different app. Not completely tho, you will have to un-install previous versions in order to install this one.
And yes, I know it's a very long and time-taking process but it is supposed to be, only if you have the source you should be able to edit the app.
As mentioned above, the tool you are looking for is Apktool.
You need to use --force-manifest flag when you decompile to decode AndroidmManifest.xml.
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.