We recently launched the Mobile Associates API (MAA) for Amazon Appstore (including Kindle) and general Android devices. Since the launch, the API has been successfully integrated in hundreds of Android apps and has helped generate incremental revenue for developers. Mostly, developers use MAA to complement revenue generated from mobile ads. Using MAA, you can sell real products from the millions of items at Amazon, whether physical (i.e. toys, clothing) or digital (i.e. eBooks), from inside your apps while earning up to 6% in advertising fees from those purchases.  With wide variety of the Amazon product catalog, there are probably many items that are relevant to your users. Plus, you have complete control over the products you want to promote and the in-app user experience. 

In this post, we will show how to build “Relevant products” experience using Mobile Associates API. In this experience, you can offer contextually relevant products in your app by specifying a search term and direct customers to mobile optimized Amazon search result page. Customers can browse through the search results page, select products, and complete the purchase after signing in to their Amazon account. You earn advertising fees equal for qualifying purchases made during that session. Most developers can build this experience in 30 minutes.

“Relevant Products” Experience

For developing other experiences, please visit Amazon Mobile Associates API

Steps to Integrate                                                                                                  

1.       Identifying relevant products to promote

2.       API code integration

3.       Testing the app

Identifying relevant products to promote

Mobile Associates API provides four parameter, searchTerm, product category, Brand, and SortOrder, to search and promote most relevant products to your app users on search landing page. Please see the available product categories and compatible sorting and filtering options here.

To identify relevant products, begin by identifying the most relevant product categories based on your app category and your app user’s demographics. You can also use different product categories in different sections of your app.

Once you have identified the relevant product categories, identify a relevant searchTerm to find relevant products within your chosen categories. Now go to Amazon.com and search for products using searchTerm within your chosen categories. App users will see this list of products when using your app. Refine your searchTerm to identify the list of products your users are most likely to purchase. These items may not be the highest value item available under the given category. For example, most app users are unlikely to buy the most expensive running shoes.

You can also sort these items in different orders. We recommend sorting them by “relevance”. You may consider other sortOrder such as “highest to lowest price” under special circumstances. You can also specify “brand” as a filter if you believe that your app users are more likely to buy a certain brand.

Once you have identified the products you want to promote, you can use the appropriate searchTerm, product category, Brand, and SortOrder in the APIs to promote the relevant products.

Example: If your app belongs to the fitness category, you can pick product categories such as “Health and Personal Care” to promote vitamins, “Shoes” to promote running shoes, or even “Books” to promote fitness related books. You should promote context appropriate products such as barbells or protein supplements to a person who does frequent weight training. Use “men’s running shoes” in shoes category if the app user is male. You should refine the searchTerm based on your conversion rates and the products your users are purchasing.  Promote brands which are popular in your app user’s geographic location. For example, Adidas is a very popular brand in Germany.

API code integration

Update the Android Manifest

Making requests to the Amazon Mobile Associates API requires the INTERNET permission. These permissions need to be declared outside of the <application> tags in yourAndroidManifest.xml file.

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

Initialize the API

In your Activity.onCreate(), initialize the API by calling AssociatesAPI.initialize(config) using your Application Key.

protected void onCreate(final Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   setContentView(R.layout.activity_main);
   AssociatesAPI.initialize(new AssociatesAPI.Config(APPLICATION_KEY, this));
}

To get the Application Key, log on to the developer portal, click on the "My Apps" tab and then select an existing app or click on the "Add a New App" button. When creating a new app, just fill in the "App Title" and "Form Factor" fields and click the "Save" button. The next screen will show the unique Application Key value, which is a 32-character globally unique alphanumeric string that is used to identify your app. The same Application Key can be used across platforms, but each distinct app must have a unique Application Key.

Direct to Amazon Search Result Page

To direct customers to an Amazon product search results page, construct an OpenSearchPageRequest by specifying the search keyword and pass the search request to the LinkService.openRetailPage method.

String searchTerm = "running";
String category = "Shoes";
openSearchPageButton = (Button)findViewById(R.id.open_search_page_by_term_button);
openSearchPageButton.setEnabled(true);
openSearchPageButton.setOnClickListener(new View.OnClickListener() {   

    public void onClick(View view) {
       OpenSearchPageRequest request = new OpenSearchPageRequest(searchTerm, category);
       try {
           LinkService linkService = AssociatesAPI.getLinkService();
           linkService.openRetailPage(request);
       } catch (NotInitializedException e) {
               e.printStackTrace();
       }
   }
});

For more details on building “Relevant products” experience, please visit the Amazon Developer Portal.

The Amazon Mobile App Distribution program enables you to distribute your existing web apps on Kindle Fire and select Android devices in nearly 200 countries across the globe (including the US, Canada, UK, Germany, Spain, Italy, France, Brazil and Japan). 

Almost any mobile friendly website you are hosting today can be run as a Web App.  This means all of the HTML5, JavaScript, and CSS code you have built today can be made available as an App in the Amazon Appstore. 

In the recent Webinar on Submitting HTML5 Web Apps to the Amazon Appstore, we covered how to get your existing web apps onto actual devices and debug and test them.

You can debug your HTML5 Web App in two different ways.

•      You can use your favorite IDE or debugging tools for normal Web App development like you are already doing. 

•      Or, you can optionally use the Chrome DevTools to debug your web app using a Kindle Fire or an Android device running the Web App Tester Tool.

Note: The Chrome DevTools, the Chrome Browser installation tool, the Android SDK and certain other development tools are provided by third parties, not by Amazon.

Setting up your Debug Environment

