Appstore Blogs

Appstore Blogs

Want the latest?

appstore topics

Recent Posts

Archive

Showing posts tagged with How To

May 01, 2014

Peter Heinrich

As a mobile app developer, you are probably always on the lookout for ways to increase your app’s visibility. Sometimes a good, old-fashioned sale is all it takes, and Amazon’s Developer Promotions Console (DPC) now gives you the ability to specify when you want to discount your app or in-app items. As an added benefit, promotions set up through the DPC will be featured automatically on the Appstore Deals Section of Amazon Appstore in the US and Germany, if appropriate.

The DPC makes it quick and easy to discount the list price of your apps and in-app items, perfect for promoting an update, taking advantage of a holiday or special event, or conducting price elasticity tests. You can specify in the DPC when and where these discounts are available, activating them over time in one or more marketplaces, or at a single instant worldwide. For example, you might want Amazon to discount your app 50% to promote the most recent update, or offer certain in-app items for free during a limited time. These promotion “campaigns” are a snap to create.

Get Featured Merchandizing on Amazon Appstore Deals

Once your price drop promotion is live, it will automatically feature in merchandizing on the Appstore Deals section of the Amazon Appstore in the US (and Germany, when applicable) to help drive traffic to your app.

Create a Campaign

To set up a price drop campaign:

  1. Log on to the Amazon Developer Portal
  2. Click the APPS & SERVICES tab and select Promotions
  3. Click the Price Drop button, and
  4. Choose the type of campaign you would like to create

A single campaign can discount one or more mobile apps, mobile in-app purchase items, or PC and Mac apps at a time. Every campaign type allows you to set a start and end date, but you have even more control over mobile discounts.

Fine Tune Timing and Availability

For example, you might choose to discount an app only on Amazon’s main marketplace in the US, kicking off the promotion at one o’clock in the afternoon. You have the option of using fixed or relative start and end times. Fixed means the campaign will go live simultaneously across all marketplaces you select, measured in Pacific Time. Relative means start and end times will be adjusted to a reference time zone local to each marketplace (see below for the time zone used in each case).

To fix the campaign timing across all marketplaces, click the radio button labeled Start at a single global instant (relative to PDT). To stagger availability by marketplace, click Start at the same local time in each selected marketplace.

This setting applies to start and stop times both, which you can specify only once per campaign. If you want a promotion to be active at different times for different marketplaces (but not necessarily simultaneously, as with fixed), create a separate campaign for each marketplace.

You can only activate a campaign in marketplaces where your app or in-app item is available. If the specific items you want to discount are not available in China, for example, you will not be able to select amazon.cn as a target marketplace for the campaign. Publish to any of these marketplaces and they become valid targets for your promotional campaigns:

  • amazon.com               time zone: America/Los_Angeles (PST/PDT)
  • amazon.co.uk              time zone: Europe/London (GMT/BST)
  • amazon.de                  time zone: Europe/Berlin (CET/CEST)
  • amazon.fr                    time zone: Europe/Paris (CET/CEST)
  • amazon.co.jp               time zone: Asia/Tokyo (JST)
  • amazon.ca                   time zone: America/Vancouver (PST/PDT)
  • amazon.cn                   time zone: Asia/Shanghai (CST)
  • amazon.es                   time zone: Europe/Madrid (CET/CEST)
  • amazon.it                    time zone: Europe/Rome (CET/CEST)
  • amazon.com.br           time zone: America/Sao_Paulo (BRT/BRST)
  • amazon.com.au          time zone: Australia/Sydney (AEST/AEDT)

Define Discount and Confirm Campaign Settings

After you have set start and stop times for your promotion, click Next to define the discount amount, then click Next again to preview the campaign settings. If everything looks good, click Submit to save the campaign and indicate it should be launched when the time comes.

Refine Your Mobile Promotional Campaigns

The Developer Promotions Console offers a self-service interface for scheduling temporary discounts on your mobile apps and in-app items sold through Amazon. It provides the ability to set up promotions to launch simultaneously around the world or at the same hour of the day in multiple marketplaces. These discounts can be made available everywhere or limited to specific geographic regions. Promotions you create are featured automatically on the Appstore Deals section of Amazon’s Appstore in the US and Germany, when appropriate.

Use this flexibility to refine your promotional campaigns and tailor them to your specific needs. Get more information about the Developer Promotions Console online, or simply log on to the console to look around and give it a try.

-peter (@peterdotgames)

 

April 22, 2014

Jesse Freeman

I got my first game console, the original Nintendo, in 1985 and it forever changed my life. Today, kids take for granted how accessible and abundant games are. From computers to phones and tablets, all the way up to dedicated gaming consoles, the next generation of gamers has numerous choices to play any type of game they could imagine. For developers, this means that we have multiple options where we can publish our games. In our house, the Fire TV will be my sons’ first video game console. If you are like me and you always wanted to build games for the TV, the Amazon Fire TV now offers you that opportunity, and access to an entirely new generation of kids growing up as gamers. With that in mind, I wanted to share the three key concepts I have found help make games more approachable to kids.

1. Make Engaging Games for Kids

Most developers think of kids’ games as matching, interactive storybooks and simple learning apps. Just look in the kids section of any app store and you’ll see these in droves. While a few games for kids stand out, the vast majority doesn’t take into account the fact that kids like to be challenged just like traditional gamers do. Developers can incorporate the game mechanics that core gamers have grown to love and adapt them for kids. These kinds of games will not only entertain kids, but will teach them critical thinking, teamwork, and even help them build the skills to play more advanced games.

For example, last year, I focused on making games that were similar to the games I liked to play on Nintendo but with my three year-old son in mind. The best example of this was my space exploration game Super Jetroid.

In this game, the player is challenged to explore a cave on an alien planet and try to survive while balancing their energy, health and air supplies. It’s a difficult game to master and a style of gameplay that I have always loved (it was heavily inspired by the classic game H.E.R.O. on the Atari). While the main game is way too challenging for my son, I have added in some special things to help him also enjoy the game. Some things to keep in mind to making a difficult game more approachable for kids:

  • Add a kids mode where they have extra health or are invincible
  • Remember that kids want to play the same games they see others playing so think through how the difficulty ramps up in your own game as to not frustrate them
  • Allow kids to replay the same level over and over again so they can practice and get better at it
  • Reward kids for completing levels. Add lots of collectables in the game including secret areas.
  • Kids love to explore so be careful with timed levels, try to remove timers as much as possible so they can move through a level at their own pace.

2. Encourage Collaborative Play

I cherish my game playing time with my son. Not all games are designed to be played at the same time but there are still lots of ways you can collaborate and let kids be part of the action, even in traditional single player games. Super Jetroid has a familiar level selection menu that is common among casual games these days. If you do well on a level, then you’ll unlock the next one. There are two difficulty settings: the “Serious” setting targets core gamers and the “Have Fun” setting targets kids.

In the “Have Fun” mode, the player doesn’t take damage, and has unlimited air and energy. Suddenly, the game was easy enough for my son. All of the other challenges still exist but he was able to experience the same game. Also, we could take turns playing the game as I unlocked new levels and he plays the ones that I’ve already beaten but at his own pace. When he feels more confident about the level, he can switch it over to “Serious” mode and challenge himself. This way he self-regulates the difficulty and still feels like he is accomplishing something by playing each level on the “Have Fun” mode.

Right now, I’m expanding the game for Amazon Fire TV. As I do this I am working on building in a more collaborative experience, especially around local multi-player and puzzle solving so we can work as a team to complete levels together. The Fire TV offers a great opportunity, similar to dedicated gaming consoles, to support up to 7 controllers (assuming you have a mini clan of gamers at home). It also has a second screen experience with tablets similar to what the Wii U leverages so there are lots of great multi-player and collaborative mechanics developer can explore.

3. Simplify the Controls

Knowing that every Fire TV ships with the Amazon Fire remote is an incredible opportunity to think about designing kid-friendly games with the remote in mind. There are already some great games on Fire TV that do this, including Despicable Me: Minion Rush and Badland. It only makes sense that more casual one-button style games are a natural fit on Fire TV.  

For years, gamers said touchscreens would never be good enough for immersive games because of the lack of hardware buttons. Now we are starting to see that some of the most successful games, such as Angry Birds, are the ones being built for touch. Building game controls that work on TV have their own set of limitations similar to what early mobile game developers faced. As developers, it’s up to you to think through how to make the best game possible with the broadest audience in mind, especially if you are designing for a younger player. Designing for the remote as the primary input for your game will not only capture the audience of Fire TV owners, but it also makes it easier for younger children to play. My son moves effortlessly from remote to game controller without a care in the world; he actually favors the remote since it’s easier to hold and use in his smaller hands.

In Super Jetroid there are only 3 buttons: left, right and up. On Fire TV for example, the game can be played with the remote or the controller for more precision. Even on touch screens the simplified controls work with a single virtual joystick and on desktop the keyboard. Across all of these different ways of playing I strive to have the game’s controls adapt to the device it is being played on so that anyone can simply pick up the game and play without a steep learning curve.

Start Building Games For the TV Now

