If you have an app on Google Play with a native library, and at some point you publish an updated version where support for an architecture (say, x86) is no more, will Google Play tell x86 users about an upgrade? Will those users still be able to download the older APK, where x86 support was present?
Example: version 1 has a native library built for ARM and for x86. Some people install it from Google Play. Then I, the author, publish version 2 where the said library is built for ARM only. Will existing users of v1 see an app update notification? Will Android/x86 users see the app on Google Play at all (with v1 available for download)?
I don't have a non-ARM Android device with Google Play on it, so I cannot check.
So you have native support libraries for x86 and ARM and you want to discontinue x86 at some point in the future and you want to know what happens when you do?
Under this scenario why would you want to tell the the x86 users to download something they already have? (the older version) or even about the new version (which they could not use)
There is a some what similar SO question here the might help with your question but as I understand it if you require native library support only devices with that architecture will be allowed to down load it, update or not.
Multiple APK support is documented here
I guess I am not totally clear what your use case is, the problem might just be that I have been up for 26 hours straight ... ;-)
Related
I got an email from Google team thay is saying my app does not have 64bit apk uploaded. I'm already using react-native 0.59.10 and I thought that between 4 generated apks two of them are already 64 bit. Anybody to help?
I'm enclosing the email:
Hello Google Play Developer,
By August 1, 2019, all apps that use native code must provide a 64-bit
version in order to publish an update. As of the sending of this email, at
least one of your apps* does not yet meet the requirement:
NAME_OF_THE_APP_OF_MINE
Action required
Please review all of your apps for 64-bit compliance and submit your
updated apps by August 1, 2019. The Android developers guide provides
step-by-step instructions for assessing the use of native code and becoming
64-bit compliant, including identifying native libraries, building with
64-bit libraries, testing and publishing.
Please note that we are not making changes to our policy on 32-bit support.
Google Play will continue to deliver apps with 32-bit native code to 32-bit
devices. The requirement means that those apps will need to have a 64-bit
version as well.
If you have any questions or concerns, please contact Google Play developer
support.
*Note: This list of apps reflects Google's best estimate as of the sending
of this email. Only the top apps in your account are listed. This list
should not be considered exhaustive. We encourage you to review ALL of your
apps for native code and make sure 64-bit variants are offered where
necessary. A full list of exemptions to the August 1st deadline can be
found in our blog post.
The Google Play Team Conversation Globe
this is from my build.gradle: include "armeabi-v7a", "x86", "arm64-v8a", "x86_64" and I uploaded all the apks (without universal apk) to google play console release.
These are generated files, that I've uploaded to Google Play:
I'm also enclosing an output of build apk analyzer (Android Studio) of arm64-v8a apk file.
It means that i have no 32bit libs left in my 64bit build or am I wrong?
Thanks for any help!
if you are adding a new app to the Play Store, or updating an existing
app, you must target API level 26 (Android 8.0) or higher. And as
Google outlined in a recent blog post, new applications will be
required to have a target API level of 28 (Android 9.0) beginning in
August 2019.
https://android-developers.googleblog.com/2019/02/expanding-target-api-level-requirements.html
I think you will have all your answers here:
https://www.codeproject.com/Articles/1288668/Making-sure-your-Android-game-is-ready-for-64-bi-2
In recent update Xamarin made it possible to publish android apps straight to the Google play (before you had to generate apk and upload it manually). More info
These are my version numbers. I was at version 10437 when the update came, I made some changes and raised version number to 10438 and tried the new way of publishing. What happened is that my version number became 141510 for some reason and when I tried to do it again it became 207046. After that I set the number to 320000 and started uploading manully again.
I suspect that the reason for this is that I had Multiple supported architectures and xamarin was uploading multiple apks and I was getting some errors about that. Since then I changed supported architectures to armeabi-v7a only.
Question is:
Can I somehow tell google to forget about these screwed up numbers so I can continue with my 10438 (it won't let me now, I get an error that version number must be bigger then the last one)? Also all versions after 10437 are private and this is the current version on beta (image is from beta channel).
Also do I lose mobile devices if I set my supported architecture as armeabi-v7a only?
versionCode vs. versionName:
The versionCode is not shown to the user:
An integer used as an internal version number. This number is used only to determine whether one version is more recent than another, with higher numbers indicating more recent versions. This is not the version number shown to users
Ref: https://developer.android.com/studio/publish/versioning.html
ABI Architecture:
Google does not breakdown the CPU Information/ABI Architectures in a Dashboard like they do for API level or screen resolution. You can get a device breakdown for your app install:
Ref: https://developer.android.com/distribute/googleplay/developer-console.html#app-stats
Assuming your app is not dependent on a 3rd-party NDK library that only supports a subset of all the ABIs, there is no general reason not to support multi-ABIs as you are just pre-limiting your applications available user-based.
Current API and Screen Sizes and Densities Distributions:
Ref: https://developer.android.com/about/dashboards/index.html
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.
Hello I am trying to use google-play-services_lib in my android project. As you know in android phone there is Google Play Service APK which provide a some features to you such as location fetching etc.
So I have confusion that Suppose user have Google Play Service APK version is 4.3 and I am using Google Play Services library version is 4.0.30 in android project to build the app.
Do we require same version on both side like build with same latest Google play service library and Google Play Services installed APK to make as like Push Notification, Location fetching work in this case or there is no link between them ?
Thanks in advance
They don't have to match.
The development of the library and the application is not completely dependant, that's why thier version number is different. As far as I know, each release of the services apk defines a maximum version of the library that is supported. So the only conflict could happen when the services apk is outdated (on the target device), and your application's library is a newer one.
The best you can do is to update the library, and the services application on your device.
It should work that way.
I dont think so that there is link between APK and supported libraries in that because the APK silently gets updated about libraries
I'm new to using Qt5 and I'm wondering how many compilers are needed to support the majority of Android devices? Which compilers cover the most devices.
In addition when submitting to Google Play do I have to specify a different build for every single device? Or do they have a method that lets you map APK files to compiler version?
Any advice for the process of going from Qt Creator to having an APK or multiple APKs that support the majority of devices.
You'll need to download additional API packages.
http://developer.android.com/sdk/installing/adding-packages.html
It depends on how many different API versions you want to support. As a first cut you can look at the Google Play Dashboard
http://developer.android.com/about/dashboards/index.html
which should give you an idea of the population of devices running which version of Android.
Given that Qt 5.x for Android supports API level 10 (Gingerbread), you should start there.
http://doc.qt.io/qt-5/android-support.html