I have an android app on Google Play, it requires a low API level.
I wish to provide versions for TV, auto and wear 2.0. This requires a higher API level.
The first question is should I release a different APK for each or two APKs is enough? (One for phone+tablet and one for wear+tv+auto)
Second question is how do I enable multiple APKs? According to
https://developer.android.com/google/play/publishing/multiple-apks.html :
"The Google Play Console provides two modes for managing the APKs associated with your application: simple mode and advanced mode. You can switch between these by clicking the link at the top-right corner of the APK files tab."
I've been searching the Google Play console for an hour already. Can't find where this switch button is or what the "APK Files tab" is ?
1) I highly suggest releasing separate APKs for wear, TV and auto. Otherwise, if you e.g. include assets for TV, these will take up space in the APK for wearable devices, but never be used. It's important to minimize the size of the APK especially for wearable devices since they have very limited battery (bigger APK equals longer time to download and install) and storage. Also, if you need to do target platform specific bug fixes you can update the APK for that target platform without impacting other users. You might also want to add platform specific features in the future. Separate APKs will make all of the above easier. It's a bit more overhead to set up in the first place, but everything can be automated, and I'm sure you'll benefit from it in the long run.
2) Like Vyacheslav mentioned in his comment you no longer need to enable multi APK support in the Play Store developer console. Just add all the APKs when you create a new release (Release management -> App releases). For this to work they need to have filters to make all of the APKs unique, and also different version codes.
Auto and Wear are not distributed in Android platforms through apks, they are features that you should enable in your app.
Android TV is more easily to publish through specific apk, that you can configure in your project using gradle variants.
Related
The code is practically the same, I just added one class, is it because when the Bundle is installed in a device just a part of it is going to go to that device and its size is going to be lower?
From the docs
Google Play’s Dynamic Delivery uses your Android App Bundle to build
and serve APKs that are optimized for each device configuration. This
results in a smaller app download for end-users by removing unused
code and resources needed for other devices.
So basically apk will be build using Dynamic delivery which will combine only necessary resources and will ensure that the build installed on particular design is optimized. There is no mention that bundle size is smaller, but it ensures that download size for end user will be less.
Also this a good article to refer to.
Mentionig some key points mentioned in it
Step 1: You write all your code for your app in an IDE such as Android Studio or a games engine such as Unity as you normally would.
Step 2: Now, when you’re ready to test or release the app, you build it as an Android App Bundle, Android’s new app publishing
format. You still sign the app so that Google Play can verify it’s
from you.
Step 3: If you haven’t already, you opt in to app signing by Google Play. If you’re releasing a new app, you can do this in a one-click
process when you upload your app. When you opt in, Play designates
the first key you used to sign your app bundle as the upload key.
This is just for security identification purposes and, if you ever
lose it, you can contact Google to verify your identity and reset
it. For existing apps, you need to visit the app signing page in
the Play Console and securely transfer your app signing key to
Google Play. Why do you need to do this? Continue to step 4 to find
out.
Step 4: When you upload your app bundle to Google Play, Play processes it and generates split APKs signed with the app signing
key for every possible device configuration and language that you
support. Split APKs are an Android platform feature introduced in
Android L. As long as each split APK is signed with the same key,
the Android platform will treat them as one app. You can think of a
split APK as ‘part’ of an APK: to run the app, the device treats
all the parts as a single app.
Step 5: When a user installs the app, Play delivers the base split APK (all the code that’s common for every device), the language
split APKs (for the languages the user speaks), and the device
configuration split APKs (for the device’s screen size and the CPU
architecture). This means the device gets just what it needs without
wasted space. For updates to be accepted by the device, every
release’s split APKs must be signed with the same app signing key as
the original app install.
I was studying Android Developer doc today and found a new topic Multiple APK Support which says that:
Multiple APK support is a feature on Google Play that allows you to publish different APKs for your application that are each targeted to different device configurations.
I am unable to find this feature on Google Play Developer Console, can someone guide me over this feature?
Update :
In Google I/O 2018, a new publishing format has been introduced for Android applications called Android App Bundle. It is a new upload format that includes all your app’s compiled code and resources, but defers APK generation and signing to Google Play
Read More from below links :
https://medium.com/mindorks/android-app-bundle-6c65ce8105a1
https://developer.android.com/guide/app-bundle
#Paul
In new UI on play store developer console APK tab has been removed. And its being replaced by Apk Release So Advanced Mode is removed in new UI on google play store
You must know some rules before upload multiple APKS to play store :
All APKs you publish for the same application must have the same package name and be signed with the same certificate key.
Each APK must have a different version code, specified by the android:versionCode attribute.
Each APK must not exactly match the configuration support of another APK.
for more information please Read
You can also see How to create multiple apk files for android application
All you have to do is upload each version one at a time. Each next version will need to be higher than the previous and it will ask you if you would like to deactivate any of your previous versions or retain them, and you will want to retain them so that they stay available. Please note, users will always receive the highest version available to them though so if they are compatible with multiple versions then they will not be given the choice of which version they want, they will just automatically receive the highest version
Later in the documentation you link, it has a "how it works" section which explains you have to enable Advanced Mode to be able to use the feature:
To publish multiple APKs for the same application, you must enable Advanced mode in your application's APK files tab (as discussed in the previous section). Once in advanced mode, you can upload, activate, then publish multiple APKs for the same application. The following sections describe more about how it works
NOTE
The above answer is deprecated. Please refer to the Feb 1 2018 answer by Dhaval Jivani below.
I developed an app that works on most phones starting API 16, the problem is that in LG G2 it only works on API 20 and higher..
Is there any way I can do this separation in the google play store?
Thanks,
Dani
This is possible using multiple APK support.
Multiple APK support is a feature on Google Play that allows you to
publish different APKs for your application that are each targeted to
different device configurations. Each APK is a complete and
independent version of your application, but they share the same
application listing on Google Play and must share the same package
name and be signed with the same release key. This feature is useful
for cases in which your application cannot reach all desired devices
with a single APK.
You can support different platform versions with each APK, which will allow you to use API 20 and API 16 as you request.
However, keep in mind this recommendation from Google:
Using a single APK to support different configurations is always the
best practice, because it makes the path for application updates
simple and clear for users (and also makes your life simpler by
avoiding development and publishing complexity).
You will need to configure your APK's platform API levels in your AndroidManifest.xml and upload the published APK in Advanced Mode in the Google Play Developer Console. This means setting up multiple AndroidManifests, configuring them to included different 'uses-sdk' elements and uploading multiple APK.
All of the filters that are valid for Multiple APK publishing are listed in this Google-provided guide:
http://developer.android.com/google/play/filters.html
While this is possible, I would advise you to avoid it if you can because maintaining it is not fun or easy.
We currently have an Android app listed in play store which supports Android 2.x and plan an update which has minimum Android 4 (having Holo theme etc).
The question now is:
If we publish the update, what will happen to phones having Android 2.x?
Will they see the last version supporting Android 2 in the store or won´t they see the app?
I didn´t find anything about this in the store guidelines. There is a concept for multiple APKs, but we do not want to publish new 2.x versions, we only want the availability of the old app version for Android 2 powered devices...
The normal flow is to have just one APK active at a time. But you can enable multiple APKs to be active by following this rules. You have to check the changes to your manifest between the two versions and see if they apply to those rules.
It worth reading the full multiple apks page to get a better understanding before making any changes/upload to developer console.
Also, note that to have multiple APKs you must switch your console view to advanced mode (because simple mode only allows to have one APK active).
This link has some guidelines specific to having multiple APKs for different API levels (which is your case).
I just uploaded my android app for beta testing for the first time and my friends are able to download it without issue. However I found that in the app page, 'Size' and 'Current Version' shows 'Varies with device' instead of the actual apk size and version..
I've only uploaded only one APK, what gives?
Screenshot below:
If you wish to access my beta testing app page, send me a message with your gmail address in, so I can add you into the beta testing list.
Have you found out the answer yet? Since you have not elected an answer as a correct one, here we go...
Google Play allows you to publish different APKs for your application. Each one targeted to different device configuration. Thus, each APK is an independent version of your application, but they share the same application listing on Google Play and must share the same package name and be signed with the same release key.
Usually Android applications run on most compatible devices with a single APK, by supplying alternative resources for different configurations (e.g., different layouts for different screen sizes) and the Android system selects the appropriate resources for the device at runtime. But in a few cases, however, a single APK is unable to support all device configurations, because alternative resources make the APK file too big (greater than 50MB) or other technical challenges prevent a single APK from working on all devices.
And even though Google doesn't encourage developers to use this "multiple APK" feature, most Google apps use it: Google+, Google Chrome, Gmail, Google Maps, Google Search, Google Play Books, Google Play Movies & TV, Google Translate.
I hope I was helpful.
Check the Artifacts library section of Release Management in Google Play developer console, you should have just one active artifact for the your app release.
My app was on closed track and the latest release wasn't showing until I removed the draft APKs in "Artifact library" and uninstalled the app from all closed test devices.