Application Deployment - Android Development Patterns: Best Practices for Professional Developers (2016)

Android Development Patterns: Best Practices for Professional Developers (2016)

Chapter 20. Application Deployment

Once you have crafted the perfect app, you will need to deploy it. Application deployment is the final step in releasing your app to users. This generally consists of cleaning your project and creating an Android application package (APK). In this chapter, you learn about how to deploy your app from Android Studio as well as preparing the necessary assets needed for a successful launch in the Google Play Store.

Preparing for Deployment

Many developers only think of deploying as a means of taking code and releasing a package or APK file that can be uploaded to Google Play and distributed through the Google Play Store. Although this is definitely a major path for app release, there are other reasons to create and distribute APK files.

You may want to create an APK for the following:

Image A privateor contract app release

Image App testing with a remote group of users

Image Enterprise app management

Image Distribution in third-party app stores such as Amazon

When you are ready to deploy, you need to create a production build of your app. You should also make sure you have any external resources ready for use. Depending on the complexity and the intended distribution method of your app, this process may require additional setup and finalization before you can create your APK file.

Production Checklist

Creating a checklist for production allows you to quickly and effectively publish your application. This procedure is great to follow, whether you are a single developer or are working with a team where each member can take a portion of the list and complete it.

Not every item will be needed, and some steps may need to be added or expanded depending on your publishing target. For example, if you are building an enterprise app that will be distributed internally without the need to publish it in an app store, you will probably want to skip creating excess application marketing images and videos and a website; you may, however, opt to spend some time on training materials instead.

Regardless of your intended publication route, the following items will get you started in the correct direction.

Certificate Keys

Certificates are used as cryptographic keys that ensure an application is authentic by means of confirming that the publisher is using an authentic version of the app in their store. You are required to generate a pair of keys and sign your app with them. This ensures that you control the updates for the app and that you are the sole publisher to that app.

Keeping your key in a safe and secure location is paramount because you will be unable to update any apps you have created if you happen to lose your key. Keeping it in a secure location prevents anyone else from using your key to forge and force an update to your users.

Note that if you plan on distributing your app in the Google Play Store, your key must expire after October 22, 2033. Any certificates expiring before that date will cause your app to be rejected from being submitted.

When you publish your app, you can opt to either include your own key in the build process or use Android Studio to sign your application. Both have advantages and disadvantages. Adding the key information to your build process may be a good idea if your publishing setup is mostly automated with regular build cycles. Using Android Studio may be better if you work with limited releases or do not have an automated system for building your app.

Contact Email

A contact email is a requirement for publishing an application on the Google Play Store, and is also a good idea to include because users may need to ask you a question, request support, or in some cases need to be walked through using your app to avoid a refund request.

A contact email may be different from a support email, so you may be interested in providing both. If you do not provide a support email, try to return any emails as soon as you get them to avoid negative user experiences and reviews. When providing a support email, it would be good to include an automatic reply that confirms you have received the original email and that it is being assigned to a support team.

App Website

Creating a website for your application is a good idea, not only because you can host your policies, frequently asked questions, and contact information, but because you can leverage search engines to pick up your app and distribute it. Depending on the app you are creating, you can show in-depth videos and other marketing materials. It also gives you the option to cross-sell or up-sell the user on different products or services that work with or in conjunction with your app.

Some of the most successful apps succeed due to offering cross-platform solutions with a website that demonstrates how each piece works seamlessly with others to provide a service that works no matter what device the user has.

The app website can also be another social touch point that can give users more information on sharing your app with their friends as well as any special contests or events that your app may provide.

External Services or Servers

Making sure that your production servers are ready to go on launch day is an important part of the release process. It may not seem like a big deal, but if you (or your marketing team) have done your job building hype for your app, then it can be the make-or-break experience for many of your users. Few things are worse than a rush on launch day and seeing your app servers crash due to demand and then watching the negative reviews pour in and seeing another app welcome these users with open (and working) arms.