The Chrome Developer Tools are freely available from Google and included in all the latest versions of the Chrome Browser.  Simply select the Chrome menu at the top-right of your browser window, then select Tools > Developer tools to begin debugging.  You can get additional information on installing the tools off the Chromium blog.  The Chrome DevTools use the Android Debug Bridge (adb), part of the Android SDK tools, to communicate with the web app from your computer.

Next, we will need to install the Web App Tester Tool from the Amazon Appstore.  This tool will allow us to create a bridge to our computer over USB or WiFi. 

Simply swipe from the top of the device (if on a Kindle Fire device make sure you tap the full screen handle on the bottom of the screen to open the status bar) and then swipe down from the top of the screen to display the Quick Settings Notification Area.  Once there you will have the option to connect over either USB or WiFI.

In this example I have selected WiFi and am given a url I can put into my browser to connect the Chrome Dev Tools to that running app.

Here is a screenshot of a Kindle Fire running my Web App with the Chrome Debug Tools showing the source for my app.  This enables me to now select actual <div> tags now in the html code via Chrome on my computer and see those <div> tags being highlighted on my actual device (as in the example below).

Conclusion

By utilizing the free Chrome Developer Tools and the free Web App Tester tool we are now able to debug our Web App on an actual device in real time.  This includes everything you would expect from the Chrome Developer Tools, like real time resource monitoring, the ability to view our html source and a JavaScript console.

For a complete walkthrough of the steps described here you can watch the short screencast below as well as checking out the web app debug documentation on our developer portal here.

-Dave (@TheDaveDev)

At the Amazon Appstore, we test all apps before we publish them, and we’ve seen a fair number of PhoneGap apps fail with Timeout Errors. We have also seen Timeout Errors mentioned on StackOverflow so I thought I’d share some of the more successful tips I’ve seen floating around the community boards.

One, from Google Groups:

If you are spending a lot of time loading resources from local stores or the web when you get your timeout error, try increasing the loadUrlTimeoutValue to 60000 in onCreate:

super.setIntegerProperty("loadUrlTimeoutValue", 60000);

Two, from StackOverflow:

It may be a version specific issue in some cases.  If you are seeing this in cordova 2.7.0 and it’s not a resource loading issue, try going to back to cordova 2.4.0 or upgrade to 2.9

Three, from StackOverflow:

If loading the URL is still being difficult, try importing org.apache.cordova.* and calling Config.getStartUrl() in onCreate.

public void onCreate() {                            
super.onCreate(savedInstanceState);         
super.loadUrl(Config.getStartUrl());
}

While not a universal elixir (as you can see from this thread), the above fixes have helped some of our developer community and might help you too.

Ever wonder what’s involved in turning your web app into an app you can launch from a mobile device? On the Amazon Appstore, it’s pretty easy, and involves just a few steps you can learn about here. One of those steps is adding a JSON file called the web-app-manifest to your web app.

This manifest file contains information required to run your app on a mobile device, and the basic manifest file is created for you on the developer portal. Where you put that manifest file can make a difference though. You should know about that and how to edit your manifest file in order to give your app access to features like geolocation on the device.

Where can you put the Manifest, and what difference that makes.

While we recommend that you put the manifest file at the root of your web app, you can put the manifest file anywhere on your server. The location of your manifest file determines what pages will render in the context of your app, and which pages will render in the default browser. The pages in the sub-domains under your manifest will be accessible by your app and will render in the context of your app. Any pages outside of those domains or directories will open in the default browser instead of in the context of your app.

Take a look at what pages will and won’t be accessible from your mobile app depending on where you put the manifest. Note the special case of www. and m. addresses in yellow below.

SSL Note:

• If the manifest is delivered with https://, then the entire app must be delivered over SSL as well.
• If the manifest is delivered with http://, the app may be still be served over SSL.
• If you use any permissions (IAP, Geo Location, Login), you must use SSL.

Now that you have a good idea where to put your manifest, what to put in it?

Contents of the web-app-manifest.json file

The manifest created automatically for you will look like this:

{
 "verification_key" : "c8efxxxx-xxxx-xxxx-xxxx-xxxxe5b239e9",
 "version" : "0.00(0)",
 "type" : "web",
 "last_update" : "2013-11-19 23:40:17+0000"
}

• “verification key” connects your website to your app.
  *This is the only required field in the manifest.

• “version” helps you track the version that you have submitted
• “type” lets us know that in this case, the app is a web-app
• “last_update” is when this manifest file was created (you can change it to match your updates)

In addition to the elements above, you may also wish to add one of these elements:

• “permissions” specifies the permissions your app will request (these will require SSL use).  They consist of:
• “Created_by” = you.
• “launch_path” identifies the file you want your app to open

1. iap = In App Purchasing
2. geolocation = Get location information
3. auth = if you request user credentials for login (facebook connect, google, your own.)

A finished web-app-manifest.JSON that uses all available fields might look like this:

Updating your web-app-manifest.JSON file

If after your app launches, you decide you want to update you web-app-manifest.JSON file, the app on device will not automatically update with new JSON file data. You will need to publish an updated version of your app. You can create an updated version of your native app in the dev portal by using the ‘Add an upcoming version’ link at the top of the developer portal page for your app (see below).

Once your new version submission is underway, you can submit and verify a new manifest, and then submit the new app version for publication.

A Tip to Remember!

Please be sure to configure your server to accommodate .JSON MIME types! For example:

.json -> application/json
.webapp -> application/x-web-app-manifest+json

More Information

You can find detailed documentation on the web-app-manifest.JSON file and on HTML5 app submission on our Dev Portal here.

Should you have any additional questions about the web app manifest file and how it is used, please send us a quick note so we can get you the answer you need.

