Derek Gebhard, Solutions Architect, a2z Development Center Inc., an Amazon.com company, is our guest blogger for this post. 

If you are optimizing your app for Kindle Fire HD support, one of the things to think through is camera integration. In this blog post, we walk through the front-facing camera optimization Allrecipes explored as they added Kindle Fire HD support to their popular Allrecipes.com Dinner Spinner for Android app.

When developing for the Kindle Fire HD, you should keep in mind that the Kindle Fire HD has a front-facing camera. Most Android devices come with a rear camera, and a number of apps—such as Dinner Spinner—take advantage of this. This means you will need to adjust a few things in your app if you want to use the Kindle Fire HD’s camera. The interesting challenge that Allrecipes.com ran into when exploring this support is that the front-facing camera API became available in Android 2.3 (Gingerbread), API level 9, which can be a problem if you want to support older Android API levels and other devices with the same code. The Allrecipes app development team solved this by checking if the rear camera is available, and if not, using reflection to see if they can fall back to the front-facing camera.

Here’s a look at the code for how you could implement this in your app to obtain the Camera object:

public static Camera getCameraInstance() {

   Camera camera = null;

   try {

      try {

         // Attempt to getthe first, back-facing camera

         camera = Camera.open();

      } catch (Exception e) {

         Log.e(TAG, "Camerafailed to open: " + e.getLocalizedMessage());

      }

      if (camera == null) { // Failed to open camera

         // Obtain classesand methods needed for accessing front-facing camera

         // Use reflectionto support API levels lower than 9

         Class<?> cameraClass = Camera.class;

         Class<?> cameraInfoClass =Class.forName("android.hardware.Camera$CameraInfo");

         Object cameraInfo = null;

         Method getNumCamerasMethod =cameraClass.getMethod("getNumberOfCameras");

         Method getCameraInfoMethod = null;                

         Field facingField = null;

         int cameraCount = 0;

         // Verify theneeded class and method exist

         if (getNumCamerasMethod != null && cameraInfoClass != null) {

            cameraCount = (Integer)getNumCamerasMethod.invoke(null, (Object[]) null);

            // Obtain objectsneeded for checking if a camera is front-facing

            cameraInfo =cameraInfoClass.newInstance();

            getCameraInfoMethod =cameraClass.getMethod("getCameraInfo", Integer.TYPE, cameraInfoClass);

            if (cameraInfo != null) {

               facingField =cameraInfo.getClass().getField("facing");

            }

         }                              

         // Iteratethrough cameras to obtain front-facing camera

         if (getCameraInfoMethod != null && facingField != null) {

           for (int cameraIndex = 0; cameraIndex <cameraCount; cameraIndex++) {

               getCameraInfoMethod.invoke(null, cameraIndex, cameraInfo);

               int facing =facingField.getInt(cameraInfo);

               if (facing == 1) { // 1 == Camera.CameraInfo.CAMERA_FACING_FRONT  

                  // Open front-facing camera

                  Method cameraOpenMethod =cameraClass.getMethod("open", Integer.TYPE);

                  if (cameraOpenMethod != null) {

                     try {

                        camera = (Camera)cameraOpenMethod.invoke(null, cameraIndex);

                     } catch (Exception e){            

                        Log.e(TAG, "Camerafailed to open: " + e.getLocalizedMessage());

                     }

                  }                        

               }                          

            }

         }

      }

   } catch (Exception e){         

      Log.e(TAG, "Camerafailed to open: " + e.getLocalizedMessage());

   }

   return camera; // returns null if camera isunavailable

}

The above function is not only useful if you are addingsupport for the Kindle Fire HD to your app and want to allow existing rear-facingcamera scenarios to continue working, it is also useful when you are startingoff creating a Kindle Fire HD app and want to leverage the rear camera whenyou add support for other Android devices. The one thing to keep in mind isthat reflection is more expensive than calling the APIs directly. You shouldonly use this method if you need to support an API level lower than 9.

For moreinformation on leveraging the Camera object to take pictures and videos you cancheck out the following documentation:

• http://developer.android.com/guide/topics/media/camera.html
• http://developer.android.com/reference/android/hardware/Camera.html

When developing for the Kindle Fire HD and Kindle Fire HD8.9”, it’s important to consider how your screenshots will appear on your product page for those devices. When customers are looking for new apps on their Kindle Fire tablets, they’re looking at all of the information on your product page – description, screenshots, and customer reviews. Providing high definition screenshots will make sure that your app looks great when customers are shopping for apps on Kindle Fire HD and Kindle Fire HD 8.9”.

Screenshots are accepted in the following high definition resolutions: 1280 x 720px, 1280 x 800px or 1920 x 1200px, in either portrait or landscape. You can update your app’s screenshots in the Mobile App Distribution Portal.

1. From the Distribution Portal, navigate to the MyApps tab. Select the app you’d like to edit and navigate to the Images &Multimedia tab for that app. Then, click the Edit button.

2. Select Upload Image from the Screenshots. You can submit up to 10 screenshots in PNG or JPG format.

3. When finished, tap the green “Save” button at the bottom right of the page.

Kindle Fire tablets use a soft key toolbar to provide a versatile user experience. In an earlier post on the Kindle Fire (1^stgeneration), we discussed how developers can optimize their layouts for the soft key toolbar . With the new screen sizes and capabilities of Kindle Fire tablets, there are more options to expose, use, and control the soft key toolbar in a dynamic manner.

In our earlier post on optimizing layouts, we detailed how the soft key toolbar can appear at either the bottom of the screen (in portrait mode) or along the right side of the screen (in landscape mode). The soft key menu is either fully visible, or if collapsed, revealed by a tap on the drag handle.  When designing your app, you should be aware that the soft key toolbar and the drag handle appear over your content rather than resizing the drawable area.

The Soft Key Toolbar

By default, the soft key toolbar contains buttons for “Home, ”“Back,” “Search,” “Favorites,” and an overflow menu. Certain other APIs, such as GameCircle,can also position icons on the soft key toolbar.

Expanded soft key toolbar

Soft key toolbar collapsed just showing drag handle

Using the Home Soft Key

Kindle Fire uses this key to replicate the functionality of the standard Android device button. Apps must appropriately use the Home soft key to allow quick navigation to and from the Kindle Fire carousel.

By default, the Home soft key returns users to the Kindle Fire carousel. When the home key is pressed, the current activity’s onPause() method will be called before the user is presented with the carousel. When your app is re-launched, the onResume() method will be called. In order to ensure that the app returns to its previous state, your app should save state in the onPause() method and reload the state in the onResume() method.

For more information about the onPause() and onResume() methods, please see our earlier blog post in the Top10 Optimizations for Kindle Fire series.

The Back Key

The back soft key's default action is to call finish() on the current activity and then resume the previous activity on the stack (as managed by the OS).

If your app has launched several activities and you want the back soft key to return the user to the previous activity, you don't need to do anything—this is the default behavior. If the user is already at the main activity of your app, the back soft key will call finish() on the activity and exit your app.

A typical solution to prevent premature exiting of the app is to override the back soft key functionality on your app's main activity to trigger a confirmation dialog. Override the function of the back soft key in an activity by including the following code in the Activity class:

@Override

public void onBackPressed() {

  // do something when the back button is pressed

  return;

}

The Overflow Menu

To maximize screen real estate in your mobile apps, you can place less frequently used actions on the overflow menu. The overflow menu can hold a maximum of 6 items and does not scroll or word wrap; try to keep your text small and use consistent capitalization and punctuation for clarity. Easily instantiate your menu when the user presses the overflow menu button by overriding the Activity.onCreateOptionsMenu method in your Activity class as described here.

The Search Button

If you want to provide app specific search then you need to override the onSearchRequested functionality and handle the action as described here.

@Override

 public booleanonSearchRequested() {

   // your logic here

   return false; // don't bubble up to thedevice search box

 }

Screen Layout Considerations

If you are working with the soft key toolbar, it is important that you are familiar with the layout guidelines to understand how it impacts the available screen size. 

Status Bar - Quick Settings

Although not directly related to the soft key toolbar, it is worth noting that when the toolbar is visible, the status bar is visible as well, which means your app should also be prepared for the user to interact with the Quick Settings capability, as well as the layout to cater for that overlay.

Status bar visible,showing notifications and access to Quick Settings.

For more details, please refer to the App Optimization and User Experience Guidelines.

Amazon Mobile App Distribution Program will be at AnDevCon IV from December 4^th-7^thin San Francisco, CA. Come meet us –we’ll be on-site and ready to answer your technical and business related questions in the exhibition center.

As a follow-up to our post yesterday, “With Great Battery Power Comes Great Responsibility”, the author, Moe Tanabian, will be speaking at AnDevCon about the same topic. At Moe’s class, you can learn more about developing power efficient Android apps. He will be covering:

• An overview of batteries that are used in Android devices, their chemistry, charge and discharge behavior
• How to objectively measure power consumption indifferent application and usage scenarios in Android devices
• Areas that an application developer and/or a device designer can effectively control to optimize power consumption, including screen usage, UI design, network services usage, and input devices usage
• Setting up a power profiling and power consumption lab that doesn’t break your bank account

If you’re interested in attending AnDevCon, here’s how to register. Plus, if you use the promotional code KINDLE FIRE, you’ll get an additional $200 off of the registration costs.

We hope to see you there.

Kindle Fire HD has a 7" high-density (hdpi) screen supporting a resolution of 1280 x 800 pixels (a 16:10 aspect ratio). This provides a great opportunity to revisit the design of existing apps to take advantage of the extra space and optimize your app layout for both portrait and landscape orientation.

Normally, there is a 35 pixel status bar overlaid at the top of the screen, along with an area allocated to the soft key toolbar that is dynamically positioned based on the orientation of the tablet.

In portrait mode, the soft key toolbar overlays the bottom78 pixels (giving a total usable area of 800 pixels wide by 1167 pixels high),and in landscape mode, it overlays the rightmost 78 pixels (giving usable dimensions of 1202 pixels wide by 765 pixels high).

If your app needs to use more of the screen (e.g., in a game or playing a video), it is possible to shrink the soft key toolbar down to just a 67 x 38 pixels drag handle or hide it completely by using one of the two available full screen modes.

Full Screen Modes

The standard full screen mode hides the status bar and soft key toolbar but leaves a small drag handle visible: 67 pixels by 38 pixels(wide by high in portrait; high by wide in landscape) floating over the content and centered on the edge of the tablet where the soft key toolbar would have appeared. Tapping the drag handle returns the soft key toolbar to the screen, allowing the user to interact with it. 

public void onCreate(Bundle savedInstanceState) {

  super.onCreate(savedInstanceState);

  setContentView(R.layout.main);

  finalView view =getWindow().getDecorView().findViewById(android.R.id.content).getRootView();

  lp.flags= WindowManager.LayoutParams.FLAG_FULLSCREEN;

  getWindow().setAttributes(lp);

}

In full-screen mode for Ice Cream Sandwich (ICS), the drag handle disappears as well. If the user taps anywhere on the screen in this mode,the drag handle will reappear, allowing the user access to the soft key toolbar.

public void onCreate(Bundle savedInstanceState) {                   

  super.onCreate(savedInstanceState);

  setContentView(R.layout.main);

  finalView view =getWindow().getDecorView().findViewById(android.R.id.content).getRootView();

  view.setSystemUiVisibility(View.SYSTEM_UI_FLAG_HIDE_NAVIGATION);

  lp.flags= WindowManager.LayoutParams.FLAG_FULLSCREEN;

  getWindow().setAttributes(lp);

}

There is more information on both full screen modes available in the UserExperience Guidelines. A sample app, covering screen layout modes and how to control the status bar and soft key display, is available at https://developer.amazon.com/sdk/fire/samples.html.

If you are designing your app to support multiple layouts, you may want to take advantage of the new (since API level 13) density pixel configuration qualifier layout resources. For example, since Kindle Fire HD has a layout of 533 dp wide (in portrait mode), you would place your resource definition inlayout-sw530dp .This is derived from the fact that Kindle Fire HD is an hdpi device and uses a generalized dpi of 240 for dp calculations. The width is computed using the following: width = (800/ (240/160)). See this article on Supporting Multiple Screens for more information.

In addition to optimizing the layout for the size of the device, you should also supply appropriate density graphics for your app, or make use of vector graphics. This ensures that the experience scales smoothly and efficiently, making the best use of the hardware capabilities and creating the best possible user experience.

Although it is usually a better experience if you design your app to support both landscape and portrait modes, in some cases you will want to lock orientation to better fit the design—for instance, a full screen game or video player. If you choose to control the orientation of your app, you should review the recommendations to ensure the best experience for the user.

For more information on this topic you can refer to the App Optimization and User Experience guidelines.

Moe Tanabian, Software Development Manager, a2z Development Center Inc., an Amazon.com company, is our guest blogger for this post.  Moe recently presented on this topic during the Android Developers Conference (AnDevCon) in May.

One of the challenging issues of building mobile devices and applications is energy consumption management. In order to support users’ mobility, and their various uses of their devices, it is necessary to make light and reliable battery-powered devices with batteries that last longer.

Smartphones and tablets are getting faster, their screens are getting bigger and brighter, their CPUs run on faster clocks, and their daily usage time is getting longer as users use them for a wider variety of functions.

The advances in battery technology have been much slower than the evolution of device technologies and their usage patterns. In fact, most modern mobile devices are powered by battery technologies that are over a decade old. That is why most efforts to prolong battery life are focused on making hardware and software more power efficient.

Knowing about power consumption and the behavior of applications on mobile devices is fundamental in making batteries last longer. There are four factors that determine how much energy a mobile device, and by extension a mobile app, consumes: The battery, the device hardware, the software that runs on the device, and the user workload.

We know that batteries and battery technologies have been slow in getting more energy dense while most hardware is getting more power-hungry. Let’s look at how we can optimize software to lower power consumption and to adapt to user behavior and workload—from an app developer’s perspective.

Power Consumption Measurement

The first step toward optimization is to measure power consumption of an application. We can use direct and indirect methods to measure the energy that an application consumes.

Direct method: Ina direct method, a relevant use case is run on the device, and using a high sampling frequency logging power-meter, an amp-meter or a volt-meter the drawn power from battery is logged. These logs are analyzed later to determine how much power was consumed to complete the use case. Figure 1 shows how a mobile device is connected for direct power measurement.

