31. Testing and Publishing

Written by Fuad Kamal

In this chapter, you’ll complete the app publishing process and discover additional ways to distribute your app. You’ll also go through the Alpha and Beta testing process to make sure your app is ready to share with the world.

Note: You don’t have to release your app through Alpha and Beta channels. You’re free to take your initial release straight to production!

Release types

Google provides three different release types: Alpha, Beta and Production.

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

Time to dive into the details of each release type as well as open vs. closed testing.

Alpha release

You’ll start by creating an Alpha release. This release is typically done with a small group of internal testers. An Alpha release may not be stable yet, but it still needs to be tested in release mode on real devices.

Bring up the main Google Play console website and follow these steps:

1. Click on the name of your app in the list of apps to go to the dashboard view for that app. On the left side of the page click App releases. If this is not a brand new app, App releases may be under Release Management. The list of Production, Beta and Alpha release types are shown.

   

2. Under Alpha, click MANAGE.

   This is where you can create a new Alpha release, upload the APK and manage the testers.

   

3. Click CREATE RELEASE.

   At this point, if you don’t already have it set up, you’ll be given an option to start using Google Play App Signing. For more information about app signing, refer to the previous chapter, “Preparing for Release”.

   When using Google Play App Signing, your app gets signed locally with an upload key. After you upload the app, Google replaces the upload key with the actual app signing key. The upload key’s only purpose is to authenticate you as the developer.

   The advantage to using Google Play App Signing is that even if you lose your upload key, or it’s stolen, you can request that Google revoke the key, and then you can generate a new one. This puts the burden on Google to securely maintain your app signing key.

   Using Google Play App Signing during this phase makes it much easier than turning it on later. Google automatically generates an app signing key and stores it; all you have to do is upload the App Bundle you already signed. The key you generated earlier becomes your upload key. If you decide to enable Google Play App Signing later, you’ll have to go through several more steps to make the switch.

   Note: If you click CONTINUE to opt-in, you’ll be permanently enrolled in Google App Play Signing for this app.

4. Click CONTINUE if you’d like to enroll in Google Play App Signing, and ACCEPT the terms of service.

   Google generates an app signing key and shows that Google Play App Signing is enabled.

5. Click BROWSE FILES and select your signed release App Bundle or APK file.

6. This shows the versionCode for the app, taken from the setting in the app gradle file, and the type of file. End users won’t see this code. In this example, you uploaded an App Bundle, so that is shown under the type. You can also specify a Release name so it’s easier to identify in the play console. By default, it’s the same as the versionName in the app gradle file.

7. Enter the release notes for this version. Make sure to place the notes within the language tags as shown in the template.

8. Click SAVE. Google validates what you’ve entered and then enables the REVIEW button.

9. Click REVIEW. This shows a summary of the release and a warning that you need to add users before you can roll it out.

   

10. Click the back arrow to go back to the main Alpha release screen.

    

You’ll see the Manage testers section at the top.

11. Select either Closed Alpha Testing or Alpha Testing using Google Groups testing method.

Closed: Only allow a specific list of email accounts to access the release. It will not show up in searches of the Play Store.

Google Groups: Allow anyone within a Google Group to access the release. It also will not show up in searches of the Play Store.

If you select the Closed method, you’ll need to supply a list of users and email addresses. You can also provide a feedback page URL.

If you select the Google Groups method, you’ll need to supply the Google Group email address.

12. Fill in the required fields and click SAVE.

    If everything checks out, the App releases row on the left shows a green check.

    

Determining the content rating

Google provides a questionnaire that you must complete to determine your app rating. Click Content rating on the left, and click CONTINUE to start the survey.

You’re required to provide an email address for the International Age Rating Coalition (IARC). This can be the same as your primary Play Store email.

Next, select from one of the primary categories:

• Reference, News, Or Educational
• Social Networking, Forums, Blogs, And UGC Sharing
• Content Aggregators, Consumer Stores, Or Commercial Streaming Services
• Game
• Entertainment
• Utility, Productivity, Communication, Or Other

Next, you’ll walk through a series of Yes/No questions.

Click the Learn More link for questions you’re not sure about.

After answering all of the questions, click SAVE QUESTIONNAIRE and then CALCULATE RATING.

The calculated rating is shown for different countries and regions in the world. Here’s the rating for the PodPlay app after selecting “No” to all questions.

Click APPLY RATING to apply the rating to the store listing.

The Content Rating section on the left shows a green checkmark.

Pricing and distribution

You also need to provide pricing information and specify where your app will be distributed.

Click the Pricing & Distribution link.

You need to decide if you want your app to be Free or Paid. Once you mark it as “Free” and publish, you won’t be able to change it to a paid app later. If you plan on charging for the app, you’ll need to set up a Google merchant account first.

The details for that won’t be covered here, but setting up a merchant account involves filling out details about your business, and providing Google with a bank account in which to deposit payments.

Next, determine the countries in which you want to make the app available. You can enable individual countries, or you can allow them all by selecting the toggle at the top of the list. The next screenshot shows that PodPlay is available in 144 countries after making them all available.

There are several items required on this page:

