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.
Related
I tried to build the AOSP platform for a Google Pixel 3 phone.
To do that, I downloaded the AOSP platform source for Pixel 3 from the Google Server.
I did not modified anything in the AOSP platform source tree and just performed the build.
It took about 12 hours and done successfully.
Using fastboot, I flashed the built images to my Pixel 3 phone and it worked!
My Pixel 3 boots successfully and works OK.
However, I can't find the Play Store App now.
Did I miss something during the build procedure?
Or should I pass the compatibility test (CTS) to get the Play Store App?
Is it required to take the CTS test even if I build the AOSP platform just for private usage?
Google Play services are not part of standard AOSP.
Yes, you need to pass CTS and get kind of licensed, and then you can get access to those.
You could also get them manually from here: https://opengapps.org/ , I thinks that's OK for private usage, not sure about the legality of distributing them.
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 have recently included android wear support in my app but when I went to publish it today I was made aware my earlier version would be archived. My earlier version was targeting api 16 to include as many devices as possible.
I was hoping if a user doesn't have the latest devices capable of running my updated android wear version then they would get the earlier version I have published.
What is the correct procedure to enable this to happen please?
Regards
It is possible to keep your app supporting API 16 while adding Android Wear support. The Google Play Services library runs on many older devices, and it will do the right thing to ensure that your code will not crash. Since an old Gingerbread phone cannot support Android Wear, you will just get an error code when you try to make use of Wear functionality, and you can just handle it gracefully with whatever way is appropriate for your application.
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
We have an app on google play, and we are about to publish update, but testing update on JB device resulted in UnsatisfiedLinkError when calling System.loadLibrary("ourlib") in our code. ourlib is library compiled by us using NDK. This error shows only on 4.1 devices.
I suspect that it has something to do with new security on JB, app was first installed with Google Play with lets say version 1, and then reinstalled with version 2 using adb or from device using apk.
I could not find anything related to that on google, what could be the problem?
this problem
http://code.google.com/p/android/issues/detail?id=35962
looks similar but it appears that it was an error in google play actually.
Does that mean that you are trying to use standard/system library? Maybe the version of the library that you are trying to load does NOT contain particular functionality that you intend to use. Check android docs when the functionality became or stopped being available.
The solution is to use:
$ adb install -r -l my.apk
this makes apk to be reinstalled with use of forward-lock (aka. copy protection), I supose that because apk was upladed to google play with copy protection enabled then also forward-lock option in adb had to be added. I know JB introduced some changes with forward lock so this might be the case. I dont know internals of what really caused this problem, but above seems to work.