Running into an issue around a native-Android Unity integration release into the Play Store. I extract it as a project out of Unity and migrate it as a Library in our native app.
When attempting to upload an .AAB into the Play Store, the following error occurs:
This release is not compliant with the Google Play 64-bit requirement.
The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: [10406]
I've already checked the following:
First, I followed the steps in the official guide: https://developer.android.com/distribute/best-practices/develop/64-bit
Unity version: 2019.4.9f1, Android player settings I've selected both ARMv7 and ARM64. No x86 option in this version of Unity. Scripting backend listed as IL2CPP
In the build.gradle file, I have listed: ndk { abiFilters 'armeabi-v7a', 'arm64-v8a' } as we want to support both 32-bit and 64-bit
I've used the APK Analyzer tool inside of Android Studio to analyze both the APK and AAB versions of the app. There are the same 10 '.so' files listed in both the lib/armeabi-v7a and lib/arm64-v8a folders.
Next I used the apktool in combination with the 'file' command to extract the contents of both an APK and AAB version of the app, and double check that the '.so' files inside the arm64-v8a folder are, in fact, 64 bit architecture
I tested that if I directly install the APK version using the following command on a 64bit device, it was successful:
% adb install --abi arm64-v8a app.apk
Performing Streamed Install
Success
I am officially out of ideas and I did contact the Play Store for assistance but they haven't responded in 2 days so I'm getting antsy.
Does anyone have ideas as to what I may have missed?
EDIT:
Forgot to mention, this is also inside the app and unityLibrary build.gradle files:
packagingOptions {
doNotStrip '*/armeabi-v7a/*.so'
doNotStrip '*/arm64-v8a/*.so'
}
Here's a repo containing my simplified gradle files, if it helps:
https://github.com/azdragon2/unityandroid-stackoverflow-question
Thank you!
The problem stemmed from the usage of '.bc' files contained within a Unity library I was using. These bc files are always interpreted as 32-bit. You'll have to upgrade whichever library you're using that contains these files.
You can determine if you have the same issue by running the following command on your APK or AAB file:
zipinfo -1 app.apk | grep \.bc$
Related
I was getting this warning in google play. This release is not compliant with the Google Play 64-bit requirement. The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code
I noticed that my apk had only x86, x86_64, armeabi_v7a folders. So I updated the gradle build script and now I have arm64-v8a folder as well. I see all the .so in armeabi-v7a generated in arm64 too.
How can I validate that this will support 64 bit devices
You can create an emulator with 64 bit image, to see that the app works on it.
Also, in your build variants, you can choose which active abi to use:
I have an android app which I am trying to upload to Google Play Console.
After analyzing the apk, I can find the same .so files in x86, arm64-v8a and armeabi-v7a folders.
I don't have a x86_64 though.
But still, when I upload my apk to google play console, I get this error:
APKs or App Bundles are available to 64-bit devices, but they only
have 32-bit native code
I have followed the documentation to add
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
in my build.gradle file, but that doesn't the structure of the apk.
This is how my analyzed apk looks like:
Please help.
The Agora SDK unfortunately does not support x86_64, which means you'll need to drop support for x86 altogether to be able to upload to the Play Console. Remove 'x86' and 'x86_64' from the list of abiFilters.
At the same time, I would recommend reaching our to the SDK developers to ask them to add support for it so you don't lose on potential users.
My native android app gets rejected from the google play console due to the 64-bit requirement, even though it contains 64bit libraries.
I followed the steps on https://developer.android.com/distribute/best-practices/develop/64-bit by checking there are x86_64 and arm64_v8a folders which contain all the .so files.
I tested installing the app using adb install --abi arm64-v8a YOUR_APK_FILE.apk which installed successfully and the app runs fine on my Pixel3a.
I do not use ndk.abiFilters in my gradle file (which defaults to all architectures).
targetSdkVersion and compileSdkVersion is 28
Screenshot of the libraries in my generated apk:
https://imgur.com/a/iBoIazG. I believe this are all from the Fresco library. Extract from my gradle file:
implementation 'com.facebook.fresco:fresco:1.13.0'
implementation 'com.facebook.fresco:animated-webp:1.13.0'
implementation 'com.facebook.fresco:webpsupport:1.13.0'
I am not using the androidX support libraries so cannot go higher than that version of fresco.
Here is the error I get when trying to upload to the console
This release is not compliant with the Google Play 64-bit requirement.
The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: 74.
I have seen a few other posts about this error but they are normally related to ReactNative or Expo, whereas my app is full native android.
Anyone got any idea on what I'm doing wrong, or how the google console checks if an app is 64bit ready?
Thanks
I recently get this error from google play console stating that
"This release is not compliant with Google Play 64-bit requirement.The following APKS are available with 64-bit devices but they only have 32-bit native code".
So I found the solution in google support and I am writing this piece of code in my defaultconfig in build.gradle
defaultConfig {
applicationId "com.abcdef"
multiDexEnabled true
ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64' //This line added
}
Note->My project is a hybrid project and not native
And after analyzing my apk after build I see two folders in lib directory i.e x86 & armeabi-v7a. There is no x86_64 & arm64-v8a directories present
So I am having a confusion that the APK That I have build is only 32 bit apk or will support both 32 and 64 bit.
It is having .so files also.
Its is just a query as from august 1st google play will not take apps with 64-bit compliance as stated in their documentation.
There is option in android studio to analyse APK. By this analysis you can confirm about what architecture (32/64 bit) your APK is supporting. Follow the below link having complete steps,
https://developer.android.com/distribute/best-practices/develop/64-bit
I am using mobile first development MFP-STUDIOS-7.1.0 so by configuring the project with latest ifix of MFP7.1.0 I was able to solve this problem by using MobileFirst Platform Studio 7.1.0.00-20190730-1558
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