• Contains ads: If this is set on, users will see a Contains ads label on the application.
• Content guidelines: You must agree to follow the Android Content Guidelines.
• US export laws: You must agree to comply with US export laws.

Several more optional items are shown on the page. You can read through these items to see if any of them apply to your app.

Click SAVE DRAFT. If you’ve completed everything, the Pricing & Distribution section shows a green checkmark.

If you followed along and completed the Store listing section in the previous chapter, now only App content will have a grayed out checkmark in the menu on the left.

App content

Click on App content in the menu. Google has now separated the Designed for Families program into its own section. In the App content section you let Google know the target audience of your app, and information about its contents. Click on the Start button to begin the content survey.

The survey consists of six parts:

1. Target age
2. App details
3. Ads
4. Store presence
5. Summary

Complete the survey. Now, all the checkmarks in the menu on the left should appear green.

Click on Dashboard in the side menu to return to the dashboard for your app. The top of the page now indicates that your app is “Ready to publish”.

You’re ready to roll out the Alpha release to your testers.

1. Click the App releases link on the left.

2. Click the EDIT RELEASE button under the Alpha release section.

   

3. Click the REVIEW button at the bottom of the page. This displays a summary of the release and waits for you to confirm the rollout.

   

4. Click the START ROLLOUT TO ALPHA button at the bottom of the page if everything looks good.

5. Click CONFIRM in the popup dialog.

   

And that’s it. Congratulations on publishing your first app to the Play Store!

You may notice that the top of the screen in the App Dashboard shows a status of Pending publication.

This is a temporary state while Google does all of the processing required to generate the Play Store listing. Take this opportunity to reward yourself with a break, and check back in on the progress in about 30 minutes.

Even before the app is fully published, you can start exploring the new options that are now available for the application.

You have access to a Dashboard with a variety of device install information, a detailed statistics page, the Android vitals page with access to crash reports, User acquisition, User feedback sections and more.

Take a few minutes to dive into the different sections of the console and see what information is provided.

There’s also a Pre-launch report that can provide valuable information about how your app is performing on real devices. On this page, you can see screenshots of your app running on a large variety of devices, security scan results and performance and crash reports.

The Pre-launch section can provide valuable insights into how your app runs on actual hardware devices even before testers have downloaded it.

Once the app status changes to Published, which you’ll see at the top of the page, head back to the App releases page and click MANAGE ALPHA.

You’ll notice a few new options on the page now. There’s a Rollout history that shows how long ago the app was rolled out. There are also buttons that let you quickly release this version to production.

Expand the Manage testers section to view the new Opt-in URL. You can send this URL to your testers. Google won’t send emails to your testers for you; you must notify them when the release is ready and include the Opt-in URL.

When a tester brings up the Opt-in URL, they’ll see a message like the following:

Once the user clicks BECOME A TESTER, they’ll get a confirmation screen with a link to the Google Play store listing.

When they visit the store link from a desktop computer, the final listing will look like this:

Here’s the final listing at the Play store on a device:

This looks like any other Play store listing; the only difference is that you have control over who can install the app.

Version codes

Before moving on to Beta testing, let’s take a quick look at how to use Version codes through the different release phases. Typically, you want your Alpha release to have the highest version code since it should be testing the most recent changes. Your Beta release will have the next highest version code, and Production will have the lowest version code.

If an Alpha tester is a member of the Alpha and Beta test groups, and you upload a Beta with a higher version code than the Alpha, the tester gets updated to the Beta version.

Note that some users may be in the Alpha group only, Beta group only or in both groups of testers.

Here’s a typical lifecycle an app might follow through the first few releases.

1. Release Version 1 to Alpha.
2. Alpha testers install Version 1 and complete testing.
3. Promote Version 1 to Beta.
4. Beta testers install Version 1 and find some issues.
5. Address issues in Version 2.
6. Release Version 2 to Alpha.
7. Beta only testers continue with Version 1. Alpha testers update to Version 2.
8. Version 2 testing is complete.
9. Promote Version 2 to Beta. Beta testers update to version 2.
10. Release Version 2 to Production, which means users can download it from the Play Store.
11. Release Version 3 to Alpha.
12. Alpha testers update to Version 3. Beta only testers and the general public remain on version 2.

Beta release

Use the Beta option for publishing to select users that may not be internal to your organization, or run an Open Beta that lets anyone on the Play Store sign up for Beta testing.

Once you’re satisfied with Alpha testing, it’s a simple step to move to the Beta phase.

Note: You can create multiple “closed tracks” beyond the Alpha track. For example, if you wanted to roll out a test feature to a select group of testers, separate from the Alpha group, you would click the “Create Closed Track” link and go through the same process as with the Alpha track. Beta test groups are always an “Open Track”.

Go to the App releases ▸ Beta and click Manage.

This takes you to the release screen for Beta where you can create a release, manage testers, add release notes and select countries similar to the Alpha process you went through earlier. However note that now under “Manage Testers” there is only one option for “Choose a testing method”, which is open beta testing.

Once you have set the testing method to open beta testing, click the Create Release button to go to the beta release preparation page. Enter a name for the beta under Release Name.

