I would like to know if there is any way to extract from an APK file the Application.mk information.
I particularly interested getting from the APK the supported CPU ABI's
if it's not possible reading the Application.mk file, then what is the right way knowing for sure what ABI's the apk is built for?
The tool that you can use server side to analyse an apk are unzip or, if you want to go deeper, apktool. When you unzip the apk you'll find a folder for each supported abi inside the lib folder of the uncompressed apk (x86, armeabi-v7a, etc.). The list of folder is the list of supported ABI, so you can get the information there. By code you can get the list of supported ABI of a device using the CPU_ABI for device running pre Lollipop and SUPPORTED_ABIS for devices running Android 21+.
About your question: the Application.mk is used to build the native library, so it's not zipped within the apk.
Related
Can I use "adb install" command to install an app intended for 32bit systems on my x86_64 Marshmallow system?
The app has opencv implementation only for x86 (because it uses opencv 2.4) which means that the libopencv_java.so libraries files is only in the 'lib\x86' directory inside the .apk file (There are other subdirectories of 'lib' directory without library files inside).
I'm not too good with Android system, so the question may seem credulous to some of you, but please help me if you can - I really need to install this app on my smartphone.
The 64b Android can run the 32b applications in compatibility mode (at least the ARM for sure, but I think x86 too, otherwise many of old legacy applets in market would be not working on 64b OS).
To make sure the 32b .apk works in emulated 32b mode, it has to contain ONLY 32b libs variants. If you have multiple native libraries from different vendors, some with 32b support only, and some with 64b support included, delete the 64b variants everywhere (but make sure those libs do have 32b variant, although that would be again a bit insane, to release anything for 64-only).
The true 32b OS will not mind 64b libraries, so rather validate manually by checking the zip (apk) content. Only 64b OS will be confused if some libraries are 64b and others are not.
Such .apk with valid set of libraries should work both when installed from GooglePlay market, or by adb install some.apk from PC.
Why didn't you simply try to install it? Or does it fail and how? If it fails and you think the 32b libs are the problem, verify the 64b libs folders are non-empty, so some other library triggers 64b mode. If they are empty, the app should work, and any other problem is probably unrelated to 32b opencv.
I have this native library that only works on certain devices (armeabi, armeabi-v7a). It provides support for a custom HW module.
I detect and enable this library in java code based on the device that actually supports it. There are no issues on arm devices that do not provide this custom HW.
However, if I try to install my apk to an x86 device (or emulator), installation will fail with INSTALL_FAILED_NO_MATCHING_ABIS.
How can I link the library into the app that would avoid the reported error? I don't care if it's an ugly hack, as long as the app installs and starts.
The device checks the content of libs directory in the APK which is (in default Gradle configuration) copied from src/main/jniLibs. If there are subdirectories and none of them is x86, it will report this error. The easy solution here is to create subdirectory x86 with some dummy file.
I've attempted the solution outlined in building-combined-armv7-x86-apk-after-crosswalk-integration-in-an-ionic-project.
The great thing is that it creates a single apk file. But when I run my cordova application, I get the following alert:
Mismatch of CPU Architecture
The Crosswalk Project Service must be updated to match the CPU architecture of the device. Please install it from the app store, then restart app.
Looks like Crosswalk is not embedded in the combined apk.
Does anyone know how to embed Crosswalk in a combined apk?
After I had spent a lot time looking for I solved it:
If you open the ".apk" file generated with a compressor (like WinRar), inside folder "lib" you are going to see folders for different architectures (x86_64, x86, mips64, mips, armeabi-v7a, armeabi and arm64-v8a in my case). After inspect all them only x86 and armeabi-v7a have "libxwalkdummy.so" and "libxwalkcore.so" files, so I deleted which ones do not have it. So "lib" folder will only contain x86 and armeabi-v7a folders.
After that it seems that app works with crosswalk embedded.
I want to publish 2 apk on google store (made with unity), using the multi-apk feature.
I looked on internet and i tried this :
Created a Application.mk at ProjectFolder/jni/
with only APP_ABI := x86 or APP_ABI := armeabi armeabi-v7a depending on the lib I wanted to use.
Created 2 apk with 2 version code with Unity 'device filtrer' settings to x86 or Ar Mv 7, depending on the apk I wanted to build.
Published both apk on google develloper console.
The Apk have not the same size, so different libs are used. (With both lib, the apk weight 16 mo more, with only arm, like ~8mo more and with only x86 like ~8.5mo).
The problem is, 'native platform' detected by google console is always 'armeabi-v7a, x86' (both architectures), no matter the apk.
So I get a error message on google console saying that both apk have exaclty same device compatibility.
(PS: if I want 2 differents apk, it's because each lib take 8mo on the final apk, so 16mo for an empty project. And with google size limitation for apk...)
Update :
Ok the probleme was from a plugin (everyplay).It had libs for x86 and arm architechture. The solution was to remove the x86 plugin lib before building the arm apk, and to remove arm plugin lib to build the x86 apk.
I also noticed that changing APP_ABI in Application.mk was not necessary, the unity parameter device filtrer override it.
If Google is pointing this out, it means that somewhere Unity is overriding / including files for x86 even when you're trying to build for ARM. Here's a couple of things you should do
Open Unity's Player Settings, go to the Android tab, select Other Settingsand under Configuration -> Device Filter select whatever architecture you want to build for (Default is both)
This one is a little more un-intuitive. Just because you do step 1 above, doesn't ALWAYS mean that only 1 architecture gets built. If a plugin, it it's /lib folder includes ANY files that are for both architectures, then both architectures are built. So you need to manually comb through each plugi folder and ensure that there's no such files.
Am using the OpenCV library for my project and after integration it produces .so files for armeabi, armeabi-v7a, mips and x86 architectures. My apk file size is around 60MB. I searched google and find a way of publishing multiple apk for different architecture. But it would be better if i can trim the file size. Please suggest.
OpenCV is probably built as a set of .so files, e.g. Machine Learning produces a -ml library. Only include the libraries which you actually need. You're almost certainly not going to need all of them.