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.
Related
For some reason my app is not 64-bit compatible.
My first thought was that it my be the lib files. I checked the resulting apk: I have arm64-v8a, armeabi, armebi-v7a, mips, x86 which all contain the same-named .so files. So, I'm thinking it is maybe because x86_64 is missing? But, I have another project running the exact same libs which IS 64-bit compatible according to the play dashboard. I can't see any difference between the two lib or gradle setups.
Has anyone encountered something similar?
UPDATE: Here is the resulting libs from analizing the apk:
Like I stated above, there are .so files for all except x86_64. Could this be the issue? Do you HAVE to have .so files for both arm64-v8a AND x86_64? And why would this not be an issue for my other projects?
Another Update:
Ok, so I THINK its not working cause I have x86 and not x86_64. Docs say " It isn't required to support every 64-bit architecture, but for each native 32-bit architecture you support you must include the corresponding 64-bit architecture." ... does this mean I can just remove x86 and it should work fine? Also, is it a good idea to remove x86? Does it remove support for many devices?
as described in official documentation
you should add ndk.abiFilters :
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
to you app build.gradle file
Ok so I figured it out.
It seems that I managed to 'trick' google into thinking my apps were 64-bit compatible. Just because the x86_64 FOLDER was available, I guess the google console assumed it contained the required libraries. The problem was that the x86_64 libs were missing. My solution, though not ideal, was to remove the x86 libraries (small percentage of device support anyway) so that I don't need x86_64.
SO, yay :) all my apps are now 64-bit compliant (although I've lost SOME device support).
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 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.
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.
I am using Crosswalk browser for my current application, and after the building process it creates 2 libraries (Which are around 17 mb in size each).
And since that adds a big amount of overhead to the application, i was trying to separate the build into 2 different apk's one for arm and one for x86 architecture.
According to android documentation it is possible, but I was not able to found enough information.
Is it possible to build two times with each time only one version of crosswalk lib getting added ?
looking at crosswalk's make_apk.py, it seems that by default, different APKs are already generated for each platform.
You can specify which architectures you want to generate an APK for using the --arch option that can be set to either x86, x86_64 or arm.
The solution for me was to manually delete libxwalkcore.so under crosswalk project -> libs -> armeabi-v7a or x86.
Depending on for which architecture you wish to built delete the other .so file.