While traditional console game development is still out of reach for most, the Fire TV enables developers to target the casual gaming audience right now. It’s also an opportunity to be one of the first TV-based games that kids play. There is no doubt in my mind that the types of games my son plays on the Fire TV will be his favorites for life, just like I still hold onto Mario, Zelda and Mega Man from my early gaming days. Even better, many of the games my son plays on the Fire TV are also with him on his Kindle Fire. The power of having the same game on tablet and TV with dedicated controls tailored to each experience has me incredibly excited as a game developer. This is a great opportunity to help shape the interests for the gamers of tomorrow by building fun, accessible, kid friendly games today.

So pick up a Fire TV and start making games for it as soon as you open the box!

Additional Resources

- Jesse Freeman (@jessefreeman)

 

April 17, 2014

David Isbitski

Amazon Fire TV offers your existing Android apps an entirely new set of potential customers to engage with. It also gives your customers the ability to experience your app across Kindle Fire Tablets, Android phones and tablets, and now Amazon Fire TV – all through the same Amazon Appstore. If a customer has already bought your app that you have made available for Fire TV, they can download it onto their new Amazon Fire TV instantly, without having to purchase an additional version. 

Adding Amazon Fire TV support to your existing Android App is as simple as following a few guidelines, compiling and uploading a new TV version of your apk, and then adding Amazon Fire TV as one of your app’s device targets inside the Developer Console.  

Amazon Fire TV opens up new discoverability possibilities for your app across many new customers. Most updates to your apps for Amazon Fire TV should be minor, and if you have been following the guidelines from Android on Designing for Multiple Screens all along, your app may already be ready for a large TV resolution. 

While you may be familiar with targeting Android tablets and phones, there are a few things you need to consider for your app to run correctly on Amazon Fire TV. This includes understanding the layout, dimensions and orientation of Amazon Fire TV views, changes to the user experience when interacting with a TV (10’ away on average), UI and navigation patterns, as well as some other TV-specific gotchas such as overscan and color reproduction.

Understanding Amazon Fire TV Video Output

You can think of the Amazon Fire TV screen as an Android device that is locked to landscape orientation, with a constant width of 960dp and with a height of 540dp. The rendering surface is always 1920x1080 with a screen density of 320dpi. Output is automatically scaled for 720p and 480p output resolutions.

The following table shows how the various video outputs of Amazon Fire TV map to their Android counterparts.

TV setting

Output resolution

(pixels)

Render surface

(pixels)

Density identifier

screen density

(dpi)

Display resolution

(dp)

Screen size identifier

1080p

1920 x 1080

1920 x 1080

xhdpi

320

960x540

large

720p

1280 x 720

1920 x 1080

xhdpi

320

960x540

large

480p

640 x 480

1920 x 1080

xhdpi

320

960x540

large



By following the Android best practices guide for Supporting Multiple Screens, you can create a different layout configuration just for Amazon Fire TV so that your existing layout adapts when it runs on the device. This is the same process you are most likely already using for generating different drawables and layouts and including them in your app’s /res directory. 

You can get a detailed overview of the resource configurations available for Amazon Fire TV here.

Thinking About the 10-Foot User Experience

TV interfaces in general are often referred to as 10-Foot User Interfaces (10-ft UI) because the user is viewing the screen from 10 or more feet away. Although the screen itself can be very large, the screen resolution is lower, and distance from the screen means a smaller angle of view.

The design choices you would make for an application or web page running on a desktop computer, tablet, or phone are fundamentally different from those of a TV, as users typically view those screens from much closer distances. In addition, as the television is used in a more relaxed fashion than a computer, a tablet or a phone, the UI on the TV should not require as much attention and precision. 10-ft UI may require you to rethink the design, layout, and navigation of an existing app.

Keep the design of your screen in a 10-ft UI simple and clean, with low information density. Limit the number of design elements or UI components (menus, buttons, images) on the screen, and ensure that those elements are large enough and spaced far enough apart to be read from a distance. Present a clear set of actions or options for each screen. Minimize the amount of text, as users do not read a lot of text on a television screen. Avoid requiring the user to input a lot of information and provide reasonable defaults where possible.

In your existing Android app for a phone or tablet, you can assume that touch is always present, and your UI elements reflect that. For example, if I run the existing Android Snake Game from my AWS re:Invent 2013 demo on a Kindle Fire, tapping the menu button with my finger brings up the standard Android options menu.

Figure 1- Android Options Menu for Touch on Kindle Fire

However, running the same app on an Amazon Fire TV shows a slightly different experience when interacting with the options menu. Instead of tapping our finger on a screen, we press the Menu button on the Amazon Fire TV remote or game controller, which brings up the Android options menu with the first item in the ListView (“New Game”) automatically highlighted.

Figure 2- Android Options Menu on Amazon Fire TV automatically highlights currently selected item for the user

This allows your users to know exactly where they are in the options menu. Pressing the SELECT button on the remote (the A  button on a game controller) raises that UI element’s ItemSelected event . 

Note that all of this works automatically, and you do not have to wire up any of the on screen highlighting for any of your user interface elements – that is done for you by FireOS itself. This does, however, affect the flow of interaction your customer has with your app when using a remote or a controller. Thoroughly test your app running on a TV screen with a remote or controller and make changes to the interaction where appropriate. 

For more helpful tips on modifying your app to work with remote and controllers be sure to check out our post with helpful tips.

Updating Your Android Views for TV

The Amazon Fire TV screen is always displayed in landscape orientation, with a display resolution of 960dp wide and 540dp high. In terms of Android supported screen size configurations, you should target large. If you have not created any large-screen assets, you need to verify that your existing sizes scale well.

Depending on the orientation you are using for your existing Android app, you may see some inaccurate screen sizing when running against the TV screen for the first time. In the example below I am using the code from my previous Ad Mediation post, which was set to run in portrait. 

Figure 3- App scaling and running in forced landscape

The first time the app runs you can see the scaling that occurs to accommodate the device screen size for an app forced into portrait mode. To fix this, call setRotation on any View like so:

 
myView.setRotation(90f);

This rotates the current view 90 degrees and places it into landscape mode. Another way to do this is to set the orientation of your main view inside of its layout file so that all children are rotated as well.

In fact, simply updating the orientation of the View of my main activity to run horizontally instantly fixed all of my screen issues and my app ran perfectly.

Figure 4- App scaled correctly and set to landscape

When testing out the Snake Game from the above example, I encountered a similar scaling and rotation issue.

Figure 5- Snake Game Demo running incorrectly

Instead of setting the orientation of the entire View you can also change the orientation of your activity itself. For example, inside the androidmanifest.xml file for my game, I provided an attribute for the orientation of the SnakeGameActivity.

Setting the android:screenOrientation to be landscape fixed all scaling issues with the game and made it instantly playable.

Figure 6- Snake Game fixed and running in landscape

With just a few adjustments to your apps’ Android Views and updates to their associated resource images, your apps can be displayed on an Amazon Fire TV connected screen with minimal changes.

Understanding TV Overscan, Text and Color

Overscan is the physical space TV hardware manufactures reserve around the displayable area of a TV screen and something you should be aware of when targeting Amazon Fire TV with your app. This space can exist on TVs of any size and limits the area in which your app is able to render its user interface. 

Figure 7- TV Overscan examples.

To avoid any issues with overscan, I recommend that you avoid placing any of your app's UI elements within the outer 5% of any edge on the screen.

Any onscreen text or UI elements should be fully within the inner 90% (the safe zone) of your user interface. Your text should also use larger type sizes (at least 14sp) so that they are viewable on large screens. Amazon Fire TV uses Helvetica Neue Regular as the system font throughout all of the system’s interfaces.

When testing your app you may also find that the colors are not represented the same when shown on a TV display as they are on a tablet. Because TV screens have a higher contrast, they have a tendency to make colors seem more saturated, brighter, and vibrant. The range of colors that can be displayed is also less than that of a PC or mobile device screen. Cool colors (blue, purple, grey) work better than warmer colors (red, orange) on a TV and a good rule to follow is to avoid using less saturated colors in your apps.

Figure 8- Color Saturation on TV Displays

Understanding Amazon Fire TV Navigation

If you choose to add an updated user interface to your app to better match that of Amazon Fire TV’s UI, there are a couple of guidelines you should follow. 

Figure 9- Navigation Screen Types on Amazon Fire TV

All navigation starts with the home screen which consists of a global navigation menu on the left and a set of content tiles on the right. 

Figure 10 - Home Screen

The global navigation menu is the primary system menu. It appears in a row on the left side of the screen. The global navigation menu allows the user to choose major content categories or other options including Search, Home, Movies, TV, Music, Games, Apps, and so on. Each item in the global navigation menu can be selected with the Up and Down directional buttons.

When the user focuses on any item in the global navigation menu, the home view for that node appears on the right side of the screen. Each node has its own home view with its own content. The overall system home view, sometimes called the launcher, is accessible with the Home key on the Amazon Fire TV remote, or by selecting Home from the global navigation menu.

Figure 11- Outer Space Has Been Focused on by User

Each home view contains multiple horizontal content rows. The title tile for the row indicates the type of content (for example, Most Popular, My Movies, Recommended for You). The remaining tiles show examples of that content. From these content rows, the user can:

  • Navigate between rows with the Up and Down directional buttons.
  • Move back to the navigation menu with the Left button.
  • Choose Select or Right to select a row and view a 1D list for that row.

Be sure to check out the Design and User Experience Guidelines for additional information on all of the screen types and important tips on creating an engaging user experience for Amazon Fire TV.