Update – 12/18/13 - As part of our continuing efforts to simplify the Amazon Appstore for developers we have loosened the requirement for SSL in Web Apps.  The practice is still recommended but not required to pass certification for certain scenarios such as Geolocation and Authentication.  You can view additional details on using SSL in your Web App here.

Following up on the latest in a series of webinars covering Amazon devices, game services, and mobile applications, here’s a list of questions we collected during and after our presentation on HTML5 Mobile Web Apps.

Q: How much does it cost to publish my Web Apps?
A: There are no developer registration or subscription fees. There is no cost to publish your Mobile Web Apps with Amazon and all of the corresponding services, such as In-App Purchasing, are free to use.

Q: How are apps currently published, do I need to have a Website?
A: Currently Web Apps get distributed by having you host all of your current on your own Web Infrastructure. You are free to use any hosting service and we walk through an AWS EC2 Micro Instance in the recorded webinar.

Q: Do I need to make any changes to my Website?
A: We support HTML5 and responsive web design for all Web Apps. The only required change is that you create a web-app-manifest.json file and return the JSON correctly. This ensures you are the owner of the website. We also highly encourage the use of SSL.

Q: How do I test my Web App?
A: Since the Web App application is the same HTML5 code as your Mobile Web site you can do all of your testing through a browser like you would normally or your favorite Developer IDE (WebStorm, Eclipse, Sublime, Visual Studio, etc.)

Q: How do I test my Web App on a Kindle Fire or Android Device?
When you are ready to see the website running on a device you can install the Web App Tester from the Amazon Appstore. The Amazon Web App tester will run on Kindle Fire and select Android devices.

Q: How do I debug my Web App on a device?
A: The Web App Tester tool uses ADB to allow debugging of your Web App through the Chrome Dev Tools. We do a complete walk through of this process in the recorded webinar and you can get more details on our SDK website here.

Q: What HTML5 features are currently supported?
A: The current version of Web Apps is built on the open source Chromium project version 25. You can view the full list of supported features here.

Q: Can I lock the device screen orientation?
A: Yes for a full list of best practices around device orientation and other capabilities check out the SDK documentation here.

Q: How do I take screenshots of my Web App for submission to the Appstore?
A: You will need to run the Web App Tester on a Kindle Fire device and hold down the power button + volume down. Once you have taken the screenshot you can find it in your pictures\screenshots folder. You can read more details here and we walk through this process in the recorded webinar.

Q: Where can I find the current version of the Amazon Web App API JavaScript file?
A: The current Web App API library is hosted here and available for viewing or inclusion in your own web projects. The recorded webinar includes a walkthrough and summary of this file.

Q: Can I use In-App Purchasing with my Web App?
A: Yes, you can choose to implement your own In-App Purchasing or you can take advantage of the Amazon In-App Purchasing API for JavaScript. We walk through setting up the IAP API for JavaScript in the recorded webinar.

Q: Are Web Apps eligible for the Amazon Developer Select program?
A: Yes, Web Apps are eligible for Amazon Developer Select and you will automatically see the status for each of your apps under the My Apps section in the developer portal.

-Dave (@TheDaveDev)

Now is one of the best times of year to submit your apps to the Amazon Appstore and have them published for Android phones and tablets, including the new Kindle Fire line of tablets. In 2012, we saw a 50% increase in the number of app downloads during Thanksgiving week as compared to an average week. During ‘Digital Week’ in 2012, the week after Christmas, customers purchased and downloaded 600% more apps than an average week during the year.

As we’ve noted in earlier blog posts, it’s easy to get started as 75% of the Android tablet apps we’ve tested already work on Kindle Fire without any extra development. Amazon also has a tool that quickly ensures your apps have the best chance of passing both Amazon Appstore and Kindle Fire compatibility testing. Even if you’ve already got an app in the Amazon Appstore, you can use this service to check out any updates you plan on submitting.

The testing tool works fast and screens your apps for potential errors or incompatibilities. For example, you’ll learn:

• If there are structural issues with implementation of Amazon APIs
• If you are using any libraries that might impact compatibility
• If your app has features that are not supported by some Kindle Fire devices

If an issue is found, you will also get some suggestions for fixing the problem. Note, the tool is not designed to replace debugging in your IDE, and it won’t find null pointer exceptions or similar coding errors.

To get started, you can find the tool in the SDK & Tools area of the Developer Portal where there is now a link for the App Testing Service.
 

The App Testing Service detail page includes a brief description of the tool and a button that initiates the App Testing Service. Clicking that button brings you to the app testing page (below) which contains a control into which you can drag your .apk.
 

To give you a sense on the experience you can expect, I’ll walk you through the short process. I started with a small quotation app that I created and dragged it into the tool. The testing was complete in under a minute and my app passed. The tool then displayed a ‘Submit to Amazon Appstore’ button that I could use to start the app submission process.

Next, I tested the same app that used Google In-App Billing instead of Amazon In-App Purchasing. The tool caught that error and correctly identified the issue and offered suggestions for fixing my app. Here is that test result:
 

Here is another test result that identifies an error in In-App Purchasing implementation:
 

Once the test is complete, you can find the results of this and all your tests in a table at the bottom of the app testing page. This lets you go back and re-visit previous issues and recommendations across all the apps you have tested.

So don’t miss out on getting in front of all those customers during the holiday season. Save time and go to https://developer.amazon.com/tya/welcome.html and make sure your apps are ready to submit to the Amazon Appstore. 

Another follow-up in the series of webinars covering Amazon devices, services, and mobile applications, here’s a list of questions we collected during and after our presentation on the Amazon In-App Purchasing API.
 

Q&A

Q: How does amazon recommend implementing restoring IAPs for device re-installs or multiple devices?