Indirect model based method: In an indirect or predictive mode based method, first we develop a power consumption model of the device based on its power consuming components. In atypical mobile device, these components include the CPU, the screen and screen illuminator, memory and flash, Wi-Fi, Bluetooth and cellular radios, GPS receiver, and available sensors on the device such as accelerometer and gyroscope as they are shown in Figure 2.

The total power that is consumed by a device (P_t) is the sum of the power consumed by the main components, plus a constant k. For the component i (for example the screen brightness) the drawn power can be modeled as the product of an associated system variable C_i, and the component’s coefficient B_i  for the time that the component is active, which is the test duration. This forms a regression estimation model that can be trained using training data observed from a direct method measurement for all components of interest.

Once the model is trained and k and B_i are determined, it can be used to estimate power consumed for a particular use case by simply plugging in the collected values of C_i from logs.

Logging and Instrumentation for Power Consumption

Instrumentation is one of the basic ways to understand the power consumption behavior of mobile device software. With adequate logging, areal-time service can deduce where and how power is consumed. Good power consumption logging covers instrumentation of the following points and events:

• Logging an associated system variable for each component that is considered important from power consumption perspective. Examples are when the screen turns on or off, the display brightness level, CPU utilization along with CPU clock, Wi-Fi, cellular, and Bluetooth radio parameters such as on/off state and TX power if available, state of sensors on the device, and finally, state of the battery.

• Important internal events that can change the running state of the app including timers, and power manager related events. For example when the device changes its state from Idle to suspend or active, or when the screen is turned off or when its brightness changes.

• Externally driven notifications and events such as incoming calls, SMS and other type of messaging.

• Logging instrumentation should have enough data in the logs, that at the time of post-processing, it should be clear which device, which user, and which session the log belongs to, and of course, without compromising the user’s privacy.

• Another important factor is the frequency of logging. It’s a good practice to make logs granular enough so that post-processing can reveal useful information about the power that is being consumed across different components for apps that are of interest. At the same time, logging too frequently itself can put excessive overhead on the device which not only will skew the results, it will lower device’s performance and shortens its battery life. Determining the optimum logging frequency depends on the target’s device’s capability, and the power manager’s internal timers and behavior. A good rule of thumb when logging is to try not to impact user experience in a demanding application, such as CPU/GPU intensive games. For most modern mobile devices, a logging power consumption variable at a frequency of 0.2-1Hz should provide enough granularity while avoiding excessive load on the device and user experience.

Power Consumption Optimization in Mobile Applications

Optimizing for power consumption requires a holistic approach that touches most decisions about designing and developing a mobile application. Ultimately, better battery life provides a better user experience and makes for more satisfied users.

The best way to optimize for battery life is to identify the most offending areas in the software and optimize them first. What constitutes the most power-consuming features greatly depends on what features users use most,and this varies from user by user. Best battery life optimization mechanisms are the ones that recognize users’ usage patterns and adapt the optimizations accordingly. In this section I’ll introduce general practices that can improve power consumption in a mobile application.

• Avoid accessing the disk and network too frequently. These are expensive operations when it comes to power consumption. Instead, try to batch up your disk reads and writes, and network operations and do them less frequently. It requires a lot less power to send 3 MB of data every 30 minutes than breaking it up into 30 iterations and sending 100KB every minute. This is because the power manager on the device minimizes power consumption by aggressively turning off major power consuming components such as radios and screen, when they are idle for a period of time. If the user or an application triggers a component frequently—for example, by sending data on a network in the case of the Wi-Fi radio—the power manager will have to turn on the radio and this can drain the battery very quickly. The same applies for CPU utilizations. Group CPU intensive tasks together and run them in bulk as much as possible, rather than in multiple chunks. This allows the CPU to go to sleep more often and save battery.

• Avoid using exact time timers and requesting high precision locations from location services. Similarly, avoid reading other sensors such as the compass and accelerometer too frequently.

• Avoid complex 2D and 3D UI, especially in multi-layer UI designs. Many graphic processors are not able to optimize complex graphics adequately and spend valuable cycles drawing parts of the screen that are not visible to the user because either they are outside of the visible area, or they are hidden behind other overlapping layers. Simple UI design has the additional of benefit of being very fast, and that’s user-friendly. Additionally, complex UI generally lowers FPS (frames per second), which degrades user experience.

• Design simple user interactions and avoid providing users with a complex set of choices and UI elements. Humans are not very efficient when they have to select among too many choices. Our response time increases substantially when we have to pick a selection among many. This is called cognitive latency and a good UI design minimizes cognitive latency. This in turn minimizes the time that the user spends on a fully rendered UI and lit up screen and it lowers power consumption.

• A darker UI is more power efficient than brighter UI.

• While this may sound obvious, it’s often neglected: avoid running unnecessary code. If your application transitions into the background and there’s no user interaction, stop listening to events, timers, and any other trigger that can unnecessarily wake up the application. For example, if your application receives stock tickers from a server and this triggers a UI update, avoid updating the UI if the application is in the background state. An even better practice is to halt the network connection and re-establish it again when the user brings the application back to the foreground.

