Today we announced Engagement Reports, a free zero-integration service that provides data on app usage. This has been a popular request from developers, who want to better understand how customers interact with their apps. Engagement Reports include daily and monthly active devices, installs, sessions, average revenue per device, and retention. Each report can be filtered by marketplace, viewed in chart form, or downloaded as a CSV.

You can find the Engagement Reports within the “Reporting” tab of the Mobile App Distribution Portal. The full list of Engagement Reports is:

• Overview: A summary of key usage data for your app or game
• Average Revenue: Daily and Monthly Average Revenue per Device (ARPD) and Average Revenue per Paid User (ARPPU) for In-App Items
• Retention: Daily Retention for days 1-3-7 and Weekly Retention for weeks 1-2-3
• Active Devices: Daily Active Devices (DAD), Monthly Active Devices (MAD), and Sticky Factor (DAD/MAD)
• Sessions: Total Daily Sessions and Average Sessions Per Device
• App Installs: Daily Installs and Uninstalls

Engagement Reports are available for apps submitted and published after October 25, 2012. If you haven’t updated your app since then, you’ll need to republish or submit an update before data can be collected. No other action is required. Engagement Reports include data from the Kindle Fire HD, the new Kindle Fire, and Android devices that use the latest version of our store.

 How to access and view your Engagement Reports

From within the Distribution Portal, you can access Engagement Reports by selecting “Reporting” (1) and then “Engagement^beta” (2). Or, click here to go directly to Engagement Reports.

Engagement Reports are separated into three sections. (3) Criteria Selection: Allows you to select the app, date range, and marketplace. Engagement Reports default to your first app in an alphabetically sorted list and display the most recent 14 days of data. (4) Report Selection: Allows you to select from five different reports: Overview, Active Devices, Sessions, ARPD (In-App Items), and Retention. (5) The Overview report highlights key performance metrics such as Daily Active Devices and 1-Day Retention across a selectable date range and lifetime totals for your app or game.

The example image below shows the Active Devices report (6) with a graph of Daily Active Devices (DAD) and Monthly Active Devices (MAD) over a 14 day period.

Developers that want to learn more about each report, including how data is collected, can review the Engagement Reports FAQ (7).

We encourage you to explore Engagement Reports and provide feedback via the “Send Feedback” link on the Engagement Reports page.

Meet Amazon at Casual Connect Seattle from July 24-26!

Happy Hour at the Diller Room- July 24, 2012 6:00-8:00 PM

Join us for drinks (two drink tickets provided) and hors d' oeuvres at the Diller Room on July 24th from 6pm-8pm. Mingle with representatives from the AWS, Amazon Mobile App Distribution, and GameCircle teams and enter a drawing to win a Kindle Fire.

You can register for the Happy Hour event on this page or just simply drop by. Please remember to bring your Casual Connect Conference badge for admittance.

The Diller Room is located at 1224 1st Avenue, Seattle, WA 98101.  The location is one block west of Benaroya Hall on the corner of 1st and University.

Amazon Speaker Sessions at Casual Connect

 Join us for two conference sessions hosted by Amazon speakers:

• Monetization Trends for Mobile Games with Aaron Rubenson, Director, Amazon Appstore for Android- Wednesday, July 25 at 10 AM.

• Optimizing Games for Kindle Fire with CJ Frost, Developer Evangelist- Thursday, July 26 at 11:30 AM.

Amazon Tables at Casual Connect

Kindle Fire development resources are now available to our developer community! These resources provide detailed documentation, best practices, an emulator, and sample code to make it easy for you to build great applications for Kindle Fire customers.

Our documentation details how to set up your development environment, create a great customer experience, and optimize and test your apps for Kindle Fire. We also provide a Kindle Fire emulator to help you more easily lay out and test your apps, and sample code that illustrates our best practices for performing specific tasks.

It’s easy to get started building and optimizing your apps for Kindle Fire. Visit the Kindle Fire Development Resources page on the Distribution Portal and start building today!

If you missed Kindle Fire and Your App(s) Part I and Part II, be sure to check them out!