A: For Entitlements and Subscriptions, you can use PurchasingManager.initiatePurchaseUpdatesRequest(Offset.BEGINNING); to get all the receipts for the currentUser, and you can validate any receipt against the Receipt Validation Service (not discussed in the Webinar.)
 

Q:Can I host website files on S3 for app program?  How will only legitimate app purchasers access the website? Mobile app program needs more info/examples. e-book publishers can't relate.

A: Yes. IAP does not care where entitled content is fulfilled from. You can fulfill content from an S3 server. Your app would be responsible for validating entitlement or active subscription for currentUser, and then pulling down the S3 content and granting currentUser access to that data.
 

Q: Could you show how it looks visually in some app?

A: See ButtonClicker, a sample in the IAP section of the SDK download
 

Q: I mean specific recommendations implemented inapp purchases with ANE.

A: For information about IAP and Adobe AIR ANE, please visit:
https://developer.amazon.com/sdk/in-app-purchasing/documentation/adobe.html
 

Q: Can one test in-app purchases through emulator?

A: Yes, you can use the SDK Tester to test in-app purchases through emulator. You can learn more about the SDK Tester at:
https://developer.amazon.com/sdk/in-app-purchasing/documentation/testing-iap.html
 

Q: Anything specific for Adobe Air ANE?

A: For information about IAP and Adobe AIR ANE, please visit:
https://developer.amazon.com/sdk/in-app-purchasing/documentation/adobe.html
 

Q: We are looking to restore saved game data using the userID, is this a sensible use for the ID? If so what is the maximum length of this string, does it contain only ASCII characters?

A: Good question. We recommend using the userID (player name and alias) from the GameCircle API. Using this, you can not only get an identifier for saved game data, but you can also sync game state, store high-scores and register achievements.  If you don't want to use GameCircle, getUserID will return an app-specific ID of the currently logged in user, meaning the result will be different for different apps, even on the same device. The UserID will, however, always the same for the same package name, even across devices.
 

Q: What format is the userID field? (length, character encoding, etc)

A: userID is returned as java.lang.String, see API reference for details:
https://developer.amazon.com/sdk/in-app-purchasing/reference/api-reference.html
 

Q: Is there any way we can test a real IAP before launching the app? We have been bitten by minor differences between IAPs made in dev and production environments in the past.

A: Unfortunately it is not currently possible.
 

Q: We submitted our app, but we are told the app crashes, but no device logs are provided to help us identify where it is crashing…how could we get device logs when a crash it detected?

A: I'm sorry to hear that. Please submit a Contact Us with the details of your app:
https://developer.amazon.com/help/contactus.html
 

Q: Can you also add a few more samples of html5 code for us to check so that we know our content will work on multiple devices. 

A: So far, the only HTML5 samples we have are in the SDK. Amazon Mobile App SDK . This is a ZIP file that contains the JavaScript files that are required for your application to access the Amazon services it needs. I recommend using the Web App Tester (free) to test how your content will work. 
 

Q: Will the emulator work on my desktop?

A: Yes, you can learn more about the emulator at:
https://developer.amazon.com/sdk/fire/arch-emulator.html
 

Q: For apps that are html5 with css, you mentioned on Aug 7th press release that we could take mobile websites and turn them into apps.  How do I set that website so that it is secure to purchasers?  

A: We have a quick security overview here: https://developer.amazon.com/sdk/webapps/webappsecurity.html. More detail should really be provided on a case-by-case basis with a developer.
 

Q: Will you accept a .htmlz file?  Or only html5? 

A: They way you submit a web-app is by putting a manifest.xml file at the root of your web app and submitting the path to that manifest, so submitting a file is not required.
 

Q. We submitted our in-app billing application, but it keeps getting rejected because of various reasons.  We are not receiving any device log, so it complicated to debug and resolve.

A. Please submit a Contact Us with the details of your app, our engineers will be able to assist you:
https://developer.amazon.com/help/contactus.html
 

Q. When we complete an IAP item in the dashboard do we submit it before we submit the app or at the same?

A. Entering the IAP items in the developer portal before or at the same time is okay. It's not okay to wait for some time after the app is submitted to add your in-app purchase items to the portal.
 

Don’t miss out on our next webinar event: 
Monetize Your Apps With Physical Goods Using Amazon's Mobile Associates API
on September 17th, 2013 @ 10:00 AM PDT.
Pre-register here!

Amazon GameCircle and the other game services we offer are designed to make mobile game development easier, but knowing where to start may still be difficult. To offer a bit of guidance, I thought it might be worthwhile to take a small, simple game and walk through the process of extending its functionality, one service at a time. Together we’ll gradually add features over the course of several posts, each one focusing on a specific way Amazon services speed development or reduce code complexity. At the end of the series, we’ll have a working game application that shows these services in action and demonstrates how you might incorporate them into other projects.

As the title implies, this post will kick off the series with a look at GameCircle, which supports leaderboards, achievements, and Whispersync for Games, a powerful mechanism to synchronize local and cloud data. Games have been saving progress and celebrating player success since the beginning, so GameCircle seems like a good place to begin our journey.

Prerequisites

Note that this blog series assumes that you are comfortable developing for Android using Java and Eclipse, and that your development environment is set up and working properly with the Android Developer Tools (ADT). Some Amazon services are available only on Kindle Fire, so that will be our target device throughout the series. You must install the Kindle Fire SDK add-ons in order to use those features. For more information, see the Get Started section of Kindle Fire Development Resources.

Importing the Monster Tag Project

Before we begin, we need a simple game that will serve as the base for our experimentation and improvements. Monster Tag displays a horde of monsters and asks the player to tag them as they bounce around the screen. Every time a monster is tagged, it gets startled and speeds off in another direction. The faster a monster is moving when it’s tagged, the more points are awarded to the player.

