Chapters

Hide chapters

Android Apprentice

Fourth Edition · Android 11 · Kotlin 1.4 · Android Studio 4.1

Section II: Building a List App

Section 2: 7 chapters
Show chapters Hide chapters

Section III: Creating Map-Based Apps

Section 3: 7 chapters
Show chapters Hide chapters

31. Testing & Publishing
Written by Fuad Kamal

Play Console overview

Developing and publishing your app is just the beginning. In 2020, Google launched a completely revised Play Console for better managing and deploying apps. The new Play Console introduced a major UX facelift, improved team management, a modern interface using Google Material design language, and a new menu structure.

The Play Console is grouped into several main areas by function: Release, Grow, Quality, Monetize and Policy. In this chapter, you’ll get an overview of the entire Play Console. You’ll deep dive into some of these sections in order to get your app published and distributed.

Google Play Console gives you the power to scale with access to billions of users. It also gives you the tools to acquire them, like the ability to test the text and graphics of your store listing to drive more installs.

The Play Console gives you the power to iterate. Testing tools and pre-launch reports help you identify issues before they affect your users so you can release with confidence. It lets your users beta test new features and then roll them out in stages to ensure a safe launch.

The Play Console provides insights about your app, such as metrics, and what your users are saying through reviews and ratings.

Grow

Grow contains everything you need to supercharge your user acquisitions, from pre-registration to store listing experiments. It also features acquisition reporting.

Quality

Google designed the Quality section for QAs and team leads. It contains all the signals and features that tell you how your app performs in the wild, including both its technical performance with Android vitals and how people feel about it through ratings and reviews.

Monetize

Monetize brings together Play Console setup, reporting, and optimization tools to help you grow your business through in-app purchases and subscriptions.

Policy

Policy helps you release confidently on Google Play. The reasons you provide for various app permissions matter and Google has become increasingly strict about Policy reviews. For more information about Google Policy, see https://play.google.com/console/about/policystatus/.

Creating your Google Play Store listing

In the previous chapter, you created a release APK suitable for distribution. Now it’s time to review the steps to create a Google Play Store listing so you can distribute your app.

Google Play Console signup

First, sign up for a Google Play Console account. The Google Play Console is your gateway to managing and publishing your apps on the Google Play Store.

Go here to sign up for a new Google Play Console account or sign in if you already have one:

https://play.google.com/apps/publish/

First, verify that you’re signed in with the correct account. Read and agree to the developer agreement. Then click CONTINUE TO PAYMENT. The current one-time registration fee is $25.

After you finish paying, you’ll go to the Developer Profile screen. Make sure you pick a good Developer name as it’s shown in the Play Store below the name of your app.

The main console

Once you finish with signup, you’ll move to the main console.

In the menu on the left, you have several options:

  • All apps is where you add new apps or manage existing ones.
  • Inbox is where you’ll find messages from Google Play.
  • Users and permissions is where you can add additional users to your account and manage what those users can do and see under your account.
  • Order Management lets you manage orders, including giving refunds, for paid apps or in-app purchases.
  • Download Reports provides various reports, including crashes, reviews, statistics, user acquisition, and financial records.

And finally, Settings provides several sub-sections:

  • Developer account: you can manage profile settings, control API access, and set up payment options. In this section, you’ll find Developer page, where you can configure how your developer page looks in the Play Store. Your developer page won’t be available until you publish your first app.

  • Preferences: this is where you set notification preferences and control privacy settings.

  • Email lists: you can manage alpha and beta testers from this section. Note that you can only use Gmail addresses for your tester distribution lists.

  • License testing is where you test your licensing and in-app billing integrations. You can set up testers to make in-app purchases without getting charged anything.

  • Manage game projects provides additional features for games. You can find more info here: https://developers.google.com/games/services/.

  • Pricing templates: you can use pricing templates to set up or manage the same set of prices for multiple paid apps and in-app products.

Creating your first app

Click Create app on the main console screen.

In the future, when you have other published apps, you’ll use the Create app button at the top of your list of apps instead:

Fill out the Create app form:

  1. First, fill in the title of your app.

  2. Then choose the default language for your app.

  3. Select whether it’s an app or a game.

  4. Then select whether your app is paid or free. If you choose free, you can only change this up until the app publishes. After that, free apps can never convert to paid apps.

  5. Check the legal declarations.

  6. Finally, click Create app.

After that, you return to the dashboard page. You’re not quite done yet. You still need to fill out a bunch of information about your app and upload the app bundle you created earlier. But now the dashboard presents a wizard listing the remaining steps and what you need to do:

It might seem like a lot of steps, but it’s not too bad. Fill out all the required information under the First steps task.

As you finish each section, a checkmark appears next to that section to show it’s complete:

You can’t skip this step. The Release your app task has a lock icon, and you can’t access it until you complete this.

Note: At this point, you’re only preparing the store listing and creating a draft version of the app. You won’t publish anything until you complete the Release your app step.

Go back to the All apps section and see your new app listed there with App status set to draft:

Click your app’s name to go back to the dashboard and setup steps. The majority of the steps gather information so the Play Store can categorize your app properly. However, the final step, Set up your store listing, asks you to upload some graphic assets. Setting up your store listing is critical since it defines how potential users find and perceive your app.

Main store listing

Click Set up your store listing to view the sub-tasks there. App name is already complete. Fill out the short and full description fields.

Store graphic assets

Your app needs the following graphic assets:

  • App icon: this icon only shows up in the Play Store. Your app’s launcher icon still shows on the user’s device. https://applypixels.com is an excellent resource for easily creating app icons and other assets required by the Play Store.

  • Featured graphic: you’ll find the featured graphic at the top of your app listing.

  • Screenshots: you’re required to upload at least two screenshots, although you can have up to eight per device type. You can upload portrait or landscape orientation screenshots.

Note: You can create screenshots from the emulator using the camera icon on the emulator toolbar.

For specifics on the image dimensions and more, see the descriptions in the Play Store Console.

  • Video: while not required, it’s highly recommended you provide a video demo of your app. A video is a great way to capture potential users’ attention.

Once you complete the First Steps section, your app title and icon will appear on the dashboard. The Release your app section is now unlocked.

Release

Release collects all Google’s tools to upload and distribute your apps, review your testing and production tracks and check how your latest updates perform.

Releases overview

The Releases overview shows you an up-to-date snapshot of your testing and production tracks to quickly see which versions are being tested, by how many users and in which countries.

Private vs public apps

There are two main types of mobile apps, regardless of the platform. The most common type is public apps, which are generally available to everyone. Developers typically distribute these through an app store, such as Google Play or Amazon Appstore.

The other type of apps are private apps. These are also known as enterprise apps or Enterprise Mobility Managed (EMM). While this chapter focuses on public apps, everything you learn here is also applicable to EMM.

If Google is your EMM provider, you can use the Play Console to manage both your EMM apps as well.

Test tracks

Before you publish your app to the world, it’s important to test it with a small group of users. Testing not only catches bugs but also helps with scaling and rolling out updates faster.

The key is to distribute a test version of your app to a small group of trusted users. This group could be your wider team, product managers, a QA team, or whoever can give you early feedback.

You could directly email or otherwise share an APK with the testers, but that can be cumbersome and places an undue burden on them. Also, you lose the benefits of using an app bundle: APKs need to be universal for all the supported devices. Therefore, the installation package is much larger than if the users receive only the files they need for their particular installation through an app bundle on the Play Console.

A track is a way to define a group of users to whom you can publish your app. Google provides three different tracks: Internal, Closed and Open. Additionally, Google designates two release types: Alpha and Beta. The Closed track only has the Alpha release type while the Open test track only has the Beta release type.

The Alpha and Beta release types provide an excellent way to get feedback to make sure your final release is as polished and stable as possible. The only requirement for testers is a physical Android device and a Gmail, G Suite, or Google account.

Alpha and Beta release types are designed for testing at scale, with potentially millions of users. Because of this, they’re also a bit more involved and tedious to deploy.

For fast iterative testing, Google introduced the Internal test track.

Internal test track

The Internal test track is for direct distribution to your quality assurance (QA) team. Deployment is much faster than the other tracks. The first time you deploy, it may take up to 48 hours. However, after that, your builds will be available to your testers within a few minutes.

With the Internal test track, you can have up to 100 testers, which you organize by email address. There are no country limitations for distribution. While they can install paid apps for free, testers still must pay for in-app purchases unless you add them to a license testers list. Any device exclusion rules you define for your app won’t apply to internal testers.

Testers don’t need a special app or permissions to install your test builds with the internal test track. All they need is a link, which you’ll find in the Play Console’s App bundle explorer.

The updates for internal testers are also different than they are for Alpha and Beta testers. Users can be either alpha/ beta testers or internal testers. They must opt out of one option to join the other.

The internal test track is great for quick iteration during development, catching bugs early, getting fast feedback from your team, and testing Play integration. Because your app is still published through Play, it supports all the Play features: in-app purchases, the Android app bundle, and dynamic developer features.

Releasing your app

Now that you are familiar with the different release types, it’s time to release your app! You’ll create an internal release. Click Select testers to go to the Internal testing page. For now, create a quick email list in this section with a list of testers who will test your first app release. If you don’t have any testers, list your email address so you can deploy builds to your device through the Play Store. You also have the option to provide a feedback URL or email address for testers to provide feedback.

Once you create one or more test group email lists, select one and click Save changes on the bottom right.

Finally, click Create new release in the upper right corner. You’ll go to the page where you upload your app bundle and make the app available to testers.

You’ll see a note reminding you Google will manage the signing key for you. Click Continue. Then drag and drop app-release.aab, the app bundle you created earlier, onto the section titled App bundles and APKs to upload your release.

When your app bundle uploads successfully, you’ll see it listed beneath the upload section with details about the build:

Next, provide a name for the release under Release details. If you haven’t already thought about a release naming strategy, now would be a good time to do so. You want to be able to distinguish each release to avoid confusion and address bugs as they appear.

