Since we launched, we’ve been seeing an influx of developers submitting their app(s) to the Amazon Appstore for Android – which is great! After apps are submitted, before they can be published in the store, we run the app through technical and content-focused testing. The vast majority of apps pass testing quickly and with no issues…to maximize the chances that your app will similarly move through our validation process quickly, we will be posting some best practices for helping your app fly through testing.
Let’s take a quick look at the most frequent reasons why apps don’t make it through:
Because many developers have their Android apps published in other stores and are simply re-using their existing apk, incorrect linking can be an area of confusion. Apps submitted to the Amazon Appstore must have links pointing to the Amazon Appstore (vs. other Android storefronts). To help your app(s) fly through testing, incorrect linking is an area you can validate and fix quickly before submitting.
Now, how do you ensure your links point to the Amazon Appstore? Easy, just follow these simple rules:
Doing a quick check through your code before you submit your app will ensure you don’t get delayed. In addition, there are a number of ways you can replace the actual String in the URI call so that you can keep one code base and not have to maintain separate code structures for each store you choose to sell your app in.
We hope you keep the scenarios above in mind as you code, and look forward to even more great apps being submitted.
During the process of submitting your app, you are required to submit information that will eventually show up on the site. We wanted to give a little more detail around where all this information actually goes, so we’re going to dive into a real detail page and lay it out for you.
Here’s a look at a real live detail page – this is the detail page for the IMDb app in the Amazon Appstore for Android (don’t get too excited, it’s not live … yet). Why is it called a detail page might you ask? This is the page where customers can get details about your app – hence, detail page. Pretty straightforward, right?
Over the fold there are three primary places you’ll be providing content for.
But wait, there’s more! The scrolling part that you see at the bottom of this screenshot is a slot that is automatically created as purchases of your app pick up. This slot is called “Customers Who Bought This Also Bought” and as the name implies, when appropriate, your app icon, title, rating, and price will show up on other item’s pages if customers bought that item and your app. Even non-app pages! Here’s an example: a customer buys an Android phone and then buys your app (they need to stock their phone, right?). Your app has a good shot of showing up on the bottom of that page to future customers!
Whether you have a bug fix, enhancement or performance optimization that you want to deliver to your customers, one of your Android apps will inevitably require an upgrade. This can be either a seamless process or a painful one for your customers. To ensure that it is the former and not the latter, the Android SDK provides some simple guidelines to help you manage this process. Last week, we discussed some useful configuration settings offered through AndroidManifest.xml for designing apps to run on smartphones and tablets. This same configuration file also provides settings to version your apk.
There are two attributes you can specify to manage the versioning process of your app:
The versionName attribute is a user facing string that identifies the version of the application in use. For example, if you are upgrading for the first time, your previous versionName may be “1.0” while a minor upgrade version would be indicated by “1.1” and a major upgrade by “2.0”. The versionName attribute is primarily used for display purposes and helps users identify differences between app versions. The following is a snippet of the manifest from the Amazon MP3 App for Android:
The versionCode is the attribute that is used by the Amazon Appstore for Android to compare versions of your app. This is an integer, like 80029 in the sample manifest, not a string like the versionName. If the versionCode of an apk is greater than the versionCode of another apk, then it is considered to be newer. Of course, for this comparison to be valid, the apk package name and signature must also match. To avoid unexpected behavior, it is extremely important to keep track of your versionCode and to always increase the value whenever you are releasing a new version.