To import the Monster Tag project into Eclipse, download and extract the source bundle to a convenient location, then choose File | New | Project… from Eclipse’s main menu. Expand Android and select Android Project from Existing Code, then click Next. 

Click Browse… to navigate to the temporary location where you extracted the source code, then click OK. Check Copy projects into workspace and click Finish. 

Once the project has been loaded successfully, you will see it in the Package Explorer:

Launch the application in the debugger for the first time by selecting the MainActivity and choosing Run | Debug As | Android Application from Eclipse’s main menu. You should see a lot of little orange guys flying around, daring to be tagged.

Establishing Trust

We have a basic game application running, but we’re still not ready to integrate GameCircle and use it to track high scores online. The GameCircle service won’t accept connections from just any mobile application—it authenticates requests to ensure they’re coming from trusted apps. Every app or game that wants to access GameCircle (and some other Amazon services) must have an “API key,” which is associated with a security profile for that app. The key tells GameCircle that our app is trustworthy.

To establish a security profile and obtain an API key, we must first let Amazon know about our game, which we do on the Mobile Application Distribution Portal. Sign in or create a developer account there if you don’t already have one. (If you’re creating an account for the first time, you’ll be asked to supply some basic information and agree to some terms and conditions. If you intend to create paid apps, you’ll have to provide some extra info, as well.)

Once you’ve logged in, go to the Apps & Services tab and hover over the Add a New App drop-down, then select Add new Android App. Now we can tell Amazon the details of our game:

Generating a Security Profile

After clicking Save we could add more details, such as pricing, icons, and screenshots, but for now we’ll skip those steps and jump right to creation of a security profile. Follow the Security Profile link that appears under the app title on the next screen, then click the Create a New Security Profile button.

You’ll be asked to name the security profile. Note that you can share security profiles between applications, which we’ll discuss in a later post. For now, we’ll assume only Monster Tag will use this one, so we’ll name it accordingly:

Creating an API Key

Now we have a security profile, but no API key has been associated with it yet. Follow the API Keys link that appears after the profile name, then fill in the required fields and click Generate.

NOTE: What you enter in the signature field, below, will depend on your own development environment; you must supply the MD5 signature of your own debug keystore. You can find information about obtaining this value in the Debug application signature section of Getting Your OAuth Credentials and API Key. Typically this involves using keytool (installed as part of the JDK) from the command line:

keytool -list -v -alias androiddebugkey -keystore /path/to/debug.keystore

You should be asked to supply a password, which is “android” by default (no quotes). Check the output for the MD5 signature, highlighted below:

...

Certificate fingerprints:

         MD5:  D4:81:0C:AA:3D:45:DE:45:59:F2:BE:DE:95:A8:E1:65
         SHA1: A1:DF:DD:0D:89:77:81:24:E0:AF:47:AA:B6:55:B6:14:58:7D:4C:E4
         SHA256: 5:50:7F:6F:43:2C:3E:CD:D6:46:F1:F7:96:F2:ED:DE:E8:DD:3A:53:00
         Signature algorithm name: SHA1withRSA
         Version: 3

Adding an API Key to an Eclipse Project

Generating the API key will result in a long base64-encoded string. This is the magic value we need to include in our project to identify our app as trustworthy.

To add it to the project, create a new file called /assets/api_key.txt and paste in the value. Note that api_key.txt must be located in the /assets subfolder.

Enabling GameCircle Data for a Security Profile

Next, we must indicate that there will be GameCircle data associated with the security profile we just created, and that our Monster Tag game will use it. Go to the GameCircle configuration page, select the security profile we created and click Confirm.

Connect a Security Profile to the App

To connect our game to the correct GameCircle data, go to the My Apps tab of your profile, click the Monster Tag app, then follow the Security Profile link. Click the Monster Tag radio button and confirm the action by selecting Apply Profile on the dialog that appears.

Next Steps

Success! Our app is registered with Amazon, there’s a security profile associated with it, and we generated a corresponding API key and added it to our project. We’re ready to use GameCircle and it’s ready to accept requests from our mobile application.

In the next installment of this series, we’ll use GameCircle’s built-in leaderboard functionality to track high scores and let users compete with each other. Now that we have the app and security bookkeeping out of the way, it will be a cakewalk.

Following up on the first in a series of webinars covering Amazon devices, game services, and mobile applications, here’s a list of questions we collected during and after our presentation on Amazon Device Compatibility and Optimization.

Is it possible to test the compatibility of my existing android app with an emulator?

Yes, you can and should use the Kindle Fire emulators to test compatibility of your Android app. The Kindle Fire emulator consists of:

• The Android emulator, which is part of the Android SDK.
• Android Virtual Devices (AVDs).
• Kindle Fire system images.

The Kindle Fire system images provide the additional code needed to emulate Kindle Fire tablets.

Note: We provide ARM and x86 system images for the Kindle Fire emulator as SDK add-ons. If your development computer can run the x86 system images, which are available for all tablets except Kindle Fire (1st Generation), you should use them for faster emulation. For more information, see Understanding the Kindle Fire Emulator.

How does DRM and license validation work in the Amazon store? Can we verify it’s working once the app is live?

When submitting your app, on the Binary Files tab, developers can choose Apply Amazon DRM? If selected, only customers who have purchased the app may use it. If not, your app may be used by anyone without restrictions. To test this once the app is live, sign in to the Amazon store with a different user account (or simply sign out of the Amazon store client) and try to open the app on the device. If DRM is active, your app is protected and an error will be reported.

What versions of Adobe AIR are available? When will new AIR versions become available?