References

1. Pro Android Apps Performance Optimization(Professional Apress) by Hervé Guihot
2. iOS App Programming Guide; http://developer.apple.com/library/ios/DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/iPhoneAppProgrammingGuide.pdf
3. Design and testing for longer battery life in Android Devices and Applications by Moe Tanabian, http://www.slideshare.net/mometan/an-devconii-moetanabianssh

Whispersync for Games provides an easy way for developers to tackle two major requests from mobile players: a way to avoid losing saved game data and a way to have their saved games follow them from device to device. This helps ensure a great customer experience while also giving developers a powerful tool to aid player retention and re-acquisition.

For most games, a carefully crafted progression scheme with purposeful pacing and escalating challenges is a key factor in providing players with many hours of entertainment. The effort put into playing the game,learning the strategies, unlocking achievements, and setting high scores represents a significant investment for the player. If their saved data, and all the effort that represents, is lost, the chance of them playing the game again plummets.

Loss of data isn't a common occurrence, but it can happen when someone loses a device, upgrades to a new device, or simply uninstalls the game to make room for other downloads. Regardless of the reason, implementing Whispersync for Games lets developers store their saved game data in the Amazon cloud so they never have to worry about lost progress being an impediment to player retention.It also helps overcome hurdles when attempting to re-acquire lapsed players.Adding new features and releasing content updates are a great way to keep a game fresh, but when a customer has to start over from the beginning because they don't have their old saved data, that's a significant barrier to getting them to play a game again.

Loading Saved Data from the Amazon Cloud

Integrating Whispersync for Games is a straightforward process and directions can be found on the GameCircle API page in the Mobile App Distribution Portal. GameCircle handles the heavy lifting, but there are some things you can do to ensure players have the best possible experience:

Always provide a helpful description when syncing data to the Amazon cloud. Whispersync for Games is usually a seamless experience for the customer, but there are times when they need to make a choice on whether to sync from the Amazon cloud data. This most commonly occurs when a player is switching from device to device and playing the same game. If the player wants a totally separate experience on the two devices, they can disable Whispersync for Games. If they haven't, we can't be certain whether their intent is to pick up where they left off or to resume playing from the saved state on the device so we give them the choice. The description you set in the synced data provides them with the information they need to make an informed decision. GameCircle will automatically display the time and device the data came from, so your description should reference something iconic or memorable within the game. The name of the level they were on, the last big story moment before the save, or how many widgets they've collected could all be good descriptors depending on the type of game.

 Choosing Which Saved Data to Use

Ensure that you'resyncing data at the appropriate times. You don't need to sync on every player action, but you should do so at major game checkpoints such as when they complete a level or reach other important milestones. It's also a good idea to sync data when a player pauses the game since that's a common indication that they have ended their current play session. Whenever you perform a sync operation, players will see a rotating Whispersync for Games icon so they know their saved games are being stored to the Amazon cloud.

Syncing Data on Level Completion

With thenew Kindle Fire HD tablets finding their way to customers over the next few months, there's never been a better time to add Whispersync for Games to your apps. Players will be upgrading to new tablets and trying their favorite games to see how they look and play. Having their saved game data stored in the Amazon cloud lets them easily pick up right where they left off, making it more likely that they'll keep playing your games after the transition.

We are pleased to announce that you can now submit apps for distribution later this year in Japan.  This is another significant addition to Amazon’s complete end-to-end platform for developers looking to build, market,and monetize their apps and games. You can get started today by visiting the Amazon Mobile App Distribution Portal.

Our community of app developers around the globe have made Amazon's mobile app distribution very successful, with millions of customers discovering and buying Android apps for their phones and tablets.  Amazon recently expanded distribution into the United Kingdom,Italy, France, Germany and Spain; allowing developers to attract even more customers.

Amazon’s developers have reported strong monetization from the apps they have distributed, thanks to services like In-App Purchasing and Amazon’s secure, 1-Click purchasing. The In-App Purchasing API makes it easy to offer digital content and subscriptions —such as in-game currency, expansion packs,upgrades, magazine subscriptions and more— for purchase within their apps.Amazon’s secure 1-Click purchasing experience gives customers a seamless shopping experience when purchasing content. Developers distributing game apps on Amazon’s platform in the U.S. have also reported increased player engagement using Amazon GameCircle, which offers features like leaderboards,achievements and syncing game-state between Kindle devices.

All developers have the ability to select the countries where they would like their apps to be sold and set list prices by marketplace.  We encourage all developers to localize their apps for different regions and to think of creative ways to deliver unique experiences to new customer segments.  By customizing your apps for different countries you can ensure customers have an easier time discovering and using your apps, In-App Purchase items, and subscriptions.  You can learn more about Android localization tips and resources and steps for localizing your app in the Distribution Portal right here on the blog, or learn more about international app distribution on the Mobile App Distribution Portal. 