External servers may be used for application resource sharing, handling user requests, messaging, and keeping user information. You can mitigate some of the damage by building web applications that scale, but you may also want to take advantage of the on-boarding process that the Google Play Store offers. This allows you to roll out your application slowly, allowing you to keep a watchful eye on your server logs and processes.

Application Icon

Depending on the structure of your development team, you may have opted to start developing immediately with the default launcher icon rather than wait for a finished design icon. This is perfectly fine, but requires that you remember to insert the production icon before you publish your app.

As a reminder, you should provide a launch icon in the following sizes:

Image LDPI: 36×36px

Image MDPI: 48×48px

Image HDPI: 72×72px

Image XHDPI: 96×96px

Image XXHDPI: 144×144px

Image XXXHDPI: 192×192px

Licensing

Some applications require the user to agree to licensing terms in order to use the app. This agreement allows both sides to come to an understanding of the policies and practices that you have in place as a company or provider. This also gives you protection should a user decide to pursue any legal claims that involve your app.

License agreements are usually offered as an End User License Agreement (EULA) when you are accessing, moving, using, or otherwise working with the personal data of a user. Many users are comfortable giving you access to their data provided that you are not doing so maliciously and that your app offers them a useful interface for their data. A EULA must be offered to the user when they first launch your app, and if they refuse the agreement, the app must close.

A EULA is not a requirement; however, some licensing should be offered with your app. This protects your app from being taken and integrated or distributed without your knowledge and potential gain. In the same vein, if you want your app to be taken and used by others, you can offer a license that allows other developers and companies that ability.

The following is a short list of open-source licenses you may want to use if you are open-sourcing your app:

Image MIT: http://www.opensource.org/licenses/mit-license.php

Image GPL 2.0: http://www.gnu.org/licenses/gpl-2.0.html

Image GPL 3.0: http://www.gnu.org/licenses/gpl-3.0.en.html

Image LGPL 3.0: http://www.gnu.org/licenses/lgpl-3.0.html

Image Apache License 2.0: http://www.apache.org/licenses/LICENSE-2.0

Image BSD 3-Clause: http://opensource.org/licenses/BSD-3-Clause

Image Creative Commons: https://creativecommons.org/choose/

Appropriate Package Name

The package name of your app is important for more than just the development of your app. Android uses your package name as an actual location on the filesystem to store data and information relative to your application. It also loads your package name into memory and allocates resources based on your package name. You cannot use a package name that another developer has chosen in order to protect applications from clashing and causing the system to be unstable.

For the previously mentioned reasons, it is a good idea to choose a package name based on your company or website name. Because package names are very similar to domain names, you could use a modified version as your package name. This also gives any users who see your package name a clue as to whom a process or file system record belongs.

As an example, if you owned the website www.dutsonpa.com and wanted to create an Android app called Office Warfare, you might consider a package name of com.dutsonpa.officewarfare. This name describes who created the app and what it is called. Depending on your application deployment strategy, you could even modify it slightly to add version or platform information. For example, if there were multiple platform versions, you mightconsider using com.dutsonpa.android.officewarfare to show what platform this package was specifically built for.

Note that once you publish an app to the Google Play Store, you cannot change the package name. Changing the package name registers an “updated” app as a “new” app instead. This leaves fragmented apps behind and may confuse users who suddenly stop receiving app updates and then notice two apps in the App Store with the same name.

Verifying Permissions and Requirements

Before you send your app into the wild, you should make sure you are sending it out with the correct permissions, hardware requirements, and supported API level.

The permissions your application states before installation are important because some users will refuse to install your app if it even hints at potentially using personal data in a way that they do not understand. Taking a few moments to make sure you know what permissions your app requires can go a long way in making your app successful in the marketplace.

You should take the time to check if you are requiring or restricting your app based on hardware requirements. If you are, then now is an ideal time to double-check that you have all of the permissions you need and have not left any out. Ratings slide quickly when users can see and install your app but watch it constantly close without any explanation.

The minimum API level of your application is important because it dictates which users can install it based on the version of Android on their device. Setting the minimum API level low is good for making sure that the maximum number of users can download your app.However, you need to make sure the features you are using support that API level. This may be done with some clever programming, or by including a support library.

