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.
Related
I've generated a release apk of my Android project in order to do some internal testing via the Developer Console.
Upon generating it, I clicked to analyze the APK file. From the picture I see most of my APk allocations go to libraries and assets.
I'm focusing on the architectures of ARM X86 and X64. I believe they are processor speeds on phones and
upon the APK being installed on a phone the Play Store will determine the phones processor and architectures and then download my APK based on that scenario.
My question is that with Android migrating to 64 bit architecture apps can't I get rid of the ARM architectures that aren't 64 bit based.
I'm unsure of what do do and would like to get rid of these extra architectures if possible to reduce APK size.
Please see the picture provided
Today, the vast majority of Android devices today are arm. The Device Catalog on the Play Console reports 98% of devices supported by Play are running on ARM. Although this number does not take into account devices not supported by Play or the number of users on each device, it still gives you an idea of the proportions.
That being said, regardless of the architectures you choose to support, when publishing to Play, you should always add support for 64 bits of that architecture. For example, if you want to support arm, you must have the libraries for arm64-v8a and if you want to support x86, you must have the libraries for x86_64.
However, to reduce APK size, there is now a better way: publishing an Android App Bundle. Play introduced this new publishing format to solve that exact problem: you publish a single App Bundle to Play, and Play takes care of generating the APKs optimized for each device, containing only the files needed for their device architecture, screen density and language (customizable).
All it takes is to enroll in Play App Signing in the Play Console (so that Play can sign the APKs it generates on your behalf), and select "Build Android App Bundle" in Studio instead of "Build APKs". -- If you use Gradle, gradlew bundleRelease instead of gradlew assembleRelease.
Hope that helps,
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.
We have an app on the Google play store with two version of the APK for different architectures (ARM and x86). This is due to a dependant library being more stable when run natively.
However, a certain x86 based device is failing when running the x86 binary and I would like users of this device to switch to using the ARM version. The options to exclude devices only seems to apply to both APK files together.
Is this possible to configure in the Google Play Developer Console?
The only solution I've found is a hack.
It's possible to add additional contraits to the x86 build as specified here:
https://developer.android.com/google/play/filters.html#other-filters
In our case, we can add a constraint on compatible-screens to the app manifest saying that the x86 build is only supported by the precise screen resolution of the device that works with the build. The problematic x86 devices have a different resolution and are then excluded.
I have an Android project that uses WebView. I want to add Crosswalk to use it instead WebView. I have followed the instructions to embed it and I've seen that there is two, one for ARM and other for x86, so I've created two projects of my Android Project and added ARm to one and x86 to the other. The problem that I have is that I don't know how I must configure each project to generate the apk corresponding to the architecture ARM or x86 to have the two apks to publish in Google Play. I have seen the instructions in developer.android.com but I do not understand them, because it talks about NDK, but I do not have any native code. If somebody could tell me what steps I have to follow to generate the apks, I would appreciate it.
Thanks in advance.
I am using OpenFL to build an Android app to distribute on Google Play. I want to target only armv7 devices, and I believe OpenFL does armv7-only builds by default.
However when building the OpenFL build system creates and populates the libs/armeabi folder instead of a libs/armeabi-v7a folder. The problem with this is that this makes Google Play believe that the resulting apk supports armv5/armv6/armv7 when in reality it only supports armv7. This means my apps get some 1-star reviews from people with the older/incompatible devices.
On this Github issue, Joshua Granick (jgranick) explains why the build tools do this:
Oh and BTW, originally we tried only armeabi-v7, but it failed to run on certain devices. This is why there's the current behavior or using armeabi, and adding armeabi-v7 only if there is an armv5/6 version too
I would like to know what the issue he mentions is, and what devices/Android versions it would affect. Depending on what it is, it may be possible to still just do an armv7 build and manually blacklist the buggy devices.
A final option is to simply support the armv5/armv6 devices by doing a "fat" build, or by only building for armv5 which I assume is compatible everywhere. This is quite easy using the <architecture> tag in the project.xml file. It's a tradeoff I may take if there is no way to work around the problem Joshua mentioned.
Also using the Google Play developer dashboard I could also blacklist armv5/armv6 devices manually, but it would be very time consuming to do this for every app/apk.
So my question is: how can I make armv7-only Android builds using OpenFL and get Google Play to only allow compatible devices, without running into problems like the one I quoted above? If that isn't possible, then what is my best option?
For reference here are the relevant Google Play apk details I get when I build armv7-only:
Thanks!
I got an answer on this GitHub issue. Some armv7 devices or the versions of Android on them cause apps to crash when there is no libs/armeabi folder in the apk. Joshua explained how this led to lime-tools (as of version 1.5.7) setup:
in my Samsung Galaxy S (perhaps other devices) the applications would not run unless there was a "libs/armeabi" folder
If there are both folders, it prefers the armeabi-v7a directory, but otherwise failed to work. So that's why the tools use only a single folder if you target only armv7, and use both folders if you include armv5 and armv7 both.
I'm not sure of a good solution for this, I think the key point of friction here is the Google Play submission process, which should allow us to account for that.
Given this, the solution that works for me was to simply do fat builds of my apps and also support armv5/armv6 devices.