Develop Reference

Pushing .so in /system/lib of Android platform by installing an APK

Our APK has a shared library (libxyz.so). When that APK is installed, it pushes the .so file in /data/app-lib/packagename/.
We want that instead of going at this path, the .so should be pushed to /system/lib automatically at the time of APK install. However, the /system/lib requires permissions and privileges.
The reason why we want to push the .so to /system/lib is that it could be loaded by other applications as well. (Could there be any other way for two apps to share the same libxyz.so)
What could be the possible ways to achieve the purpose ?

We want that instead of going at this path, the .so should be pushed to /system/lib automatically at the time of APK install
That is not possible.
The reason why we want to push the .so to /system/lib is that it could be loaded by other applications as well
That would be a bad idea, even if this were possible. You have no means of forcing the user to upgrade all applications that would use this library. Unless you are very very careful, apps will crash because they are expecting an older version of the library and you updated the common copy to a new one. This is why Google goes to very great lengths to minimize API changes, even at the cost of having some things not be in the public API that developers would like to have. This is generally referred to as "dependency hell".
What could be the possible ways to achieve the purpose ?
You are welcome to create a custom build of Android that contains this .so, create a ROM mod that contains that custom build, and deploy that ROM mod to devices that you control.

If you have a rooted device, you can use cp to copy .so to /system/lib
Process process = Runtime.getRuntime().exec("su");
DataOutputStream writer = new DataOutputStream(process.getOutputStream());
writer.writeBytes("cp /your/path/xxx.so /system/lib/xxx.so");
writer.flush();

How can I change an apk's internal name?

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.

Load native shared library from another Android application

I need to distribute an application (a player), which depends on a native library built for a given ARM version and extension (Tegra, Neon). This native library is quite large so I can’t distribute all its versions in one universal package. So I decided to split the application into one small universal .apk and more specialized .apks – plug-ins without any activities.
How can I access a specialized native shared library in the plug-in app from the main host application? Is it possible to use simply
System.loadLibrary("path_to_library");
If so, how can I get the path to that library?
How to solve this problem in case it is not possible?

System.loadLibrary() takes a library name and maps it to a full path somehow.
foo => libfoo.so
The system normally checks the apk itself and then usually /system/lib/
If you have a full path, use System.load()
In any case it will be a hassle to manage the location of your lib unless it's either in the apk or with all the system libs.
I'd just pack the specific lib with the apk.

Eight years later, the major concerns of the TS have been addressed: there are splits that can produce smaller APK for each ABI, there are app bundles that allow easier packaging, there are extensions that even allow to delay download of a native library until it is really needed by the app…
Still, the same technique to System.load("/data/data/{app-package}/lib/lib{library-name}.so") still works, and may be useful in some scenarios.

Can an APK be repacked after a minor text edit?

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.

What's the difference between a regular Android APK and one included as part of a device's system image?

We have a manufacturer that wants to pre-install our application on their Android device. We sent them the APK and even though it installs fine when used by a user, it appears to not get installed correctly when included in the manufacturer's build image. FYI, our application uses the JNI layer and some libraries built with NDK. The exception we're seeing seems to indicate that the class loader cannot find the library and is unable to load it. They have verified that the library files are indeed present in the APK.
Since we dont make devices, its unclear why they are seeing this exception and what needs to be done differently when including a package as part of the Android build image.
Any Android folks here care to comment?

I have worked with pre-installed Android apps, that also uses library files, in my case jar files. I am assuming that you have added the appropriate lines to AndroidManifest.xml like <uses-library android:name..... I am also assuming that you have provided instruction on how to install your library files on handset, with instructions like adb push ... on the command prompt. If you havent, do provide them the instructions.
Another issue may be permissions, we had to get the library jar AND the permissions xml file installed, that may be the issue.
Also ensure that you are using the correct version of Android for testing. And if everything fails, ask them to send one of the handsets that is not working to you and you can then compare with the one in office and debug this. Good Luck, as all this can be pretty frustrating.

Besides moving the apk file into /system/app, you should ask the manufacturer to move the native libraries created by NDK (.so files) to /system/lib or the path specified by LD_LIBRARY_PATH.
Please refer to https://groups.google.com/d/topic/android-porting/r_Ao7_PWgKQ for more details.