How to Prepare Your Android App Code for Publishing in the Google Play Store - dummies

How to Prepare Your Android App Code for Publishing in the Google Play Store

By Barry Burd

At this point, you’re probably tired of looking at your own app. You’ve written the basic Android app, tested the app, fixed the bugs, tested again, added features, done more testing, stayed up late at night, and done even more testing. But if you plan to publish you’re app, here’s one piece of advice: After you’ve finished testing, test some more.

Ask yourself what sequences of buttons you avoided clicking when you did your “thorough” testing. Then muster the courage to click the buttons and use the widgets in those strange sequences. And while you’re at it, tilt the device sideways, turn the device upside down, hold the device above your head, and try using the app. If your device is a phone, interrupt the app with an incoming call.

Are you finished testing? Not yet. Have your friends test the app on their devices. Whatever you do, don’t give them any instructions other than the instructions you intend to publish. Better yet, don’t even give them the instructions that you intend to publish. (Some users won’t read those instructions anyway.) Ask your friends about their experiences running your app. If you sense that your friends are being too polite, press them for more details.

Un-testing the app

When you test an app, you find features that don’t quite work. You check the logs, and you probably add code to help you diagnose problems. As you prepare to publish your app, remove any unnecessary diagnostic code, remove extra logging statements, and remove any other code whose purpose is to benefit the developer rather than the user.

In developing your app, you might have created some test data. (Is there a duck named “Donald” in your app’s contact list?) If you’ve created test data, delete the data from your app.

Check your project’s AndroidManifest.xml file. If the <application> element has an android:debuggable=true attribute, remove that attribute. (The attribute’s default value is false.)

Choosing Android versions

When you create a new project, Android Studio asks you for a Minimum SDK version. Your project’s build.gradle file keeps a record of your choice in its minSdkVersion field. You can change this number by editing the build.gradle file.

This minSdkVersion number is important because it shouldn’t be too low or too high.

  • If the minSdkVersion number is too low, your app isn’t using features from newer Android versions.

    If your app is very simple, this is okay. But if your app does anything that looks different in newer Android versions, your app’s vintage look might turn users off.

  • If the minSdkVersion number is too high, the Play Store won’t offer your app to users with older devices.

    In fact, if your app’s minSdkVersion is 21, a user who visits the Play Store on a KitKat device doesn’t even see your app. (You might have already encountered the INSTALL_FAILED_OLDER_SDK error message. Android Studio can’t install an app on the emulator that you selected because the emulator’s SDK version is lower than the app’s minSdkVersion.)

    You don’t want to eliminate users simply because they don’t have the latest and greatest Android devices. So to reach more users, keep the minSdkVersion from being too high. If your app doesn’t use any features that were introduced after API Level 11, set your minSdkLevel to 11.

Try running your app on emulators with many API levels. When you run into trouble (say, on an emulator with API level 10) set your project’s minSdkLevel to something higher than that troublesome level.

When you create a new project, the Target Android Devices dialog box contains a Help Me Choose link. When you click this link, you see a chart showing the percentage of devices running Lollipop, KitKat, Jelly Bean, and other Android versions. This clickable chart describes the features in each Android version and (most importantly) shows the percentage of devices that are running each version. With information from this chart, you can choose the best compromise between the latest features and the widest user audience.

Android’s support libraries allow devices with older Android versions to take advantage of newer Android features.

Setting your app’s own version code and version name

When you create a new project, Android Studio puts some default attributes in your build.gradle file. These attributes include the versionCode and versionName fields:

defaultConfig {
versionCode 1
versionName “1.0”

The version code must be an integer, and your app’s code numbers must increase over time. For example, if your first published version has version code 42, your second published version must have a version code higher than 42.

Users never see the version code. Instead, users see your app’s version name. You can use any string for your app’s version name. Many developers use the major-release.minor-release.point system. For example, a typical version name might be 1.2.2. But there are no restrictions. Android has all the dessert names, and Apple used to use jungle-cat names, so you can add something like

versionName “sea squirt”

to my build.gradle file. (Look it up!)

If you intend to publish on the Amazon Appstore, don’t use phrases like sea squirt for your versionName. The Amazon Appstore insists on a versionName of up to five integers separated from one another by dots. For example, versionName values such as 2.30 and work just fine.

Choosing a package name

Every Android app has its own package name. So, if your first published app is in the com.example.earnmeamillion package, put your second app in a com.example.secondtimeisacharm package.

Your package name should help to identify you or your company. If you have a domain name, start the package name with the domain name’s parts reversed!