How do you get a high-resolution icon for your app to display on Kindle Fire?

The icons on Kindle Fire are dynamically pulled from the Amazon Appstore for Android. Side-loaded apps cannot use this feature. Once you've submitted your app, and it's live in the Amazon Appstore, your app's appropriate icon will automatically be displayed.

You set up an emulator per the specifications in the Kindle Fire FAQ but the screen is being recognized as an x-large screen instead of a large screen, and loading assets accordingly. How do you fix this?

The default Android emulator mis-identifies the screen size as x-large instead of large with the standard emulator configuration. To override the configuration, complete the following on your activity onCreate method (before loading layouts or anything else):

final Configuration config = new Configuration(context.getResources().getConfiguration()); config.screenLayout = (config.screenLayout & Configuration.SCREENLAYOUT_LONG_MASK) + Configuration.SCREENLAYOUT_SIZE_LARGE; context.getResources().updateConfiguration(context.getResources().getConfiguration(), context.getResources().getDisplayMetrics());

Taking this action will ensure the emulator configuration properly uses the large screen size and loads the appropriate assets.

How do you keep the soft key menu on Kindle Fire visible at all times, instead of partially hidden?

To keep the menu bar present at all times, remove any code in the activities that enables full screen mode. The soft key bar at the bottom will then be visible at all times. Sample code to remove:

getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,WindowManager.LayoutParams.FLAG_FULLSCREEN);

How do you connect Kindle Fire to Android Debug Bridge (ADB)?

To connect Kindle Fire to your Android Debug Bridge (ADB), follow the instructions in this PDF. Kindle Fire has USB debugging enabled by default.

Your app requires access to Google Mobile Services. Will it work on Kindle Fire?

Apps that run on Kindle Fire do not currently have access to Google Mobile Services (GMS). If your app currently requires access to GMS apps or services, we recommend that you either remove the features that require these services or modify them to degrade gracefully when invoked (e.g., with an error message such as: "This feature is not currently available on this device.").

Your app is optimized for the Motorola Xoom (Honeycomb 3.0-based Android). Will it work on Kindle Fire?

In general, apps optimized for a tablet experience will work on Kindle Fire. To increase the probability that your app will be compatible with Kindle Fire, you should only use APIs that are backwards compatible with Gingerbread (Android 2.3 OS).

What are the dimensions of the status bar (time, battery, signal strength, etc.) on Kindle Fire?

The status bar is 40 pixels in height.

How can you promote your app to Kindle Fire users?

We encourage you to promote your app's availability on Kindle Fire and in the Amazon Appstore for Android using Amazon-approved marketing assets. Developer Portal account holders can find Amazon approved marketing assets and brand, trademark and marketing guidelines here:

Amazon Appstore for Android Trademark Usage, Brand, and Marketing Guidelines

How do you get your app marketed on Kindle Fire?

All apps in the Amazon Appstore for Android are discoverable by millions of Amazon customers. Amazon's automated and targeted marketing and merchandising algorithms provide a unique and personalized shopping experience for every Amazon customer.

The Free App of the Day is our premier promotion in the Amazon Appstore for Android.  Each day, the app we select is featured in some of the most visible placements in the Amazon Appstore.  These placements and the exposure they provide drive significant traffic to the featured apps and allow the developers to quickly grow their installed base.  In fact, it is common for apps to be downloaded more than 150,000 times on the day they are featured in the Free App of the Day.  That volume of new users can not only generate great word-of-mouth publicity for your app, but can also provide a compelling opportunity for you to monetize your apps downstream through features like in-app purchasing and advertising.

If you'd like to submit your app for inclusion in the Free App of the Day program, please complete this form.

This post discusses how Android apps can use Amazon Web Services (AWS) to send e-mail without additional infrastructure. The sample code presented here uses Amazon Simple Email Service to record feedback from users but this same method could be used in the following scenarios:

• automated alerts/bug reports
• feature requests
• blog by e-mail