In addition to the global navigation, menu notifications are also displayed in a certain way within the base Amazon Fire TV user interface.

Figure 12- Informational Notification

Amazon Fire TV includes three kinds of notifications you can use inside of your own apps: Informational, Media and Modal. Informational Notifications can be used for general messages to the user, with optional actions. Media Notifications are used when the user is interacting with media inside your application (music with artist and title for example). Modal notifications are used for alerts that require user input. Modal notifications may appear at any time over your application. A modal notification takes the focus and the user must take actions to dismiss that notification.

Note: Modal notifications can only be generated by the Amazon Fire TV user interface in response to critical issues (such as an unavailable network connection). System-wide modal notifications cannot be generated by individual apps. You can use alert dialogs (AlertDialog) to create modal alerts within your app.

Figure 13- Modal Notification

Amazon Fire TV Notifications are slightly different from standard Android Notifications. Although the API for Android notifications is available in the Amazon Fire TV SDK, and apps that use that API will compile, standard Android notifications do not appear in any way on Fire TV. You must convert your app to use the Fire TV notifications API. 

One you have installed the Amazon Fire TV SDK Add-on, you will then need to import the Amazon device notification namespaces:

	import com.amazon.device.notification.AmazonNotification;
	import com.amazon.device.notification.AmazonNotificationManager;

Next, use AmazonNotification.Builder to create a notification object, as you would a standard Android Notification. The AmazonNotification.Builder class has a new required method, setType(), which indicates the type of notification. You have these notification types to choose from -- TYPE_INFO maps to Information Notifications and TYPE_MEDIA corresponds to Media Notifications.

Once you decide on the type of Notification to create you need to set up the Builder object like below:

 	AmazonNotification.Builder builder = new AmazonNotification.Builder(getApplicationContext());
	builder.setSmallIcon(R.drawable.notification_icon);
	builder.setContentTitle(title);
	builder.setContentText(text);
	builder.setType(AmazonNotification.Builder.TYPE_INFO);

Lastly, register the Notification object with the AmazonNotificationManager, as you would a standard Android Notification. You should also assign it an ID to update or cancel the Notification later.

 
        AmazonNotificationManager notificationManager = (AmazonNotificationManager)     
        getSystemService(Context.NOTIFICATION_SERVICE);
        notificationManager.notify(notificationId, builder.build())

Please note that unlike the Kindle Fire, there is currently no Notification Tray on Amazon Fire TV so if your customer is in an immersive mode app, they will not see the Notification.

For full details and more sample code on implementing notifications, check out our developer documentation here.

Handling Web Content

If your app contains any web content, you will need to do some slight modifications. By default, Amazon Fire TV does not include a Web Browser, but web content is allowed using the Android’s WebView. To use web content, set the WebClient of the WebView and override url overloading. This can be done by calling the setWebViewClient method of the WebVew to a new WebViewClient whose shouldOverrideUrlLoading property has been set to return false. 

This code ensures that your app does not attempt to load an external browser with web content and instead loads it into the WebView. You can see the url being loaded successfully into the WebView below.

Figure 14- WebView HTML content loaded successfully

Note that if you attempt to do a direct call to WebView.loadUrl without setting a new WebViewClient whose shouldOverrideUrlLoading method returns false like above you will see an error like this one:

Figure 15- webview.loadUrl security message

If you would like to link to other apps on the Amazon Appstore, for example, to cross-promote your own offerings, you can also use Android Intents with amzn:// urls, just as you can on the Kindle Fire. If you “deep link” to an app that is not ready for Amazon Fire TV we still show the detail page for the app, but customers are not able to download it. Check out this post for more information.  

Conclusion

Once your app is updated for Amazon Fire TV, your app’s listing on the Amazon Appstore runs across all the available devices you chose when you submit your app. Customers pay for your app once and begin to engage across all of their Kindle Fire tablets, Android phones and tablets, and now Amazon Fire TV. The opportunities for your customers to discover and engage with your app continue to grow!

In addition to the tips I’ve included here, be sure to check out these additional resources:

Purchase an Amazon Fire TV

Amazon Fire TV SDK Frequently Asked Questions

Amazon Fire TV SDK

Device Specifications

Display and Layout

User Interface

Design and User Experience Guidelines

Android Developer Multiple Screen Guidance

Supporting Different Screen Sizes

Supporting Different Densities

-Dave (@TheDaveDev)

 

April 16, 2014

Mike Hines

Amazon WebView (AWV) is a Chromium-derived web runtime exclusive to Fire OS. AWV makes better performing and more powerful apps possible by providing support for a faster JavaScript engine (V8), remote debugging, and hardware optimizations for Kindle Fire devices including an accelerated 2D Canvas. Enabling your Cordova project to support AWV gives you access to HTML5 features not supported by Android’s built in WebView such as: CSS Calc, Form Validation, getUserMedia, IndexedDB, Web Workers, WebSockets and WebGL.

For developers who are not familiar with Cordova, it is an open source solution that provides tools and templates that wrap web code and assets, allowing you to publish your web code and assets as if they were native apps. Cordova is also customizable via its plugin architecture which allows developers to extend the framework in order to access OS level APIs like the built-in contact list, as well as physical hardware on the device itself like the camera.  Cordova also makes it possible for two way communication from the web app wrapper to the device’s native language.

To ensure that all core Cordova plugins will be natively supported, Amazon worked with the Apache community when adding Cordova support for the Amazon Fire OS platform. Here is how to set it up on your local computer, enable Amazon Web View and create a project from scratch.

1. Install Tools

You need to make sure you have all the required tools and libraries needed to compile and package an Android application. Download and install the following (please note these links will take you to third-party sites):

You'll need to have Java installed, and the Android SDK from developer.android.com/sdk which includes the Android Developer Toolkit (adt). You may be presented with a choice of where to install the SDK, otherwise move the downloaded adt-bundle tree to wherever you store development tools.

For Cordova command-line tools to work, you need to include the Android SDK's tools and platform-tools directories in your PATH environment:

To modify the PATH environment on Mac, Linux, etc.:

  • Use a text editor to create or modify the ~/.bash_profile file, adding a line such as the following, depending on where the SDK installs:
export PATH= $ {PATH}:/Development/adt-bundle/sdk/platform-tools:/Development/adt-bundle/sdk/tools

You will also need to enable Java, Ant and/or Node from the command line. Open a command prompt and type "java", then "ant" then "node". Reinstall, or append to the PATH whichever fail to run.

This will expose the tools in newly opened terminal windows. Otherwise run this to make them available in the current session:

$ source ~/.bash_profile

To modify the PATH environment on Windows 7:

  • Click on the Start menu in the lower-left corner of the desktop, right-click on Computer, then click Properties.
  • Click Advanced System Settings in the column on the left.
  • In the resulting dialog box, press Environment Variables.
  • Select the PATH variable and press Edit.
  • Append the following to the PATH based on where you installed the SDK, for example:
;C:\Development\adt-bundle\sdk\platform-tools;C:\Development\adt-bundle\sdk\tools
  • Save the value and close both dialog boxes.

You will also need to enable Java, Ant and/or Node from the command line. Open a command prompt and type "java", then "ant" then "node". Reinstall, or append to the PATH whichever fail to run:

;%JAVA_HOME%\bin;%ANT_HOME%\bin

2. Install Cordova

Make sure you are able to invoke npm (Node Package Manager) on your command line; it's added as a part of Node.js. (You can install Node.js from the nodejs.org homepage and type NPM in the command line to validate the installation.)

To install Cordova, open a command prompt/terminal and use:

$ npm install -g cordova

On Unix-like systems, you may need to append "sudo" to ensure it is installed correctly. See Cordova's documentation for the Command-Line Interface for more details.

3. Create Cordova Project

Create project. Open a command line/terminal in a directory where you'd like to have your project stored and run the following commands to create a project and add the files needed to build for Amazon Fire OS:

$ cordova create hello com.example.hello HelloWorld

Add Amazon Fire OS platform.  Change into the newly created project directory and add the files needed for the amazon-fireos platform target.

$ cd hello
$ cordova platform add amazon-fireos

4. Install the Amazon WebView SDK

The first time you try to add the amazon-fireos platform you will be instructed add the Amazon WebView SDK. Download and extract the Amazon WebView SDK zip file from the Amazon Developer Portal.

Copy awv_interface.jar from the unzipped folder into the amazon-fireos directory found in Cordova's global working directory. Note: You'll need to create the libs/ folder manually.

On Mac/Linux:

$ mkdir ~/.cordova/lib/amazon-fireos/cordova/3.4.0/framework/libs
$ cp awv_interface.jar ~/.cordova/lib/amazon-fireos/cordova/3.4.0/framework/libs/

On Windows:

> mkdir %USERPROFILE%\.cordova\lib\amazon-fireos\cordova\3.4.0\framework\libs
> cp awv_interface.jar %USERPROFILE%\.cordova\lib\amazon-fireos\cordova\3.4.0\framework\libs

Then you will need to remove and re-add the platform:

$ cordova platform rm amazon-fireos 
$ cordova platform add amazon-fireos

5. Build your Project

Add HTML5 assets. Your web app's assets - HTML, CSS, JavaScript, images, etc.  - should be placed in the project's www folder. You can use the sample placeholder files installed as a template, or you can replace them completely with your web apps's files.

