I received an email from Google that we need to start supporting 64-bit CPUs in our Android apps by August 1, 2019. In their documentation, it states that there should be a lib/arm64-v8a folder in your apk contents if you're correctly supporting 64 bit.
In my Xamarin Project Options > Build > Compiler settings, my Platform target is set to "Any" so I would expect it to build both 32 and 64 bit versions. However, when I generate a release build and package it into an apk, when I browse the apk it only has a lib/armeabi-v7a folder, there is no v8a folder. So what do I need to do to support 64 bit architectures?
EDIT: I should have included this screenshot, showing my Supported ABIs:
Go into your Project settings / Build / Android Build / Advanced and enable arm64-v8a as one of your supported ABIs.
And then do a fresh build (or a new archive if you are using that feature of VS).
Note: Make sure you do this for your Release configuration
As #sushihangover mentioned, you just have to Make Sure that on your "Release" configuration, you need to select the arm64-v8a ABI configuration.
Remember to "Rebuild All" before you hit "Archive for Publishing" so that you don't run into issues based on cached data.
You can view this article for more details and a video.
In my case (after many weeks of frustration), it turns out that Google Play Console (depending on app release setting) may try to 'retain' older versions of your application. You need to remove all older versions during the release.
Related
I am working with Xamarin Forms and I published the Android app ad-hoc to disc.
What I would like to do is to give the apk to some people to test by uploading it to a web site I have so they can download it. Here's what was created:
com.xx.xx-arm64-v8a.apk
com.xx.xx-armeabi-v7.apk
com.xx.xx-x86_64.apk
com.xx.xx-x86.apk
com.xx.xx.apk
My question is twofold. Why does it create four apps and which of those should I give to the person? I assume it's okay to give the last in the list but if that's the case then why are the others created?
I also heard something about a new feature with Android that would allow smaller builds and just let a person download the build that is needed for their device. Can someone tell me if I could use that with these apks and if so how I would do it.
Thanks
Here are the list of options that I have selected:
Please open your Android Options, If you enable the Generate one package (.apk) per selected ABI selection, you will get serveral .apk file. If you want to generate one .apk file, just unselect it like following screenshot.
If you want to enable the Generate one package (.apk) per selected ABIselection. you can give the .apk file by Users' device(CPU Architectures).
Xamarin.Android supports the following architectures:
armeabi – ARM-based CPUs that support at least the ARMv5TE instruction set. Note that armeabi is not thread-safe and should not be used on multi-CPU devices.
Note
As of Xamarin.Android 9.2, armeabi is no longer supported.
armeabi-v7a – ARM-based CPUs with hardware floating-point operations and multiple CPU (SMP) devices. Note that armeabi-v7a machine code will not run on ARMv5 devices.
arm64-v8a – CPUs based on the 64-bit ARMv8 architecture.
x86 – CPUs that support the x86 (or IA-32) instruction set. This instruction set is equivalent to that of the Pentium Pro, including MMX, SSE, SSE2, and SSE3 instructions.
x86_64 CPUs that support the 64-bit x86 (also referred as x64 and AMD64) instruction set.
If you want to know more details about CPU Architectures, you can refer to this thread.
https://learn.microsoft.com/en-us/xamarin/android/app-fundamentals/cpu-architectures?tabs=windows
while you are creating an apk Please make sure your Architecture should be armeabi-7a and armeabi-v8a in Project Properties - > Android Options -> Advanced.
after that Clean Solution.
than Please go for .apk Archive it will create simple Signed Apk which you can distribute.
Hope it helps.
enter image description hereI select arm64 (64 bit) and x86 and amrv7 and select build app bundle in player setting
so but when I want publish so I have an error like :
Error
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: 2.
Include 64-bit and 32-bit native code in your app. Use the Android App Bundle publishing format to automatically ensure that each device architecture receives only the native code it needs. This avoids increasing the overall size of your app.
All plugin worked in my other game but A plug in i new(=applovin sdk), this is a system ads , How can I understand applovin sdk support for 64 bit ?
Why can't I publish the game?
please help me
I have this problem some week and can not publish my games ? please help me
What is my wrong?
Go to project properties, Switch to project back end IL2CPP.
Android project properties -> https://docs.unity3d.com/Manual/class-PlayerSettingsAndroid.html
IL2CPP setting -> https://docs.unity3d.com/Manual/IL2CPP.html
other stuff that you probably already did:
https://docs.unity3d.com/Manual/BuildSettings.html
switch platform -> to Android
ensure you have API compatibility set, and that you have downloaded the required API versions via the Android NPK tooling.
Based on your error you could also try temporarily disabling the ARM7 option.
[update]
Based on OP's response, while the above is general troubleshooting, it seems to be native plugin. If this is the case use the following technique to determine if the plugin is 32 bit.
1. Create a new android project, make sure it builds. set ARM64 and not ARM7 in project settings.
2. add just the plugin. Rebuild the project.
3. If there is an exception related to the platform it may be the plugin is 32 bit.
If you get an error
First check the error, it may not be related (i.e. a red herring).
Go back to the plugin site, check for 64 bit, also check if the plugin has git source such as on GitHub.
If it does you can probably recompile the plugin to 64 bit (separate question).
I know i'm replying a bit late, but i think the solution is to just:
Enable IL2CPP
Disable x86
According to https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html:
In August 2019, Play store will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions.
I have a React Native application (which includes native code). My question is how can I know whether a third party library I'm using or even my own code is not supporting 64-bit? And how can I fix it?
Update
I added x86_64 to my build.gradle and I now see the x86_64 folder in the apk but I think some of the files are missing.
Here is, how my x86 folder looks like:
And here is how my x86_64 folder looks like:
React Native will support 64 bit for android starting version 0.59
https://github.com/facebook/react-native/issues/2814#issuecomment-457688789
https://github.com/facebook/react-native/commit/f3e5cce4745c0ad9a5c697be772757a03e15edc5
All of the native code for an app is stored in the libs/ directory in the root of the apk. eg for compiled ARM or x86 code, you can find it in libs/architecture_type/lib_name.so.
An APK is essentially just a zip file so you can extract it with any zip tool.
The list of architectures (ABIs) is here. If you don't have directories for arm64-v8a or have x86 but don't have x86_64 then you are missing the 64 bit native code.
https://github.com/facebook/react-native/issues/2814
Facebook seems to be dragging their feet on supporting 64 bit builds.
You can check the intermediates in the build folder to see what abis you are supporting.
https://developer.android.com/ndk/guides/abis.html
Android takes the lowest common denominator of build abi. This is going to become an issue if Facebook doesn't address it soon.
React native has been released the new version of the react native on 12 march.
In this new version react native support the 64 bit systems.
You can read more detail about this on below link.
http://facebook.github.io/react-native/blog/2019/03/12/releasing-react-native-059
react-native new versions support 64 bit automatically.
just update react-native version to 0.59.0 or after and rebuild your application, just run:
react-native upgrade 0.59.1
If you are using react native version less than 0.59 then you must upgrade your apps to react native 0.59 or higher. React native supports 64 bit only from 0.59 version.
Also, make sure your app has following lines in your MyProject/Android/App/Build.gradle file.
splits {
abi {
reset()
enable enableSeparateBuildPerCPUArchitecture
universalApk true // If true, also generate a universal APK
include "armeabi-v7a", "x86", "arm64-v8a", "x86_64"
}
}
For more refer:
Update your React Native Apps to be 64 Bit
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 currently in the process of updating our project OpenSSL to 1.0.1i using http://wiki.openssl.org/index.php/Android.
Looking in the config file I found that OpenSSL has 2 Android build options: android-armv7 and android-x86.
I have been able to build the armv7 configuration and it appears to be working correctly on a Nexus 5 and a Kindle Fire 1st Gen.
What I am wondering is would my current library work if it were in the armeabi directory instead of the armeabi-v7a directory? I was not able to find sufficient information as to whether it matters if the OpenSSL is built with armv7 but my project libraries are built with older arm in mind.
Note: My minimum API level is 8.
What I am wondering is would my current library work if it were in the armeabi directory instead of the armeabi-v7a directory?
I think there are a couple questions here. First, can you put libssl and libcrypto in armeabi/. That's an Android question (not an OpenSSL question). I seem to recall Brian talking about this on the NDK mailing list (but I can't find it at the moment). I believe the idea is armeabi/ is a fallback if a more specific library is not found in, for example, armeabi-v7a/.
Second is, can you run ARMv7a version of libssl and libcrypto on other platforms. I believe ARMv7a added a few hypervisor extensions over ARMv7, so you should be OK since OpenSSL does not use them. However, you might find yourself in trouble if running on an older device with ARMv6 or ARMv5.
In this case, you might want to download an older version of the Android NDK that builds for ARMv5, and then place ARMv5 version of libssl and libcrypto in armeabi/. You can find older versions of the NDK at Android NDK about a third of the way down the page.
To be more specific, Android 2.2 is API 8, and it was released around May 2010. So you might want to fetch and build with Android NDK Revision 3 from March 2010. NDK R3 only supported armeabi and targeted ARMv5TE (from the CPU-ARCH-ABIS.TXT file). The download is http://dl.google.com/android/ndk/android-ndk-r3-linux-x86.zip.
OpenSSL does not follow the instructions at Standalone Toolchain for ARMv7a. Its missing the -mfloat-abi=softfp flag. You might have trouble calling a function that passes a float to the library from Java. There are not many of them, but one is RAND_add. The entropy estimate is passed as a float and after the incompatibility, your estimate will likely be 0.0f. See Hard-float and JNI on the NDK mailing list and [Bug #3080]: Android NEON and CFLAGS options.
Here's a note from the README's that you should also be aware of:
III.3. Automatic extraction of native code at install time:
-----------------------------------------------------------
When installing an application, the package manager service will scan
the .apk and look for any shared library of the form:
lib/<abi>/lib<name>.so
If one is found, then it is copied under $APPDIR/lib/lib<name>.so,
where $APPDIR corresponds to the application's specific data directory.
If you update the APK and nothing changes, then be sure to delete anything under lib\ or delte the APK first (they have a tendency to become "sticky").
Another issue you will likely encounter is building and compiling against 1.0.1. Be sure you provide a wrapper shared object with a different name. Otherwise, you will likely link against 0.9.8 at runtime, and not the 1.0.1 gear in your APK. That's because Zygote loads Android's version of OpenSSL, and that version is 0.9.8. Later, when Zygote forks to create your process, the link-loader will not map-in your version of OpenSSL because its already present from Zygote.
OpenSSL has 2 Android build options: android-armv7 and android-x86
I added android-x86 to the script in June 2014. I was able to get through the build with one patch: [Bug #3398] PATCH: fix broken compile on android-x86 with no-comp configure option. I don't have an x86 Android device, so I was not able to run the self tests on a device. Feedback is welcomed.