Amazon Simple Email Service (Amazon SES) is a highly scalable and cost-effective bulk and transactional email-sending service for businesses and developers. Amazon SES eliminates the complexity and expense of building an in-house e-mail solution or licensing, installing, and operating a third-party e-mail service.

This post shows a sample for the Android platform. The complete sample code and project files are included in the AWS SDK for Android. A link to the SDK is available at the end of this post.

To use the AWS SDK for Android, you will need AWS credentials, that is, an Access Key ID and Secret Access Key. If you haven't already signed up for Amazon Web Services, you will need to do that first to get your credentials. You can sign up for AWS here. After you sign up, you can retrieve your credentials at this page.

The sample application described here demonstrates how Android apps can record feedback from their users through Amazon SES. It requires that you already have a verified e-mail address; this address will be used as both the sender and recipient of the message, so it is not necessary to get production access to Amazon SES before using this sample application. You can verify an e-mail address on the AWS console and read more about verification and production access in the Amazon SES Getting Started Guide. Amazon SES can also be used to create other types of e-mails not shown here.

Creating an Amazon SES Client

Making requests to Amazon SES requires creating a client for the service. The code below shows how to create a client on both the iOS and Android platforms.

AWSCredentials credentials = new BasicAWSCredentials(                                           PropertyLoader.getInstance().getAccessKey(),                                           PropertyLoader.getInstance().getSecretKey() );AmazonSimpleEmailServiceClient sesClient =                              new AmazonSimpleEmailServiceClient( credentials );

Creating E-mail

SES will accept both regular and raw e-mails. Our application makes use of the regular method, meaning we do not have to construct our own headers. Regular e-mails require a source, destination (list of to, cc, and bcc addresses) and a message, which itself comprises a body and subject. The code below shows how to create the various parts of the email on both the iOS and Android platforms.

String subjectText = "Feedback from " + nameField.getText();Content subjectContent = new Content(subjectText);    	String bodyText = "Rating: " + ratingBar.getRating() + "\nComments\n" + commentsField.getText();Body messageBody = new Body(new Content(bodyText));	    	Message feedbackMessage = new Message(subjectContent,messageBody);    	String email = PropertyLoader.getInstance().getVerifiedEmail();Destination destination = new Destination().withToAddresses(email);

Sending E-mail

Once we've constructed our e-mail components, it simply becomes a matter of creating a SendEmailRequest and passing this to the SES client we created earlier. The code below shows how to create a SendEmailRequest and send it with Amazon SES on both the iOS and Android platforms.

SendEmailRequest request = new SendEmailRequest(email,destination,feedbackMessage);SendEmailResult result = clientManager.ses().sendEmail(request);

References

A sample application that includes this code is provided in the AWS SDK for Android. The download link can be found on the following pages:

• AWS SDK for Android

For more information about using AWS credentials with mobile applications see the following article:

• Authenticating Users of AWS Mobile Applications with a Token Vending Machine

Questions?

Please feel free to ask questions or provide comments in the Mobile Development Forum.

A few months ago, Amazon introduced Kindle Fire and, here on the blog, we talked about how you can get your app(s) onto Kindle Fire. We endeavor to provide our developers with useful, relevant information to help you develop your app(s) and we continue to get queries about developing for Kindle Fire. We have more information to share!

Your app requires an SD card—does Kindle Fire have one?

Kindle Fire has an internal SD card that your app can write to. Kindle Fire's SD card is internal and is not removable. You should not have to change your app for Kindle Fire if it currently stores data on the SD card. Using getExternalStorageDirectory() will enable you to write to the internal SD card on Kindle Fire.

Your app uses Adobe Air—will it work on Kindle Fire?

Yes, Adobe Air 2.7.1.1999 is pre-installed on Kindle Fire. If you wish to create and publish Adobe AIR 3 applications, you may do so by packaging them as 'captive runtime' apps. Note that captive runtime apps will not support on-device debugging.

Your app needs the support of an e-mail client—is that a feature of Kindle Fire?

Kindle Fire has a pre-installed e-mail client that will respond to both mailto links and e-mail intents.