If you had a new App Bundle or APK you wanted to use for this beta, you could upload it in the Android App Bundles and APKs to add section using the browse files button. However, if you wanted to use the same build you are already using, for example from an Alpha release, you can instead choose an existing build using the ADD FROM LIBRARY button.

Click this button now and choose the build you previously used to set up the Alpha release.

Click the Add button to add the build to the beta release. Update the release notes and click the Save button. Click the REVIEW button.

Click START ROLLOUT.

After the rollout to Beta is complete, the App release overview page shows the new Beta release.

If you go to manage the existing Alpha release now, you will see there is a new button there now, Release to Beta, which lets you directly promote an existing Alpha release to the Beta track.

Production release

Once the Alpha and Beta testing are complete, you’re ready for the final release to Production! This is as simple as promoting the final Beta version to Production.

Go to the App releases ▸ MANAGE BETA section and click RELEASE TO PRODUCTION.

This creates a release in Production and displays the release screen to verify the details. Just like the Alpha and Beta release, you need to review the release information before it’s published to the Play Store.

When you are ready, click REVIEW. If everything checks out, the START ROLLOUT TO PRODUCTION button is displayed.

For first-time app publishers, this can be both an exciting and stress-inducing moment. The app you’ve worked so hard on will finally be available for the public to enjoy.

Don’t be nervous, go ahead and click START ROLLOUT TO PRODUCTION.

Pay attention to any warnings that may crop up. If everything looks good, click CONFIRM.

Within a short amount of time, your app will be live in the Play Store. Go ahead and celebrate. Throw a launch party and spread the news about your first published app.

But don’t party too long, because you’re not done yet. Just like a newborn child, your production app can’t be left on its own. It needs some loving care and attention to thrive!

Post-production

Here are some final tips to help keep your app in top shape.

• Review your app stats on a regular basis. The Play Console provides a wealth of information about the number and types of installs, number and frequency of crashes and overall ratings. Look for spikes or drops in any these categories to stay on top of changes. Don’t assume items will fix themselves; be proactive and address issues as soon as they appear.

• Check reviews and look for problem trends. It’s inevitable that even the best-made apps will get some negative reviews. Look for common threads in the reviews. If a large number of users are all complaining about the same thing, that’s an excellent hint to focus on that issue. Positive reviews can also provide valuable feedback about what you’re doing right and help drive future product development. You can also respond to user reviews using the Google Play Developer Reply to Reviews API (https://developers.google.com/android-publisher/reply-to-reviews) or in the Google Play Console.

• Be aware of new Android releases. In some cases, a new Android OS release can impact how your existing app performs. Make sure to keep up with beta releases of the Android OS, and make sure your app performs as expected before the OS is released to the public.

• List well-known issues. If you have issues that are known and can’t be fixed quickly, consider mentioning them in the Play store description along with a workaround if possible. It’s better if users know about these before being surprised after they download the app.

• Consider using staged rollouts. Google has built-in support for staged rollouts only for app updates, not on the initial release. When using staged rollouts, you specify the percentage of users that will be updated to the new release. You can also limit the update to specific countries. For the first release, you might consider rolling out to a single, smaller country, before targeting your primary countries.

Other publishing methods

In some cases, you may need to distribute an app without going through the Play Store. It might be an enterprise app that will never go public, or it might be a side project that you’re distributing to friends and family.

There are a few ways to distribute an app directly.

Email distribution

Email requires the least amount of work on your part. All you do is attach the APK file to an email, and have your users open the email on a compatible Android device.

Users will need to configure their device to allow “unknown sources” before the APK can be installed. It’s a good idea to include instructions in the email when sending out the APK.

If a user is running Android 8.0 or newer, they should look for the Install unknown apps section in the device settings.

If a user is running a version before Android 8.0, they should enable Unknown sources in the Security section of the device settings.

When the user opens an email with an APK attached, they can download the APK.

The user will then find the APK in their downloads app or by pulling down the notifications view. When they tap on the APK file, they’ll be prompted to install the app.

Website distribution

Another option is to host the APK file on your website. You can either send a link to the download location or point the users to the download page on your site. Whether the user taps on the link from an email or the browser on the device, they’ll be prompted to install the APK.

As with email distribution, the device must be configured to allow unknown sources.

Other app stores

There are some other app stores available for publishing your app; you should take time to explore which options are available. One of the most well-known stores is the Amazon Appstore. Amazon’s Appstore is installed by default on Amazon devices such as the Fire TV and Fire Tablet. It contains apps made especially for the Amazon products as well as many apps that can also be found in the Google Play store. There is no registration fee for developers on the Amazon Appstore, and it also offers some unique monetization models.

There are some fundamental differences between Google and Amazon in the way apps are purchased and how in-app billing is handled. However, in both cases, you’ll get 70% of the app earnings.

One big difference is that you can’t switch a free app on Google Play to a paid one. That decision must be made during the initial rollout. Amazon lets you start your app as free and change to paid at any time. The Amazon App store process is a bit more involved and requires you to wrap your APK in their code.

You can always start by releasing to the Google Play store and then decide later if you also want to distribute the app to other app stores.