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.
Related
Currently I'm building a UnityPlayer-Plugin for Flutter. Therefore I include some external libraries as static libraries(Unity, Vuforia).
Integration into Flutter app brings problems.
As you can see in APK Analyzing when flutter builds the app its creates additional ABI architectures for
x86 (only flutter.so)
x86_64 (only flutter.so)
arm_64-v8a (only flutter.so)
armabi-v7a (not flutter.so, but all *.so from third party libs)
Currently Unity is not supporting x64 builds and I'm using a arm64-v8a device for testing. This device will automatically use arm64-v8a in jniLibs which only has flutter inside and no unity libraries.
What's the best way to get Unity libraries to x86 and armabi-v7a and 64 bit (arm_64-v8a,x86_64) devices use as fallback (armabi-v7a,x86).
First tries with gradle Split APK's were overwritten bei flutter.gradle and I don't find a way to get the flutter.so to armabi-v7a.
In the end I would image something like this.
x86 (flutter.so, libunity.so, libVuforia.so,...) -> used by x86 devices
armabi-v7a (flutter.so, libunity.so, libVuforia.so,...) -> armabi-v7a devices
x86_64 (only flutter.so) -> use libunity.so, libVuforia.so,... from x86 as fallback
arm_64-v8a (only flutter.so)-> libunity.so, libVuforia.so,... from armabi-v7a as fallback
Hope my usecase is clear and hope to get feedback soon.
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 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 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.
Background
I've recently started to develop some code using the NDK, and I've thought of a possible portability problem that could occur while developing using NDK.
The problem
Since NDK uses native code, it needs to be compiled per CPU architecture. This is a problem since the user needs to run the app no matter what CPU the device has.
Possible solutions I've found so far
I've noticed I can modify the file "jni/Application.mk" and use:
APP_ABI := armeabi armeabi-v7a x86
however, I don't know what I should do from this step on. Will the app contain all of the compiled code for each of the CPU architectures and automatically choose the correct one when running itself?
Also, what if there will be another CPU architecture that is unknown?
What will happen if I try to run the app on Google TV, which according to what I remember doesn't support the NDK at all?
Another solution I've found is the multi-apk support. However, I'm not sure I understand it. Does it all mean that you create the same APK, each time with a different configuration? No special automation tool from ADT to help with that?
If you don't set APP_ABI at all, or use
APP_ABI := all
in your Application.mk, then ndk-build will build for all architectures supported by your version of NDK. The latest one, to date r8d, will in addition to armeabi armeabi-v7a x86 build also for mips. When another architecture will be released, you will hopefully automatically get the APK built to support it.
When you application is installed on an Android device, the system will automatically choose the matching ABI version and install the correct shared libraries from the APK.
One drawback of this approach is that if the native libraries are big, your "monolithic" APK file may become huge. You can use the multi-APK approach to make user downloads smaller. The official site recommends: You should generally use multiple APKs to support different device configurations only when your APK is too large (greater than 50MB). You should carefully follow the version code guildlines if you choose this route.
Unfortunately, there are no trustworthy prophecies regarding NDK support on Google TV, but there seem to be no technical justification for its current unavailability. If and when it arrives, your ndk-build will take care of it automatically.
UPDATE Here is a simple process to maintain split APK. And by the way, the new Android TV does support NDK.
For the latest version (now r9) you have to specify in "jni/Application.mk"
APP_ABI := all
or
APP_ABI := armeabi armeabi-v7a x86 mips
without ./ndk_build will only build 'armeabi'