Developer Console
Appstore Blogs

Appstore Blogs

Want the latest?

appstore topics

Recent Posts


October 30, 2012

Amazon Mobile App Distribution Program

Mudeem Siddiqui, Solutions Architect, a2z Development Center Inc., an company, is our guest blogger for this post. 


initiatePurchaseUpdatesRequestis an important API call that enables developers to restore in-app purchases. A common use case for this method is when a customer buys in-app items on one device and then downloads the same app on another device, or when a customer re-installs the app after removing it from their device. In both scenarios, through the initiatePurchaseUpdatesRequest() call, make past in-app purchases and restore those purchases to the correct state.


Consider a scenario where a freemium app uses the In-App Purchasing API to grant an entitlement to the full version of the app. A customer downloads the free version and unlocks the full version through an in-app purchase. Then, they remove the app from their device. The customer then re-installs the app from the cloud. If the initiatePurchaseUpdatesRequestcall is used correctly, the customer will have a seamless experience and have access to full version of the app without taking any action. This is a great customer experience.


On the contrary, if the call is not used or used incorrectly, the customer will not have access to content they’ve already purchased. Instead, the customer will be presented with the free version and the option to purchase the full version. This is a bad customer experience and could lead to negative reviews.


PurchaseUpdates MethodCall

Make the PurchaseUpdates call whenever the onResume() activity lifecycle method is invoked and determine if the customer has already purchased any entitlements and subscriptions. Based on the result, lock/unlock content in the app as appropriate.


Here are the technical details of how to use PurchaseUpdatesAPI calls:


1. Override and implement onPurchaseUpdateResponse callback: In the Observer class that extends BasePurchasingObserver, override and implement callback onPurchaseUpdatesResponse. This callback will be called on initiation of purchase updated request.


private class MyObserver extends BasePurchasingObserver{



 // Is invoked once the call from initiatePurchaseUpdatesRequest is completed.

 // On a successful response, a response object is passed which contains the request id, request

 // status, a set of previously purchased receipts, a set of revoked skus,and the next offset if

 // applicable. If a user downloads your application to another device,this call is used to sync

 // up this device with all the user's purchases.


  // @param purchaseUpdatesResponse

 //   Response object containing the user's recent purchases.



