Develop Reference

App with native libs distributed as AppBundle does not work but as an APK it works

I have this Android app using an old video player library called Vitamio. Vitamio has not been updated for ages however it does work, at least until recently.
The library (and the app) works fine when compiled into an ordinary APK but if I create an App Bundle, I get a crash due to "java.lang.UnSatisfiedLinkError" when running the app on the phone.
The Google PlayConsole does not give me any errors nor warnings.
As a test, I set "enableSplit = false" for "abi" in the app build.gradle file but there was no difference.
It seems strange that when compiling to an AppBundle, it would mess up things so previous compilations as an APK do not work any longer.
Anyway, I could fix this?

The APKs generated from the App Bundle leave native libraries uncompressed in the APK so they're not extracted at installation on the device, thus saving space on the device. Depending how you load the native libraries, this can lead to this exception.
Ensure you use the Android standard way of loading native libraries. If you can't for any reason, then you can disable this feature using android.bundle.enableUncompressedNativeLibs=false in the gradle.properties file. At the cost of a bigger app for your users.
If you don't use Gradle to build the bundle, the information about the compression of native libraries is stored in the BundleConfig.pb inside the bundle (which is passed to bundletool by the build system). See https://github.com/google/bundletool/blob/master/src/main/proto/config.proto#L77

How to make APK compliant with Google Play 64-bit Requirement?

I know this question has been asked before, but I am still struggling to find a functioning answer on how to properly achieve this. When I upload our APK to the Google Play dev console, I get the following warning:
Our application uses three jniLibs that fall into the following architectures: arm4-v8a, armeabi-v7a, and x86. Clicking the Learn More link attached to the error gives the following solution to this problem:
However, adding this ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86' in my default config in my build.gradle stills gives the same error referenced above. I am kind of lost on this as I am following what Google recommends and would appreciate any help on the matter.
Here's some additional information:
APK Analyzer Results
I am building a signed APK using the V2 (Full APK Signature).
Removing the x86 jniLib allows me to upload the APK to the Google Play store with zero errors, however, then I am unable to run the Android Emulator because the AVDs only support x86.
An optimal solution would either be: Upload the to the playstore with the x86 support without encountering any errors or upload to the Playstore without the x86 library and still be able to run the emulator within Android Studio. Any ideas?

I'd see two whole other options there ...
A) You'd have to exclude that Epson native assembly for x86 from the release build... because when x86 is present, it will also demand x86_64. I'd assume it is there for x86 emulation, but for debug builds this isn't the problem. Removing it and using a slow ARM emulator might not be the answer. Try adding this into buildTypes.release (in order to keep it for debugging purposes):
packagingOptions {
exclude "lib/x86/*.so"
}
B) Seiko Epson would meanwhile offer native assembly for x86_64 ...if you'd update their SDK.
Technically speaking, option A would be a whole lot better, because of a smaller package size.

Google Play Console states that if you support a 32-bit architecture, you must also support the corresponding 64-bit version.
I see two options:
Provide the x86_64 versions of your libs.
Remove the x86 version of your libs and use an arm architecture AVD system image, which are available.

No debuggable process and Assigning debug symbols to .so files

I am running one app on my Nexus 6P. But While I am using the Android Studio, its showing "No debuggable process detected". Although I am getting log messages from logcat. Why am I getting this problem?
I have few shared libraries .so files. while starting the apk it's telling me to debug this apk, I need to add debug symbols with this .so files.
How to assign debug symbols with this .so files?

The android build system is not really straight forward in this manner and part of it is due to gradle not being forceful with build types. By default gradle does not have build types like debug and release, the android plugin is the one that adds this by default.
The cmake native build builds debug and release variants correctly and puts them into the corresponding build type of the end result APK or AAR.
By default Android Studio builds debug builds, you have to explicitly change this to not have debug builds, so it's likely that you already have debug symbols.
One important thing is that for some reason android project linkages are still not fixed so if you have a linkage of Application that uses an Android Library then in reality it will link the library in release, regardless of the build type of the Application, see here : https://stackoverflow.com/a/20617949/2880011 this way it is possible to not have debug symbols for native code that is coming from the Android Library.
For prebuilts you have to make sure in the native build system that you link against the proper library, so in cmake you have to detect and link it accordingly, but even then the APK packager may ignore this and bundle the same variant for both debug and release.
Android Studio also has some prerequisites for native debugging see here : https://developer.android.com/studio/debug/index.html