The original Kindle Fire runs Gingerbread and therefore ships with AIR 2.7. The second generation Kindle Fire, including all Kindle Fire HD devices, run IceCreamSandwich and ship with AIR 3.1. Developers that need newer versions of AIR 3 in their apps can do so by leveraging captive runtime.

Is there a low-tech solution to creating a screen-size that will work for Kindle Fire and Kindle Fire HD, like 600x600?

Please see Screen Layout and Resolution for information on designing for the different Kindle Fire screen. The simplest option would be to test each layout on the Kindle Fire emulators to confirm and tweak them as necessary. See Running the Kindle Fire Emulator for more information.

When you say unsigned apk, is that the same as not exporting the apk in Eclipse?

Yes. That is correct. We are referring to an apk not built for release.

Is there a rule, or recommendation about package names in different App Stores? Can they be the same?

Yes, they can be the same.

Can I apply a signature to my app?

All applications must be digitally signed with a certificate. The default signature applied to your app is a certificate supplied by Amazon that is unique to your developer account. If your signing strategy requires that a different certificate be applied, you may do so by submitting a request using the Contact Us form. Please indicate the title of the app for which you are submitting the request.

Is the certificate different from .keystore?

Yes. The type of certificate used by Amazon to sign a developer's application is the same type generated by standard tools like keytool or jarsigner.

Don’t miss out next webinar event: Integrating GameCirle in Your Games on July 25^th, 2013 @ 10:00 AM.

Pre-register here!

Recent news has many users increasingly concerned about privacy, and we know that your customer’s privacy is as important to you as it is to us. That’s why it’s important that you include links to your privacy policy on the product detail pages for your apps.

We require all apps that collect personally identifiable information or personal information to provide a link to their privacy policy, so if you haven’t already done so, please take a moment to submit the privacy policy link for each of your apps today. It’s quick, simple, and it’s also the right thing to do.

Please follow these steps to update the product detail page for your app with a link to your privacy policy:

1. Sign into the Amazon Mobile App Distribution Portal with your developer account
2. Go to the My Apps page then click on your app name
3. Click on Edit in the bottom right corner of the page
4. Add a link to your privacy policy in the Privacy Policy URL field, then click Save

Once you have followed the steps above and added a link to your privacy policy, the link will show up on your app’s product detail page.

There’s nothing worse than building an app that you’re proud of, submitting it and then finding it failed because of something simple that could easily have been avoided. To help make sure your app has the best chance of passing we have collected a few of the more common issues that we see to give you a head start on the process. All of these guidelines are aimed at creating a better user experience for your customers and hopefully making for a smoother process for you as a developer.

Links to other app stores

This is an easy thing to miss but is a factor in about one third of failed submissions. Apps that link to other app stores are not permitted on Amazon. To ensure a consistent experience for users, we test for these links and will alert the developer if found. To correctly link to Amazon within your app, please visit this page.

App functionality does not match its description

It may seem obvious, but an app not functioning as described is a significant factor in one in five submission failures. This can be a result of a feature highlighted in the description not being available, or failing and either showing an unhandled error to the user or causing the app to crash.

If your app relies on external assets, such as remotely hosted video files or data feeds, you should make sure all required resources are available and working as expected before submitting your app for testing as their absence often leads to these types of failures.

Call or SMS interrupt

If the app does not correctly pause, preserving state, when an incoming call or SMS arrives, or details are lost once the user has read the message or disconnected the call, then the app will fail testing.

In-App Purchasing Failure

If an app uses the Amazon In-App Purchasing API, our review process requires that the In-App Purchasing SKUs are available before the app is submitted in order to test them. The descriptions have to be accurate – leading or trailing spaces, additional special characters, or incorrect case can trigger a failure even if the expected item is available.

In addition, make sure that the SKU name in the Mobile App Distribution Portal matches the SKU in your app’s purchase request. If your app tries to purchase a SKU that’s not in the Distribution Portal, the in-app item purchase will fail. Remember that SKUs are case sensitive.

Icon Mismatch

The icon in the app package needs to match the supplied icon for the catalog. This directly relates to the user experience and the first impression when an app is installed. If the icons don’t match then the user may find it hard to find the app they just installed and rate your app poorly.

Force close on launch and other stability issues

Believe it or not, about one in 20 apps fail to even launch during initial testing. Others crash repeatedly in general usage. Stability can either exhibit as a Force Close message, an Application Not Responding condition or the app simply returning the user to the launcher screen. We also see apps that don’t crash but simply display a blank screen and never proceed.

Incorrect device targeting, poor memory management, referencing APIs that are not present on the device, or making assumptions about the SD card path, among other things, can cause stability issues.

We test on real devices with current firmware and encourage developers do the same, if possible. Once an app is live we strongly recommend you regularly check the Crash Reports in the Distribution Portal to ensure any scenarios not identified in testing are not impacting your users.

Usability

If our review process identifies significant usability issues during testing, we will fail the submission. As most developers want users to enjoy their experience, this is becoming less of an issue over time but it still contributes to failures.

Examples of things that would be flagged here are:

• The display of the app is inverted or does not react as expected on rotation.
• Images are distorted, blurred, overlapped, obviously pixilated or stretched.
• Text in the app is cropped, blurred or unreadable.
• Some (or all) controls on the touch screen do not respond in a timely manner.

Suggestions for ways to manage text and graphics for different devices are discussed in the “Screen Layouts and Resolutions” document on the Distribution Portal.

Security

To help protect your users we look for potential leaks of passwords and other data that should be secure. For example, you should not transmit or store any sensitive information, such as password, in plain text –or write them to the log in your production build.

Networking resilience

If your app relies on a data connection to function, you should always ensure that you test and handle various network conditions. These include (but not limited to):

• No connectivity
• Unreliable or intermittent connectivity
• Consistent but degraded (low bandwidth) connectivity