Add support for Android devices if needed. If your app is going to be used on non-Fire OS devices running Android, you can provide a fallback to the stock Android WebView engine by adding the awv_android_factory.jar file found in the AWV SDK bundle into your Cordova project under the platform libraries folder. For example:

./hello/platforms/amazon-fireos/libs/awv_android_factory.jar

Adding the code above will allow you to submit the app to the Amazon Appstore and target non-Kindle Fire devices as well as all Kindle Fire devices.

Build and deploy your project. Make sure that USB debugging is enabled on your device as described on the Android Developer Site, and use a mini USB cable to plug it into your system. (Note: Currently, testing via an emulator is not supported for Amazon WebView based apps.)

Then you can build and deploy the app to the device with the following single command:

$ cordova run

What You Can Do Now

With Amazon Web View support enabled for Cordova, you can build higher performance apps with tools like WebGL, CSS Calc and Web Workers, debug your app remotely, and see performance gains through a faster JavaScript engine and access to accelerated hardware on Kindle Fire devices.

To learn more, follow these links (some of which will take you to third-party sites):

 

 

 

April 15, 2014

David Isbitski

In May last year we announced Login with Amazon (LWA), an OAuth 2.0 protocol authentication service that allows your mobile apps for Android and iOS to securely connect with Amazon customers.

Today we are making things even easier for customers using apps enabled with Login with Amazon  on the latest generation of Kindle Fire devices.  Starting today, mobile apps and games that use Login with Amazon on these Kindle Fire devices will no longer need to ask Amazon customers to sign in each time the app is run. Instead, the first time the app is run Login with Amazon will automatically use the account registered to the Kindle Fire device.  The user will then simply need to consent to share their information once for each of those apps to be automatically signed in.

What Has Changed for Developers?

In addition to enabling single sign-on for Kindle Fire, Login with Amazon is now integrated with the Amazon Mobile App SDK with documentation available here in the API section of developer.amazon.com.  Login with Amazon is now part of your one-stop destination for all of Amazon’s Mobile App Developer offerings.

What Has Changed for Kindle Fire Customers?

Mobile Apps and Games downloaded to Kindle Fire devices that have implemented Login with Amazon will no longer need to ask customers to sign in each time.

In the below screenshot I launch the Sample Login with Amazon app from the Amazon Mobile App SDK.

Figure 1- Launching the Login with Amazon Sample App from the Amazon Mobile App SDK

The Sample App provides a Login with Amazon button for the user to click.  Since this is the first time I am logging in with the Sample App I am greeted with a prompt where I agree to consent to share specified information from my Amazon account under the Settings section.  Note, I am only prompted the first time I run the app and when I use the app in the future, I will automatically be logged in. To stop logging in automatically, go to Your Account>> Manage Login with Amazon settings and remove the app.

 

Figure 3- Giving the App permission to automatically log you in on future launches

What Versions of Kindle Fire Are Supported?

All third generation of Kindle Fire are supported including:

  • Kindle Fire HDX 7” HDX (3rd Gen)
  • Kindle Fire HDX 8.9” HDX (3rd Gen)
  • Kindle Fire HD 7" (3rd Gen)

How Do I Get Started?

To enable Login with Amazon, click on the Login with Amazon tab in the Developer Console to create or select a security profile.

Next, follow the below steps to setup your developer environment and add Login with Amazon to your app:

  1. Install the Login with Amazon SDK for Android
  2. Run the Sample App
  3. Register with Login with Amazon
  4. Create a Login with Amazon Project
  5. Use the SDK for Android APIs

The above Login with Amazon sample app is now included with the Amazon Mobile App SDK.  Simply download the latest version and navigate to  Android/LoginWithAmazon/samples/SampleLoginWithAmazonApp in the folder where you unzipped the SDK.

Learn more about the Login with Amazon API section of developer.amazon.com here.

Conclusion

By enabling Login with Amazon on your Mobile Apps and Games for Kindle Fire, you no longer need to ask customers to sign in. This streamlines the experience for your customers and increases engagement for your apps where your customers may have needed to remember their specific login credentials. 

-Dave (@TheDaveDev)

 

April 14, 2014

Jesse Freeman

We are excited to announce that developers can publish their web apps to the Amazon Appstore without a manifest. As we continue to streamline the web app submission process our goal is to make submitting hosted web apps just as easy as submitting Android ones. Now all you need to do is supply your hosted web app’s url, instead of uploading an APK, and the rest of the process is exactly how you would expect. Fill in the app’s description, upload screenshots and define your app’s permissions which allow you to quickly publish web content to the Amazon Appstore. Let’s take a look at how this works.

Our web app submission process revolves around being able to take any online website and by submitting its URL it will be published like a native app to the Amazon Appstore. For customers who have websites that support responsive design, work well on mobile, and are looking for a way to distribute their site next to native apps, this is the best solution out there for getting hosted content in the Amazon Appstore. Additionally, they can monetize their website by setting a base list price or by using Amazon’s In-App Purchasing APIs. If this is your first time submitting a web app, you simply provide a url where you would normally upload a native APK.

 

Let’s take a look at how you can get your own web app ready for submission in four easy steps.

Step 1: Verifying Your Web App’s URL

You can now validate your web app’s URL right from the developer portal.

Simply put your URL in, click the verify button and the tool will let you know if the contents at the URL pass the preliminary submission requirements. We check for the following things:

1.      Is the URL properly formated

2.      Make sure that a URL does not return a 4XX or 5XX http status

3.      URL has valid security certificate

4.      Redirects don’t lead to an eventual 4XX or 5XX code 

Just keep in mind that users will need to have an Internet connection to access your site once it’s submitted.

Step 2: Declaring Web App’s Permissions

Once your URL has has been verified, you can select your app’s permission. Simply check off the options that apply to your app.

 

Step 3: Select Compatible Platforms

Then you can define on which devices this web app can be published.

While the Kindle Fire HD and HDX devices offer the best performance for web apps, make sure you test your web app on older devices to ensure the performance is ideal for your users. Intensive web games and anything using WebGL should be distributed on Kindle Fire HD and above.

One other thing to keep in mind is that while you can install web apps in the Amazon Appstore on any Android device that has the store installed, it will default to the native WebView on that device. This means you will not have access to the optimized Amazon WebView and will see a drop in performance. Make sure to test out your URL in the web app Tester and select Android Web View to see what it will run like on native Android devices.

Macintosh HD:private:var:folders:r1:5hltj0dj3272l3kqmjr1k_k40000gn:T:3kR700:Microsoft PowerPoint.png

Step 4: Agreeing to Distribution Rights

Finally, the last thing you need to do is check off Distribution Rights.

 

This ensures that you own the domain and the rights to publish the app. We will do our own verification to make sure you are in fact the owner of this domain and are not trying to publish another site to the store.

Wrapping Up

As you can see, the process of submitting a web app to the Amazon Appstore couldn’t be easier. Now that the entire process is done through the developer portal it should take you only a few minutes to expand your web app’s user base by making it available to millions of Amazon Appstore customers in nearly 200 countries. Better yet, you now have the ability to charge for your web app or add in-app purchases to create new opportunities to monetize your online content on mobile devices.

Additional Resources

Amazon Developer Portal -

- Jesse Freeman (@jessefreeman)

 

April 10, 2014

Jesse Freeman

Add Remote and Game Controller Support to Your Amazon Fire TV Game in ­10 Steps

One of the most exciting prospects of publishing your game on Amazon Fire TV is that you can run Android games directly on the TV. If you are already building games for Android, you can use the same codebase you currently have, and make that game playable on Amazon Fire TV.

One thing to consider is how to add support for user input from the newly announced Amazon Fire TV remote and Amazon Fire game controller. Luckily, basic controller support is already built into Android.  You can leverage the Android input device APIs and the game controller API from the Amazon Fire TV SDK to get your game ready to publish in no time. Here are the top ten things you should do in order to get your game ready for Amazon Fire TV customers.

1. Think Remote First

An Amazon Fire TV remote is included with every Amazon Fire TV. That means at the very least, your app should support simple four-way navigation and selection input from the remote itself. Let’s take a look at the button layout:

 As you can see above, the remote has a standard set of navigational buttons and a single selection button in the center. That is your player’s primary means of input.  The remote also has some additional proprietary buttons including home, back and menu buttons which respond exactly how you would expect them to on any Android device. I highly suggest referring to the Guidelines for Controller Behavior for our recommendations around supporting the Amazon Fire TV remote in your game.

Also consider that the Amazon Fire TV remote is the most common input device users of Fire TV use. By designing games that will take advantage of the remote, you increase your chances of appealing to a broader audience. While you can publish games that only use the Amazon Fire game controller to the store, keep in mind that not everyone has a game controller -- those games that leverage the remote input will have a broader audience appeal.

2. Navigating the UI with a Remote

Now that we have gone through basic remote input, let’s look at how to implement the user flow in your game’s navigation. When it comes to basic UI, I simply focus on supporting 6 core inputs you receive from the Amazon Fire TV remote:

Action

Amazon Remote Button

Amazon Game Controller Button

Other Game Controller Button

Behavior

Select/
Main Action

D-Pad Center

A

A

Select the item in focus, confirm menu options or prompts, or perform the main game action.

Cancel/Back

Back

Back

B

B

Cancel the current operation, or return to the previous screen.

 

Intercept this action to provide confirmation dialogs ("Are you sure you want to quit?")

