I've made a Xamarin Android app in Visual Studio 2015 Community with Xamarin.
Until recently, I could publish it with no problems for beta testing and I had ~10.000 supported devices.
After I've updated Xamarin to 4.3.0.784, the publish option was replaced by Build>Archive. When I use this new option and distribute my app to Google Store, I have just 1632 supported devices.
I've noticed that on the APK Details page in Google Developer Console, it lists just arm64-v8a as "Native Platforms". In my previous builds that worked, I had all 5 platforms. No matter what supported architectures I select in Visual Studio project properties > Android Options> Advanced, after I distribute APK Details in Developer Console shows arm64-v8a.
Am I missing something or there's a bug in the new tools? What I want to achieve is to have an application in store with the supported architectures that I've selected in VS, so I won't be limited to the 1632 devices.
In the end, I distributed it ad hoc to my drive, zipaligned it manually and uploaded it. It gave a bunch of errors about devices being served by more than 1 version of the APK when trying to publish. Apparently, the VS publishing process messed with the version codes also (I had 1,2,3,4,5 , now they are something like 232329, 232932 etc.) Some are for all platforms, some just for 64bit and I can't explain how that happened.
I still can't publish because of this error and I ran out of patience to surf the net all day so I can use the Build->Archive feature. So I created a new application and uploaded the apk by hand. (this app is in beta so it's ok to make another one). Everything is fine with the new one, 12.000 devices supported for the same APK that had 1600 devices supported.
Still don't understand what happened but it looks bad.
I consider this topic closed.
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 a xamarin forms solution with visual studio 2019 on mac.
I try to publish my apk on google play console but it says that they are Unoptimised APK.
In visual studio, I went to Android project options > Android Build.
In release configuration, I checked Generate one package (apk) per select ABI. In the advanced tab, I checked the 4 supported ABI. Then I published and then uploaded 4 apks to google play console.
It doesn't seem to be enough, the website advises me to:
- Use the Android App Bundle to automatically optimise for device configurations (Not sure it is supported for xamarin solution)
- or manage it yourself with multiple APKs (which I did with no success)
I cannot ignore the warning, the button to go to next step is grayed.
Unfortunately Xamarin Android does not yet support App Bundles.
They are working on it and will be available soon:
https://github.com/xamarin/xamarin-android/issues/2727
The PR for the build task is already merged: https://github.com/xamarin/xamarin-android/pull/3146
if you want to try the preview version you can try this (from the Xamarin team):
you should be able to download a visx from our CI system via the Build Status section of our README.md (see https://github.com/xamarin/xamarin-android#build-status) and then picking a Job and going to the Azure Artifacts page. Or just use this to get the latest stable build https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/lastStableBuild/Azure/
Note that these will be the Open Source bits only. So some things (like fast deployment) won't work. But if you are building a release app that should be ok.
The only thing you can do until the App Bundles support will be released, is to use one APK per ABI and ignore the warning from Google Play
Until all your GRAY CHECKS in Google Play Console (on the left side menu ) become green, you will not be allowed to publish in play console and ignore the warning.
New in Visual Studio 2019 for windows 16.4 and for Mac 8.4
added support for building android app package aab format
I seem to be having a problem with limiting the size of my installed Android Application. During development I used Android Studio to deploy my application to my testing device. The app took a total of 2.32 MB in storage when freshly installed.
The problem in size came up when I published my application to the Google Play Store for alpha testing. I uninstalled the same app I had loaded with Android Studio, then downloaded the one I listed on the Google Play Store. The funny thing is that the same app now takes up 4.11 MB in storage.
How did this occur? The testing environment is the same, therefore what additional libraries or information would need to be added to the app causing it to take up the extra 1.79 MB?
TL;DR
App installed on testing device via Android Studio: 2.32 MB in storage
Same app installed on the same testing device through the Google Play Store: 4.11 MB in storage
Why is there such a significant increase in the size of my application? No other variables aside from installation source have changed.
That's because compiling & installing app into one target device and all devices is different.
When you click the run button, you are targeting only single device.
When deploying a signed release apk, you are targeting all screen densities, intel and arm processors. It includes extra files. It makes your apk file bigger.
Check out this existing answer on SO. Android release apk bigger than debug
The answers point out how a debug version only includes resources for the connected devices screen density. For production all images/res are included. Also, you should be able to further reduce size of your apk by using pro guard if you aren't already.
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 a newbie to Android programming and i started putting together an application using Google Maps using Eclipse with KitKat SDK. I developed a simple app to display Google Maps in the Emulator by installing com.android.vending(4.6.16) and com.google.android.gms(4.3.25) apks. I downloaded these APKs from different sites(not sure how authentic they are).
I am making use of the command aapt dump badging to determine the version.
The map opens but i was repeatedly getting a message that "Unfortunately Play Services has stopped"
Objective is to ensure that I am using the right set of APKs with the emulator
The trouble that i am facing is there seems to be no clear directives on where i can find the authentic version of these APKs. I tried Google Play and when i give a search for com.google.android.gms, it yields a result of applications. I was expecting a URL to download the recent version of the APK. Correct me if i am wrong
1. How to download just the recent version of APKs from Google Play ? Am i looking at the correct site
2. Second is there any authorized site from where i can download these APKs?
I was looking for a listing of the APKs with the version number against it. So that i can download the version that i need. I am not sure of the dependencies of the APKs on the Android platform.
3. Finally is there any dependency between com.google.android.gms.apk and the com.android.vending.apk on the basis of the version or the SDK platform used?
Thanks
Govindarajan
I have a suggestion, Try to use Genymotions for testing maps/places app. it is faster than emulator and you can build and check maps application.
www.genymotion.com/
LINK