If you are not sure what level you should be targeting, you can view the official dashboard at https://developer.android.com/about/dashboards/index.html. This dashboard lists the current distribution of active Android devices. Note that this list is generated by users who have the Google Play Store installed.

Log and Debug Removal

In Chapter 18, “Optimization,” you learned about memory usage and ways to make your app run in a cleaner and more efficient manner. In continuing the optimization of your application, you should remove all the debugging and logging from your final production application. This saves the Android system from writing out excess logs that will never be read, and it saves on embarrassing notices, toasts, messages, and other forms of debug values appearing inside of the application.

You will want to remove any calls to the Log class as well as remove the android:debuggable property from the <application> element in your application’s manifest XML file. Other debugging methods, such as startMethodTracing() andstopMethodTracing(), should also be removed.

Removal of Excess Unused Assets

It is not uncommon to have extra assets collect in a project over time. These may include assets that were cut during a release cycle, or ones that were used as placeholders until final art or assets could be approved and integrated into the app.

You should do your best to remove any test libraries, frameworks, extra JAR files that are not needed, unused layouts, strings, and other files. Pay special attention to anything in your /res/raw and /assets directories because files stored there may take up large amounts of space. These files may also need to be updated to the latest version and may require you to remove files that will no longer be used.

Because every byte of data matters, it is in your best interest to remove as much excess data as possible before you compile and publish your app. Because the space of a single APK file is limited and a user has to download that entire file before they can use your app, you need to be as thorough as possible in cleaning out your app before publishing.

Preparing for Google Play

When distributing your app through the Google Play Store, you have a few more requirements in order to successfully upload and launch your app. As the Google Play Store has matured, it has provided requirements that it has found increase user adoption and that help you feature and promote your app.

If you have not already created a Developer Account with Google, start by visiting https://play.google.com/apps/publish/signup/ and signing in with your Google Account. After you sign up, you need to accept a distributor agreement and pay a one-time fee of $25.

Once you are a registered developer, you can log into your Google Play Developer Account by visiting https://play.google.com/apps/publish/. After logging in, you can either add a new application or work with existing ones. By using the Add New Application button, you are prompted to name your application and either upload an APK or prepare the store listing of your app. Note that both of these options must be completed before your app will be listed in the Google Play Store.

Application Screenshots

You are allowed to place eight images per form-factor on which your app will run. This means that you can place eight images for the following:

Image Phone

Image Tablet

Image Android TV

Image Android Wear

You must provide at least two images in either JPEG or PNG format without any transparency. Images must have a dimension of 320px and a maximum dimension of 3840px, with the maximum being no larger than twice as long as the minimum dimension. It is best to use images that show the functionality of your app and to use actual screenshots of your app in use rather than just promotion or marketing materials.

Note that if you want your application to be featured in the “Designed for Tablets” section of the Google Play Store, you will need to provide tablet-sized images.

You should also be aware that images for Android TV will only appear in the Google Play Store that is used on Android TV devices and not in the same store that tablets and phones use.

Promo Video

You may consider placing a video for your app that highlights the features and shows the app in action. This may also be a trailer or gameplay video that shows your app off in a produced manner. This way, a user can see what your app is like in actual use without having to download and install it first.

Videos must be hosted on YouTube and must not be restricted by age in order to be viewed. You must also make sure the YouTube link you use for your listing is a direct link to your video and not to a playlist or profile page.

When you use a promotional video, it will be shown on the app page as the first viewable graphic asset. This means that if you have uploaded eight other screenshots, the video will appear before these to encourage users to view the video content.

High-Res Icon

The high-res icon is both similar and different from the launch icon you included in your app. The high-res icon is displayed on the Google Play Store in the cards that display apps as well as on the listing page at the top. Because of this, it should be very close if not identical to the launch icon.

The high-res icon should be a 32-bit PNG (with alpha) sized at 512×512px with a maximum file size of 1MB.

Feature Graphic

The feature graphic is used on the listing page of your app and may be used on other pages or sections of the Google Play Store to highlight and show off your app. This image should highlight the creativity of your app, along with easy-to-read text showing the name of your app.

