No results found

Try a different or more specific query
Developer Console
Amazon Developer Blogs

Amazon Developer Blogs

Showing posts tagged with Kindle Fire

June 13, 2013

Mike Hines

If you have decided on publishing an interactive periodical title, congratulations! Having an interactive periodical means that users can scroll articles on a page, play a music sample, manipulate a map, or otherwise interact with your content in ways that are just not possible with static content. While interactive publications are more work than simply rendering a PDF replica of your print publication, they are often well worth the extra effort. Interaction can drive deeper engagement with the content, more time per page, better reader usage reporting and other advertiser-friendly benefits.

In this two-part series on Interactive Periodical Publishing on Kindle Fire I will discuss some of the technical considerations for those who will write their own periodical application or who will use a publication platform such as Woodwing or Adobe. The first part introduces thoughts on layouts, resolutions and interactions, and part two will cover how to submit your periodical app to the Amazon Appstore to minimize time investment on your end and optimize user experience.

A 10,000 Foot View of Layouts

If your content is text-centric, you can look into using a fluid layout (Liquid Layout) design. The Wall Street Journal app for Android and iOS uses a set of relative layout templates into which the daily text of the newspaper flows. Once your templates are set, you can simply stream content and the templates handle the layout.


WSJ can flow text into templates easily

If your periodical is image-heavy, or you wish to exercise more exacting creative control, you can probably constrain your digital layout work to two fixed aspect ratio layouts, one for the 4:3 aspect ratio iOS tablets, and another 16:9 layout for Android tablets. True, not all Android tablets are 16:10, but if you are comfortable with a small amount of letterboxing, non-standard devices can be accommodated. 

Table 1

Wired Magazine Layout

WIRED Magazine has precise layout needs

Working with Resolutions

Publication platforms like those from Adobe can take a specific layout from InDesign and generate multiple renditions in which you can bundle images that are specific to the screen resolution of the target device. This can help reduce total package size and reduce asset scaling artifacts. Other platforms ask that you submit the largest assets you have, and will then scale down the assets to match the screen resolution of the target device. If you write your own app, you can make either choice, or even stream appropriate images to your app if your application returns the properties of the device on which is it running. If you do write your own app, please be aware that periodicals are often read in both landscape and portrait orientations. Your app should accommodate accordingly.

Building Interactions

If you are creating your own app, you can use just about anything you want to create interactions; Native code, Java, HTML, even HTML5. If you are using a platform like Adobe, you still have a fair amount of flexibility within the scope of the tools and webkit provided by the platform. In either case, be aware that the code you put onto any single page will use heap memory, and if you cache multiple heavy pages at the same time, you could find yourself running short on memory and fighting with the garbage collector should you ever hit onPause(). Avoiding this usually requires coordination between the content folks (who usually don’t think about heap size) and the IT group (who usually don’t think about editorial requirements). If you can flatten some of your non-interactive elements to PDF, you can save a good deal on file size and memory usage.

That covers (at a very high level) some of the important considerations to keep in mind when designing your periodical app. The next installment of this series will cover submitting your app to the Amazon Appstore, setting up In-App-Purchasing for subscriptions and individual issue sales and more.


May 30, 2013

Peter Heinrich

It’s no secret that customer satisfaction is key to Amazon’s success. It’s something we obsess about, and we constantly tweak everything from product selection to payment options to website design. We experiment, we measure, and we decide whether or not a change improves the user experience. One of the most powerful tools at our disposal is something we call a Web Lab, which allows us to test two (or more) different versions of a webpage, or roll out a new feature to a limited audience.

Perhaps this concept is less familiar to mobile application and game developers than to those who write web code, but it shouldn’t be. In fact, it’s so useful and important that Amazon’s A/B Testing service was one of the first we made available to mobile developers (If you haven’t tried the service yet, check out Getting Started with A/B Testing for a quick introduction).

Now a significant enhancement has just been released: Segmentation offers greater flexibility and control over who sees your experiments, allowing you to limit your tests to a set of users based on any dimensions you care to associate with them.

User dimensions

A “dimension” in this sense is simply a named characteristic whose value is a number or a bit of text. The UserProfile singleton object manages the dimensions you define, keeping track of their values for the current user. It’s these values that determine whether the current user is a member of a particular segment, and it’s entirely up to you how they are chosen, named, and initialized.

