How can I extract the type of architecture a certain APK was built for? I have to different APKs, one for 'x86' and the other for 'armeabi-v7a'.
I think you have .so files. While importing them, you need to classify your folders. So each releated .so files should go related folder that is named.
libs
arm
*lib.so
x86
*lib.so
Related
I'm currently working on two different xamarin forms projects which are kind of similar though. This means that they both have mostly similar functionalities + a lot of external dependencies are the same. But I just realized that the generated .apk files are very different in size. Upon analyzing both apks with the android studio apk analyzer I found out, that the main difference between both apks lies within the "lib" folder. While one apk only contains .so files the other (bigger) one contains a lot of .dll.so files. These cause the apk to be much bigger (40MB vs 75MB).
1.) Do you have any idea why there are dll.so files in one apk but not the other?
2.) Are these dll.so files needed?
3.) If not, is there a way to get rid of these?
Application binary interface(ABI) defines how binary files (especially .so files) run on the corresponding system platform, from the instruction set used, memory alignment to the available system function library. On Android system, each CPU architecture corresponds to an ABI: armeabi, armeabi-v7a, x86, MIPs, arm64-v8a, MIPS64, x86_64.
For a mobile phone with a 64arm CPU, when it runs the app and enters libs to read the dynamic library file, it will check whether there is an arm64-v8a folder. If it didn't find arm64-v8a folder it will search for the armeabi-v7a folder and the armeabi folder, and then if the folder is not founded it will throw an exception.
I have library project with precompiled so files. I want to minimize size so I want to use "armeabi" .so file for all arm abi's. (i need only arm code). To do this I put in jnilibs only the armeabi folder with the .so file.
The problem rises when i try to test this:
I created a demo app that uses my library project, the google play says i don't have a compatible device for this app.
Is it possible to use the same so file for all arm architectures and maintaining the size (in library project) ?
I don't care about preformance
I'm building a native C++ library for Android, for use with a Unity 3d project.
I want to build for arm and x86, so I set this in application.mk
APP_ABI := all
This gives me several seperate .so files. Unfortunately currently the way to include an native android library in a unity app is to add the library to the folder assets\Plugins\Android.
I can only put one file with the libraries name in that folder. So i can only have one of the .so files in there.
Is there any way of merging them into one file?
You can put multiple .so files, one for each architecture, into the Plugins/Assets folder, per the Unity documentation:
For specific Android platform (armv7, x86), the libraries (lib*.so) should be placed in the following:
Assets/Plugins/Android/libs/x86/
Assets/Plugins/Android/libs/armeabi-v7a/
Merging multiple architectures into a single .so can't be done on Linux.
That requires fat binrary support, and the FatELF project is now dead.
I have an enterprise app which I am deploying manually (no Google Play) which uses a number of .so libraries for mapping (ArcGIS). However, the .so files (arm, armv7a, x86) in the libs folder blow the .apk size out from 3mb to 21mb. I dont particularly want to remove one of the .so files (removing support for that architecture), or mess around with one .apk per architecture.
Can anyone think of a way I can update my app without including the .so files in each update .apk?
Yes, you can have the Java portion of your app manually download the appropriate .so files into your app's internal storage folder and mark them executable.
You will then have to load them with System.load() and the full pathname of the .so file, rather than System.loadLibrary() and the trimmed library name.
The biggest issue here is that you are now responsible for matching the ABI's yourself, and more importantly, providing your own protection against being tricked into installing a modified or imposter library which might do something nefarious in the name of your app and using it's permissions.
Of course you have to make sure not to try to call any of the native methods before you have installed them.
You could also consider delivering the .so files as binary assets each in its own skeleton .apk having a shared user id (and matching certificate) as your main .apk
Or you could simply make platform-specific .apk's for each target, containing only one .so, and have your distribution system pick the right ones (though that doesn't help with the upgrade problem).
I have noticed that some jar's resources (such as META-INF/**) are not included in apk files but that some others (xml, dtd, xsd) are kept (I'm using Android Studio 0.2).
Does anybody have a comprehensive list of what kind of resources are excluded from jars when added as libraries in an Android project?
Thanks.
After a bit of experiment, it seems that all files are kept (txt, no extensions, etc.) except those in the META-INF folder...