If your app will be downloading data over a WAN connection, we would recommend that you notify the user and ensure they are aware of that. The “Data Transfers and Mobile Networks” article has more information about how you can handle it.

Forewarned is forearmed

Testing your app against this list will help you avoid some of the most common issues we see. Reviewing the general guidelines available at the Distribution Portal will help you understand the testing process.

The philosophy behind our testing process is to ensure your users have a good experience with your app. No developer likes to be told there’s something wrong with their app, so I hope this list helps you prepare for a great submission, and I look forward to seeing your app fly through testing into the store.

The Amazon Mobile App Distribution Portal now offers the ability to submit separate APKs for Kindle Fire, Kindle Fire HD 7", Kindle Fire HD 8.9", and general Android (all non-Amazon) devices. You can find a brief overview of device targeting use in the Distribution Portal here. Below is a more detailed example of exactly how this new feature can be used.

In this example we will target all non-Amazon devices with one binary, and all Amazon devices with another binary. In order to accomplish this using our device targeting, you should create two APKs, following these steps:

Create your first binary—let’s refer to it as Binary1. Edit the Binary1 manifest.xml file so that it conforms to standard Android device targeting naming conventions. Let’s use a version name of { 1.0 } and a version code of { 1 }. Your package name stays the same for both binary(s).

NOTE: Binary1 is your non-Amazon device binary. Regardless of whether you will be updating this binary in the future, you will need to keep it as part of your future submissions for backward compatibility.

Create your second binary—let’s refer to it as Binary2. Edit your Binary2 manifest.xml file so that it conforms to device targeting naming conventions – this is done in your apps manifest.xml file. Let’s use a version name of { 1.0 } (note that version names must be the same) and a version code of { 2 } (note that version codes must be different). Your package name stays the same. Make sure that your version names for Binary1 and Binary2 are the same, and that your version codes for Binary1 and Binary2 are different.

NOTE: Binary2 is your Amazon device specific binary { xx.apk, 1.0 , 2 }. This will be submitted along with Binary1 later in the process.

You now have everything ready to submit your new app version to the Distribution Portal for testing.

1.     Sign into the Distribution Portal

2.     Go to My Apps > [choose your app]

NOTE: If you are creating a new app, you will need to select Add a New App and complete all of the tabs prior to the Binary File(s) before you will be able to upload your binaries. If you are simply creating a new version to an existing app, Add Upcoming Version (your metadata will be copied from the prior version).

3.     Fill out the fields for Binary1 (your non-Amazon version) and upload Binary1

a.     You will need to complete the prior tabs before being able to access the Binary File(s) tab

b.     Select whether or not you wish to have Amazon DRM applied to your app

c.     Click into the Binary File square to upload Binary1

d.Check/uncheck the appropriate boxes for which devices you want Binary1 to support—in this example, we unchecked all but the top box for All non-Amazon Android devices based on my manifest

e.     Select the languages your binary supports

f.      Be sure to check the Export Compliance checkbox

g.     The binary alias will default to Binary1—change the name as desired

4.     Select Save and Add a Binary

5.     Fill out the fields for Binary2 (your Amazon device version) and upload Binary2

a.     Select whether or not you wish to have Amazon DRM applied to your app

b.     Click into the Binary File square to upload Binary2

c.Check/uncheck the appropriate boxes for which devices you want Binary2 to support—in this example, we left the boxes checked for all Amazon devices: Kindle Fire (1^st Generation), Kindle Fire, Kindle Fire HD, Kindle Fire HD 8.9

d.     Select the languages your binary supports

e.     Be sure to check the Export Compliance checkbox

f.      The binary alias will default to Binary1—change the name as desired

NOTE: The server will automatically fill in any devices that are not yet supported in the Device Support section. If you do not have any further devices to support, the Save and Add a Binary button is no longer active. This is a good check to make sure you have addressed all available devices and everything has been accounted for.

6.     Select Save

If you update an app, make sure you are targeting (at least) the same set of devices as you did with your original version. For example, if you were supporting Kindle Fire (1st Generation), Kindle Fire, and Kindle Fire HD before, ensure that between Binary1 and Binary2 you are still supporting Kindle Fire (1st Generation), Kindle Fire, and Kindle Fire HD.

If you are switching to multi-binary in an app update, it is a good idea to add a release note (the Release Note tab will appear when you update an app) indicating that you are addressing backward compatibility to set proper expectations for your users. Something like the following would be appropriate: “This update addresses backward compatibility for non-Amazon devices in the Amazon store.”

Don’t forget to Submit Your App for testing after making your updates in the Distribution Portal!

A key feature of Amazon’s in-app purchasing (IAP) solution is tracking entitlements and subscriptions for users. This allows you to provide a seamless user experience when a user enjoys your app on multiple devices. Best of all, it does so without requiring you to implement any server-side code.

You have the option of implementing your own user management on top of Amazon’s existing user management. In such cases, while the device remains registered to the same Amazon user account, the app may allow the user to create an additional internal login, nickname, or any other means by which users can log in and out of the app. For apps with a user base that spans multiple OSes, this provides a means of tracking the users’ entitlements and subscription using a 3rd party user ID that is not platform dependent. This way, when a user starts the app and logs in with their credentials, the app is able to poll its own server for that user’s entitlements no matter which device or platform the app is running on.

On Amazon, an in-app item belongs to the Amazon user that bought the item. With that in mind, apps that both use Amazon In-App Purchasing and manage users internally have two sets of entitlements: one for the internal user and one for the Amazon user. These two sets might be equal, partially intersect, fully contained, or even disjointed.