For example, say I want to test a new wine feature in my restaurant review app. I don’t want everyone to see it—just my beta testers—so I define a dimension called “isBetaTester” and initialize it based on some information I know about the current user:

        // Determine if the current user is actually participating in the beta,

        // based on my own definition of “participating.”

        boolean isBetaTester = validateUserAsBetaTester();


        // Set the dimension for the current user.

        UserProfile.addDimensionAsString("isBetaTester", String.valueOf(isBetaTester));


        // Initialize the Insights SDK to enable A/B Testing.





                 . . .

In this case, validateUserAsBetaTester() is a helper method I define to assist me in deciding whether the current user is a beta tester or not. This could be a preferences setting, or perhaps a check against an email whitelist.  Regardless, I’m responsible for setting the value, which I do before initializing the A/B Testing system.

Create a segment

Now that I’ve established a dimension to differentiate users, I need to define a segment that actually refers to it. The segment may be associated with any A/B test, limiting access to users who match (or don’t match) along the relevant dimension. From the Amazon Mobile App Distribution Portal, I navigate to the A/B Testing tab of my app, then click Add a New Segment.

Next, I fill in the segment information, paying special attention to the dimension information, since that must correspond to the name (“isBetaTester”) and type (String) I use in my application. In this case, I define a segment called “Beta Testers” that will include anyone whose isBetaTester dimension is a string equal to “true”:

Limit a test

With a segment defined, I can now use it to limit the scope of an A/B test. Let’s say I want to experiment with the length of user-submitted wine reviews. (I’d like to give people more space, but have to balance the storage required against the benefit of more detailed content.) When I create the test, the last setting allows me to specify the user segment I want to target. In this case, I choose my beta testers, whom I just identified:

When the test is started, beta users will begin to see variations of wineReviewLen, subject to the distribution I specify.  In my app, I can initialize a variable with the maximum allowable review length for the current user:

        ABTest.getVariationsByProjectNames("Wine Reviews")

            .withVariationListener("Wine Reviews", new VariationListener() {

                public void onVariationAvailable(Variation variation) {

                    maxReviewLen = variation.getVariableAsInt("wineReviewLen", 256);



For users outside the Beta Testers segment, the control variation will always be allocated. However, these users will never be included when the results of the experiment are calculated.

Complex segment criteria

In this simple example, a single boolean value was enough to distinguish segment members, but segmentation supports much more complicated criteria. You can easily attach more than one variable or change how variables are evaluated. String equality works as demonstrated (numeric equality is identical), but it’s also possible to create a segment based on a numeric range or set membership.

For example, perhaps I want to further segment my beta testers by those who have made a past purchase. I can create a numeric value called purchasesToDate and define the valid range as any non-zero value—note that I just have to start at 0 (exclusive) and omit the upper bound:

If I wanted to create a segment of customers in the Pacific Northwest, but only those who have used the app in 2012 or 2013, I could combine two tests for set membership:

Important note: users retain the variation they are initially allocated, even if their dimensions change later on.  This means that once a user has been identified as a member of one segment, they never move to another for the duration of the test, even if their dimensions change. This ensures a consistent experience; significant changes to features or interface could be jarring. (If a new test is started, the dimensions will be re-evaluated.)

That’s it!

Setting up segments is simple and adds a lot of flexibility to your experiments.  Give it a try the next time you’re considering A/B testing.  For information, be sure to check out the Insights documentation.

May 28, 2013

Mike Hines

The Amazon A/B Testing service is an effective tool to increase user engagement and monetization. It allows you to set-up two in-app experiences (each of which is presented to a different group of users) and evaluate the success of each, based on criteria you establish. Another, less obvious, use of the A/B testing service is feature timing. It’s easy to turn on a new feature at a specific time, or release a series of features on a schedule. You can do it in four simple steps, which I walk through here:

  1. Creating a new A/B project and launch used for releasing a feature
  2. Integrating the SDK and API into your Android app
  3. Adding the Java code necessary to enable your feature based on the A/B launch
  4. Releasing your feature via Amazon’s A/B Testing portal

Step 1: Creating a new A/B project and launch used for releasing a feature

Using the Amazon A/B Testing service requires an Amazon developer account and an Android app associated with the account. If you don’t already have a developer account you can sign up here. The first step for using Amazon’s A/B Testing to release a feature is to create an A/B launch used to determine whether the feature in your app is hidden from users or accessible by them. Once signed into your developer account the following steps can be used to accomplish this:

  1. Navigate into your app. Click “My Apps” on the navigation bar of the Mobile App Distribution Portal to access your list of apps.
  2. On the detail page of your app, click the “A/B Testing” link as shown below.

    App Detail Page

  3. A screen displaying your list of A/B projects is displayed. Click “Add a New Project”.

    Amazon A/B Testing Page

  4. Enter a title and description that indicates this test is used for the launch of a specific feature and click “Save Project”.

    Add A/B Testing Create Project Page

  5. Click “Add a New Launch” on the detail page of the project you just created.

    A/B Testing Project Detail Page

  6. We are now looking at the page for creating an A/B launch. Enter a name and description that indicates this is used for a feature release. For the variable, we create a boolean that tracks whether the feature is enabled. The old variation is set to false and the new version is set to true. Make sure to keep the old variation set to 100% of the distribution. This means all users of your app will not have the feature enabled when you check this A/B launch’s variable. Click “Save” to add your A/B launch.

A/B Launch Creation Page

  1. Click the “Start” button on the newly created A/B launch to make it available for use.

List of A/B Items under the Project

Step 2: Integrating the SDK and API into your Android app

We now have an A/B launch containing a corresponding variable for determining whether our feature is made available. The next step is to integrate the A/B Testing SDK into our app using the following steps so we can write code to obtain whether the feature is made available.

  1. Download the Amazon A/B Testing SDK from here.
  2. Set the required permissions INTERNET and ACCESS_NETWORK_STATE in your AndroidManifest.xml file.

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

  1. Add the Amazon Insights Processing Service to your AndroidManifest.xml.

    <service android:name="" />

  1. Add the AmazonInsights Android SDK jar and all 3 AWS Android jars to your Android project.  These jars can be found in the libs folder of the SDK download.

Step 3: Adding the Java code necessary to enable your feature based on the A/B launch

With the SDK setup its time to add code to either make our feature hidden or available based on the variable we configured for our A/B launch. The steps below detail the code needed for accomplishing this.

  1. Import Amazon Insights in to your code.


  2. Initialize the Amazon Insights SDK in the onCreate method of your Activity. Note: Your application key and private key can be found on the Amazon A/B Testing page for your application where we created the A/B project in step 1.



  1. Add code to enable the feature based on the A/B launch variable.  We obtain our A/B launch variable and check whether we should enable access to the feature.

//Get our “Feature Launch - FeatureName” experiment and retrieve the variable
//for whether the feature is made available.
   .getVariationsByProjectNames("Feature Launch - FeatureName")
   .withVariationListener("Feature Launch - FeatureName", new VariationListener() {
      public void onVariationAvailable(Variation variation) {
         boolean featureNameEnabled = variation. getVariableAsBoolean(
            "FeatureName_IsLive", false);
         if (featureNameEnabled) {

 Step 4: Releasing your feature via Amazon’s A/B Testing portal

With your app now supporting the release of the feature, the final step is to make your feature available at the appropriate time. This can be done completely via the Amazon A/B Testing portal and doesn’t require an APK update with the feature enabled. To launch the feature use the following steps:

  1. Navigate back to the A/B launch experiment you created for your app’s feature release. This is accessible by clicking the “A/B Testing” link on your app’s detail page. Next click on the current experiment for our feature launch A/B project as displayed by Image 8 below.

    App Detail Page

A/B Project List

  1. Click the “Edit” tab to change the distrubtion of the variable we use to determine if the feature should be made available.

    A/B Launch Detail Page

When the Launch was created the distribution was set to 100% to the “Old Version”. Change the distribution of the new variation to 100%. All users of your app are going to receive true for the variable used to enable your feature. Click “Save Launch” and your feature will now be live for all users. 

In some scenarios you might want to incrementally release a new feature over time. This can beneficial when releasing features for which scaling might be a concern. For example,  you can use Launch to safely increase the percentage of customers receiving the feature while you monitor the scalability of your service.   If a problem is detected you can stop incrementing the release or in an extreme case pull it back.

A/B Launch Edit Page

That is all it takes to support releasing a feature via Amazon A/B Testing in your Amazon app. You can find more information the Amazon A/B Testing service here.


May 28, 2013

Daniel Winner

You may have seen the news that our store is expanding to nearly 200 countries. As we grow, we continue to focus on developer success around the world. We’ll be spotlighting developers from countries in which we operate here on our blog over the next few months.  First, we take you to the UK, where just six months after the launch of the store on Kindle Fire in October 2012, British developers and publishers are already seeing some impressive results.

Kent-based P2 Games publishes titles based on popular children’s character licenses, including Peppa Pig (the UK’s leading pre-school franchise), Fireman Sam, and Bob the Builder.  P2 Games was already successful before Kindle Fire launched in the UK, but saw sales quickly grow once the store launched in their home market. 

Peter Sleeman, Director of P2 Games, spoke with us about the success they are experiencing on Amazon.  As he notes, ‘’The popular children’s brands we build apps for were already well-represented on Amazon. For example, they sell Peppa Pig products across multiple product categories, such as Toys, Books, Video Games, and DVDs. It made sense to try to reach these same customers with our apps, particularly given the Kindle Fire is such a family-friendly device. Through our conversations with Amazon, we were aware of the demand for our apps, information gleaned from customers’ actively searching for Peppa Pig titles.’’

Although P2’s Peppa Pig Apps have already been downloaded more than one million times since launching in September 2010, they achieved some terrific results just months after the launch of our store in the UK. 

Peter Sleeman continues, ‘’We launched our first Kindle Fire version in January 2013 and within a few weeks we saw sales on Amazon overtake Google Play by a factor of four or five times. Kindle Fire is now a legitimate contender, and although our apps have been out much longer on iOS formats, our current rate of sale is close to parity with iOS most days in the UK. The launch of our newest paid Android app, Peppa Pig Party Time, in March 2013 has followed in the footsteps of previous titles and is proving very successful. ’’

For P2 Games, these results have changed the way they develop for Android.  Peter told us that, ‘’Our success on the Kindle Fire has been game-changing; our Android development efforts now lead with the Kindle Fire version. We’re really excited to have a number of our other key titles in development for release on Kindle Fire later this year.’’

Publishers like P2 Games tell us that one of the reasons they are turning to Amazon is because it monetizes so well. P2 Games is just one of thousands of UK-based developers and publishers that have already experienced the value of connecting with Amazon customers on mobile devices, and are reaping the rewards of distributing apps on Kindle Fire.  Developers benefit when customers find the apps that interest them through behavioral recommendations and buy ‘friction free’ through 1-Click purchase.

May 14, 2013

Mike Hines

As developers, we’re occasionally (okay, maybe more than occasionally) stuck in the middle between designers who ‘know what works’ and executives who ‘know what they want.  Even in smaller shops, it may not be clear which user experience will more often result in the desired behavior. Beyond simple use tracking, testing two different options to determine which works better usually meant two separate APKs and a lot of data mining and management to see which was the best.

Amazon has changed that with the release of the A/B Testing Service, where developers can run experiments within one APK. You define the variables to test in each of two variations, and then decide what percentage of downloads will get each variation. The app then collects data and allows you to make an informed decision about which variation you want to enable. These variations could vary from the speed of the ball in a game, or the message displayed while trying to upsell an In-App purchase item like extra lives. It’s easy to configure and integrate the A/B Testing Service with your app and it’s also free for any developer distributing their apps on the Amazon Mobile App Distribution Program for Android.

In this post, you will learn how to integrate A/B testing into your app. For our example, we will use the “Snake Game”. In the traditional game, the speed of the snake increases every time it is fed.  We will run tests to figure out the optimal speed increment in order to ensure that the game is neither too easy nor too hard for the player and that the player is always engaged.  In our case, a successful test would be if 70% - 73% of players are able to feed the snake 20 times before the snake collided with the boundary or the snake itself. This will give us objective data on whether the increment was too high, too small, or just right.

Creating your test

Once you have identified your test, you can create an A/B test by going to the Mobile App Distribution page to create it.

In our example, we will create a project called “Snake Speed Project” and an A/B test called snakeSpeedTest. We will use this to test out various increments in the speed of the snake until we find the optimal one.

To configure an A/B test you will need the following information:

  1. Name of the test
  2. Event name to count the number of views
  3. Event name to count the number of conversions
  4. Variable name for each variation
    1. Variation A
    2. Variation B
  5. Distribution percentage

In our example, the test would look like the screenshot below:

AB Testing Setup Form

For more details on how to setup an A/B test, please visit the startup guide.

Integrating the API

Now that you have a test set up in the Mobile App Distribution page, you’re ready to integrate it into your application. For this, you will need to download the SDK.

After downloading the SDK you will need to integrate it into your project. For more information on how to setup your project, please visit Integrate the SDK.

To initialize the Amazon Insights SDK, you will need to obtain the following from the Mobile App Distribution page:

  1. Application key – Which can be retrieved by going to your “My Apps” dashboard and selecting the app. One of the properties available in the General Information is the Application Key.
  2. Private Key Which can be retrieved by going to the  app’s A/B testing page and click on “View Private Key”.

You can now initialize the SDK using these two keys.

// Configure the Amazon Insights SDK

Now that your application is initialized, you can start receiving different variations for your test. In our case, it is the increment by which to increase the snake speed. 

//Get a variation allocated for the “Snake Revive Project” experiment and
//retrieve the speed variable.

    .getVariationsByProjectNames("Snake Speed Project")
    .withVariationListener("Snake Speed Project",new VariationListener() {
        public void onVariationAvailable(Variation variation) {
          speedMultiplier = variation.getVariableAsString("speedMultiplier",
            //... increase speed.



 After you have successfully retrieved the variation, you would need to notify the Amazon A/B Testing Service of a successful view. You can do that by simply adding the following code. (Note that snakeSpeedIncremented is the same event we added in the A/B testing portal page for counting views)

 // record when the snake is fed for the first time only (visit)

 Once the game ends by either the snake colliding with the boundary or itself, we will check the count of the how may times it was fed. If it was more than 20, then we will record a successful conversion. (Note: snakeLevel20Reached is the same event we added in the A/B testing portal page for counting conversions)

 // record if number of feeds is more than 20.
if (noOfFeeds > 20) {


 Once you have incorporated the SDK and deployed it through the Amazon Mobile App Distribution Program, you now start collecting data.

In our case, we determined that 95% of the players reached level 20 for both test increments, which suggest that the game play was easier than our target. We ran additional rounds of tests by doing launches with new increments and found that the 1.65 multiplier was the optimal level of difficulty, as the conversation rate was around 71%. Refining the increment amounts to do new rounds can be done by just going to the A/B test page. No new APK is required.

The Start your first A/B test guide tells you how you can start an A/B test, view results, and end a test.

As you can see, setting up and integrating Amazon’s A/B Testing Service is simple and straightforward. The best part is that it’s free for developers of the Amazon Mobile App Distribution Program.

May 13, 2013

Mike Hines

Amazon has started distributing Amazon Coins, which can be used to buy Kindle Fire apps and In-App Purchasing (IAP) items (except subscriptions). Starting today, every U.S. Kindle Fire owner is getting 500 coins ($5) to spend on apps, games, and IAP items. Customers will also be able to buy more coins from Amazon at a bulk discount of up to 10%. As customers use their coins, you will have the opportunity to make money and monetize your Kindle Fire app.

If you don’t have an app for sale on Amazon yet, it’s easy to get started. Based on our testing, over 75% of Android apps submitted to us work on the Kindle Fire, without any additional development required.

Create your developer account then submit your app to benefit from Amazon Coins. For more details about Amazon Coins, see the official press release here.


May 07, 2013


Mobile devices create an amazing ecosystem for developers to express new ideas, create new business, and expand existing worlds. Services like GameCircle and In-App Purchasing make those experiences more sticky and re-playable, drawing users into the experience with more depth. Another category of ecosystem depth that we've been focusing on is app-enabled accessories. Kindle Fire (as well as other Android devices) can connect to and control an incredible range of new devices, and a couple weeks ago we launched a few of these devices on as official Kindle accessories, creating new ways and new opportunities for developers to connect with Amazon customers.

From the self-stabilizing, Kindle-controllable AR.Drone and the high-tech Nest learning thermostat, to the Sonos wireless music system and the Nexia home automation system, there's virtually no limit to what an application can do with the right accessories.

I've had the opportunity to try out some of the development experiences the devices provide, and I wanted to share just how easy it is to get started. I've chosen the Philips Hue personal wireless lighting system, the starter-kit for which will be available for pre-order on the Amazon App Enabled Accessories store this week. Hue lights connect to a Wireless bridge that connects to your network, and exposes a RESTful API for control over the bulbs -- either individually or in groups. Accessing this API in Android, for Kindle and other devices, is pretty simple...

Once you've got everything connected, you can get started by authenticating as a new developer directly on the bridge:


Enter the root API url "/api" and send a JSON object containing your new developer identity:


Submit the form with POST. You'll get an error back telling you to push the link button on your bridge. Press it, then POST again, and you're in. This creates your development URL on the bridge, separating your commands from any other app. You can now send commands to the URL:


From here, you can send commands to groups:


Get state, or send commands to individual lights:


Here's some Android code telling the bridge to turn all the lights to blue...

            HttpClient httpClient = new DefaultHttpClient();
            HttpPut httpPut = new HttpPut("http://<bridgeip>/api/kindledev/groups/0/action");
            JSONObject lampMsg = new JSONObject();
            lampMsg.put("on", true);     //set the lamps to on
            lampMsg.put("sat", 255);     //set the saturation to 255
            lampMsg.put("bri", 255);     //set the brightness to 255
            lampMsg.put("hue", 46360);          //set the hue to blue
            StringEntity se = new StringEntity(lampMsg.toString());
            httpput.setHeader(HTTP.CONTENT_TYPE, "application/json");
            HttpResponse response = httpClient.execute(httpPut);

Full documentation on the Hue API can be found on their website.

The other devices I mentioned all have programmability interfaces as well. Their own apps hit Amazon a couple weeks ago, but we can't wait to see what other experiences the developer community can create with them!

April 25, 2013

Mike Hines

Amazon will be sending tens of millions of dollars to Kindle Fire users; money that can only be used to buy apps for Kindle Fire.  If you don’t want to miss a minute of that action, make sure your app is available for sale on Kindle Fire devices, or submit a Kindle Fire compatible app by April 25 for the best chance of getting in the Amazon Appstore in time. (If you submit after 4/25, your app will still be eligible, but may not make the start of the gold rush.)

What kind of money is this?

In May, Amazon is introducing Amazon Coins, a new virtual currency that customers can use to pay for apps and most in-app-purchase items. To help promote this new currency, Amazon is going to give away tens of millions of dollars in Amazon Coins to Kindle Fire users. This money will be burning a proverbial hole in customers’ pockets as they look for places to spend it. We’d like your app to be one of the tempting places to spend that currency.

How do Amazon Coins work?

U.S. customers will be able to spend Amazon Coins on apps and most in-app purchase items. (Subscriptions cannot be purchased with Amazon Coins.) Each Amazon Coin is worth 1-cent, so a $2.99 app will cost 299 coins. The way you get paid doesn’t change if the customer pays with Amazon Coins or a credit card; you get paid in real U.S. Dollars, at the same 70% revenue share you normally receive.

What do I have to do for my app to be eligible for Amazon Coins?

If your app is available for sale on a Kindle Fire device, then you’re done; nothing else to do. It doesn’t matter if your app is also available on other Android devices, as long as it is available on a Kindle Fire device, it is eligible.

My app isn’t available on Kindle Fire now. How can I fix that?

If you already have an app in the Amazon Appstore for Android, it’s fairly easy to make it available for Kindle Fire Tablets. Take a look at the Kindle Fire Development Best Practices here for hints on how to make your app shine on Kindle Fire, and then re-submit your app with the appropriate Kindle Fire devices selected on the Binary Files tab (see below).

Please submit your apps by April 25th to give us the best chance of having enough time to review them and get them in the Amazon Appstore before tens of millions of dollars in Amazon Coins arrive in customers’ accounts.

If you don’t have an app in the Amazon Appstore, don’t worry. You may be able to submit your existing Android app without too much work.  If you use Google Play Services for In-App Billing, Messaging, or Maps, you will need to replace them with the corresponding Amazon APIs before submitting. These APIs are:

  • Amazon In-App Purchasing API
  • Amazon Device Messaging API
  • Amazon Maps API

Learn more about these APIs here.

For more information on making your app available on Kindle Fire devices, check out these links:

  1. Create an account on the Mobile App Distribution Portal
  2. Download the Amazon Mobile App SDK
  3. Review the Kindle Fire development resources

For more detailed information on Amazon Coins, see the FAQ for Amazon Coins.

April 11, 2013

Amazon Mobile App Distribution Program

Amazon Coins is launching in May. Tens of millions of dollars of Amazon Coins will be given to customers for free to spend on Kindle Fire apps, games, and in-app items. If your apps are already on Kindle Fire, then no action is required. If you have new apps or games ready, submit them by April 25th to ensure we have time to review your apps before millions of dollars in Amazon Coins arrive in customers' accounts.

For more information on Amazon Coins, click here. Stay tuned to the Distribution Blog for more updates and announcements regarding the launch of Amazon Coins.

April 10, 2013

Peter Heinrich

Not familiar with Amazon GameCircle? Read how easy it is to add achievements, leaderboards, and save-to-cloud features to your next game.

From a game developer's perspective, the Amazon GameCircle API offers a lot of advantages over home-grown achievements and leaderboards, not to mention data synchronization to the cloud or between devices. It instantly provides a social aspect to your game with very little coding, and simplifies progress saving and back-up (two of the features most requested by customers).

GameCircle isn't just about developer convenience, though--customer experience is also critical. We see again and again how integrating GameCircle improves user engagement and conversion, so we know it provides value to game players as well as game developers. More engagement and better conversion leads to increased average revenue per user, so GameCircle may add directly to your bottom line.

With this in mind, we've developed a few guidelines to help maximize GameCircle's contribution to your game. These best practices have grown out of our own experience, as well as those of other developers with successful games using GameCircle. If they seem like common sense ways to make the user experience better, you're right.


Order – Keep in mind that the first leaderboard listed for your game will be the one to appear on the GameCircle summary screen. Give that slot to a leaderboard that will provide useful information game-wide, as opposed to a specific level or section. The Amazon Mobile App Distribution Portal supports drag-and-drop ordering of leaderboards, so making changes is easy.

Descriptions – It seems obvious, but each leaderboard should have a description, making it clear to the player what is being tracked.

Draft/sandbox – Remember that leaderboards (and achievements, too) are considered "draft" until they're published from the Distribution Portal. Only players who have been added to the GameCircle sandbox for your app can view unpublished leaderboards or post scores to them. When you're ready to make the leaderboard publicly available, check the appropriate Status box to mark it Ready to Publish, then click Start Publishing.

Note that this step cannot be undone, as un-publishing a live leaderboard might lead to a poor user experience if an app expects a leaderboard to be available. However, after publishing a leaderboard, you'll still be able to reset a leaderboard's high scores from the Distribution Portal, which may be useful for weekly quests or contests.

Multiple game support – You can easily share one set of leaderboards (and achievements) with multiple versions of your game. If you release separate Free and Paid versions, or offer Standard and High Definition variations of your game, choose one version of your game to be identified as the "master," and then create your leaderboards and achievements for that version only. Then just add the package/signature pair of each version that will use the shared leaderboards and achievements to the “master” whitelist registry.


Order – GameCircle automatically shows users the next locked achievement, encouraging them to keep on playing. Arrange achievements in the order they're likely to be earned and they'll be recommended in the same order and the progression will seem natural. Like leaderboards, achievements may be reordered on the Distribution Portal using its simple drag-and-drop interface.

Descriptions – Like leaderboards, achievements should have clear descriptions so players know what they're striving for. You don't have to lay out the precise steps to earn each achievement—hints or a simple phrase are fine—but keep in mind that a rich description may provide more incentive to unlock the achievement. If the description is too vague, earning it may feel like luck rather than skill.

Locked/unlocked descriptions and icons – GameCircle allows you to specify different text and icons for locked and unlocked versions of each achievement. Adjust the description for an earned achievement to describe what was done or to congratulate the player. For example, "Defeat the Spider King" may describe an achievement until it's unlocked, after which "You Killed the Spider King!" might be more appropriate.

Similarly, the images should be noticeably different. Color is a good mechanism to indicate lock status, with neutral or gray-scale imagery signifying an achievement not yet earned. Other options include different backgrounds, an overlay or watermark, or a common image shared by all locked achievements (with an achievement-specific icon for the unlocked state).

Use hidden achievements sparingly – GameCircle supports "hidden" achievements, which are not visible to the player until actually earned. Since the user doesn't know about them (let alone how to earn them), hidden achievements are best used for incidental progress—things that might happen through ordinary game play, requiring no specific effort. If your game's achievements are all earned through special actions, you should probably avoid hiding them.

Mix up the difficulty – If all the achievements in your game are easy to earn, users may do so quickly and be less likely to keep playing. If the achievements are all hard, there may not be enough regular rewards to keep players coming back. A mix of easy and hard achievements delivers positive reinforcement while rewarding those who put in the extra effort to complete them all.

Likewise, you may wish to alternate between incidental rewards and ones that require complicated actions or special effort. As with hidden achievements, this depends on your philosophy—some developers prefer not to define achievements that are awarded through the course of normal game play. If you do choose to include incidental rewards, maintain a balance by offering complex achievements, too.

Pace achievements throughout the game – An achievement early on (completing a tutorial, for instance) should kick off a steady flow of positive feedback throughout the game, leading to a final achievement at completion (if appropriate).

Draft/sandbox – Like leaderboards, achievements are created in "draft" mode by default. This means that they're only visible to players who have been added to your game's sandbox via the Distribution Portal. The process for publishing an achievement is identical to that for a leaderboard, and is also irreversible, for similar reasons.

Note that unlike leaderboards, achievements cannot be reset once they're published. Until then, the Distribution Portal can be used to clear an achievement from all users in the sandbox, but that option disappears once the achievement becomes publicly available.

Multiple game support – See the note under Leaderboards, above.

Whispersync For Games

First sync on a fresh device – The very first time your game is run on a fresh device, there will be no local saved data; the game should simply copy down whatever cloud data exists for the user. To do this, call synchronize() with a conflict resolution strategy of AUTO_RESOLVE_TO_CLOUD (the default, PLAYER_SELECT, will prompt the user to choose between device and cloud—obviously not appropriate in this situation.)

First sync of the game – Every time your game starts (except on a brand new device—see above), you should call synchronize(). The latest cloud data will be retrieved, if appropriate, or updated, if a local data change is pending. If the data conflicts, the user will be prompted to choose the authoritative source.

Sync at major checkpoints, pause, and exit – Whenever a player reaches a significant milestone or stopping point in your game, you should save state to the cloud with synchronizeProgress().

Sync description – It's critical to associate a useful description with each progress update, since this information will be presented to the user in the case of a conflict, or if you allow them to restore to a save point. GameCircle will include the date and time automatically, but a friendly description such as, "Completed Level 3," or, "Round 7: 12 minutes in," can help the player choose which data they want to use.

Virtual goods – If you store entitlements locally (that is, you don't handle virtual goods through an authoritative server), it's important to either exclude this data from Whispersync updates or disallow save points. If you don't, a restore to an earlier save point may wipe out your customer's purchases—a guaranteed way to generate complaints.


CANNOT_BIND from the emulator – Remember that GameCircle works only on registered Kindle devices, including emulators. If you encounter this error while running on the emulator, make sure you have actually registered and signed in from there as well. You can do this from Settings | My Account.

This problem can also arise if the Target is incorrect for the Android Virtual Device you are using. It should start with "Kindle Fire…" to ensure Amazon functionality is available.

Don't forget to publish Achievements/Leaderboards – This is a very common oversight, but fortunately simple to correct. Be sure to publish your achievements and leaderboards using the Distribution Portal once your game is ready be made publicly available.

Game alias only available if corresponding setting is enabled – If you are unable to retrieve the GameCircle alias/nickname when testing, make sure the appropriate setting is enabled. This is accessible from Applications | Amazon GameCircle. "Share your GameCircle Nickname" should be set to Show.

CANNOT_AUTHORIZE due to app signature – Note that on most platforms, the keytool command line program will silently accept the wrong password when generating a keystore signature. In some circumstances, you may need to run the command in the same directory as the keystore you are processing. See Authenticate Your Game with Amazon GameCircle for more information.

NoClassDefFoundError at runtime – If your application links without errors but throws this exception at runtime, ensure that the amazon-gamecircle-1.2.x.jar is actually included in the .apk. Simply adding the jar file to the build path is not necessarily sufficient. In Eclipse, for example, you may need to add the file or create a link to it in /libs.

No negative leaderboard values – Leaderboards do not currently support negative scores, so you will experience errors if you submit them.

Javadoc errata

·       FRIENDS_ALL_TIME is not currently a valid LeaderBoardFilter value

·       AchievementsClient.resetAchievement() and its plural counterpart do nothing