If you own a Kindle, you’ve experienced the power of having a Digital Locker and the ability to download your purchased content to just about any device. The notion of “buy once, read anywhere” will now also apply to your Android apps purchased through the Amazon Appstore.
Customers who purchase an app will retain an entitlement to their app even if they decide to replace their current Android device and/or purchase new devices, as long as the new devices meet the installation requirements of the app. This provides insurance to customers that their purchased apps will be available for use on all supported devices, even if the customer has uninstalled or otherwise removed those apps in the past.
The digital locker service combined with a robust Digital Rights Management (DRM) solution not only make managing apps easier for customers, they also address one of the biggest concerns developers have: unauthorized copying and distribution. An authorized user can now install your app on any of their supported devices; however, if you chose to apply DRM on your app at submission time, your app will not run on unauthorized devices.
Any app that has Amazon DRM applied to it will require users to have installed and signed-in to the Amazon Appstore client to access the app. When an app is accessed by the user, it will verify with the Amazon Appstore device service as to whether the user has an entitlement to the app. If the user does not sign in or does not have an entitlement to that app, then the app will not be usable. However, any user can gain an entitlement by purchasing the app through Amazon.
We will be posting more updates on Amazon DRM over the next few weeks on the Amazon Appstore Developer Blog. We will cover additional topics, such as sharing data between apps and signing your app after Amazon DRM has been applied.
Update: In response to your questions, we’d like to take this opportunity to provide a few clarifications.
Do I have to use Amazon DRM if I sell my app through Amazon.com?
No, it is not required. When you submit your app you can choose to offer your app DRM free or you can apply Amazon DRM.
Do customers need to have internet access to use an Amazon DRM-enabled app?
No. Once an app is installed, a user can use the app without having internet access.
How can you verify that the user has an entitlement to the app without internet access?
During the installation process for an app, the Amazon Appstore client downloads a small token that grants the user the right to access the application. A valid token permits the user that purchased the app to access their app offline. The Amazon Appstore client will periodically communicate with Amazon servers to refresh the token.
As an app developer, you know the importance of using external services and APIs offered by other developers. Leveraging third-party software eliminates unnecessary coding on your part and allows you to quickly bring higher-quality, feature-rich apps to market. An app can leverage the features of other apps to handle various types of requests. One common example is using a browser to handle user requests to hyperlinked text displayed in your app. Another example is launching a third-party social networking app to authenticate your user. Although on the surface these integration points appear similar-- the reality is that they can be very different. The difference lies in the mechanism used to invoke the external app.
In the first scenario, when a user clicks on a hyperlink, the action will automatically invoke an intent, which is sent to the Android system to process. The intent, which encapsulates an operation to be performed and contains the necessary data to send to the operation, acts as the glue between two or more loosely coupled Android apps. The Android system matches the intent to one or more activities, services, or receivers that have registered with the system. In the case of a hyperlink, typically the default browser activity will handle the intent. However, if more than one intent handler is able to process the operation (such as when a user clicks on an e-mail address), the system offers the user the option to select the intent handler they are interested in using. In the example below, an e-mail handler and the copy-paste handler are invoked after a user clicks on an e-mail address within a browser.
The important thing about the first scenario is that your app does not concern itself with who handles the intent, and no data is shared between the two. Your app will defer to the user to make the appropriate selection.
In the second scenario, you will have a more tightly coupled dependency on the authentication service provided by the third-party social networking app. This means that you do not want just any social networking app to authenticate your user. Instead, you are looking for a particular app, and if that app does not exist, you will respond accordingly.
However, before this dependency can be created, your app will need to be able to share data with the service provider. This is done by signing your app and obtaining the appropriate security key(s) from the third party to access its API. Depending on the requirements of the service provider, you can then either bundle its library with your app or require that the third party’s app be installed on the device.
At runtime, if you cannot resolve the dependency to the third-party app (i.e. it’s not installed), then you will want to provide the user an opportunity to install the app. This can be done by launching an intent from your app to an Amazon Appstore URL:
String url = "http://www.amazon.com/gp/mas/dl/android?p=com.amazon.mp3";
Intent intent = new Intent(Intent.ACTION_VIEW);
The above example links the intent to the Amazon MP3 app. To link to a different app, you can simply take the package name (“com.amazon.mp3”) and replace it with the one for the app you are depending on. The Amazon Appstore mobile client will be configured to handle URL intents of the following pattern:
The invocation of the intent will then provide the user the option to view the app page through the Amazon Appstore mobile client.
From there, the user can take advantage of Amazon’s 1-Click purchase feature to download the app (paid or free). After the user installs the third-party app, they can go back to your app’s activity and continue from there.
The following list includes some other helpful links you can use to make requests to the Amazon Appstore:
February 23, 2011rebeccajoye
When submitting the assets for your app to the Amazon Appstore Developer Portal, you’ll have the opportunity to write a description for your app on the Application Details page in the General Information section. Any information you include in the “Description” field will be sent to our team of Amazon editors, who will review your text and update it if necessary.
A successful product description should consider its audience. Be clear, honest, and straightforward about exactly what your app does. If your app is a health and fitness app that tracks calorie intake, explain how that works. Don’t make sweeping claims about how the app will save people's lives. Customers may read that as fluff.
Compelling app descriptions get these right every time: They keep things simple; use basic, clear language; and never include misspellings or incorrect grammar.
Your app's description is your opportunity to show off your product, not to be overly clever or coy. When you sit down to write, consider the following Dos and Don'ts:
Go-to Writing and Grammar Tools on the Web
Product Description Writing Guides on the Web
Since the official launch of the Amazon Developer Portal, we have received tons of positive feedback regarding the developer registration and app submission process. However, with the large volume of activity, it’s not surprising that developers have a few questions that are not directly answered in our FAQ. We’ll take this opportunity to answer some of those questions:
Are you required to submit a video along with other multimedia content, such as icons and screenshots?
Although compelling videos can be helpful to customers when they are deciding on which app to buy, they are not required.
The only multimedia files that are required are:
The maximum size for each image is 3Mb. More information about multimedia files can be found here. If you have submitted your app and see the status “Incomplete (Missing Multimedia)”, then it is likely that you did not submit one or more of the required images. If you believe you have submitted all multimedia files and are still seeing this status, we encourage you to contact our support team.
What is the maximum video size that you can upload for an app?
The maximum size for a video is 30Mb. There is a 3Mb limit for video files submitted through the Developer Portal’s web console. If you want to submit a video that is greater than 3Mb (but under 30Mb), please use your FTP account. The process to create an FTP account and submit your app video is described here.
What video formats do you support? Your FAQ says MP4 H.264- so does this mean you don’t accept any other format?
We require your videos to be stored in an MP4 H.264 encoded format. This is to ensure an optimal visual and performance experience for your customers. Remember that these videos will not only be viewed on Amazon’s retail website, but also on mobile devices. If you upload videos that do not meet the requirements outlined in our FAQ, there may be a delay in your submission review, or your video may not be included on your final detail page.
If you have any additional questions as you go through the Amazon Appstore submission process, please do not hesitate to contact our support team.
If you’ve ever shopped on Amazon.com, you’ve likely seen items show up throughout the site based on what you recently browsed or purchased, as well as what other customers have browsed or purchased. The same thing will be true for apps – they will show up on Amazon.com based on algorithms (which are based on customer behavior).
Let’s take a look at three of the automated placement types and how they work:
Out of the gate, your app will show up in search results across Amazon.com. That’s the no-brainer. Amazon has also come up with quite a few algorithms that display items relevant to the browsing customer – meaning, we deliver a more targeted audience to developers and vendors. Simple, right?
Browse based results:
On the Amazon.com homepage we’re constantly striving to help customers find what they’re looking for. To do this, we often present items that are similar to what a specific customer has been browsing, or what’s in their cart or on one of their lists.
We present these items in sections such as “More Items to Consider,” “New For You,” “Related to Items You’ve Viewed,” and more:
Throughout the site, we also display items based on other customers’ past purchases. Here’s where it gets interesting. Let’s say I buy an Android tablet from Amazon’s tablet store. Then I visit the Amazon Appstore and download the IMDb app, the Audible app, and a few games. When another customer is looking at the Android tablet in Amazon’s tablet store, they may see the apps I downloaded in a section called “Customers Who Bought This Item Also Bought”:
Other places your app may show up include “What Do Customers Ultimately Buy After Viewing This Item?”
As the name implies, this shows what customers browsed and then actually bought.
Another interesting spot is Bestsellers within the Amazon Appstore. We will be displaying Bestsellers separated by “Free” and “Paid” apps to make it easy for customers to find what they’re looking for. This also helps avoid “Paid” apps getting buried under all of the “Free” apps that may be downloaded more often because they’re free.
We’re constantly striving to make the customer experience easy and to help vendors and developers get more than just a spot in a store.
Stay tuned for more great ways to get your app(s) exposure.
While designing and building your apps, you may encounter the question: Should I create multiple versions of my apk for different devices? In most instances, the answer should be an emphatic no! Unnecessarily offering multiple copies of your apk to your customers will not only make your development process more complex and painful, it may also create confusion for your users. A well-designed app that follows the best practices guidelines will be deployable and usable on almost all Android devices.
Some common scenarios when developers think they need to create multiple apks, but really don’t, include supporting:
If you are concerned about your app being installed on an unsupported environment, follow the best practices guide for Android development to avoid such issues.
After appropriately defining settings in your Android manifest file, you will want to design your app to make the necessary runtime decisions at the lowest levels in your code. For instance, you may want to implement conditional user interface logic at the latest point possible, such as altering display and layouts based on device screen and density settings. This is an ideal way to not only lower the total lines of code you write, but it may also reduce the number of bugs in your app and reduce the size of your apk.
There are, however, a handful of situations that justify creating multiple apks. These include:
If you are offering your app for a different price to customers on a smartphone versus a tablet, then submitting a separate apk for each form factor makes sense. Furthermore, if the apk file size difference is significant and you want to avoid users of your SD version unnecessarily downloading MBs of HD images, then a separate apk may be appropriate. You should consider making this decision when your apk grows larger than 8 MBs. Under these circumstances, and others that we did not cover, you will need to submit each apk individually to the Amazon Appstore as separate apps.
In conclusion, unless your reason for creating multiple versions is well-justified, we recommend that you submit only one apk per app version.
Nobody enjoys rejection--especially when it involves the Android application you worked so hard on. Here at Amazon, we test every app that’s submitted. If you resubmit an app after it's been rejected, it will have to undergo our testing protocols all over again.
We test Android apps to help ensure a positive customer experience. We want our customers to feel secure that any app purchased from Amazon functions properly and does what it says it’s going to do. We certainly don't want to be prescriptive or pass judgment on your app. Our goal is to prevent any bugs that will get between you and your users.
Every submitted app undergoes a series of tests to ensure the app is stable, safe, and compatible with most mobile devices. Our testers use the following series of tests:
1. Linking: Does your app follow the linking guidelines found in the FAQ on the Developer Portal?
2. Stability and functionality tests: These tests involve a wide range of protocols:
-Does the app open within 15 seconds?
-Does the app have compliance with the major carriers?
-Does the app exhibit freezing, force closing, and other forms of instability?
-How does the app react to phone calls, text messages, and alarms?
3. Content issues: These tests ensure that the app has all the necessary and appropriate content. We watch for missing content, unreadable text, and incorrect graphics. We also check if the app complies with the Content Guidelines as outlined in the FAQ. These guidelines include policies regarding offensive content, copyright infringement, or illegal activities.
4. Security issues: All apps sold by Amazon must be secure and safe for any phone. Security tests include making sure the app does not store passwords without the user's consent, does not collect data and send it to unknown servers, and does not harm existing data on the device.
In order to save you time and help you avoid the hassle of recoding and resubmitting your app, we’re providing the six most common reasons we reject apps, along with tips to create and submit your app so it passes on the first submission.
1. Are the app's buttons all working?
Dead buttons will almost always result in a fail.
Do: Double- and triple-check those buttons to make sure they're doing what they need to do.
2. How does your app respond to phone call and alarm clock interrupts?
Let's say your app is a music player. What happens if someone calls you? Does the music keep playing while you answer the phone? Although you may love that Lady Gaga song playing on your app, you probably don’t want it blaring in your ear while you're on the phone. Neither will most customers.
Do: Carefully test how your app responds to interrupts. A music player should definitely shut itself off for a phone call, or it will fail. A phone call or alarm clock should also interrupt a game. However, if your game makes the user start over from the beginning (without saving the player's place or at least the level the player is on), your app will fail. Web browsing apps also fall into this category. A phone call or alarm should not interrupt a download, for example.
3. Have you double-checked to make sure all your content is on every screen?
Blank screens = fail. If some of your screens come up black, or are missing content, you'll only confuse the customers. Every screen on your app must serve a specific purpose.
Do: Take a look at every screen in your app to make sure no blank screens come up.
4. Have you tested your app on all SDKs that you support?
Apps must support the SDK claimed in the app’s manifest.
Do: Be sure your manifest maps to the true SDK your app supports. This is specified in the Android.xml file here:
5. How does your app respond to flipping the phone from Portrait to Landscape mode, and vice versa?
Another important test is how your app responds to the user holding the phone vertically (Portrait mode) and horizontally (Landscape mode). Does your app smoothly transition to these modes? If your app is designed to be used in only one mode, does it still work smoothly when the phone is flipped to the other mode?
Do: Be sure your app doesn't crash just because someone is holding the phone the "wrong" way. If it does, your app will fail testing.
6. Are the text and fields in your app properly formatted?
Sometimes, we run into apps that have text on top of other text, which is almost impossible to read. We also have seen apps with fields that are too narrow or misaligned with the text, making filling out forms a confusing process.
Do: Make sure your text isn't top of other text and that your fields are properly aligned. Again, it is important to test your app on a variety of phones, as different models may format your text in different ways.
Give Your App a Second Chance
At Amazon, customer experience is our top priority and central to our company culture. We want to make sure our customers have a large selection of apps to choose from. For this reason, we really want to publish your app. More apps in our store result in a better customer experience, but we also want to make sure all of the Android apps in our store meet the standards our customers expect. For this reason, we encourage you to resubmit apps that have failed. In the rejection notices, you should receive a detailed explanation of why your app failed testing. More often than not, it's for one of the six reasons listed above. Once your app's errors are fixed, your app should easily pass testing the second time around.
If you have any questions regarding why your app failed, or how to prevent your app from being rejected, our account managers will be happy to answer your questions and help expedite the publishing process. You can contact them through the Contact Us page in the developer portal.
Last week we talked about what a detail page looks like over the fold in the Amazon Appstore for Android. This week, we’re going to dive into what customers see when they scroll down. Before we talk about what’s under the fold, here’s a look at the Airport Mania: First Flight app detail page over the fold.
While the first thing most customers see when they’re looking at apps is the title, icon, and price, what cinches the deal is often what’s in the details. So what does this mean for you? The content under the fold is invaluable in helping customers make decisions about what to buy/download and what to skip. It’s important to provide details including images and appropriate descriptions that show what your app can really do.
There are 5 key components of a detail page “below the fold.” The first two are are:
1. Product Details
2. Product Features
This is the “just the facts ma’am” section where we bottom line what the customer is getting, ASIN (Amazon Standard Item Number - this is your unique Amazon app ID similar to what a barcode is for products in stores), dates of note, and average customer rating. You’ll see we encourage customers to tell us what they think.
Here’s where we bottom line what your app is all about – we take this information directly from what you put into the Developer Portal, so it’s important to list accurate, helpful features. If a customer doesn’t have time to read the detailed description, they can get the gist from the Features.
3. Product Description
We use the Description you provided in the “Description” section on the Appstore Developer Portal as well as information that’s on your website (if applicable) to create a detail page with rich, helpful information about your app. We also like to include images in the Description when available (we pull these from the screenshots you provide with your app submission). An abbreviated version of this description is included on the detail page in the mobile store itself (stay tuned for a peak at a detail page on the mobile store!). If your app doesn’t sell itself, we hope the product description helps.
The final two sections are really all about you and the app requirements. They are:
4. Developer Info
5. Technical Data
We want to boost your brand. Here’s where you can talk about who you are and what your expertise is. We pull this directly from what you put in the Developer Portal.
As the name implies, this is where we put the technical info including app size and version.
Since Android’s first release in September 2008, the number of Android users and supported devices has steadily increased. A recent comScore report shows that there are now nearly 16 million users in the US owning Android smartphones, surpassing the total number of iPhone owners. Late last year, Canalys reported that Android claims a quarter of the smartphone market segment share. Their recent report says that Android’s growth in 2011 will be twice the rate of their major competitors, including Apple’s iOS-based devices. There is a growing market segment here that presents a great opportunity to developers including those in the Android space, and those who have only developed for iPhone and iPad. For iOS developers, porting apps to Android presents a rare opportunity to tap into this market segment and a fast growing user base.
If you are considering taking advantage of this opportunity, here are key topics to be aware of when porting your apps from iOS to Android.
Differences between iOS and Android programming
Apps for iOS are written in Objective-C, an object-oriented descendent of the C programming language. Android apps are written in Java, a very popular programming language invented by Sun in 1994, traditionally used for building server-side applications over the past 15 years.
In addition to the differences in language, syntax and semantics, there is also a key runtime difference that affects how your code is written. Java has automatic garbage collection, which means that you do not have to explicitly free objects after they are used. Objective-C requires developers to manage memory explicitly.
Integrated Development Environment (IDE) options and SDK platform support
You have more options when it comes to selecting an IDE and platform when writing code for Android. While building Java-based apps, you can write and compile your code on all major operating systems, including Linux, Windows, and Mac OS X. Furthermore, the Android SDK integrates with most major IDEs, such as Eclipse and Intellij, which means you can run an Android emulator and test your application on either of these IDEs and operating systems. The iOS SDK, which includes XCode IDE, runs only on Apple-based operating systems.
Apple is the only provider of iOS devices, while many vendors offer devices supporting Android
As we discussed in a previous post, Android has many vendors, which means Android devices have varying capabilities and features. iOS devices are only manufactured by Apple and are currently limited to iPhone, iPad and iPod touch. For developers who are accustomed to building apps for a small set of devices, building apps for Android presents a completely new challenge.
Ultimately, iOS developers with a good understanding of these fundamental differences will be able to assimilate well in developing apps for Android. In fact, the developer who was previously constrained by the platform limitations of iOS devices may now find the flexibility of having IDE options, SDK platform support and the nuances of the Java language to be refreshing and energizing.
During the process of submitting your app, you are required to submit information that will eventually show up on the site. We wanted to give a little more detail around where all this information actually goes, so we’re going to dive into a real detail page and lay it out for you.
Here’s a look at a real live detail page – this is the detail page for the IMDb app in the Amazon Appstore for Android (don’t get too excited, it’s not live … yet). Why is it called a detail page might you ask? This is the page where customers can get details about your app – hence, detail page. Pretty straightforward, right?
Over the fold there are three primary places you’ll be providing content for.
But wait, there’s more! The scrolling part that you see at the bottom of this screenshot is a slot that is automatically created as purchases of your app pick up. This slot is called “Customers Who Bought This Also Bought” and as the name implies, when appropriate, your app icon, title, rating, and price will show up on other item’s pages if customers bought that item and your app. Even non-app pages! Here’s an example: a customer buys an Android phone and then buys your app (they need to stock their phone, right?). Your app has a good shot of showing up on the bottom of that page to future customers!
A picture is worth a thousand words. Use that picture (and those hypothetical thousand words) to effectively market your app.
When you submit your app to the Amazon Appstore for Android through the Developer Portal, you will need to submit an icon, a thumbnail, a promotional image, a square version of the promotional image, and screenshots. Having compelling images help get your app noticed. Also, great looking apps look great on our store – if you look good, we look good!
Here are details and recommendations for creating great images for all your submissions:
Here’s an example of a “do” icon image:
You can learn more about image guidelines and best practices in the Appstore Developer Portal online here.
That’s it! So go tell your app to “say cheese!”
Whether you have a bug fix, enhancement or performance optimization that you want to deliver to your customers, one of your Android apps will inevitably require an upgrade. This can be either a seamless process or a painful one for your customers. To ensure that it is the former and not the latter, the Android SDK provides some simple guidelines to help you manage this process. Last week, we discussed some useful configuration settings offered through AndroidManifest.xml for designing apps to run on smartphones and tablets. This same configuration file also provides settings to version your apk.
There are two attributes you can specify to manage the versioning process of your app:
The versionName attribute is a user facing string that identifies the version of the application in use. For example, if you are upgrading for the first time, your previous versionName may be “1.0” while a minor upgrade version would be indicated by “1.1” and a major upgrade by “2.0”. The versionName attribute is primarily used for display purposes and helps users identify differences between app versions. The following is a snippet of the manifest from the Amazon MP3 App for Android:
The versionCode is the attribute that is used by the Amazon Appstore for Android to compare versions of your app. This is an integer, like 80029 in the sample manifest, not a string like the versionName. If the versionCode of an apk is greater than the versionCode of another apk, then it is considered to be newer. Of course, for this comparison to be valid, the apk package name and signature must also match. To avoid unexpected behavior, it is extremely important to keep track of your versionCode and to always increase the value whenever you are releasing a new version.
It’s well known that Amazon is all about customer experience. With a growing developer customer-base, we’re constantly striving to make it easier for developers to do just that – develop! Last month, we launched an Amazon Web Services (AWS) SDK for Android. “We’re really excited about the launch of the AWS SDK’s for mobile,” says Jeff Barr, Senior Web Services Evangelist, Amazon Web Services. “As a developer myself, I’m looking forward to seeing all sorts of cool and creative AWS-powered applications show up on mobile devices in the future.”
Some highlights of the AWS SDK for Android include:
The SDK includes a library, full documentation, and some sample code. You can get the library on GitHub. Also, in true open source fashion, AWS is open to and encourages external contributions.
Check out this blog post on the AWS blog for more details about the AWS SDK as well as an iOS SDK. You can download the AWS SDK, access documentation, and participate in the discussion forum online here.
Finally, right now Amazon has a free usage tier available to new AWS customers to help get started in the cloud. As of November 1, 2010, new customers can run a free Amazon EC2 Micro Instance for a year, while also leveraging a new free usage tier for Amazon S3, Amazon Elastic Block Store, Amazon Elastic Load Balancing, and AWS data transfer. AWS’s free usage tier can be used for anything you want to run in the cloud: launch new applications, test existing applications in the cloud, or simply gain hands-on experience with AWS. Learn more here.
At last week’s CES, it was hard to ignore the fact that many technology pundits are considering 2011 as the year of the tablet. And although Apple should be thanked for resurrecting interest in tablets in 2010, 2011 will see a record breaking surge in the number of vendors bringing new tablets to market. Sean Dubravac, Chief Economist and Director of Research, Consumer Electronics Association, predicted, “While many firms are touting product launches within the tablet sphere for the fourth quarter of 2010, the real action will occur a few weeks after the end of the quarter at CES.” The next few weeks will be telling for the future of the tablet and so far it’s looking quite bright.
The good news for you, the Android developer, is that many of these tablets will be sporting Android OS and, with the recent announcement of the Amazon Appstore Developer Portal, you have a convenient way of offering your apps to both tablet and smartphone users. We’re not mandating that you optimize your apps for tablets as well as smartphones, but it’s definitely something you should consider.
The expected surge in the number of tablets on the market and the number of Android devices a single user will own brings forth new opportunities and challenges. The opportunities are clear—more devices mean more users, more hardware features and more APIs to take advantage of. These new tablets will continue to feature larger screens and supported resolution levels, ample amounts of disk space and extremely fast processer speeds that are not far behind that of a typical laptop. An important thing to remember as a developer is that customers may be using your app across tablets and smartphones – no longer just one or the other.
A quick comparison of the best selling smartphones and tablets on Amazon.com shows that tablets boast 50-100% more screen real-estate and 50% more disk space. Furthermore, many of the tablets demonstrated at CES also feature dual-core CPUs. These differences make it more important than ever for developers to be aware of the device capabilities and limitations. With Amazon.com’s convenient 1-Click purchase and digital locker features, customers will be able to buy your apps and run it on any of their Android devices. Unfortunately, the growth in devices will present one of the biggest challenges for you—you want to continue to build and extend your killer apps and offer it to the tens of millions of Amazon.com customers, but you also want to keep your customers happy by setting expectations on how and where the apps can be run.
The Android SDK requires that each application contain a file called AndroidManifest.xml within the apk. This is where you can let the system know what your app needs at a minimum to run and what resources and services it will use. For instance, if you are building a word processor app that is designed to only run on a tablet, you will want to set the android:largeScreens attribute to “true” on the <supports-screens> property, while explicitly setting the small and normal screen flags to false. If you don’t declare this requirement for your app, then the Android system will assume it works on all screen sizes.
On the other hand, if you are building a game that looks great on any phone or tablet, then you can declare this in the xml file by including the following settings:
One thing to be aware of, however, is that once you declare support for all screen sizes, you will want to check the DisplayMetrics settings at runtime to make important display decisions in your code. This information can be used to make performance optimizations, such as displaying low to medium resolution images on small devices and high resolution images on large screens—a great way to avoid creating multiple versions of your app.
Apps that depend on hardware resources, such as GPS, Wi-Fi or Bluetooth capabilities, can define these requirements by appropriately setting the <uses-features> option.
Furthermore, with last month’s announcement of the Gingerbread release, there are now 6 flavors of Android OS in use. If the trend over the past two years continues, you can expect one more major release (3.0, Honeycomb) and another minor release to be announced before 2012. With major features being added in every new platform version, such as improved copy-and-paste and faster text input processing in Gingerbread, you will want to take advantage of these capabilities and also ensure your apps only run under their supported environment. The manifest provides a way to enforce dependencies on specific SDK features by using the <uses-sdk> flag.
Customer satisfaction is a key driver behind Amazon.com’s success. As you develop and offer your application to Amazon.com’s customers, following these Android development best practices guidelines is a great start towards achieving similar success.