10 Tips to Optimize Android Apps for Amazon & Kindle Fire HDX

Kindle Fire HDXLast month we wrote about the newest additions to the mobile testing matrix – Amazon’s Kindle Fire HDX line and version 3.0 of their FireOS. You already know that these new offerings will require additional mobile app testing, but what exactly should you focus on to make sure your app looks perfect on the new tablets and runs perfectly with the new OS?

To answer that question we went straight to the source. Mike Hines, an Amazon Appstore Technical Evangelist, sent us 10 guidelines to help you optimize your app.

*****

On September 20th 2013, Amazon introduced a new generation of Android-based tablets. The hardware spec on these devices is pretty impressive, and there are a lot of new customer-focused enhancements we’ve added to the stock build of Android 4.2.2 (API level 17).  We call our enhanced Android build FireOS 3.0, but developers should know that as far as apps are concerned, this is Android Jelly Bean.

While 75% of Android apps submitted to Amazon just work on Kindle Fire, and require no additional development, most developers would like to make sure that they are not in the other 25%! To help you make sure that your Android app is going to be in the 75%, we have collected the top 10 issues that cause apps to fail, and some guidelines so you can avoid them. All of these guidelines are aimed at creating a better user experience for your customers and hopefully making for a smoother process for you as a developer.

1. New Device IDs

The single largest issue we see on the new HDX devices is usage of incorrect device IDs. We recommend that you use capability detection to determine which features to support and which layouts to use. This is much more likely to work on new devices, and should be easier to maintain.

However, if you have used specific device detection in your code, you should be aware that each of the three new devices has a new model number, and you will need to update your code with the correct Device ID list or switch to capability detection. You can find specifics on the Kindle Fire Device and Feature Specifications.

2. Links to other app stores

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

3. App functionality does not match its description

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

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

4. In-App Purchasing Failure

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

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

5. Icon Mismatch

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

6. Force close on launch and other stability issues

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

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

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

7. Poor Usability

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

Examples of things that would be flagged here are:

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

8. Security

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

9. Networking resilience

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

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

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

10. Things to consider about graphics

The new devices now use Andreno hardware. If you use a development framework like Unity, Epic or other, please make sure that you select PowerPVR and Andreno options when building your apps!

You should check to see if your visual assets look good at the 2560×1600 resolution of the new 8.9” device. If not, you should supply 2560×1600 assets instead of letterboxing your existing content.

Learning More

If you would like more information, please check out our developer portal, and follow us on Twitter @AmazonAppDev.

You can follow me on Twitter @MikeFHines

Essential Guide to Mobile App Testing

Comments

  1. says

    ‘ So you can simultaneously display strength stage from
    a pc, a movie from the Iphone and notes out
    of your i – Pad. Your information that is personal and computers are vulnerable.

    This is achievable because in the various apps that are obtainable to your Smartphone,
    including Vo – IP applications and programs like Skype.

  2. Michelle L. Rader says

    I’m trying to figure out my new kindle fire HDX 7″ that I received as a Christmas gift. I just received a NOOK HD 7″ for my recent birthday that is still sealed and I also have a Samsung Galaxy S 111 cellphone. I just would love to know how to use them to the full potential. It’s driving me crazy not knowing how to get it together. I’m research but still have no clue where to start. It’s funny coming from me, who has two associates degrees in business. My adorable three year can work my phone, kindle, and desktop computer for shows, games, and other educational apps she plays daily.lol Well sorry to rant. =) Wish me luck. My 13 yr old son and 11 yr old daughter are saying, “Mom you don’t have to write all of that while smiling and smirking.” I am blessed with very smart children. But I felt the need to share. THANKS
    Sincerely confused lol,
    MICHELLE, OH

  3. says

    You have touched some good points here, and I found it quite useful. Maybe you can elaborate those ideas you shared in a future post for my blog site. Anyway, keep up with your writing! I’m sure more people will be more interested in your website in the future.

  4. says

    Its like you read my mind! You seem to know a lot approximately this,
    such as you wrote the e book in it or something. I feel that you
    just can do with some % to pressure the message house a
    little bit, but instead of that, that is great blog. A great read.
    I’ll certainly be back.

  5. says

    Sweet blog! I found it while searching on Yahoo News.

    Do you have any tips on how to get listed in Yahoo News?
    I’ve been trying for a while but I never seem to get there!
    Cheers

  6. says

    It’s a pity you don’t have a donate button! I’d most certainly
    donate to this superb blog! I suppose for now i’ll settle for book-marking and
    adding your RSS feed to my Google account. I look forward to fresh updates and will share this
    website with my Facebook group. Chat soon!

  7. David Scott says

    Some good tips there.

    What would really be good would be if the test team weren’t so incompetent. I’ve had hundreds of rejections when the fault was the test team hadn’t set up their test environment properly.

    Just this morning I got a rejection for something that I know is working fine. As per usual I just have to resubmit it and hope they test it properly this time. It’s a waste of time for both parties!

    Then when it actually was a valid rejection recently, they were so useless that the reason they sent was for something completely different, that was working correctly.

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *