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
Related
I create application in Android Studio, and send it to Google Play Store, after time i add library "littleprxy"(based on netty), and when it came time to send updated application in Google Play Console i see Supported platform : amd64-Linux-gpp, amd64-Windows-gpp, arm-Linux-gpp, i386-Linux-gpp, i386-MacOSX-gpp, x86_64-MacOSX-gpp, x86-Windows-gpp, and ofcourse 0 supported Android devices, but i can install apk manually, and it work fine.
How i can fix it? Maybe some parameters for gradle or manifest...
Sorry for English
LittlePrxy is written atop Netty. Netty is kind of "heavy" for Android. Most of Android devices are resource limit. memory footprint, cpu usage should be carefully treated. This is the reason why Netty doesn't support Android OS. Sure you will be able to use this lib but it is not recommended. This is why GooglePlay reports an error, because Android is not specified in the list of supported OS of this lib.
In short, you should not use LittlePrxy in your app. You should find another library.
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.
I am integrating a third party API into an Android application and must include their NDK libraries. I am using Android Studio w/gradle and putting all native libraries under:
src/main/jniLibs/
My question is this: they have provided '.so' libraries under the subdirectories:
armeabi/ mips/ x86/
Do I need to include all of these directories under jniLibs in my app?
The implementation instructions specified only 'armeabi', but then I am not sure why the other architectures are provided. The mips directory is about 3.2 MB and the x86 directory is about 6MB, so I do not want to package these in my app if not necessary. Not sure what they are for.
MIPS-powered devices take a relatively small market share these days, and this is the low-end (primarily in terms of retail price) segment of the market. Your app may be exactly fit for this niche, or you may not be interested to pursue this opportunity (note that marketing approach and even technical challenges are significantly different for the top-end and low-end targets).
On the other end, all Intel-based devices I saw, have decent ARM emulation built-in, exactly for the purpose to compensate for poor coverage of this platform by developers of native apps. So, if you are not concerned with the performance, you can painlessly drop the x86 support.
Actually, it might be more important to provide armv7-a version of your native libs, because use of advanced instruction set (especially with NEON) may boost performance of your app for a vast majority of users (most of the modern tablets and phone these days come with one of the chipsets that support these).
Furthermore, in less than a month, new ABIs will enter the market: 64-bit Intel and ARM devices, e.g. Nexus 6, running Android 5.0 Lollipop.
But ultimately, your primary concern probably is that the size of APK file that millions of your users will be downloading from the Play Store will be unnecessarily huge. To resolve this, there is a different technique, which allows you to split your APK and upload to Play Store separate versions, one for each ABI. The trick is that the version numbers should be managed carefully, to allow smooth upgrades for users of each platform. Here yours truly proposed (and Ashwin S Ashok improved) a version numbering scheme that helps manage this task.
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 ... ;-)
I'm tending to release and submit to GooglePlay two apk files of the same application. One with android sdk 7 for android version lower than 4.0, one with android sdk 14 for android 4.0 and upper. Is it possible?
Yes you can. But, it might be tricky.
http://developer.android.com/guide/google/play/publishing/multiple-apks.html
There will be some problems, when you different apks for devices, which are close to each other. But, you can get started with the above link.
It's recommended though, to have a single apk.
Note: You should generally use multiple APKs to support different device configurations only when your APK is too large (greater than 50MB).