Finally, fill out the release notes section and click Save. Then click Review release at the bottom.

If there are any issues with your release, they’ll appear on the next screen. You can Edit release to address them.

If you have no errors, click Start rollout to internal testing at the bottom of the screen. You’ll see a confirmation dialog. Click Rollout to release your app.

Congratulations! You’ve released your app to the Google Play Store!

Note: It may take a little time for your app to appear published on the Google Play Console. You also might need to refresh the Google Play Console page to see the publication status update. If you included your own Gmail address in the selected tester list, you can search for and install your app using the Google Play app on your Android device.

Once your release shows as published, click Testing -> Internal testing in the Google Play Console to see the release under the Releases tab.

Click the Testers tab. You’ll also see a Copy link button at the bottom. You can use it to get a URL that you can share with your testers to install the app.

Exploring the internal test track

Go to the Play Console and select All apps from the menu. You’ll see a list of apps under a title heading, which includes the number of apps you currently have in the Play Console.

You may have only one app at this time, but as the number of apps in your Play Console grows, you can highlight the most important ones by pinning them. Click the pin icon in your app listing to add it to the Pinned apps list:

When you have multiple pinned apps, you can drag and drop them to arrange their order. You can see summary KPIs for pinned apps without going into the dashboard for each app.

Click View app to go to the dashboard for your app. Then click App bundle explorer from the Play Console menu on the left to go into the App bundle explorer.

In the App bundle explorer, you can see all the deployment details for your current app bundle. Spend some time exploring and become familiar with all the information here. Some things of particular note are:

  • The permissions that your app lists in its manifest.
  • Which API levels your app is compatible with.
  • The number of Android devices, specifically which devices your app should work on.
  • How many active releases you have.
  • Which types of releases you have.

You can also see the size of the download for your users to install the app.

Next, click the Downloads tab in the App bundle explorer. Here you’ll again find the link you can share with your testers to install the internal test build.

Installing an internal test track build

So you’ve deployed your build to the internal test track and you sent out the shareable link to your testers. You check with your testers to see how it’s going, only to find out they weren’t able to install it.

Some of them say they got a 404 Error when they clicked the link. Others say when they click the link on their device, they get a popup message that says Internal app sharing is turned off…. What have you done wrong?

Actually, you haven’t done anything wrong. It turns out there are some extra steps your testers need to take to install builds from the internal test track.

First, if you restricted the testers to only people on your selected email lists, they must sign in to their Google account with the respective email address on the device on which they are trying to install the build. If they aren’t signed in with the correct email address, they may get a 404 server error on their web browser when they tap the install link.

Alternatively, you can open up testing to anyone who has the link. You can check this in the Play Console under Release -> Setup -> Internal app sharing.

Second, the testers need to perform a bit of magic, similar to what developers do before they can debug on a device. That’s why they got the popup message.

In the Google Play app, the tester should click the menu in the navigation drawer, then Settings.

Then they should Enable Developer Options. This is similar to enabling Developer Options within the Android Settings app.

Tap seven times on the Play Store Version.

Once they get the You are now a developer! prompt, they’ll see the Internal App Sharing option pop up on their device. Enabling internal app sharing will display a warning regarding the internal test nature of the apps they can now download.

Once they’ve enabled internal app sharing they can click the download link again and see your internal test build available to install.

One last, slightly confusing trick

In the Play Console menu, navigate to Release-> Setup -> Internal app sharing. Here you will find a page dedicated to letting you share your app bundle with testers simply using a link. Or, so it would seem. :]

If you click the link on this page, it takes you to another page where you can upload an APK or app bundle. The uploaded app bundle then has a “copy link” icon which you can provide to your testers to download the app.

Indeed, testers can use this link to download your app, but it’s not exactly a direct download. Rather, it takes them to the Play Store on their device and they can install it from there. How is this “internal app sharing” different from the internal testing track? The main difference is, this last type of sharing does not go through any review process at all from Google. You also don’t get many of the benefits of the Play Console test tracks that were described earlier. Why is the name of this feature so close to the internal test track? Why is it tucked away in a strange category like settings? Only Google really knows, but it seems this feature is a holdout from the previous version of Play Console. Keep in mind though, this means it might also disappear at some point, so while it might be convenient for quickly distributing builds, don’t become too heavily dependent on it.

Key Points

In this chapter you covered a lot, but it’s only scratching the surface of Android app distribution. In summary you covered:

  • An overview of the many features offered by the Play Console.
  • How to create a listing for your app, which is required before you can actually upload your app bundle for distribution.
  • The various types of releases and test tracks.
  • How to actually release and distribute your app on the Internal Test track.
  • An alternate, easier method to quickly distribute your app to testers while still using the Play Store.

Where to go from here?

In these last couple of chapters, you’ve learned how to deploy your app to the Play Store. You’ve also gotten a taste for how much more you can do beyond just the initial publication and distribution of your app. To explore these topics and much more in greater depth, check out the Android App Distribution book from raywenderlich.com.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.