Up

Down

Left

Right

D-Pad

D-Pad

Left Stick

D-Pad

Left Stick

Move the input focus in the appropriate direction.

 

On game controllers, the left stick should have the same behavior as the D-Pad.

It is critical that you design your UI with the remote in mind. This means putting the starting focus at the correct location in the UI. This is often the most likely object your users will interact with first. Let’s look at a simple weapons store screen in Super Resident Raver and see how the UI flow works with basic directional input events:

 

Here you can see the game places the player’s focus in the store area, at number one. From there, the player can move DOWN to buy something via the Buy button, or continue moving down to the Continue button to move to the next screen. When the player is inside the actual store area, they can move from item to item using the LEFT or RIGHT navigation buttons. If they move up from the top of the item area or down from the Continue button, the focus moves to the Quit Button and the entire UI makes a full circle.

Not only should it be clear where the player can navigate to, but the game should also make sure that UI flow never lets the player get stuck or makes the user keep back tracking to find the operations they want, or missed when moving around too quickly.

3. Capturing Remote Key Events

Android has built-in support for D-Pad key events. These function similarly on the Amazon Fire TV as they did in the past when Android phones had rocker D-Pads. Let’s walk through a quick example of how to actually implement this in your own game. Just like you would support this in any Android project, simply override the onKeyDown() method in your View and use a switch statement to test the key code value that gets passed in.

Here we have some basic logic that captures the main input events from the Amazon Fire TV remote.

@Override
public boolean onKeyDown(int keyCode, KeyEvent event){
    boolean handled = false;
 
    switch (keyCode){
        case KeyEvent.KEYCODE_DPAD_CENTER: case KeyEvent.KEYCODE_BUTTON_A:
                // ... handle selections
                handled = true;
                break;
        case KeyEvent.KEYCODE_DPAD_UP:
                // ... handle up action
                handled = true;
                break;
        case KeyEvent.KEYCODE_DPAD_RIGHT:
                // ... handle right action
                handled = true;
                break;
        case KeyEvent.KEYCODE_DPAD_DOWN:
                // ... handle down action
                handled = true;
                break;
        case KeyEvent.KEYCODE_DPAD_LEFT:
                // ... handle left action
                handled = true;
                break;
     }
     return handled || super.onKeyDown(keyCode, event);
}

Now we have the building blocks for moving through our game’s UI, and we can also use this code for simple movement in a game. In addition, you can build upon this foundation by adding support for the Amazon Fire game controller.

4. Adding Controller Support

Amazon Fire TV supports up to seven Bluetooth gamepads at the same time. Here is the key layout for the optional Amazon Fire TV game controller.

Since controller support is built into Android, if you have previously worked with adding controllers to your Android game, working with Fire TV controllers will be very familiar. Leverage the default onKeyDown() method for the controller buttons just like we used for the remote, and use onGenericMotionEvent() for capturing the joystick’s movement events. This is a key concept to understand since it means if you build your game to support navigation or in-game control via the built-in KeyEvent handler, you won’t have much additional work to do in order to capture the analog movement events from the controller that are not part of the remote.

Let’s look at the two  methods in Android for handling the Amazon Fire game controller events. The first is exactly the same as what we use for the Amazon Fire TV remote support:

@Override
public boolean onKeyDown(int keyCode, KeyEvent event){
    boolean handled = false;
 
    switch (keyCode){
        case KeyEvent.KEYCODE_BUTTON_X:
                // ... handle x button 
                handled = true;
                break;
            }
     return handled || super.onKeyDown(keyCode, event);
}

When it comes to dealing with movement input from the joystick, the second override we can make to capture those events are part of the View’s onGenericMotionEvent() method like this:

@Override
public boolean onGenericMotionEvent(MotionEvent event){
    // get changes in value from left joystick
    float deltaX = event.getAxisValue(MotionEvent.AXIS_X);
    float deltaY = event.getAxisValue(MotionEvent.AXIS_Y);
           
    return true || super.onGenericMotionEvent(event);
}

You can see the full list of controller input events here. As you may have noticed from the reference table, especially with the D-Pad controls, there are primary and secondary events. While the most granular way of getting analog movement input from a game controller is the MotionEvent, the secondary event is a useful fallback that allows you to support the Amazon Fire TV remote and Amazon game controller at the same time. Another example of this is the A button which has a secondary event of KEYCODE_DPAD_CENTER.

If your game only supports the D-Pad, take advantage of the onKeyDown() method and listen for the secondary event types while ignoring overriding onGenericMotionEvent(). Likewise you can simply listen to KEYCODE_DPAD_CENTER events ignore KEYCODE_BUTTON_A events for the controller’s A button. This ensures that your game works with the included Amazon Fire TV remote and also the optional Amazon Fire game controller. The only caveat is that if you listen to both primary and secondary events you may get multiple events saying the same thing so be prepared to handle that in your code.

5. Using the GameController API

Using the built-in event handlers is helpful for Android-based games that use of Views, some games may use a custom engine or need more direct access to the current input event on a frame by frame basis. The GameController API, part of the Amazon Fire TV’s SDK offers the following things:

  • Methods to associate game controllers with the player numbers as defined by the Amazon Fire TV.
  • Methods to query controller state at any time.
  • Input event constants specific to gamepads.
  • Behavior to enable you to process gamepad input events on a per-frame basis (that is, within a game loop).

To use the GameController API simply import the correct classes from the SDK:

import com.amazon.device.gamecontroller.GameController;
import com.amazon.device.gamecontroller.GameController.DeviceNotFoundException;
import com.amazon.device.gamecontroller.GameController.PlayerNumberNotFoundException;
import com.amazon.device.gamecontroller.GameController.NotInitializedException;

From there you will have to initialize the GameController in your onCreate() method:

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    //...
    //Initialize GameController with the context to attach to the game controller service
    GameController.init(this);
}

If you don’t initialize the GameController before accessing any of its APIs, it throws a NotInitializedException exception. Once you know it is properly initialized, you can begin using it. Here are some important APIs to get more granular data over each controller’s input state:

  • Getting GameController Objects by Player - simply use GameController.getControllerByPlayer() and supply the player number for access to that particular controller. There is a constant you can use to iterate through all the controllers called GameController.MAX_Players, which is capped at 4 by default.
  • Test for Key Down - Once your have the reference to the player’s controller you can call getKeyValue() on it and pass in a constant such as GameController.BUTTON_TRIGGER_LEFT to see if that key is pressed. It will return a true or false value.
  • Get Axis Value - Likewise you can also access the analogue stick by calling getAxisValue() on the reference to the player’s controller and supply a constant such as GameController.AXIS_STICK_LEFT_X to return a float value you can use to determine the direction it is being pushed in.
  • Testing Changes In Value - Finally you can test if a change has occurred since the last frame by calling getAxisValue() and supplying a constant such as GameController.AXIS_STICK_LEFT_Y. This will return a Boolean to help you decide if you need to apply a new change in the game.

While the above code is simply here to illustrate how this works, I suggest going through the GameController API documentation to see more sample code that you can use in your own game. Also, make sure you check out the GameController Event Constants as well.

6. Supporting Multiple Controllers

Now that we have covered the basics of the GameController API, let’s talk about multi-player games on the Amazon Fire TV. While you can connect up to seven Bluetooth game controllers to the Amazon Fire TV, only four of those controllers are assigned to player numbers in the GameController API. Getting the player’s number from the API is an easy way to manage your game’s players. You can use this by calling GameController.getPlayerNumber() and supply an Android Device ID to get the player number for that device. Likewise, there is a helper method to get you the Android Device ID if you call GameController.getDeviceID() and pass in a player number. You can iterate through all the devices by using the GameController.MAX_PLAYERS constant.

If your game supports more than four players, you can manage controllers and player numbers manually. For most games though, four is a great experience for local multi-player and you will find that the Amazon Fire TV is more than capable of keeping up with the action. While you can also do remote multi-player via standard networking APIs, keep in mind that you will have to manage that system separately from the game running on the Amazon Fire TV.

7. Handling Interruptions In Your Game

Your game should be prepared to handle interruptions. At the very least, make sure you support Android’s native onPause() and onResume() methods in your View. This is critical when the following events or situations happen:

·         Remote or Controller Drops - if you lose the connection to the main input of the device, possibly due to a battery or connection issue, you want to make sure your game is able to pause itself immediately. You should also build in some simple way to test that the controller is still active. This is critical in multi-player games; if one player drops you need to immediately pause the game.

·         User Presses the Home Button - if the user presses the home button on the controller, no event is raised, but onPause() is called. Your game exits back to the home screen.

·         User Performs a Search - once the user tries to perform a search, the event cannot be intercepted and onPause() will be called in your View.

·         User Presses the GameCircle Button - this immediately takes the user to the GameCircle dashboard while in your game.

It’s also important to capture ‘back’ events and handle exiting the game from a ‘back’ button properly. If you are on the home screen of your game and you receive a back button event, your game should prompt the user if they actually want to quit.

8. Building Controller Friendly UI

Each interactive UI element should have the following states:

  •           Enabled
  •           Disabled
  •           Highlighted
  •           Selected

These states are critical to helping your player understand where they currently are in the UI and also what action they can do. Sometimes you may need to have multiple states such as Disabled Selected in the case of the Resident Raver store scenario where it’s possible to select an item that can’t be purchased just to see what the price is.

