Google Play Console: Publishing
Tags: android
Published: 2022-10-01 11:39:07

---
title: Google Play Console: Publishing
published: true
date: 2022-10-01 11:27:14 UTC
tags: Android
canonical_url: https://www.rockandnull.com/google-play-console-publish/
---

 ![Google Play Console: Publishing](https://images.unsplash.com/photo-1503694978374-8a2fa686963a?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDJ8fHByZXNzfGVufDB8fHx8MTY2NDYyMzU1Ng&ixlib=rb-1.2.1&q=80&w=2000)

Play Console is one of the most important tools in an Android developer’s toolbox.

Nevertheless, few know the console’s features outside of the core publishing ones. Harvesting the power of the console could have benefits for the entire lifecycle of an app. Just being aware of the features the console offers increases the chances of succeeding in the competitive app market.

In this post series, I plan to go through some of the most interesting features of the console. I am not a big fan of lengthy blog posts - no one has time to read those - so I will do my best to have concise yet informative posts. Join me for a quick guide through the Play Console.

We will start with the core feature of the console: publishing / releasing. Even though this sounds quite self-explanatory and without much need to deep further, the publishing features in Play Console over the years have expanded their scope and capabilities consistently. This has led to a significantly more complex and powerful offering than just an "upload your APK form".

You can find most of the publishing-related functionality in Play Console under "Release". The ones below are the core pages related to publishing an app in the console. When releasing a new version of an app, ideally it would go through multiple release channels until it reaches general availability (i.e. production). The console offering is so comprehensive that can satisfy the needs of a huge company, such as Facebook. Therefore, if you have a smaller app you might choose not to utilize some release channels but it's good to know all the capabilities available.

![Google Play Console: Publishing](https://www.rockandnull.com/content/images/2022/09/image.png)
_The core pages related to publishing an app in the console_

### Production

The general availability channel. When an AAB/APK is in this channel means it can be downloaded by anyone on the Play Store.

One super useful thing is the graphs in the "Release stability" tab. These show an overview of how the latest release is going. Any crashes, reviews, and any other useful metrics are shown here. This is especially useful when doing staged roll-outs and you want to decide whether to increase the rollout percentage or halt the release. In theory, this tab will give you an answer. Just see the stats and if everything looks ok, proceed with the increase.

Please note that depending on the install base, any issues with a new version might not appear overnight. For instance, if you have a few hundred active devices, and you roll out to 10% then you will need to wait several days before making an assessment. The rollout percentage indicates the install base of the new version that will eventually be accomplished. But this takes time since devices are auto-updated only under specific circumstances (e.g. on power, on wi-fi, etc).

### Open testing

![Google Play Console: Publishing](https://www.rockandnull.com/content/images/2022/10/Screenshot_20221001_133604_Google-Play-Store.jpg)
_Play Store prompt for users to join the open testing channel_

This is the channel that will reach any user who has signed up for the "beta" call you can see in the Play Store screenshot above. As soon as you activate this channel, this prompt will appear in Play Store.

This is extremely useful since you can reach your most "adventurous" users who are willing to test any new less stable versions and give you feedback. Since they have explicitly signed up for this you don't need to worry (that much) an unstable version will reach this user segment.

Nevertheless, you should still do your best to ship as stable versions as you can (i.e. automated tests, manual QA, etc) since these are public users. When they are in this channel any reviews they leave will not be public, but still, an unhappy user is not something you want.

### Closed testing

In contrast to the previous testing track, you will have to manually do the recruitment for testers in the closed testing. Another difference from the previous testing track option is that you can have multiple closed testing tracks.

This feature is mostly useful for bigger companies who have multiple private tester groups and they are using a more comprehensive testing procedure (e.g. EAP programs, QA groups, etc).

To add users to one of the closed testing tracks you have to either add them manually from the console or share with them a specific link to join the track. Either way, it's your responsibility as a developer to recruit and maintain the testers in these tracks.

As a bonus, don't forget that every time you publish an AAB/APK to a test track, you'll automatically receive a pre-launch report that can identify some issues/crashes. If you want, you can combine this with a staged rollout to this track, and if everything is OK with the report, you can proceed to the full rollout in the testing track.

### Internal testing

You know how you publish an APK/AAB and you need to wait some hours/days until it's approved for users to download? Well, this is the testing track that avoids almost all of those approval checks.

As soon as you release something on this track, it becomes almost immediately available to the testers. Similarly to the previous testing track you need to explicitly select the testers of this tack. Usually, these are the development team, the QA team, and any other trusted user. Since almost no check is performed for this track, there's a maximum number of 100 invited testers, which is more than enough for most development teams. This is the ideal track to integrate with a CI/CD system using the Publishing API.

### One more thing: Internal app sharing

Even though this is not included in the "Release" section of the Play Console navigation bar, this is still a publishing-related feature.

This is more for ad-hoc sharing with testers. For instance, you have to build a version of your app that you want a specific user to test who might not be a tester in one of the tracks we discussed earlier. In the APK world, you would just send them the APK to side-load. But in the AAB world, the exact APK for the user will be generated by Play Store depending on the user configuration.

This is where internal app sharing comes in. You can upload an AAB here, share the link with the user, and they will download the exact APK for their configuration. No need to set up tracks or add the tester. Also, note that you can specify which users are allowed to generate these internal app sharing links so they don't even have to have access to the developer account.

This post was a bit longer than I expected but shows how many publishing capabilities Play Console has. Hopefully, you learned something new or at least cleared some things up that you were confused about.

Happy publishing!