New to Amazon?  We’re currently waiving all first year program fees It’s free to register for a developer account for new developers and it’s easy to download our SDK here.  

Dasha Kobzeva, Head of Marketing and PR, Playrix, is our guest blogger for this post.

Playrix is a strong team of more than 100 inspired professionals, dedicated to creating multi-platform video games of the highest quality. The company was founded in2004 and since the very beginning we've been striving to accomplish our mission- to bring fun to millions of our players worldwide by creating unique games.It is impossible to fulfill our mission and engage a truly global audience without localizing our apps into different languages.

We have seen a significant increase in the number of downloads and monetization levels on various platforms after launching a localized version of the game, that is why we believe that developers should not overlook this opportunity.

Here are a few tips we’d like to share with fellow-developers on how to manage localization based on our own experience:

1. Localize Smart

Obviously there is no need to localize an app in every language out there. Pinpoint the markets that have higher download and monetization rates for your apps and work on the localized versions for these territories. If you do not have enough time or resources to localize the content, make sure to localize your metadata (descriptions and screenshots). It may improve your download rate and attract wider audience.

2.  Put Extra Thought into Your App’s Title

Whether to localize the app name or not is a tough question. On the one hand, players might be confused to see different names of the same app in different languages, and sticking to a single name will help to consolidate the game’s brand worldwide. On the other hand, it might be a good idea to localize the name if the universal title makes no sense in the target language or is simply misleading. For instance, when we first brought one of our flagship PC titles, Fishdom, to the German market,online portals were reluctant to use the original English name and wanted us to change it, because in German the name of the game might have been perceived as“Fish Cathedral”. However, at that point the game was very popular and successful in the US, and we decided to stick with the same name, but given different conditions, we might have gone with a more German-friendly name.

3. Provide Contextual Information to Your Translators

Cultural differences may drive characters and story-lines to be perceived differently across markets and languages. Research the markets you are entering and keep cultural differences in mind when localizing your app so that the essence of your apps or games are consistent globally even after translation.  Make sure to provide as much contextual information as possible: screenshots, description of the characters, design documentation, string length, character limitations, playable build of the game, link to the existing game or prequels, etc. One of our games, Gardenscapes, features a character, the butler, who uses a lot of British-style jokes and puns, and we wanted to bring this inimitable and funny character to users worldwide in all its integrity. Providing your agency with thorough instructions will save your time eventually and contribute towards quality.
 

4. Strive for Quality

No matter whether you decide to work with internal translators or an agency, make sure you have a quality translation in the end. Remember that a bad localization is worse than no localization at all. Here at Playrix, we carry out internal linguistic QA after the localized content has been added into the app.  If working with an agency, prepare detailed and clear instructions to prevent over-the-top email exchanges.
 

There are many reasons to want a screenshot from Kindle Fire HD: taking screenshots for visual marketing materials on your app’s detail page, posting on your own site for promotion, marking up design changes, or simply to have a user show you an issue they’re seeing.

For developers it’s  easy to get a screenshot – connect your device or emulator to the Dalvik Debug Monitor Server (DDMS) and then just click the camera icon to grab an image of whatever is on the screen.  On the Kindle Fire HD, however, there’s a simpler option that doesn’t require developer tools or USB cables:

When the image you want to capture is on the screen, simply press and hold the Power and Volume Down buttons at the same time.  You will hear a shutter sound and briefly see an image of the screen with a border around it. As soon as you’ve taken the image, release the two buttons and the device returns to normal.

To use the screenshots on the device you can use a file explorer app, send an e-mail and add the images from /Photos/Screenshots as attachments, or connect the Kindle Fire HD to your PC or Mac and access them from the USB mounted drive.

Amazon offers a Kindle Fire HD 7" emulator to test and debug your apps if you don't have a Kindle Fire HD 7" device. While we recommend developers test their apps on a physical device, you can test many aspects of your apps without running your code on a device. This allows you to be confident that the user interface, navigation and flow through the application are as you designed it. If you need to test the same application on multiple devices you can quickly compare the experience without juggling cables.

As the emulator images reflect the underlying devices as closely as possible, they include support for some of the Kindle Fire unique capabilities such as GameCircle, In-App Purchasing, and Maps.  Because the emulator images run as self-contained virtual machines, it is possible to have multiple, concurrent instances allowing you to deploy and compare results simultaneously. As you can imagine this leads to very efficient, iterative development making device-specific interface adjustments easier to manage.

To ensure that the emulator performs as well as possible on a range of computers,we support GPU emulation which delivers a smoother graphical experience and faster start-up experience. While this will help performance throughout the emulator for host computers that support these capabilities, it will have the most impact in graphics-intensive OpenGL- based applications such as games.Learn more by following the instructions at this link. 

Another tip we can offer is to preview the customer experience as if the user is signed-in.  Kindle Fire HD comes to customers pre-registered, and our trusted 1-Click purchase process increases purchase and download of your apps and in-apps items.  Because users of your apps will be signed in, we recommend you test the user experience as a user who is signed-in.  The Kindle Fire HD 7” emulator will not be signed-in by default.  To preview the experience of a registered user, you should navigate to Settings->My Account and then register the device with a valid Amazon account.