On the same topic, it’s also important to take the Highlight state of the other UI elements into consideration. Here is a screenshot with the main UIs Selected states visible.  The selected state moves as the player moves around from main UI element to main UI element.

Finally, no matter what you end up designing, make sure there is consistency in each button state so that the player can intuitively understand where they are on the screen and what they need to do next.

9. Handling Joystick Dead Zone

Like all controllers, the joystick needs to be properly calibrated. Many things can happen that may mess-up the alignment of the joystick. At the very least, you need to account for adding a joystick dead zone to ignore joystick movements that are not large enough to cause an actual require a movement event to be recognized. Here is an example of how you can calculate this by using the GameController API.

gameController = GameController.getControllerByPlayer(1)
float x = gameController.getAxisValue(GameController.AXIS_STICK_LEFT_X);
float y = gameController.getAxisValue(GameController.AXIS_STICK_LEFT_Y);
float value = (float) Math.sqrt(x * x + y * y);

Here the formula returns a value between 0 and 1. You can choose how aggressively you want to ignore controller drift. A good place to start is somewhere above 0.25f - 0.35f. Test that the value is greater than your allowed dead zone value before applying the movement. In addition to this, I also suggest allowing the user to recalibrate their joystick in the options menu. Nothing is more frustrating than an unresponsive or “sticky” joystick control in a game.

10. Clearly Display What the Controls Are

Before any of my games start, I always show a screen with the game’s controls. While most people skip right over this, there will be a few who stop to read it in order to figure out what they will need to do in the actual game.

This also means making sure you remove any reference to touch controls, especially if you ported the game over from mobile. Also make sure you remove on screen pause buttons and sound buttons. Sound in your game should be managed via the TV’s remote. The only exception is if you have two separate user configurable volumes for the sounds effects and music which I would still keep in as long as it can be modified via the remote or controller directly.

Wrapping Up

There is a lot to consider as you begin to add support for the Amazon Fire TV remote and Amazon Fire game controllers to your game. It helps to take a step back and map out how this should all work. Having poor controls in your game will not go over well with your players, so nailing tight, responsive, and intuitive controls is critical to launching a successful game on the Amazon Fire TV. Also,look to other similar TV based gaming experiences for inspiration on how your UI and game controls should work.

For More Information

Amazon Fire TV Remote Input: Learn how to handle input from the Amazon Fire TV remote.

Amazon Fire Game Controller Input: Learn how to handle input from game controllers (both the Amazon Fire game controller and other game controllers).

GameController API: The Fire TV SDK includes a utility API for games to help you manage game controller input. This API includes the ability to associate player numbers with controllers and to manage input events on a frame-based basis.

Identifying Controllers: Users may pair up to seven Bluetooth controllers to the device at a time. Learn how to identify different controllers paired with the system and interpret input from those controllers.

Controller Behavior Guidelines: For consistency with the Fire TV user interface and across different apps we suggest you implement the guidelines in this document for controller behavior.

Controller Image Assets: If your app or game provides instructions or help screens for how to use a controller, you may freely use the controller images and button hints on this page in your app.

 

- Jesse Freeman (@jessefreeman)

 

April 07, 2014

David Isbitski

This quick video will give you an overview of the Amazon In-App Purchasing API.  It will cover how to get started, offer advice on popular In-App items and categories, and cover the process for creating your own In-App SKU catalogs.  Whether you are completely new to In-App Purchasing, or have existing items for sale on other Appstores like Google Play, this video will help point you in the right direction.

April 04, 2014

Mike Hines

Go Live when You Want To

Amazon has recently added the ability to specify the date and time you would like your app to go live on the Amazon Appstore. This gives you the ability to coordinate your app release on Amazon with releases on other stores and in conjunction with any press or social media launch events you may wish to plan.

How Does It Work?

You start by completing the new app submission or the app update submission as you normally would, but make sure that you enter the date and time you want your app to go live in the Availability & Pricing section (see image below). Times are shown in Pacific Standard Time.

Then you simply submit your app as usual.

What Happens Next?

Submitted

When you first click the ‘Submit’ button, your app will display the status “Submitted” for up to 60 minutes until we kick off testing for your app.

Under Review

Typically, within 60 minutes of submission, your app will enter testing regardless of the launch date you have chosen. This lets us notify you of any issues prior to your launch event. While your app is being tested, your app status will show as “Under Review”.

Approved

If your app passes testing, your app will be staged on our servers, waiting for the date and time you specified. During this waiting time, your app will show an “Approved” status in the Developer Portal.

Live

At the time of your launch, we complete the publishing process to make your app available in the Amazon Appstore. We work hard to complete the testing process as quickly as possible, and our goal is to publish at least 90% of apps within 60 minutes of the time specified. Once publishing is complete, your app will have the “Live” status in the developer portal.

You can edit the launch date and time any time prior to your app going “Live” in the Appstore.

What You Can Do Now

Mike Hines

@MikeFHines

 

March 11, 2014

Mike Hines

If you are a developer who has had an app in our store for a while, or someone new to our platform, we encourage you to use Amazon Appstore and Kindle Fire badges and branding to help promote your app.  In this article we’ll review badges, other images, links and guidelines for their use with your app and marketing.

Badges:

There are two badges with three color-treatments each that you can use. Here are the badges that you can use to promote the availability of your app in our U.S. store:


The Amazon and Kindle Fire badges above are available in English, Spanish, German, French, Italian and Japanese. The Amazon badges are also available in Portuguese.

You can get full-size downloads of these badges on this page, along with some usage guidance.

Other Images

If you’d like to use a plain icon:

Or if you would like to use a Kindle device image:

You can find links to those resources about half way down this page.

Links to the Amazon Appstore

For web-browser based linking, please:

Use this link structure: http://www.amazon.com/gp/product/ASINnumber/ref=mas_pm_app_name

Replace the bold “.com” with your country marketplace suffix. (.com for US, .de for Germany, etc)

Replace the bold “ASINnumber” with your mobile app’s ASIN (Amazon Standard Item Number) and app name. Please use an underscore (_) to separate the words in the “app_name” portion, if your title is more than one word. You can find the ASIN on the Product Details section of your mobile app on www.amazon.com/apps.

For example, this is the Air Patriots link in the German marketplace:

http://www.amazon.de/gp/product/B008KE3960/ref=mas_pm_air_patriots

For in-app advertising or mobile app-based linking:

In the US:

Use this link structure: http://www.amazon.com/gp/mas/dl/android?p=com.example.package&ref=mas_pm_app_name

Replace the bold portions with the package name of your APK, and app name respectively.

For our international stores:

Use this link structure:

amzn://android?p=com.example.package

Replace the bold portion with the package name of your APK.

NOTE: With any of these link structures, please test the links before using them to make sure that they direct to the correct page or search results.

The link instructions above are pretty much identical to the guidance near the bottom of this page.

Other Useful Guidelines

There is still more good stuff on the handy page I keep linking to. This includes guidelines for correct use of the Amazon Appstore trademark when blogging or using social media to promote your app. I would, of course, be remiss if I failed to mention the legal requirements listed at the bottom of the page. Our attorneys have done a good job of breaking the important points down into easily readable bullet points. Please do look at them, it won’t take long.

Just in case you missed the link earlier, you can read all of this information here, on our developer portal.

 

February 14, 2014

David Isbitski

When displaying ads in your apps and games, you may want to know how often you are actually displaying ads to your users, what types of ads are being displayed, and how your users are interacting with an ad. 

Thankfully, the Amazon Mobile Ads API includes events that can aid you in understanding performance of ads displayed on your apps.  You have the ability to track when an ad is successfully displayed from the Amazon Ad Network, how long a user views an ad, and when your user opens or closes a rich media expandable banner ad.  These events should help you track and better understand user behavior in your apps when ads are being shown.

With a guaranteed CPM of $1.50 for banner ads displayed on qualified apps during March and April (up to 2 million impressions per app per month), there has never been a better time to get started using the Amazon Mobile Ads API.

Handling Ad Events

All of the events associated with an ad provided by the Amazon Mobile Ads API will be returned by the AdListener interface.  Once you have declared an instance of an Amazon AdLayout, setting an event listener to the layout will let you track the entire life cycle of an ad. 

Keep in mind all of the listener's events are part of the main UI thread.  So if you are planning on executing any long running tasks you should do so in an AsyncTask.

Capturing Metrics When Ads are Loaded

You can capture metrics in your app each time an ad is loaded using the AdLoaded event.  AdLoaded is called each time an ad is successfully served by the Amazon Mobile Ad Network, and available for display.  You can use this event to adjust your app’s user interface when a new ad is loaded or to keep track of the type of ads you are being served. 

For example, if you have a game, you should choose to delay displaying the AdView until the player is at a point where an ad will not interrupt gameplay.  In the below example I am updating a TextView each time an ad is successfully loaded and then adding the AdView to the root container for display.

You can get additional properties about the ad being served at runtime through AdProperties.  These properties can help determine if your ad is a static banner or a rich media expandable banner.  Static banners are HTML web views that typically open an in-app browser, native browser, or Android Intent.  Rich Media Expandable Banners are HTML web views that expand in-app with rich interactive content (including videos), but also typically include opening an in-app browser, native browser, or Android Intent.

 