Note that you should avoid text other than the name of your app, and assets should be centered in the image. You should also avoid adding your launch or high-res icon in the image. This is a promotional standalone image that should complement your other assets rather than repeat them.

If you have added a promotional video to your app listing, then a Play button will be placed in the center of the feature graphic allowing users to view your promotional video when tapped or clicked.

The feature graphic should be either a JPEG or a 24-bit PNG (no transparency) with dimensions of 1024×500px.

Promo Graphic

The promo graphic is no longer a required asset and has been replaced by the feature graphic, which is an image that is used in versions of the Google Play Store or Android Market on devices running on Android earlier than 4.0.

The promo graphic should be treated in the same manner as the feature graphic; however, it does have a smaller dimension. It should be a JPEG or 24-bit PNG (no transparency) with dimensions of 180×120px.

Banner for Android TV

The banner is similar to the high-res icon, only it is displayed on Android TV devices only rather than being displayed on phones and tablets. Even though it is called a banner, it has relatively small dimensions.

The banner image should be a JPEG or 24-bit PNG (no transparency) with dimensions of 320×180px.

Getting Paid

If you are planning on charging for your app, you will need to link your Google Play Developer Account to the Google Payments Merchant Center. The Google Payments Merchant Center is where your business information will be stored and will require your legal business name, address, phone number, and the name that will appear on creditcard statements when a transaction is made.

If you already have a Google Play Developer Account and a Google Payments Merchant Center Account, you can link them together by logging into your Google Play Developer Account and clicking the Reports link and then choosing the Financial Reports option. This displays a message prompting you to set up your merchant account.

APK Generation

APK files are generated when the build process runs on your app. That said, the APK generated is usually signed with a debugging key that renders the APK useful for testing, but not usable for distribution. There are ways to sign an already generated APK, but the easiest way to make sure your application is signed and generated correctly is to use the built-in tooling of Android Studio.

Using Android Studio, the signing and APK generation of your app goes as follows:

1. Open your project in Android Studio.

2. Click the Build menu item and then click Generate Signed APK.

3. In the window that appears, select the app module of your app in the Module Selection box and click Next.

4. Select the keystore (certificate container with an extension of .jks) you want to use to sign the app. If you do not have one, you can generate one at this step by clicking the Create New... button, choosing a secure place to store the generated keystore file, and entering the information requested.

5. After you have either created a keystore or selected one and typed in the required passwords, click the Next button to continue.

6. Choose where to store the generated APK file as well as the “release” for the build type. Note that if you have multiple Gradle build configurations, you will have an option to select the one you want to use. Click the Finish button after you make your selection to start building the APK for your app.

When the process has completed, you can take the generated APK file and upload it to the Google Play Developer Console. If you are not planning on distributing your app through the Google Play Store, you can now use the generated APK file through other means of distribution.

If you plan on giving the APK file to other users, note that they will need to configure their Android device to install from “unknown sources.” This is done through the device settings under Settings, Security. The user sees a message informing them that trusting unknown sources may make their device and personal data vulnerable to attack and that they agree to be solely responsible for any damage, loss, or theft that occurs from installing unknown apps.

After enabling Unknown Sources, the user can select an APK file through a file manager or similar utility and then launch it. Android recognizes the file and prompts the user to install the app, showing them a list of requested permissions and giving them an opportunity to decline the installation. Once approved, the app will be installed and is accessible in the app drawer.

Summary

In this chapter, you learned about the process of publishing an app. This began with a suggested checklist you should look over to make sure you are ready to publish and distribute your app. You learned about the importance of including these items and were given information on why each item on the list should be included or at least considered.

You learned about the assets required by the Google Play Store in order to make your app launch more successful, and even some extra assets such as promotional videos that will help you sell users on trying out and using your app.

Finally, you learned about using Android Studio to generate a signed APK file with a step-by-step guide for either selecting or creating a keystore for signing your app and creating the APK file. You were also informed of the potential problem of distributing your app outside of the Google Play Store and how users will need to enable or “opt into” allowing apps to be installed from unknown sources.