Can I upload apks for multiple architectures into the Google Play store without using the android NDK?

I need to produce 2 apks, one for x86 and one for ARM. I do this with different versions of crosswalk, which internally uses cordova. All I need to do one the two projects are created is ./cordova/build --release and then sign the APK. The Google Play store docs mention a way of uploading both into a single app listing, but they assume I'm using the Android NDK, which I'm not. Will I need to start using it or is there another way to simply upload both apks?

Google does support posting of architechture-specific APKs: http://developer.android.com/google/play/publishing/multiple-apks.html. Note however that the documentation states, in bold:
we encourage you to develop and publish a single APK
So, if you take the single APK approach:
Just compile your native code into libraries (i.e. .so files) and place them in the following locations
<Project_Root>/app/src/main/jniLibs/armeabi/
and
<Project_Root>/app/src/main/jniLibs/x86/
The build process will package these in the appropriate manner so that your APK contains libs for both architectures. Then at runtime, Android will ensure that the architecture-appropriate library is loaded.
Note that the above assumes that you are using Gradle to build your APKs. If you are using the old ant-based build process, the locations are slightly different:
<Project_Root>/libs/armeabi/
and
<Project_Root>/libs/x86/

How can I publish to play store the x86 and ARM apks of my cordova-crosswalk app?

My app is developped/published with Cordova and Crosswalk. Crosswalk generates an apk for ARM cpus and another one for x86 cpus.
At the moment, when I upload my ARM apk to the play store and then try to upload the x86 one, it prevents me from doing so and display a message that says that I cannot have two apk with the same version code.
It seems it's possible to upload on the play store multiple apk files for the same version of an application byt filtering the devices targetted by each apk file.
However, it seems to require the use of an "Application.mk" file that the Cordova project structure doesn't seem to have by default.
How can I include an Application.mk file within my apks so that both the ARM and the x86 with the same version code will be uploadable to the Play store ?

It's absolutily possible.
This feature receve the name of: Multiple APK
You don't need to use the 'Application.mk'
The process is simple:
In Developer Console, switch to Advanced Mode (click the Switch to advanced mode button at the top right of the APK tab - note that you must have uploaded at least one APK for that button to appear)
Upload the two APK
Publish!
There's some rules to use multiple APK, but if you use the files generated by cordova crosswalk, you have nothing to worry about.
The problem that you described with version code, happens beacuse each app must have a different version code. In my case, I use ionic framework (extends cordova) and in the build process, it generated a diferent version code por each apk, so I had no problem. If it not happens for you, you can try to change de android:versionCode directly on the AndroidManifest.xml file.
Here is how my manifest looks like:
<manifest
android:hardwareAccelerated="true"
android:versionCode="102"
android:versionName="0.1.2"
package="br.org.yyyyyyy.xxxxxxxxxx"
xmlns:android="http://schemas.android.com/apk/res/android">
In my case, the arm7 apk, the
android:versionCode="102"
And in x86 apk the
android:versionCode="104"
References:
Android Multiple APKs DOC
Maintaining Multiple APKs DOC

I`m doing simple way. Example your main v code is 102, so you build first arm with 102 v code, and upload. Until upload runs, you can go change v code in manifest and in build grade to 103 and build another one x86. Easy and simple.

I think things have changed in the past year. I used the same version code and uploaded both apks (one at a time - in the normal way). Google Play auto-detected that they were targeted to different native platforms, and allowed both to be entered into production.

The cordova-crosswalk doc instructs how to make an apk that works for both arm and x86. The problem is that it makes a huge apk.
If you really want to make two apks, you can try (sorry not tested yet) to create the Application.mk file in the folder platforms/android/jni
For arm you'd put this line in Application.mk :
APP_ABI := armeabi armeabi-v7a
And for intel x86 :
APP_ABI := x86
And you have to change AndroidManifest.xml to have a different version for each platform (following the instructions in the link you provided).
Be carefull, if you run cordova build android again, it will probably replace all the content of platforms/android, and your changes will be lost.
To build the project use
platforms\android\cordova\build.bat -release
instead of
cordova build android --release