In the above screenshot, I have set a breakpoint to get information from the AdProperties variable.  There are four types of information that are filled by AdProperties.  These include:

  • adType - possible values are 'Image Banner', 'MRAID 1.0' or 'MRAID 2.0'.  MRAID stands for Mobile Richmedia Ad Interface Definition and will determine the capability of the rich media expandable banner.
  • canExpand – determines if the ad can be expanded
  • canPlayAudio – determines if the ad plays audio when expanded
  • canPlayVideo – determines if the ad plays video when expanded

Trigger changes when an ad expands

The onAdExpanded and onAdCollapsed events are called when a rich media expandable banner ad has been clicked by a user and is either expanded or collapsed.  You can use this event to pause your game or suspend background audio music when an ad has expanded, among other options.

 

Handling Ad Load Errors

If an ad fails to load, the AdListener.onAdFailedToLoad event returns an AdError object that contains an error code and a descriptive response message.  For example, the onAdFailedToLoad event below is logging the ad error message, removing the Amazon view from the UI, and then loading a Google AdMob view to request an ad.

 

It is important to keep in mind that the there is no logic to retry loading an ad.  If you encounter an error, you should decide whether to call AdLayout.loadAd again based on the error code returned. 

The error codes are helpful in debugging where errors may be occurring; server side, network based, or within the app code itself.  In the below example we see an AdError occurring due to the developer setting an incorrect view size.  This can happen if an ad is requested before its parent view is available. 

 

The possible error codes that can be returned include the following.

  • NETWORK_ERROR The ad request failed due to problems with network connectivity. Try again when a connection becomes available.
  • NO_FILL The ad request succeeded but no ads were available. Don’t retry immediately.
  • INTERNAL_ERROR The ad request failed due to a server-side error. Try again but limit the number of retry attempts.
  • REQUEST_ERROR There is a problem with the ad request parameters. Do not retry. Review the error message and update your app accordingly.

For specific error message descriptions, please refer to the following chart on our developer portal here.

You can get more information on the Amazon Mobile Ads API including code samples and training videos here.

-Dave (@TheDaveDev)

 

February 13, 2014

Jesse Freeman

The Current HTML5 Landscape

In a world quickly moving toward mobile device adoption, there is a growing pressure for web developers to learn new languages in order to adapt to the ever-changing landscape of content delivery. For the past 16+ years, web has been the king of mass distribution. But now as app stores on mobile devices are driving huge monetization opportunities, how do web developers stay competitive in this new “post PC world”? The key is to understand how you can maximize your web app’s potential in the distribution vs. monetization model.

The Distribution Vs. Monetization Model

As developers look to create new content, be it a web app or native app, they should be thinking about the following model:

 

The distribution vs monetization model.

 

The concept is that the larger your distribution base, the better your chances of monetization are. Along the far side of the x-axis is the native mobile and tablet space, which is fragmented around several different platforms, and the individual platform distribution potential is much smaller. On the flip side, since all mobile devices and computers have web browsers, an online web app’s potential reach is staggering.

The reality of this however has been that even with the smaller distribution of mobile, developers are seeing much higher opportunities to monetize on those devices. On the web, we have seen more difficulty to monetize that content without the help of built-in systems like IAP (in app purchase) or integrated checkout, which are generally available on native devices through their app stores. The ideal solution would be to actually target both demographics, and the only platform we have seen that is capable of effectively doing that is HTML5.

Scaling Your Web App

When most developers hear “scaling a web app” they instinctually think about the backend or server side of things. But over the past year as responsive design has come into its own, we are finally seeing websites that can not only run on desktop browsers but elegantly reconfigure themselves to accommodate all the different viewports users are visiting with.

The most common responsive design resolution breakpoints.

The forethought that goes into building a truly responsive design that flows correctly from desktop to mobile phones is no small task but the opportunity for capturing the largest possible distribution is worth it. Gone are the days of splitting off your web traffic between a mobile only site and a desktop site because the cost of maintaining both grow exponentially. But what about still reaching native app stores?

But What About Still Reaching Native App Stores?

Some of the current solutions on the market for publishing HTML5 content next to native apps have revolved around the PhoneGap/Cordova model. These allow the developer to package the web app and submit it to a native app store. But there is one glaring downside to this kind of distribution; you lose the ability to maintain a single codebase. In an ideal world, you would want to simply redistribute your online app in a mobile store and keep the two in sync. This is some of the thinking behind our HTML5 web app resources for Amazon Appstore.

Own Your Content and Keep it Online

The last thing a developer would want to do is fork a project and end up maintaining multiple code bases to support each platform it is distributed on. So why not just keep your content online where it will get the largest potential for distribution and still submit it to an app store that offers you an entirely new way to monetize it? This is a fairly new publishing model that has been growing more and more popular over the past few years. It offers the best of both worlds since you maintain a single place were your web content can live and you gain the added benefit of being able to distribute your app in a native store. With that distribution comes the potential of increased monetization by simply charging for the app, using IAP or continuing with your current ad based model.

The best part is that you can experiment with this new type of distribution today in the Amazon Appstore with our HTML5 Web App Tester. Simply download the app, point it to your site’s URL and test out how your web app works. From there it’s easy to submit to the Amazon Appstore and begin reaching a whole new audience.

 

February 11, 2014

Mike Hines

There is still plenty of room for more great mobile apps. That is, if you’re thorough and obsessed with quality. Recently, I was reminded of the importance of doing a solid job of testing all aspects of an app when reviewing geography bee apps.  

For the last two years, my son has competed in his middle school geography bee, and rather than suggest that he spend his time buried in an atlas, I suggested a handful of apps designed to help students prepare for geography bees. Of the apps that we found, not one app was rated 5-star by customers.

The shortcomings of these apps generally fell into one of three categories:

  • The app was different than described
  • Poor UI/workflow impeded use
  • Deal-Breaker Bugs

Description should match the apps

Sometimes an app might be useful but just doesn’t deliver what a customer expected based on the description. Imagine an app that purports to be a Geography Bee study app, yet quizzes for dates of events and asks for definitions of sedimentary rocks. Some of the apps we tried were like this, being better suited to geology or history quizzes than to a geography bee.

What can you do?

Make sure the product title and app description accurately reflects what the app actually does. The apps that I was disappointed in were not bad apps, just a bad fit for my needs.

Streamlined User Experience

Sometimes an app had solid content, but the navigation was too confusing or it took too many steps. I’m in the business of apps, so I’ll give any app a thorough review. But many users won’t bother to enter their name and age every single time the app launches. And if a customer loses their user state in the middle of a series of questions, you can bet they’ll be frustrated. 

What can you do?

Think more like a user. For example, when a student uses a geography bee app, more than likely they’ll be interrupted. The app not only needs to go from start to finish cleanly, but it also needs to tolerate interruptions, be fast to re-enter, and avoid re-doing completed work. Have someone else try the app and see what he or she tries to do. If they seem frustrated, then it’s probably worth considering whether the experience needs to be re-designed in some way.

Squash the Bugs

Strangely enough, some bugs were easier to live with than problems with UX or failure to deliver on value. Bugs, like truncated buttons, pixelated graphics or having to tap twice on an answer, might cost a star in the rating, but they still leave the app usable. Other bugs, like text entry boxes hidden under keyboards, were considerably more problematic. The app whose UX I liked the best contained outstanding educational content, but it didn’t get much use because it kept crashing on both iOS and Android tablets.

What can you do?

Be maniacal about your QA. If your resources are constrained, there are solid testing services out there. The services have apps that they can refer you to, so you can get a sense of how well the testing works. Check out the referral apps, and if the quality seems top notch, consider using them to help with your QA. This attention to detail can go a long way to help you get the app rating you’re looking for.

 

February 10, 2014

David Isbitski

Setting up your Kindle Fire device for testing and debugging is a simplified process thanks to Android Debug Bridge (ADB) support.  Since questions around ADB driver support have come up on Stack Overflow and our developer forums I thought it would be beneficial to walk through the setup process. 

Certain development tools referenced in this post are provided by third parties, not by Amazon. Any links to these tools will take you to third-party sites to download and install them.

Getting Started

Note – this post was updated on April 16th, 2014 to reflect changes in the Amazon Android SDK addon.

First, ensure your development computer has at least one package of Kindle Fire system images installed. This is critical because the package includes the vendor identification needed for ADB to recognize any of the physical Kindle Fire tablets.  This is done through the following steps:

  • Ensure you have the Android SDK already installed
  • Launch the Android SDK Manager
  • Under Tools, select Manage Add-On Sites, and enter the following url: http://kindle-sdk.s3.amazonaws.com/addon.xml

  • Select Close and wait for the list of available packages to refresh
  • Select Kindle Fire USB Driver, Kindle Fire Device Definitions, and optionally the Amazon AVD Launcher.

  • Select at least one Kindle Fire image so that vendor information is available for ADB.  I’ve chosen to select the three Kindle Fire 3rd Generation images (API Level 17).

  • Accept the license agreements and install.

For complete information about setting up your development computer and installing the SDK packages, see Setting Up Your Development Environment.

Uninstalling existing Windows drivers