How do you configure the supports-screens element for compatibility with Kindle Fire?

To ensure your app is compatible with Kindle Fire, specify <supports-screen android:largeScreens="true"/> in your manifest file.

Your app has audio—what audio playback does Kindle Fire support?

Kindle Fire supports the following audio formats natively:

• AAC LC/LTP
• HE-AACv1 (AAC+)
• HE-AACv2 (enhanced AAC+)
• AMR-NB
• AMR-WB
• MP3
• MIDI
• Ogg Vorbis
• PCM/WAVE

You plan to upgrade your app to Android v4.x (Ice Cream Sandwich)—will your upgraded app work on Kindle Fire?

To increase the probability that your app will be compatible with Kindle Fire, you should only use Android 4.x APIs that are backwards compatible with Android 2.3 Gingerbread.

Your app has lots features—what specific features does Kindle Fire support?

Kindle Fire supports the features in the following list. To ensure your app is compatible with Kindle Fire, it should only use features found in this list.

One great benefit to having your app on the Amazon Appstore for Android is cross-promotion. Cross-promotion is a form of marketing where customers of one product are targeted with promotion of a related product. Amazon.com has millions of customers, and those customers purchase tens of thousands of products every day. With so many great products (and customers), we have the unique ability to employ cross-promotion, even across product categories.

So, what do you need to do? Nothing! By default, apps that are published in the Amazon Appstore qualify to get picked up in the cross-merchandising widgets and promotions.

In the below image, you’ll see the product detail page for an Android app. In the Customers Who Bought Related Items Also Bought widget right below the general app information, you see that our site is automatically recommending a USB cable to the customer who is interested in this app—simply because other customers purchased similar items.

Similarly, in the following image, you can see the Customers Who Bought This Item Also Bought widget. This form of cross-promotion allows customers to make informed decisions about which apps they purchase while also showing them additional apps that might interest them.

Another Amazon widget that can benefit your app is the What Other Items Do Customers Buy After Viewing This Item? widget. Below, the widget is appearing on the product detail page for a tablet device and is advertising an app that was purchased by a customer who also purchased the tablet.

All of the above-mentioned widgets are automated, but we also have the ability to manually cross-promote your app. In the following image, note that on the product detail page for a hardcover copy of this Dr. Seuss book, we’ve added a recommendation for the related Android app.

Cross-promotion means customers can discover your app in a number of ways—not just by searching on the title or category. And over time, your app sales have the potential to increase, purely based on this cross-promotion. That’s never a bad thing, right?

With the rise in popularity of bar code-reader apps, QR Codes have become a convenient way of transferring text from media to mobile devices. A report published recently by MGH indicates that a growing number smartphone owners use the two-dimensional images to gain access to products and promotions.

A QR Code is a square, black and white image that contains standardized patterns to store text, in the same way that bar codes contain patterns for alphanumeric characters. The amount of encoded text can vary depending on the size of the QR Code image, but typically the text encoded is relatively short and takes the form of a URL. You may have seen the following options on our Get Started page to quickly give you access to the Amazon Appstore on your Android device:

As mentioned in a previous post, you can link directly to apps in the Amazon Appstore with a mobile-friendly URL. The URL can be represented as a QR Code, which can then direct potential customers on your website or blog to your app on the Amazon Appstore mobile client. For instance, the following link and corresponding QR Code will send users to the detail page for the Amazon MP3 App for Android:

http://www.amazon.com/gp/mas/dl/android?p=com.amazon.mp3 

The following URL will invoke a search to find MP3 related apps on the Appstore:

http://www.amazon.com/gp/mas/dl/android?s=mp3

Any QR Code generator that meets the ISO requirements will suffice. Some websites that can do this for you include Delivr, bit.ly, the URL shortening site, and Google.

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:

• Different Android SDKs and OS versions
• Different  hardware features (GPS vs. non-GPS)
• Various screen resolutions and densities (high definition vs. standard definition)

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:

• Pricing differences for certain devices
• Large resources, such as images and videos, make your apk too big

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.