  public void onPurchaseUpdatesResponse (PurchaseUpdatesResponsepurchaseUpdatesResponse){


    for (final String sku : purchaseUpdatesResponse.getRevokedSkus()){

      // Revoke Items here



    switch(purchaseUpdatesResponse.getPurchaseUpdatesRequestStatus()) {

    case SUCCESSFUL:

        for (final Receipt receipt: purchaseUpdatesResponse.getReceipts()) {

          switch (receipt.getItemType()) {

          case ENTITLED:

            // If the receipt is for an entitlement,the customer is re-entitled.

            // Add re-entitlement code here


          case SUBSCRIPTION:

            // Purchase Updates forsubscriptions can be done here in one of two ways:

            // 1. Use the receipts to determineif the user currently has an active subscription

            // 2. Use the receipts to create asubscription history for your customer.




      case FAILED:

        // Failure Case






NOTE: Please be aware that this method is invoked on the UI thread. Any long-running tasks should run on another thread. It is best practice to use AyncTask to implement onPurchaseUpdatesResponse functionality. Please see ButtonClicker example for details.


2. Initiate the purchase update request: initiatePurchaseUpdatesRequest initiates a request to retrieve updates about items that customer has purchased. A good place to call this function is from onGetUserIdResponse()callback where initiateUserIdResponse() should be called from OnResume() in the MainActivity to check which customer has signed in. Chaining these calls ensures that you can correlate the user to the purchased content.


private class MyObserver extends BasePurchasingObserver{



 // When the application resumes the application checks which customer is signed in.


  protected void onResume() {








private class MyObserver extends BasePurchasingObserver{




  publicvoid onGetUserIdResponse(final GetUserIdResponsegetUserIdResponse) {









The argument to initiate PurchaseUpdateRequest is an offset. The offset represents a position in a set of paginated results. Operations that make use of an offset as input will provide an offset as an output. You can use the offset to get the next set of results. To reset an offset, you can pass in Offset.BEGINNING. It is a best practice to continue the current offset of the call within your app and use that offset for subsequent calls. It is best practice to associate an offset with a UserID in the event multiple customers share the same physical device. Offset values are base64 encoded values and not human readable.


NOTE: It's a best practice to have the onGetUserIdResponse implementation in an AsycTask. In that case, initiatePurchaseUpdatesRequest() should be called from onPostExecute() function of the AsycTask.


For a comprehensive example see ButtonClicker sample part of In-App Purchasing API.

October 29, 2012

Amazon Mobile App Distribution Program

Kate Shoaf, Marketing and Public Relations leader at PlayTales, is our guest blogger for this post.

PlayTales is a world leader in children’s bookstore apps, that has expanded internationally, with offices in the USA, UK, Spain, Romania, and China. Founded in 2010, PlayTales develops and distributes interactive playable storybooks for children within the world’s leading children’s bookstore app for smartphones and tablets.

International distribution has become a prominent part of PlayTales’ business plan as we’ve realized the international market can open the door to millions of downloads for our apps. Although we developed the app with the intention of mainly distributing in the USA, China and the UK have become some of our top downloaders. We´ve developed and localized our app to cater to the needs of our various international customers.

Based on our experiences, there are several things developers should consider as they prepare and launch their applications:

Language options

A unique feature of our app is the several language options users can choose. The selected language of the application is based on the settings of the user’s device, but within the application itself, you can choose to view the stories in a different language. For example, all of your menus and links are in English, but you can easily view all stories in their Spanish version, French version, Italian version, and so on. We know our target users are interested in exposing their children to various languages so we’ve developed our app to make this possibility easily attainable.


If you look at this screen shot, you’ll notice that all menu items are in English, while the books are available in Spanish; a unique feature that caters to our target user.


There is no substitute for a native speaker

Anyone can learn a new language, but when it comes to common phrases and appropriate expressions we’ve found that working with native speakers is the best method for localization. At PlayTales we translate our stories into eight different languages and there is no substitute for working with a native speaker. When translators become a part of your localization team, they understand the message and product quality you are trying to develop within your app.

Keep an eye on currency

With the current economic crises going on it seems that currencies all over the world are constantly on a roller coaster of changing value. Because our books are available in so many different countries, monitoring exchange rates has become an important pastime within the office. We deal with Dollars, Euros, Yuan, and Pounds and the constantly changing exchange rates have kept us on our toes. It is important to monitor the currencies you deal with because you can lose business if your prices are too high, and also miss opportunities to generate more revenue if your prices are too low. Monitor your money and don’t lose out on business because of this common mistake.


Direct contact with multilingual tech support

It’s almost impossible to release an app that is absolutely perfect. Listening to the comments of users can really help work out the kinks and improve your app. Within all PlayTales accounts, users have the option to directly contact our tech/localization team in whatever language they want. Because our translators work in-office, we are able to efficiently respond to everyone that contacts us in their native language. If you are going to have a multiple language app, make sure that your users can communicate with your tech team in their preferred language.

Adapt your app

Adapt your app so that it can be accessed by potentially everyone. PlayTales started out as an app only accessible through iOS devices. But as tablets like the Kindle Fire were released, it became obvious that adapting our apps to function on these devices was necessary. After teaming up with Amazon, we’ve seen a great increase in our number of downloads. Amazon’s submission module makes submitting localized features such as texts, graphics, and user interfaces a simple and quick process. Using Amazon as a distribution platform has made our app easily attainable for tablet users and has given us a chance to enter a market we hadn’t considered before. Remember that iTunes is not your only resource; you can develop and adapt your apps to function on almost any device and consequently tap into new markets.

Distributing internationally is becoming a necessity for many developers who want to stay on top of the market. Know your target users and develop your app accordingly, remember to use native speakers to help with localization, monitor exchange rates, offer tech support in various languages, and adapt your app to a changing market. Following this advice may help you find the international success we’ve experienced. New technologies are spreading to every part of the world, and along with it the newest applications. Take advantage of this opportunity and go global. 

October 24, 2012

Amazon Mobile App Distribution Program

Amazon’s mobile app distribution platform continues to expand internationally, giving developers a chance to grow their businesses. We are pleased to let you know that the Kindle Fire and Kindle Fire HD will be coming soon to Japan. Check out the press release here.


Additionally, we started shipping Kindle Fire and Kindle Fire HD tablets to the U.K., France, Germany, Italy and Spain this week.

Visit Kindle Fire Developer Resources to build for the Kindle Fire and Kindle Fire HD. And you can learn more about taking your app international with Android localization tips and resources and steps for localizing your app in the Distribution Portal right here on the blog.

Sign in to your Amazon Mobile App Distribution Portal account now to get started.

October 23, 2012

Amazon Mobile App Distribution Program

We’ve released a beta of the Kindle Fire HD 8.9" emulator to enable you to test and debug your apps in anticipation of the device launch next month. While we recommend developers test their apps on a physical device whenever possible, 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.

The emulator for the Kindle Fire HD 8.9" is currently available as a beta. Be aware that the user interface and functionality of the beta emulator may not match the experience available in the Kindle Fire HD 8.9"when it is released later this year.

With high resolution device emulators such as the Kindle Fire HD 8.9”, we recommend enabling GPU emulation. This will deliver 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

We’ve also updated the emulators for the all-new Kindle Fire and the Kindle Fire HD7” to reflect the software in the latest over-the-air software update.

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

October 23, 2012

Amazon Mobile App Distribution Program

Kindle FreeTime is available in the latest over-the-air software update that was released today for the Kindle Fire HD and all-new Kindle Fire. This new feature provides a dedicated space for kids to interact with books, movies, TV shows, apps, and games.  


With Kindle FreeTime, parents never have to worry about the content their kids will access–parents select the content their kids will see , and kids can’t exit FreeTime without a password. Kindle FreeTime also offers parents enhanced tools to manage their child’s content and interaction, including multiple profile support and daily time limits. Parents can create a profile for each of their children and choose which books, movie, TV shows, apps, and games they want to give each child access to.

As a developer, you don’t need to do anything to participate in Kindle FreeTime other than build great products. Simply by including them in the Amazon Mobile App Distribution Program, your apps will be available for parents to include in their children’s personalized experience.

October 18, 2012

Amazon Mobile App Distribution Program

Join the Amazon team, along with mobile app and game developers like you, at AWS re: Invent for two days of sessions covering everything you need to know to grow your business and monetize on Kindle Fire. Amazon’s first developer conference is the perfect opportunity for you to learn strategies and tips to help you thrive, from creating engaging user experiences on Kindle Fire to building mobile apps that scale for rapid user adoption. You'll also be able to learn more about Amazon GameCircle, which makes it easy for you to create more engaging gaming experiences via achievements, leaderboards and sync APIs. 

Aws logo

Stop by our booth and play with Kindle Fire—we’ll have the Kindle Fire HD available for you to play with loaded with mobile apps and games that have already been optimized for the tablets. Plus, Amazon Mobile App Distribution marketing and technical representatives will be there, ready to answer your questions on optimizing for and being marketed on Kindle Fire.

Here are just some of the sessions offered for mobile app and game developers:

Distributing Apps Through Kindle Fire and the Amazon Appstore for Android

Aaron Rubenson, director of the Amazon Appstore, will provide an overview of the Amazon Mobile App Distribution Program, the Amazon Mobile App SDK, and resources available to developers for Kindle Fire tablet optimization. Learn how to grow your business by engaging new customers and monetizing your apps.


Creating the Killer App for Kindle Fire

Mike Nash, vice president of Kindle Developer Programs, will be providing tips and optimizations you can easily implement to make the killer app on Kindle Fire and stand out from the crowd.

Monetizing Your App on Kindle Fire: In-App Purchasing Made Easy

Mekka Okereke, developer services lead for the Amazon Appstore, will discuss how in-app purchasing can help you monetize your app and grow your business, as well as how to integrate the Amazon In-App Purchasing API into your mobile apps.

Level Up Your Kindle Games with Amazon GameCircle

Jason Chein, director of Game Services, will be presenting the brand new games library experience, fully integrated with Amazon GameCircle, and offering tips on how to increase customer engagement of your content. This session is open for all but specifically tailored for game designers,producers, and publishers.

In addition to the sessions and the expo, we will also be hosting other events:

  • Ready to test your skills, building apps in the AWS cloud or optimizing for Kindle Fire? Complete in our Code Challenge, where you can win prizes such as Kindle Fire tablets, AWS credits, or gift cards.

  • If you have questions about marketing your apps or optimizing your apps on Kindle Fire, come and meet with our technical and marketing teams—either in our expo booth or one-on-one during our office hours.

  • Learn from accelerators, venture capitalists, and start-up founders on paths to launching your start-up. Hand-selected start-ups will publicly launch at AWS re: Invent. Are you ready to launch? Tell us about your start-up and be considered for one of the launch spots.

AWS re: Invent will be held Tuesday-Thursday, Nov. 27-29,2012, at the Venetian in Las Vegas. For more information about AWS re: Invent and to read about the 150+ sessions and other conference activities, go to the AWSre: Invent website.

We hope to see you there.

October 18, 2012

Amazon Mobile App Distribution Program

Amazon recently expanded electronic payments to include additional countries. Now more developers in the E.U. can select an electronic payment method as a more convenient way to receive payment.

Using electronic payment gives you the benefit of having your mobile app distribution payment sent directly to your bank, reducing the time it takes you to get paid. Plus electronic deposits paid in your home currency may help you avoid conversion fees that could be imposed by your bank.

Sign in to your Amazon Mobile App Distribution Portal account now to make sure your next payment is electronic. Simply select your bank’s location from the “Where is your bank/financial institution?” drop-down menu. If available, you will have the option to choose an electronic payment (this could be “wire transfer” or “electronic funds transfer”, depending on your location). Once selected you will need to enter your bank information.

The following thresholds must be met before Amazon issues a payment:

  • USD Electronic Funds Transfer: $10
  • EUR Electronic Funds Transfer: €10
  • GBP Electronic Funds Transfer: £10
  • Swiss Francs Electronic Funds Transfer: $10, €10 or £10
  • EUR Wire Transfer: €100
  • Check: $100, €100 or £100

See our previous post for some additional information here.

October 15, 2012

Amazon Mobile App Distribution Program

Derek Gebhard, Solutions Architect, a2z Development Center Inc., an 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 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 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 =;

      } 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:

October 10, 2012

Amazon Mobile App Distribution Program

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.

October 09, 2012

Amazon Mobile App Distribution Program

Kindle Fire tablets use a soft key toolbar to provide a versatile user experience. In an earlier post on the Kindle Fire (1stgeneration), 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:


public void onBackPressed() {

  // do something when the back button is pressed



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.


 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.

October 09, 2012

Amazon Mobile App Distribution Program

Amazon Mobile App Distribution Program will be at AnDevCon IV from December 4th-7thin 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.

October 08, 2012

Amazon Mobile App Distribution Program

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) {



  finalView view =getWindow().getDecorView().findViewById(;

  lp.flags= WindowManager.LayoutParams.FLAG_FULLSCREEN;



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) {                   



  finalView view =getWindow().getDecorView().findViewById(;


  lp.flags= WindowManager.LayoutParams.FLAG_FULLSCREEN;



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

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.

October 07, 2012

Amazon Mobile App Distribution Program

Moe Tanabian, Software Development Manager, a2z Development Center Inc., an 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 (Pt) 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 Ci, and the component’s coefficient Bi  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 Bi are determined, it can be used to estimate power consumed for a particular use case by simply plugging in the collected values of Ci 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.


  1. Pro Android Apps Performance Optimization(Professional Apress) by Hervé Guihot
  2. iOS App Programming Guide;
  3. Design and testing for longer battery life in Android Devices and Applications by Moe Tanabian,

October 02, 2012

Amazon Mobile App Distribution Program

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.

 Whispersync-3Choosing 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.

Whispersync-4Syncing 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.

October 02, 2012

Amazon Mobile App Distribution Program

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.  

Want the latest?

appstore topics

Recent Posts