Ready to get started?  Review the documentation, install the emulator, and give it a whirl. We’d love to hear your feedback in the forums.

With the launch of our Kindle Fire HD family of devices, we are introducing a new feature called Amazon Device Targeting, which offers you the ability to target APKs to specific devices.  While it is easy to support optional APIs and device capabilities within a single binary, you may decide that it is easiest for your apps to generate different binaries for the Kindle Fire and Kindle Fire HD.   For each title, you can now offer separate APKs for Kindle Fire, Kindle Fire HD 7", Kindle Fire HD 8.9", and general Android(all non-Amazon) devices.  

Amazon’s Device Targeting feature provides several benefits for your mobile apps:

• Better search relevancy for your app: Instead of having multiple apps for a similar title, your reviews, page views,downloads are consolidated to a single app—pushing your app up in search and relevancy rankings. 
• Reduced customer confusion:  Customers won’t be confused by multiple device-specific versions of your app.
• Device specific feature optimization: Tailor your APK for screen size and density, OpenGL compression format, and API version. 

User Experience

You may be wondering about the experience of your customers if you leverage the Amazon Device Targeting feature.  Say a customer owns both a Kindle Fire HD device and an Android mobile phone.  The customer downloads or purchases one of your apps on their Kindle Fire HD device. When the customer moves to their Android mobile phone, the correct APK is delivered based on screen and size density, OpenGL compression format, and API version—a by device optimized customer experience.   Customers will appreciate not having to sort the differences between Kindle Fire and regular editions of your app.  Increasing a customer’s confidence around the correct app purchasing decision for their devices will enhance your app brand messaging, build customer trust and loyalty, decrease your catalog fragmentation, and strengthen your footprint on Amazon.

Steps to Implement Amazon Device Targeting for Your Apps

1.  Create targeted binaries in your development environment as outlined in our FAQ.

2. Add a new app to the distribution portal (or select a current app). Within your Binary Tab, upload your binary, select the devices you are targeting, choose a binary alias then save & upload another binary.

Device Targeting currently allows for up to 4 individual APKs that can target non-Amazon Android devices, Kindle Fire (1^stGeneration), Kindle Fire, and Kindle Fire HD 7”. We will soon add the capability to add a 5th APK for Kindle Fire HD 8.9”. Please be mindful of versionCode and versionName requirements when building your APKs.

Note: You will see a warning if your first APK uploaded targets less device types than the last live version of your app.  This warning disappears once you have APKs targeting at least as many device types as your previous app version.  If you do not update your APKs to all device targets, customers will be unable to purchase your app on the device type you did not target.

3. If you are uploading a binary larger than 30mb, be sure follow the FTP instructions for naming convention. More information on FTP is available below.

4. You should now have your binaries listed at the top of your Binary Tab in your Development Portal . Each binary is now set to target a different device. 

Note:  currently, when you update an app in the multi-binary environment, you will need to create and upload an updated version of each binary. For example, if you have 4 target binaries for your app, and make an update to one of them, you will also need to update the version codes for the other 3 APKs and upload all 4 binaries.

Uploading a Binary with FTP

If you are uploading a binary larger than 30mb, be sure follow the FTP instructions for naming convention below.

You build the APK name as follows:

The first element is your version ID, ex:M3RRPI3Z18JUMV (this will stay the same for this app)

The second part is your binary alias.  For example, Binary1 (you can have multiple binary aliases each targeting a different device).

Ex: M3RRPI3Z18JUMV-Binary1.apk, M3RRPI3Z18JUMV-Binary2.apk,M3RRPI3Z18JUMV-Binary3.apk, M3RRPI3Z18JUMV-Binary4.apk

Note: If you currently have all hardware targeting options selected with the binary you have previously uploaded for this app update,  step through your existing uploaded binaries for this update, and adjust your device targeting per binary so that this APK can target a device type. 

1. Follow the basic instructions given in the FTP instructions and naming convention link. This will give you your Amazon Host/Username/Password so you can use your FTP client to upload selected binaries. Most, if not all, operating systems come with a command line FTP client you can use, though you are free to use any that supports the standard FTP protocol.

Example of FTP File Submissions

2. You should receive an e-mail indicating that you have successfully uploaded and associated your APKs with your app. Most errors are the result of improper naming conventions.

3. When you go to the Distribution Portal and select your app's Binary File tab, you should see your binary listed at the top of the edit page.

4. Select your first binary, select EDIT at the bottom of the screen and choose the appropriate Device Support settings for each binary.

Note:  No two APKs can target the same device type. However, a single APK target may target any amount of device types.   

5. Be sure to save.