The best practice in this situation, which provides for the most consistent user experience, is to entitle the logged-in user to the union of both sets. In other words, the user should have access to whatever they are entitled to as the internal-user in addition to their Amazon entitlements (see image below):

When uploading multimedia or binary files to your Amazon Mobile App Distribution Portal account, files larger than 100 MB must be uploaded using FTP. To upload your larger assets using FTP, simply follow the below instructions:

Mike Hines, Technical Evangelist for Amazon Kindle, is our guest blogger for this post.

So writing your app was the hard part. Okay, true enough;but it’s not the last part. You still need to sell your app, and a great product description will help you do that. Here's how to make sure your description puts your app in the best light.

Start with the Basics

Make sure your description is clear, honest, and straightforward. If you have a personal finance app that tracks income and expenses and helps you budget, explain why and how this is helpful and how the app works. Don’t make grandiose promises about how your app will make users wealthy; customers see through inflated claims, and your description will lose credibility.

Use the following checklist to get the basics right:

Do:

• Always use proper punctuation and grammar.
• Introduce your app clearly and succinctly.
• Describe your app's most notable features.
• Use a conversational tone.
• Explain why and how your app will benefit users.
• Show off, but don’t inflate claims. Include the attributes that make your app stand out.
• Finish with a call to action.

Don't:

• Write your product description in the web form on the Mobile App Distribution Portal. Instead, write your product description in a word processor and paste the finished result back to the Distribution Portal.
• Refer to your app only as "this app" or "an app"—use your app's full name at least once in your product description.
• Make false, hyperbolic claims—this type of marketing rarely works and may hurt your app in the long run.
• Simply list your app's features. Instead, explain why these features are awesome and worth adding to a customer’s app collection.
• Use atypical or inappropriate language that could mislead or confuse customers.

But wait, there's more! Remember—this is the Basics checklist. If you just do the things in the list above, you’ll only get an okay product description. We can do better. 

Learn from the Masters

Consider the following description:

This is a clever, addictive game that’s a lot like a word search game. It also makes you think instead of just looking for words. Create words by linking letters that disappear when you link them. When they disappear, they are replaced with letters from the grid above.

If you’re clever, you can set yourself up to create long words and get lots of points and you’ll never run out of games to play. In addition to Standard mode, there is a 'Timed' mode too. Tracked stats include 'Longest Word', 'Highest Scoring Word', 'Total Score' and more! Play MyGame in Portrait, as well as Landscape view. MyGame is the best game ever for everyone who likes puzzles and games.

This example is not “a bad example.” This product description would do alright as is, because it does several things right:

• It describes the game in terms of a reference most users will understand (“…like a word search game.”)
• It takes a shot at describing what the app actually does. (“Create words by linking letters…”)
• It describes why it is unique and may be a lot of fun. (“…you can set yourself up to create long words…and you’ll never run out of games to play.”)
• It even makes an attempt to appeal to a market. (“MyGame is…for everyone who likes puzzles and games.”)

Still, this product description isn’t brilliant. This writing probably won’t generate the enthusiasm, curiosity, or the confidence required to convert a marginally interested shopper into a buyer. It reads poorly, uses choppy structure, and is imprecise or confusing on a number of items.

Now consider a much better description of the same game:

MyGame is a word search game with a tactical twist.

Create words by linking letters within a grid of scrambled letters. Each word created is then removed from the grid and the letters above fall into the gaps left behind, creating new word possibilities. With careful play, letters can be brought into play strategically and used to create longer, higher scoring words. The starting grid is randomly generated, so no two games should ever be the same.

MyGame offers two modes of play: 'Relaxed' - for those who like to take their time and try to create the longest words, and 'Timed' - where players can test themselves against the clock to see how they score under pressure. Your 'Longest Word', 'Highest Scoring Word', 'Words Made' and 'Total Score' stats are all recorded so you can track your achievements. If you like word search puzzles, you’ll love this game. Download MyGame and start finding words with a twist today!

This description does a number of things differently than the previous description. It completes the checklist, but more importantly, it provides the following subtle improvements.

The improved description:

• Is more fluid and reads more easily.
• Includes the name of the title, and avoids unnecessary superlatives or exaggeration.
• Uses more precise and descriptive language to describe how the game works.
• Describes the uniquely fun component of the game in more detail (“With careful play, the letters can be brought into play strategically and used to create longer, higher-scoring words.”) This type of precision is missing from the first description.
• Includes context and benefits for its features.
  • It describes why long words are desirable (“…create longer, higher scoring words.”) so users have context to the benefit of ‘Relaxed’ mode (“…take their time and create the longest words,…”).
  • The score-tracking features are given a benefit statement (“…are recorded so you can track you achievements.”).
  • The claim in the first description (“…never run out of games...”) is substantiated in the second (“The starting grid is randomly generated, so no two games should ever be the same.”)
• Includes a call to action in the last sentence.

While these two product descriptions are similar, one of the big differences lies in the implementation of the required checklist elements (and, honestly, a bit of proofreading).

Refine the Nuances 

So how do you refine the nuances of your description? Use these three simple checks to see if you've met the bar.

1. Don’t ignore spell and grammar check results.
2. Read your product description out loud. This is a great test for continuity and flow.
3. Ask someone who has never used the app to read the product description and describe what the app is, how it works, and why they might want it. If they struggle to get any of those points right, or fail to see why they should buy it, you need a rewrite.

Start Today 

Trust us: It gets better from here. Even if your first few product descriptions are closer to good than great, it is okay to rewrite your description. With practice, you’ll find it easy to develop a solid, recognizable style in your product descriptions that can help establish consistency, brand recognition, and consumer trust.

So, go ahead—why wait? Get started today by using these guidelines to make a small edit or two to an existing product description.