If you installed a previous version of the Kindle Fire USB driver then take the following steps to remove the previous USB device driver and force re-installation of the driver.

  • Connect your Kindle Fire tablet to the USB port on your development computer.
  • On the development computer, from the Start menu, right-click Computer, and then click Manage.
  • In the left pane, under Computer Management, expand System Tools, and then click Device Manager.
  • In the right pane, expand Portable Devices.

  • Next, Right-click Kindle and then click Properties.
  • In the Kindle Properties window, on the Driver tab, click Uninstall, and then Confirm.

  • Finally, unplug your Kindle Fire tablet from your computer.

Enabling ADB on the Kindle Fire

Next, we need to turn on ADB support on our actual Kindle Fire device.  Follow these steps:

  • On your Kindle Fire tablet, go to Settings.
  • On a third-generation Kindle Fire tablet, tap Device.  On a second-generation Kindle Fire tablet, tap Security.  First-generation Kindle Fires already have ADB enabled by default so no action is needed.
  • Set Enable ADB to On, and then accept the pop-up warning message.       

As a security precaution, you should set Enable ADB to Off when you are not trying to connect to the Kindle Fire tablet to your development computer.

Installing Windows ADB drivers

First, ensure you have enabled ADB on the Kindle first as described above.  For the USB driver to install correctly, Windows must recognize the device as Android Composite ADB Interface during installation. If ADB is not enabled, Windows instead recognizes the device as Portable Devices.

Do the following to install the Kindle Fire USB driver:

  1. In your Android SDK directory, at \extras\amazon\kindle_fire_usb_driver, run KindleDrivers.exe, and then follow the instructions on the screen.

  1. Connect your Kindle Fire tablet to a USB port on your development computer.
  2. From Start, click Control Panel, and then select Device Manager.
  3. In Device Manager, under Kindle Fire, verify that the device appears as Android Composite ADB Interface.

Next, do the following to detect your Kindle Fire tablet through ADB:

  1. Open a command prompt window.
  2. Change directory to your Android SDK platform-tools directory.
  3. Run the following commands and confirm that the serial number for your Kindle Fire tablet appears in the list of devices.

adb kill-server

adb start-server

adb devices

If the serial number does not appear after running adb devices, do the following:

  1. Change directory to your Android SDK tools directory.
  2. Run the following command:

android update adb

  1. Change directory back to your Android SDK platform-tools directory.
  2. Run the following commands:

adb kill-server

adb start-server

adb devices

If your Kindle Fire device still does not show up you may need to reboot your development machine and then try again.

Installing Mac OSX ADB drivers

Perform the following steps if your development computer runs OS X:

  1. Connect your Kindle Fire tablet to a USB port on your development computer.
  2. Open a terminal shell and navigate to your Android SDK tools directory.
  3. Run the following command to update ADB.

./android update adb

4. In the terminal shell, navigate to your Android SDK platform-tools directory.

5. Run the following commands and confirm that the serial number for your Kindle Fire tablet appears in the list of devices.

               

If your Kindle Fire device does not show up in the list of devices you may need to reboot your development machine and then try again.

You should now be able to fully test with your Kindle Fire device over the Android Debug Bridge.  For additional information on enabling ADB for Kindle Fire Devices, see Setting Up Your Kindle Fire Tablet for Testing.

-Dave (@TheDaveDev)

 

January 30, 2014

Russell Beattie

Creating an application using Amazon's Mobile App Distribution Program is a great way for developers who have hosted web apps to create downloadable apps available on the Amazon Appstore. Web app developers benefit from the increased discoverability that the store provides when users are searching for new apps, as well as being reminded to use the web app by the icon on their device's home screen afterwards. In addition, all of a user’s linked devices that use the Amazon Appstore will have the icon waiting in their Cloud list of apps as well.

And because web apps are hosted online, developers have increased flexibility to re-use existing assets and make changes or fixes to the app quickly and easily, without having to re-create a new app that has to be re-installed by the end user. But what happens if the user wants to use the app offline? Obviously, if the app relies on live server-side content - such as streaming videos or airline reservations - then obviously it's not going to work. But if the web app is self-contained and doesn't need to talk to a server for its core functionality - like most games - then being able to take the app offline is something that should be an option for users.

Happily, enabling your web app to be used offline can be done using HTML5's built-in Application Cache with only a few small changes to your code. Below I'll outline the steps you need to take to create a basic offline web app. It's surprisingly easy to set up, but beware! Application Cache has a well deserved reputation for being difficult for developers to get a handle on.

Offline Web App Walkthrough

1. Create Manifest File

The first thing you need to do is create an HTML5 manifest text file with a list of every asset file your web app requires - HTML, JavaScript, CSS, images, icons, fonts, etc. The manifest file can have any name you choose, but we'll use app.appcache to be clear and to avoid overlap with other types of manifest files.

Here's the content of a basic manifest file:

CACHE MANIFEST 
# Version 1.0 
CACHE: 
main.js 
main.css 
logo.png 
NETWORK: 
*

- The first line needs to be CACHE MANIFEST.

- The second line in this example is just a comment, but is useful to make changes to your web app by simply incrementing the version number. Note: Only changes to the manifest file will invalidate the cache.

- The third line begins the CACHE: section where you list out the asset files used by your web app, either relative to the location of the manifest file, an absolute path or complete URL. Note: DO NOT list app.appcache in your manifest.

- The NETWORK: section has a wildcard which permits the browser to download files that are not listed in the CACHE: section. Note: Without the NETWORK: section, the browser will ONLY re-request files listed in the CACHE: section after the initial page load.

2. Confirm Server Settings

You need to also make sure your web server serves the correct MIME type for the manifest file. For Apache, it looks like this:

AddType text/cache-manifest .appcache

You also need to makes sure the manifest file is not being cached on the server. If the HTTP Cache-Control header for the manifest file doesn't update, or a 304 Not Modified is return, then the web engine won't be able to see if the manifest file has been changed or not, which is the only way to invalidate the offline cache.

3. Add Manifest Attribute

You then need to add an attribute to the tag of every HTML page you serve pointing at the manifest file, like this:

<html manifest="app.appcache">

4. Add Update Script

Finally, you need to make sure your app updates itself if the manifest changes - the easiest way to do this is to add this bit of JavaScript to your main HTML:

<script>
window.applicationCache.addEventListener('updateready', function(e){
    window.location.reload();
});
</script>

5. Test

Your web app should now be offline enabled! If you have Python installed, you can test this by setting up a local server to see what's happening both on the server and in the browser.

beattier@amazon.com:~/html5demos/offline$ python -m SimpleHTTPServer

Serving HTTP on 0.0.0.0 port 8000 ...

1.0.0.127 - - [21/Jan/2014 13:42:52] "GET / HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /app.appcache HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /main.css HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /main.js HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /logo.png HTTP/1.1" 200 -

... 

If you request the page again, you'll see that *only* the manifest is requested.

1.0.0.127 - - [21/Jan/2014 13:43:12] "GET /app.appcache HTTP/1.1" 304 -

By modifying the manifest file and reloading, you'll see that all the files listed will be re-downloaded again.

You can also connect the Amazon Web App Tester to see the client side of the process as well by using Remote Debugging. (See our previous overview of setting up the Tester here.) In the screenshot above, I've connected to a Kindle Fire HDX and loaded a demo offline web app stored on Github. By looking at the Resources tab and drilling down into the Application Cache folder, I can see the assets that are cached locally, and a log of the Application Cache events.

Application Cache Gotchas

This is just a basic way to setup an offline web app. There are more options that you can add to your manifest file, more events you can track in JavaScript and more functionality you can use to make your web app's offline experience much more seamless to the end user. Check out the links below for more information.

Conceptually, it's important to understand that once you've enabled a manifest, your web app is now offline first and forever. Let's repeat that for clarity: OFFLINE FIRST AND FOREVER.

OFFLINE FIRST means:

- Your web app's files will then always be loaded from the offline cache first, and then a request will be made to the server for the manifest file to see if there have been any updates.

- The browser will not automatically refresh if the manifest has changed. It will in fact download the files from the server, but it will wait until the next time the page is requested to use them. This is why the script in step 4 above to detect a manifest change and immediately refresh the page is important.

FOREVER means:

- The only thing that can invalidate the offline cache and trigger a re-download of files is a change in the contents of the manifest file - not just the timestamp.

- There is no programmatic way to invalidate the offline cache from the browser. Even changing or deleting the manifest attribute in the tag will not invalidate the cache.

- Until the browser requests a manifest and receives a 404 or 410 from the server, it will continue to consider the web app as being offline and use the last downloaded version, rather than updating from the server.

Summary and External Resources

The info above should be able to get you started with offline web apps. Once you've added in the manifest, your web app will be available offline the next time your users load up your app. Fair warning: This can be a tricky feature to implement - especially if you misconfigure or forget some of the steps above. Getting the browser to let go of the manifest and refresh your code can be incredibly frustrating. I think the upside is worth it though, as enabling your web app to be used anywhere a native app can be used is incredibly satisfying.

To get more information about Application Cache, I encourage you to check out these great articles which dive into the topic in even more detail.

·         http://diveintohtml5.info/offline.html

·         http://www.html5rocks.com/en/tutorials/appcache/beginner/

·         http://www.html5rocks.com/en/mobile/workingoffthegrid/

·         http://alistapart.com/article/application-cache-is-a-douchebag

In future posts, I'll expand on offline apps by looking at topics such as offline data storage and efficient caching strategies.

-Russ (@RussB)

 

Want the latest?

appstore topics

Recent Posts

Archive