The all-new Kindle Fire and the Kindle Fire HD family of tablets include a new feature, called Billboards, that introduces customers to new apps using engaging and colorful imagery.  Ina similar fashion to how large outdoor billboards are designed to catch the eye, our Billboards feature makes use of engaging imagery on the all-new Kindle Fire and Kindle Fire HD storefront to introduce customers to new apps. At Amazon, we are constantly looking for new ways for you to grow your business by connecting you with new customers. Billboards is one of our newest features to improve app discoverability for both customers and developers. 

Customer Experience

When customers view our store on an all-new Kindle Fire or Kindle Fire HD device, they’ll see multiple scrollable billboards at the top of their screen.  Each billboard serves as an immediate entry point to its app’s detail page where the customer will have the opportunity to purchase or download the app.  Promotional images will be curated from our selection of apps and highlighted in the billboards placement. We recommend developers use promotional images that visually communicate the essence of their app.  The promotional image should speak to what your app is all about, your brand and should entice customers to simply check out your great app.  Customers will see billboards on the all-new Kindle Fire and Kindle Fire HD. 

Creating Your Billboard

Promotional images should be 1024x 500 pixels and in PNG or JPG format.  When creating your image, were commend that you strive for an engaging image that speaks to what your app is all about. Make your image colorful to catch the eye of customers, and choose imagery that promotes the essence of your app and brand. Text on your promotional image should be large, simple, and readable. Do not add the price to the image ($0.99) or any discount call outs (50% off).

Submitting Your Billboards

Once your billboards are ready,submit them to Amazon through the Mobile App Distribution Portal. 

1. From the Distribution Portal,navigate to the My Apps tab. Select the app you'd like to edit and navigate to the Images & Multimedia tab for that app. Then, click the Edit button.

2.  Select Upload Image from the Promotional Image field. Choose the image you’d like to upload, and then save the image. Images must be 1024 x 500 in PNG or JPG format.

Soon after its introduction last November, Kindle Fire became the most successful product launch in the history of Amazon.com. In its first nine months, it accounted for 22% of U.S. tablet sales. Last week, Amazon introduced the next generation of tablets: Kindle Fire HD. The newKindle Fire tablets will give players a completely revamped gaming experience, powered by Amazon GameCircle, and with the general release of the Amazon GameCircle API, will give game developers an opportunity to get additional features and visibility at no cost.

A New Games Library

 Since playing games is one of the most popular activities on Kindle Fire, Amazon created a new Games library to give players a home base for their game collection. Games is now the first product category listed in the navigation.

Kindle Fire Carousel and Navigation

In the Games library, players can immediately see all their games, sorted by the most recently played. For games that have integrated with Amazon GameCircle, players can see their friends, achievement, and leaderboard activity before starting play. Leading games such as Jetpack Joyride, Where’s my Perry?, Skylanders Cloud Patrol and Temple Run have already integrated with Amazon GameCircle.

New Games library With GameCircle Statistics

GameCircle-enabled games also get several pages of content in the game library, including a “Summary” page, a friends page, an achievements page and a leaderboards page. The “Summary” page highlighted below features friends ranking, player scores and next achievement to earn, with a“Play” button to launch the game.

Summary Page

Social Gaming

In July, AmazonGameCircle launched with the leaderboards and achievements that customers love.Now, GameCircle lets players connect with other GameCircle players or import their Facebook Friends to compare achievements and compete for higher scores. Customers are now able to see what games their friends own and what new games they should try.

Friend Profile Page

Detailed friend-to-friend comparison pages also help customers find out how they stack up against their friends, giving a quick overview of achievements and high scores for each player. 

Friend-To-Friend Comparison Page

As a developer, all you need to do to get these features for your game is to add GameCircle achievements or leaderboards.  Best of all,these services are free and easy to integrate. Once integrated, your game will automatically feature player stats, game library content and leverage all the new social features and game discovery mechanisms.  Select GameCircle games are also highlighted in Amazon Appstore, giving your game a chance to get additional visibility among Kindle Fire customers.

For more information on GameCircle and for access to the achievement, leaderboard and Whispersync APIs, visit https://developer.amazon.com/sdk/gamecircle.html.

You may have noticed a new API on the Amazon Mobile App SDK tab in the distribution portal.  When we announced Kindle Fire HD, we also made the Amazon Maps API available to our developer community.The Amazon Maps API makes it easy for you to integrate mapping functionality into apps that run on the all-new Kindle Fire and Kindle Fire HD. These new devices will also support location-based services through the android.location API.

The Amazon Maps API provides a simple migration path for developers who are already using the native Google Maps API on Android.  Our Maps API offers two core features:

• Interactive Maps. You can embed a Map View in your app for customers to pan, zoom and fling around the world. You have the option to display a user’s current location, switch between standard maps and satellite view, and more.

• Custom Overlays. You can display the locations of businesses, landmarks and other points of interest with your own customized markers and pins.

The Amazon Maps API is available now in beta.  Apply today to get access through the Amazon Mobile App Distribution Portal, and see how easy it is to add maps to your app.