In house testing with side-loaded apps is great for isolating and fixing bugs, but it’s not enough. To be certain that your customers are getting the experience you want them to have, you have to test your app against a production environment. 

We’re excited to announce a new tool for mobile developers called Live App Testing. Live App Testing allows you to quickly distribute your apps in the Amazon Appstore to a pre-defined set of testers before you go live.  The testers will be able to sample the full suite of Amazon services - including in-app purchasing - against our production environment, so you can ensure your app is working as expected.  This allows you to gather feedback, improve quality, increase stability and optimize the experience before you push your app live for all customers to download.

What is it?

Live App Testing allows you to create a version of your app that is only distributed to select testers of your choice. You invite testers by adding their email address to Live App Testing.  Once testers are invited to test, they will receive an email with instructions to download the test app and begin testing against Amazon’s production environment.  Only invited testers will be allowed to download and test your app.  As a part of Live App Testing, you can test your apps on any Android or Amazon Fire device.

What does Live App Testing Include?

• Test your app against Amazon production environment before distributing to everyone:  You no longer need to wait until after your app is launched to get real world testing.  You can now distribute your app to a set of testers you define, which gives your more control over the test.  And, you can quickly test against a production environment (yours and Amazon’s), ensuring a higher quality app when you release to the general public.
• Tester Management: Easily define the list of testers you want to be able to test your app.  You don’t need to keep track of who you have invited to test your app.  Amazon takes care of the complexity of ensuring that only the set of testers you defined are the ones that are testing the app.
• Test on all Android and Amazon devices, including Fire TV and Fire phone:  You can choose to test your app against all Android and Amazon devices, including the Fire TV and Fire phone. 

Step by Step guide

1.  Go to the Amazon Developer Portal and select “My apps”. You’ll need to sign into your developer account. If you don’t have one yet, the sign up is easy and it’s completely free.

2.  Select an existing app or click on “Add a New App”.  If “Add a New App” is selected, go to step 3, otherwise, skip to step 4.

3.  After selecting “Add a New App”, select “Android”.  Click next and fill out the New App Submission information.

4.  Select Live App Testing to begin to setup a test for this app.  Once on this page, click on “start your first test run” to begin the process of setting up your first test.

5.  Fill out all of the required tabs

In this step, you will be adding the metadata and the APK that you want to test.

6.  Once you have filled out each tab, you can either submit your app (without assigning testers) or go to the dashboard and add testers.

If you are not ready to add testers at this time, you can select “Submit” and submit the app for publishing.  This process can take up to a few hours.

If you would like to add testers before submitting your app, select “Go to Dashboard” to add testers following the steps below.

7.  On the dashboard, click on “Add Testers” to add testers to the test.

8.  On the testers page, click on “Add Testers”.

9.  Either upload a list of tester email addresses or add the testers individually.  I recommend you add yourself as a tester so you can get the invitation email which will signify that the binary is available to download and test.

10.  Once you add the testers, select save.

11.  You will notice on the dashboard that you have 1 tester assigned to the test.  At this time, select actions (the sprocket icon) and select submit.

You’re all done.  Testers will receive an email to join your test once the app is live.

Managing Your Test

Once your app is running, you can either end your test, or promote your test to an upcoming version.  By promoting your app to an upcoming version, you can make some finishing touches such as upload final screenshots or metadata before going live.

Tests that you have ended will appear on the Live App Testing Dashboard under the “Past Tests” section.

You can also easily see the crashes that have occurred during this test in the Live App testing Dashboard.

Try Live App Testing Yourself

The new Amazon Live App Testing helps you manage testing to help you publish higher quality apps in the Appstore with fewer errors. Creating a new test is easy through the Amazon Developer Portal, at no cost to you. Click here to get started.

Click here to get a free Amazon developer account.

Do you want your app or game to be on the new Fire phone?  Most Android apps already work on Fire phone. Take 90 seconds to find out if your app is ready by using the Amazon App Testing Service. If any incompatibilities are found while testing, you’ll get a detailed report with guidance on how to remedy the situation.

To help you get started, here’s a step-by-step guide and a video that walks you through the process.

1) Go to the developer portal

To start, head over to the developer portal at (https://developer.amazon.com/welcome). All you need is your app’s .APK.

2) Drag your App’s .APK onto the tester

3) Get compatibility test results in 90 seconds

Most Android apps work on Fire mobile devices without change. If the tests do find anything that could prevent publication, you’ll receive specific suggestions and be directed to documentation that will help you make the necessary changes.

4) We’ll also test it on the device

The top section of the results page includes a list of screenshots. Click through them to see what your app looks like on the right.

Below that are sections that show you memory and CPU usage and your log during the test.

5) Now Is the Time to Submit Your Apps for Fire

Once you’re ready to submit your app, begin the submission process by clicking the orange button in the middle of the screen or by going to: https://developer.amazon.com/public/support/submitting-your-app

To submit, you’ll need to sign in. Developer accounts are free so go ahead and make one if you haven’t already.

Create immersive apps that respond to the way a customer holds, views and moves the phone. We have updated Appstore Developer Select and Amazon Mobile Ads API with more incentives:

• Amazon Developer Select: Optimize your apps for Fire phone and get enhanced merchandising and 500,000 Amazon Coins incentives for your customers. Get the details here.

• Amazon Mobile Ads API: Developers earn $6 for every thousand interstitial ads displayed across any supported device in August and September (up to one million impressions per app per month) when they distribute their apps on Fire phones and send the first ad request from a qualified app. Get the details here.

• Amazon App Testing Service: Most Android apps just work on Amazon devices. Test your app's compatibility in 90 seconds by dragging and dropping your Android APK into our testing tool. Sign up for a free developer account to test your app's look and feel on devices and get the results within 6 hours. Test your app now.

Now is the time to submit your apps and games! Apps that are submitted by July 18 and approved will be in the Amazon Appstore when Fire ships on July 25.

Fire Developer Resources:

Get a free Amazon Appstore developer account

Fire Getting Started Guide

SDK downloads

@PaulCutsinger

Our A/B Testing service just added support for A/B/n tests, allowing more than two variations in a single experiment. This feature makes it even easier to quickly optimize your app in the field—without having to republish your APK. A/B/n testing saves you time since one experiment can now test up to five variations at once.

For example, suppose you have four ideas for how to label a Buy button – Buy, Purchase, Add to Cart, and Get it Now! – and want to know which label leads to the most purchases. You start by setting up an A/B test as you normally would (if you’re new to A/B testing on mobile, learn more about getting started) and click Add Variation for each new variation:

A/B/n testing saves time, since standard A/B testing of four variations would require completing multiple A/B tests one after the other. The experiment above, for example, would require three separate tests, with the winning test becoming the new control each time.

A/B/n testing lets you compare all four variations at once, so only one test is necessary:

When planning an A/B test it is important to consider the size of the daily active user base you want to affect and how long you can wait for the test to complete. If a variation’s slice of the data is small, the A/B test may take a long time to achieve statistical significance. Apps with a large audience can likely distribute most customers to Variation A (Control) without sacrificing test time or significance. Apps with a smaller audience will want to distribute tests evenly across all variations as shown below:

After you identify the winning variation, the A/B Testing service allows you to launch it to customers with a simple button click on the Mobile App Distribution Portal. There’s no need to republish your app. You can simply indicate which variation the service should distribute to customers from now on.

If you’re an Android developer, explore this update to the free Amazon A/B Testing service. We’re interested in hearing your feedback on A/B Testing. Please take this short survey to help us improve the service.

I had to take a class in accounting before I understood the difference between sales and earnings. Fortunately, learning about Amazon Mobile App Distribution Program sales and earnings reporting is quite a bit simpler than that accounting class. 

While there are 7 possible reports to choose from, in this blog post, we’ll cover three popular financial reports:

• Sales reports – show basic sales less returns over customizable time periods and countries.
• Earnings reports – show more details (including adjustments) in a fixed one-month period.
• Payment Reports – show you what you are actually paid every month.

Sales Reports show trends in sales and returns over standard or custom time periods. You can get daily breakdowns in CSV reports, and you can see sales broken out by individual marketplace or by the almost 200 countries in which you app could be sold. Data in sales reports are updated every few hours but do not reflect processed financial data for the current month. They do not include adjustments and other data that will affect your payment.

Below are two examples of reporting that can be customized by app and international marketplace. The first is a map view. Note the drop-down buttons for ‘Date’, ‘All Apps’ and ‘All Marketplaces’. These let you show a specific date range and show sales by marketplace (like amazon.co.uk or amazon.fr) or by the country (such as Brasil or Norway).

The next example shows a tabular view of the Sales report with detail such as Units Sold, Units Returned, Units Refunded and Gross Revenue.

Earnings Reports represent the sales, refunds, app earnings and adjustment data used to calculate royalties earned during a given month. Data in earnings reports are released on a monthly basis once royalties earned in the previous month have been processed and approved. Monthly summary information is available in the Amazon Mobile App Distribution Portal and daily breakdowns are available through CSV export.

Payment Reports represent the actual disbursement of funds from Amazon. Monthly summary information is available in the Amazon Mobile App Distribution Portal on the payment reports section.

Accessing Reports Getting these reports is easy. Log in to the Amazon Portal and click on the Reporting link (shown below). Then select the report you want, then select your customization filters below that.

(Note: of the seven reports shown in the screen shot below, all but the Beta Engagement report now allow reporting by country of sale)

The Amazon Moblie App Distribution Program gives you useful reporting data that is pretty easy to access and understand. My accounting teacher would be proud. Try getting a few reports now, and see how easy it is to get data on your apps today.

It’s easy to see how hackathons can spawn creative teams and fantastic ideas, but I’ve also seen great ideas die because bad pitches sink good hacks.

In a Hackathon event like AngelHack, developers, designers and entrepreneurs gather on a Saturday morning to mingle and meet like-minded folks, form teams, and decide on a cool project to work on. These teams will then spend all night building the project they design. Sunday afternoon, it’s pencils down time, and the teams get between 3 and 5 minutes to present what they’ve done to a panel of judges, who in the case of AngelHack, will decide who to send to the Bay Area to meet with venture capitalists for potential funding.

To be sure, hackathons are won with great hacks. Liam Boogar, hackathon judge and the brains behind rudebaguette.com, says “For me, people win hackathons with awesome hacks, not thoroughly thought out business models. A business model is a means to justify the long-term growth of an amazing product - without the amazing product, the business model is useless.”

Point well made. No business or presentation wizardry will save your team if you have a worthless hack, but a great hack that understands the business end will beat a great hack that doesn’t. 

Questions You Need to Answer:

The good news is that communicating the business side is as easy as addressing these 5 questions:

1. Who is going to use your app and what is their need?
2. How does your hack address that need? (this is where you demo your awesome hack)
3. How does the user acquire the solution? (if the monetization approach is clever, demo it here)
4. Is your hack unique? How is it unique?
5. Can the hack be scaled to be a viable business?

Most teams miss one or more of the points above, and a few teams miss all of them. So even if you copy/paste this list to a document, write the answers underneath, and then read that doc to the judges, you’ll be doing better than most. (Seriously, don’t worry if you’re not a great public speaker. At one event, a team whose speaker read the entire presentation from his laptop still progressed to the finals because it was a good hack and the judges understood the business.)

Building the Demo:

Once you have answers to the 5 questions above, it’s time to build the presentation and demo. This does not have to be complicated, and it shouldn’t take long. Here is some guidance from AngelHack judges:

PowerPoint or not? Some teams use a slide deck, some don’t. I’ve seen valuable and impactful presentations done both ways.  Just make sure you demo what you have built. I was on a judging panel where the team showed only slides. Great business model, but the hack was completely missing. That did not turn out well!

Demo the hard part. Most solutions have easy parts and hard parts. Rendering a simple list on the screen isn’t a hard part. Getting the correct data to render often is. If you try to hand-wave your way around the hard problems, you’re in trouble. Don’t show loading screens or other trivial stuff. Liza Kindred, AngelHack Judge and founder of Third Wave Fashion, says via Twitter: “We don't want to watch you log in! Have it ready to go, your three minutes are too short!”

Tell a story. If you can, weave the points above into a story.   Here is how one team used a story to weave in a lot of points in short time:

One speaker told a story about how his grandmother couldn’t respond to text messages even though she wanted to stay in touch more often (Question 1, time: 15 seconds). He showed the hack, demonstrating how their project removed the barriers that prevent the elderly from using technology (Question 2, time: 2 minutes). The speaker described the ways that grandma might come to own their product (Question 3, time: 20 seconds). 

The only part of their message they didn’t weave into a story was their product’s differentiating factors and how they scale to be a viable business. Whether or not the judges agreed that this was the right solution for helping grandma doesn’t matter. We all remembered the story. We talked about the story. Stories work.

If you can’t tell a story.  Some projects or some teams just don’t work with stories. That’s okay. You’ll just need the discipline to avoid detail overload when outlining your points. Good hacks can get great scores even without a story.

Discuss what you built over the weekend. Rebecca Lovell, CEO at Vittana.org, says: “We want to know what you were actually able to accomplish over the weekend. If it's an existing company and you built a Kindle app, tell us. If you just thought of the whole idea this weekend, we'll be duly impressed with whatever you were able to hack over such a short period of time.  Above all: be transparent with the status of your product development and achievements.”

Presentation Time Management Tips

As long as you end up covering all of your points, you’ll have a good demo. These tips are designed to help you make sure you can get your message across in what seems like no time at all.

• Practice your presentation. For goodness sake, practice the whole thing, end to end, with demo components. You’ve only got 3-5 minutes to pitch your hack at these events. Many teams fail to complete their presentation due to poor time management. Practicing will help alleviate this.
• Leave enough time to demo your hack. …and then be sure to demo the hard stuff, not splash pages, loading screens, or login dialogs. I’d suggest leaving no less than half your time to demo the hack. I’ve seen speakers go into so much detail describing how they built the solution that they leave only 30 seconds to show it!  We need to see the great hack if you’re going to win a hackathon.
• More than your name may not matter. Don’t spend time with introductions longer than your first name unless it’s describing experience directly relevant to the project.
• Don’t let your knowledge hurt you. When you have a great deal of domain expertise, it’s easy to get caught up in details that may be important, but not necessarily relevant for a short pitch.
• Be prepared for unmitigated disaster.  At one hackathon, there were some technical problems with the HDMI cable to the room projector, and it flustered some folks so much that they didn’t do as well as they might have otherwise. Be ready to walk a device around to the judges if you have to.
• Practice your presentation. I’ve seen at least a dozen teams plan how they will do their presentation and call that practicing. It’s not. Rehearsing in your head is not practicing either. Actually finding a place to speak the whole thing quietly to a teammate is practicing. Just 10 to 15 minutes will make a big difference.
• Have Fun! Rebecca at Vittana.org says: “We know you're sleep deprived and hopped up on Red Bull, but make sure to sell it!  Show your passion!”

So, after all is said and done, you need a great hack to win a hackathon. And the great hack that clearly communicates business basics will beat a great hack that doesn’t.

Before Mike Hines was a Technical Evangelist for Amazon, he founded a financial services company and an education software company. Join Mike Hines and Amazon at the Silicon Valley AngelHack in San Jose, CA on June 15 and 16. You can follow Mike on Twitter @MikeFHines

Starting today, customers can now buy apps and games directly from PCs and Macs for their Android phones, tablets, and Kindle Fire. You can now reach the millions of customers visiting Amazon.co.jp, either by automatically being included in recommendations on product detail pages or product search results, or featured on the Amazon Appstore for Android web storefront. Plus, you can now directly link to your app or game to promote its availability on Amazon.co.jp—learn more about linking to your apps and games on Amazon here.

This comes on the heels of our recent announcements of the opening of our store in nearly 200 countries worldwide, and Kindle Fire HD becoming available for pre-order in those countries as well. The shop is open today, and available at www.amazon.co.jp/apps.

It’s no secret that customer satisfaction is key to Amazon’s success. It’s something we obsess about, and we constantly tweak everything from product selection to payment options to website design. We experiment, we measure, and we decide whether or not a change improves the user experience. One of the most powerful tools at our disposal is something we call a Web Lab, which allows us to test two (or more) different versions of a webpage, or roll out a new feature to a limited audience.

Perhaps this concept is less familiar to mobile application and game developers than to those who write web code, but it shouldn’t be. In fact, it’s so useful and important that Amazon’s A/B Testing service was one of the first we made available to mobile developers (If you haven’t tried the service yet, check out Getting Started with A/B Testing for a quick introduction).

Now a significant enhancement has just been released: Segmentation offers greater flexibility and control over who sees your experiments, allowing you to limit your tests to a set of users based on any dimensions you care to associate with them.

User dimensions

A “dimension” in this sense is simply a named characteristic whose value is a number or a bit of text. The UserProfile singleton object manages the dimensions you define, keeping track of their values for the current user. It’s these values that determine whether the current user is a member of a particular segment, and it’s entirely up to you how they are chosen, named, and initialized.

For example, say I want to test a new wine feature in my restaurant review app. I don’t want everyone to see it—just my beta testers—so I define a dimension called “isBetaTester” and initialize it based on some information I know about the current user:

        // Determine if the current user is actually participating in the beta,

        // based on my own definition of “participating.”

        boolean isBetaTester = validateUserAsBetaTester();

        // Set the dimension for the current user.

        UserProfile.addDimensionAsString("isBetaTester", String.valueOf(isBetaTester));

        // Initialize the Insights SDK to enable A/B Testing.

        AmazonInsights.withApplicationKey(MY_APPLICATION_KEY)

                      .withPrivateKey(MY_PRIVATE_KEY)

                      .withContext(getApplicationContext())

                      .initialize();

                 . . .

In this case, validateUserAsBetaTester() is a helper method I define to assist me in deciding whether the current user is a beta tester or not. This could be a preferences setting, or perhaps a check against an email whitelist.  Regardless, I’m responsible for setting the value, which I do before initializing the A/B Testing system.

Create a segment

Now that I’ve established a dimension to differentiate users, I need to define a segment that actually refers to it. The segment may be associated with any A/B test, limiting access to users who match (or don’t match) along the relevant dimension. From the Amazon Mobile App Distribution Portal, I navigate to the A/B Testing tab of my app, then click Add a New Segment.

Next, I fill in the segment information, paying special attention to the dimension information, since that must correspond to the name (“isBetaTester”) and type (String) I use in my application. In this case, I define a segment called “Beta Testers” that will include anyone whose isBetaTester dimension is a string equal to “true”:

Limit a test

With a segment defined, I can now use it to limit the scope of an A/B test. Let’s say I want to experiment with the length of user-submitted wine reviews. (I’d like to give people more space, but have to balance the storage required against the benefit of more detailed content.) When I create the test, the last setting allows me to specify the user segment I want to target. In this case, I choose my beta testers, whom I just identified:

When the test is started, beta users will begin to see variations of wineReviewLen, subject to the distribution I specify.  In my app, I can initialize a variable with the maximum allowable review length for the current user:

        ABTest.getVariationsByProjectNames("Wine Reviews")

            .withVariationListener("Wine Reviews", new VariationListener() {

                public void onVariationAvailable(Variation variation) {

                    maxReviewLen = variation.getVariableAsInt("wineReviewLen", 256);

                }

            });

For users outside the Beta Testers segment, the control variation will always be allocated. However, these users will never be included when the results of the experiment are calculated.

Complex segment criteria

In this simple example, a single boolean value was enough to distinguish segment members, but segmentation supports much more complicated criteria. You can easily attach more than one variable or change how variables are evaluated. String equality works as demonstrated (numeric equality is identical), but it’s also possible to create a segment based on a numeric range or set membership.

For example, perhaps I want to further segment my beta testers by those who have made a past purchase. I can create a numeric value called purchasesToDate and define the valid range as any non-zero value—note that I just have to start at 0 (exclusive) and omit the upper bound:

If I wanted to create a segment of customers in the Pacific Northwest, but only those who have used the app in 2012 or 2013, I could combine two tests for set membership:

Important note: users retain the variation they are initially allocated, even if their dimensions change later on.  This means that once a user has been identified as a member of one segment, they never move to another for the duration of the test, even if their dimensions change. This ensures a consistent experience; significant changes to features or interface could be jarring. (If a new test is started, the dimensions will be re-evaluated.)

That’s it!

Setting up segments is simple and adds a lot of flexibility to your experiments.  Give it a try the next time you’re considering A/B testing.  For information, be sure to check out the Insights documentation.

Login with Amazon is now available to developers to integrate in their mobile apps and websites. The new service lets you take advantage of the same user authentication system used by Amazon.com.  Login with Amazon allows you to securely recognize millions of Amazon customers and provide them with a personalized user experience.  For example, you can greet visitors by their name or display customized offers based on their zip code.

Login with Amazon uses the OAuth 2.0 protocol making it easy for you to integrate it in your app or website. Developers who have previously worked with the OAuth 2.0 protocol will find the terms and concepts straightforward and consistent with other implementations. 

How does Login with Amazon work?

1. The user visits your website or app and clicks the Login with Amazon button.
2. The user is presented with a login screen hosted on Amazon.com.
3. The user enters their Amazon credentials.  First-time users will see a consent screen hosted on Amazon.com to grant your site permission to specific pieces of information.
4. After the user consents, your app will be able to securely access customer profile data (name, email, zip code) to create a new user account and provide a personalized user experience for them.

Login with Amazon SDKs are available in public beta for Android, Kindle Fire, and iOS. To integrate the service in your app or website, go to login.amazon.com to register a developer account, download the SDKs, and view the Getting Started Guides.

Login with Amazon adds yet another capability for mobile app developers.  Now, developers can use Amazon Web Services (AWS) for its infrastructure (e.g., compute, storage, and database). For those interested in building cloud-backed apps, you can read more about it here.

The Amazon A/B Testing service is an effective tool to increase user engagement and monetization. It allows you to set-up two in-app experiences (each of which is presented to a different group of users) and evaluate the success of each, based on criteria you establish. Another, less obvious, use of the A/B testing service is feature timing. It’s easy to turn on a new feature at a specific time, or release a series of features on a schedule. You can do it in four simple steps, which I walk through here:

1. Creating a new A/B project and launch used for releasing a feature
2. Integrating the SDK and API into your Android app
3. Adding the Java code necessary to enable your feature based on the A/B launch
4. Releasing your feature via Amazon’s A/B Testing portal

Step 1: Creating a new A/B project and launch used for releasing a feature

Using the Amazon A/B Testing service requires an Amazon developer account and an Android app associated with the account. If you don’t already have a developer account you can sign up here. The first step for using Amazon’s A/B Testing to release a feature is to create an A/B launch used to determine whether the feature in your app is hidden from users or accessible by them. Once signed into your developer account the following steps can be used to accomplish this:

1. Navigate into your app. Click “My Apps” on the navigation bar of the Mobile App Distribution Portal to access your list of apps.
2. On the detail page of your app, click the “A/B Testing” link as shown below.
   
   



3. A screen displaying your list of A/B projects is displayed. Click “Add a New Project”.
   
   



4. Enter a title and description that indicates this test is used for the launch of a specific feature and click “Save Project”.
   
   



5. Click “Add a New Launch” on the detail page of the project you just created.
   
   



6. We are now looking at the page for creating an A/B launch. Enter a name and description that indicates this is used for a feature release. For the variable, we create a boolean that tracks whether the feature is enabled. The old variation is set to false and the new version is set to true. Make sure to keep the old variation set to 100% of the distribution. This means all users of your app will not have the feature enabled when you check this A/B launch’s variable. Click “Save” to add your A/B launch.

7. Click the “Start” button on the newly created A/B launch to make it available for use.

Step 2: Integrating the SDK and API into your Android app

We now have an A/B launch containing a corresponding variable for determining whether our feature is made available. The next step is to integrate the A/B Testing SDK into our app using the following steps so we can write code to obtain whether the feature is made available.

1. Download the Amazon A/B Testing SDK from here.
2. Set the required permissions INTERNET and ACCESS_NETWORK_STATE in your AndroidManifest.xml file.

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

3. Add the Amazon Insights Processing Service to your AndroidManifest.xml.

<application>
    ...
    <service android:name="com.amazon.insights.InsightsProcessingService" />
</application>

4. Add the AmazonInsights Android SDK jar and all 3 AWS Android jars to your Android project.  These jars can be found in the libs folder of the SDK download.
    

Step 3: Adding the Java code necessary to enable your feature based on the A/B launch

With the SDK setup its time to add code to either make our feature hidden or available based on the variable we configured for our A/B launch. The steps below detail the code needed for accomplishing this.

1. Import Amazon Insights in to your code.
   
   import com.amazon.insights.*;


2. Initialize the Amazon Insights SDK in the onCreate method of your Activity. Note: Your application key and private key can be found on the Amazon A/B Testing page for your application where we created the A/B project in step 1.

AmazonInsights

    .withApplicationKey(YOUR_APPLICATION_KEY)
    .withPrivateKey(YOUR_PRIVATE_KEY)
    .withContext(getApplicationContext())
    .initialize();

3. Add code to enable the feature based on the A/B launch variable.  We obtain our A/B launch variable and check whether we should enable access to the feature.

//Get our “Feature Launch - FeatureName” experiment and retrieve the variable
//for whether the feature is made available.
ABTest
   .getVariationsByProjectNames("Feature Launch - FeatureName")
   .withVariationListener("Feature Launch - FeatureName", new VariationListener() {
      public void onVariationAvailable(Variation variation) {
         boolean featureNameEnabled = variation. getVariableAsBoolean(
            "FeatureName_IsLive", false);
         if (featureNameEnabled) {
            enableFeatureName();
         }
    }
});

 Step 4: Releasing your feature via Amazon’s A/B Testing portal

With your app now supporting the release of the feature, the final step is to make your feature available at the appropriate time. This can be done completely via the Amazon A/B Testing portal and doesn’t require an APK update with the feature enabled. To launch the feature use the following steps:

1. Navigate back to the A/B launch experiment you created for your app’s feature release. This is accessible by clicking the “A/B Testing” link on your app’s detail page. Next click on the current experiment for our feature launch A/B project as displayed by Image 8 below.
   
   

2. Click the “Edit” tab to change the distrubtion of the variable we use to determine if the feature should be made available.
   
   

When the Launch was created the distribution was set to 100% to the “Old Version”. Change the distribution of the new variation to 100%. All users of your app are going to receive true for the variable used to enable your feature. Click “Save Launch” and your feature will now be live for all users. 

In some scenarios you might want to incrementally release a new feature over time. This can beneficial when releasing features for which scaling might be a concern. For example,  you can use Launch to safely increase the percentage of customers receiving the feature while you monitor the scalability of your service.   If a problem is detected you can stop incrementing the release or in an extreme case pull it back.

That is all it takes to support releasing a feature via Amazon A/B Testing in your Amazon app. You can find more information the Amazon A/B Testing service here.

You may have seen the news that our store is expanding to nearly 200 countries. As we grow, we continue to focus on developer success around the world. We’ll be spotlighting developers from countries in which we operate here on our blog over the next few months.  First, we take you to the UK, where just six months after the launch of the store on Kindle Fire in October 2012, British developers and publishers are already seeing some impressive results.

Kent-based P2 Games publishes titles based on popular children’s character licenses, including Peppa Pig (the UK’s leading pre-school franchise), Fireman Sam, and Bob the Builder.  P2 Games was already successful before Kindle Fire launched in the UK, but saw sales quickly grow once the store launched in their home market. 

Peter Sleeman, Director of P2 Games, spoke with us about the success they are experiencing on Amazon.  As he notes, ‘’The popular children’s brands we build apps for were already well-represented on Amazon. For example, they sell Peppa Pig products across multiple product categories, such as Toys, Books, Video Games, and DVDs. It made sense to try to reach these same customers with our apps, particularly given the Kindle Fire is such a family-friendly device. Through our conversations with Amazon, we were aware of the demand for our apps, information gleaned from customers’ actively searching for Peppa Pig titles.’’

Although P2’s Peppa Pig Apps have already been downloaded more than one million times since launching in September 2010, they achieved some terrific results just months after the launch of our store in the UK. 

Peter Sleeman continues, ‘’We launched our first Kindle Fire version in January 2013 and within a few weeks we saw sales on Amazon overtake Google Play by a factor of four or five times. Kindle Fire is now a legitimate contender, and although our apps have been out much longer on iOS formats, our current rate of sale is close to parity with iOS most days in the UK. The launch of our newest paid Android app, Peppa Pig Party Time, in March 2013 has followed in the footsteps of previous titles and is proving very successful. ’’

For P2 Games, these results have changed the way they develop for Android.  Peter told us that, ‘’Our success on the Kindle Fire has been game-changing; our Android development efforts now lead with the Kindle Fire version. We’re really excited to have a number of our other key titles in development for release on Kindle Fire later this year.’’

Publishers like P2 Games tell us that one of the reasons they are turning to Amazon is because it monetizes so well. P2 Games is just one of thousands of UK-based developers and publishers that have already experienced the value of connecting with Amazon customers on mobile devices, and are reaping the rewards of distributing apps on Kindle Fire.  Developers benefit when customers find the apps that interest them through behavioral recommendations and buy ‘friction free’ through 1-Click purchase.

As of today, customers can buy your apps on Amazon in nearly 200 countries worldwide using online and mobile stores in the US, Canada, Germany, France, Spain, and Italy. It was also announced that Kindle Fire HD is available for pre-order starting today, shipping to over 170 countries on June 13. This is a great opportunity for you to reach millions of new customers who can now discover your apps and games online through the Amazon website and on Android and Kindle Fire HD devices. This launch expands developer reach and monetization potential to Amazon customers around the world. For more information see the press release here.

It’s easy to make your apps available in all of these countries. If you are creating a new app, it will be available in all countries by default. You can select country and territory availability for each of your apps if you want to limit their availability. First, go to the Availability and Pricing tab in the distribution portal then select “Only in the following countries…” at the top of the page. You’ll see a list of continents that you can expand to make your selection. The number of countries you have selected in this manner will show up in parenthesis at the continent level. You can set the list price for your apps for each marketplace where Amazon sells apps, or you can have Amazon calculate a list price for you automatically using your base list price. Finally, to help report on all of this international goodness, your sales reporting now reflects your sales by country.

Please be sure to check that your existing apps are for sale in the countries in which you wish them to be sold, and have fun in all the new countries!

(See the International Program Overview FAQ here for more details.)

Amazon Device Messaging, a free service that allows you to send cloud-based push notifications to Kindle Fire customers, is now out of Beta and is in general availability.

You can use ADM to send encrypted real-time notification to update users on breaking news or let them know that a new game task is available for them to complete. You can also use ADM for instant messaging functionality or social networking notifications within your app.

Messaging Overview

• Deployment. We have documentation, sample code, tools, and FAQs to help you integrate ADM. Adding ADM to your app is easy. You obtain your ADM credentials and key (remember, this is an encrypted message), include the ADM library as an external JAR file, update your manifest, store your key as an asset, and implement your broadcast receiver. (we have sample code that shows this). To send a message, your server needs the app registration ID and a security token. You can find more implementation details here.
• Simple. ADM delivers message data to your app on the device, and your app can decide what to do on receipt of that data like download content or display a notice. Your message should be no greater than 6KB in size and sent in the form of JSONObject key:value pairs.
• Delivery. Messages expiration is one week by default, but can be configured to persist for one month if required. ADM will wake up the device to deliver messages, so messages can be sent and received during off-peak hours when the device is likely to be asleep. We use Amazon Web Services as a backend for this service, so we can scale up quickly and reliably.
• Compatibility. ADM is supported on Kindle Fire HD 8.9" 4G, Kindle Fire HD 8.9", Kindle Fire HD 7", and Kindle Fire (2nd Generation) devices.
• Free. Enough said.

Getting Started

Get started with Amazon Device Messaging by downloading the SDK here and reviewing our documentation, sample code, and FAQs. Submit your ADM-enabled app through the Amazon Amazon Mobile App Distribution Portal today!

Feedback from the Beta

During the ADM beta, we had big and small companies try the service, and we got international developer feedback as well. Here is some of the feedback we received:

From Wooga, a social game developer based in Berlin:

“The decision to integrate Amazon Device Messaging into Diamond Dash was a cinch – it is a clear win”, said Soenke Bullerdiek, Senior Manager Strategic Platform Partnerships, from Wooga, “Even better, it was easy to enable and only took a few days of work to start sending push notifications to our users.”

From Gameloft, a world-wide game developer based in the U.S.:

“We decided to use Amazon Device Messaging as a new way to engage our Oregon Trail American Settlers customers on Kindle Fire.  The documentation and sample code was easy to understand for our studios.” Baudouin Corman, VP Americas Gameloft.

We’re pleased to announce that you can now submit apps for distribution in the United Kingdom, Germany, France, Italy, and Spain, using the Amazon Mobile App Distribution Portal. We’ll begin distributing apps in these countries later this summer (and we have more countries planned in the near future). 

The Amazon Appstore in the U.S. has had a very successful year with millions of customers discovering and downloading apps and games. We continue to welcome new developers onto our platform, and since launch, we’ve grown to tens of thousands of apps—with more coming every day. Our recently launched In-App Purchasing API is already helping developers like Mobile Deluxe, G5 Entertainment, and Social Gaming Network delight their customers and generate significant revenue. Amazon now offers developers the opportunity to experience similar success with app sales outside the U.S.

Now is a great time for new developers to sign up and become familiar with the program. You have the ability to select the countries where you would like your apps to be sold and set your list prices by marketplace. If you are already participating in the program, your apps will automatically be made available for sale internationally by default. And you can easily change international availability for your apps via the Distribution Portal if your apps should not be sold in select countries. Developers allowing Amazon to sell apps internationally are responsible for ensuring their apps comply with all applicable export and import restrictions and the laws of the countries in which the apps are sold.

Though Amazon will not require apps to support multiple languages, we encourage you to consider localizing your apps with language translations and to think of creative ways to deliver great experiences to your international customers. Just as in the U.S., if you sell apps in the U.K., Germany, France, Italy, and Spain, you will benefit from Amazon’s trusted 1-Click purchasing as well as the easy-to-integrate In-App Purchasing API.

Today we are also announcing two changes to the Amazon Mobile App Distribution agreement. First, building on the success of the April In-App Purchasing Service launch, and to simplify our global terms, Amazon will be aligning the revenue share for paid apps with that for in-app products sold using Amazon’s In-App Purchasing Service. Starting July 1, you will earn 70% of list price on each paid app sale. This is a change from the prior terms under which you earned either 70% of the app’s sales price or 20% of list price (whichever was greater). To put it differently, starting in July, you’ll receive 70% of the list price for all sales, regardless of whether you monetize your apps up front (paid apps) or downstream (using our In-App Purchasing Service).  

Second, we will be adapting the terms of the distribution agreement to provide more flexibility around timing for app submissions. You will now control which apps you will make available to Amazon customers, and when, as well as the countries in which your apps may be sold. As a reminder, it’s your responsibility to ensure your list prices do not exceed the lowest prices at which your apps and in-app products are sold in similar stores. To review the full agreement, including the two changes described above, please follow this link.

If you don’t already have a developer account, it’s easy to join and we’ve waived the annual fee for 2012  it’s free to register for a developer account. Sign up now, and start submitting your apps for international distribution later this summer!

What is code obfuscation?

If you are ready to submit your app to the Amazon Appstore for Android, you might consider obfuscating your code. Obfuscating your code modifies your source and machine code to be difficult for a human to understand if your app gets decompiled. If you are concerned about your app being reverse engineered, using a tool to obfuscate your code can help a great deal.

Caveat

Not all of your source can be obfuscated, however. If you are implementing In-App Purchasing for your app, the Amazon Appstore relies on certain methods being available to call and provide you with information about a purchase request. If these methods get obfuscated and renamed, the Appstore will not be able to send information to your app. This post is a brief walkthrough on adding code obfuscation to your project.

Proguard

For android apps, Proguard is a code obfuscation tool that is provided to you once you download the Android SDK. The program shrinks and obfuscates your source code.

Setting Up Code Obfuscation for your Project

Prerequisites

This walkthrough assumes you have the Android SDK and Amazon In-App Purchasing API installed and your project already completed.

For help on installing the Android SDK, please refer to their website at http://www.developer.android.com/sdk/installing.html. Download the Amazon In-App Purchasing API by going to http://developer.amazon.com/

Enabling Proguard for your App

To enable Proguard for your Android app, refer to the following documentation from the Android SDK: http://developer.android.com/guide/developing/tools/proguard.html

Edit the build.properties file inside of your project, and add the following line (if you don’t have this file in your project directory, make one):

 ‘Keeping’ the In-App Framework Intact

When incorporating the in-app framework into your library, you will need to specify classes to ‘keep’ and not obfuscate. Add the following lines anywhere in your proguard.cfg file.

Finalizing and Releasing Your App

Now that you’ve fully set up your proguard.cfg and build.properties file, you can run Proguard through the ant  build script for your project.

Obfuscation with another Program

If you are using another program for code obfuscation, to ensure that in-app functionality is preserved, make sure your program does not obfuscate any class under the com.amazon.* namespace, including method names and identifiers. Your obfuscation program must also preserve annotations.

Conclusion and Additional Resources

The code in this article serves as a walkthrough for enabling and using Proguard for release candidates of your app. Sample apps that include the code from this article are provided in the In-App Purchasing API. Again, you can download the SDK by logging into http://developer.amazon.com/

G5 Entertainment participated in Amazon Appstore for Android’s in-app purchasing (IAP) beta program because they had successfully launched over 100 games with in-app purchasing on other devices.  Larissa McCleary, Director of Marketing at G5 Entertainment writes, “We found that by offering a product with IAP, rather than a traditional "lite" or "full" set of offerings, our conversion rates went up as did our revenue on a per title basis. Although our experience on Amazon has always been great, we are thrilled now that IAP is available. This will allow us to continue our business model, but also to allow other developers to partake as well. Eventually, if more and more developers participate, we think we will experience even higher conversion rates, since players will be more familiar with what IAP is and how it functions, making the play experience even more engaging.”

G5 Entertainment takes the approach that if the game is interesting, customers will be more engaged. The maker of popular games such as Virtual City Playground and Mahjong Artifacts, McCleary tells us, “Our basic strategy has been to make the games as fun as possible. We are working hard to optimize and improve our features on an on-going basis.” How do they decide what will be fun for players? Playing the games themselves, focus testing, and team brainstorms have all led to added content.  However, McCleary notes, “In the end we decided that we should let players decide what they want, by giving them as many in-app options as possible.”

The G5 team reported that overall, the integration was quick and simple. McCleary says, “The code was ready in one day, and metadata was entered quickly too.” Comparing their experience to past integrations, the Amazon Appstore compared favorably. “It’s definitely easier to integrate the Amazon IAP APIs than other IAP solutions we have implemented,” notes McCleary.

During the beta program, G5 found their main hiccup in the testing process. G5’s QA team provided feedback that helped the Amazon Appstore improve the testing process by introducing the SDK Tester. The SDK Tester allows a developer to validate common path and edge case scenarios in their app, all without uploading or configuring anything in the Amazon Developer Portal. This approach reduces the friction a developer faces when testing their apps, and allows for rapid testing across any device that supports the Amazon Appstore. Still, the IAP API was well worth integrating for G5, and the G5 team recommends “reading the documents available on Amazon’s Developer Portal and keeping your code simple.”

About G5 Entertainment AB

G5 Entertainment AB is a developer and publisher of high quality downloadable games.  G5 started as the leading mobile game development studio working for Electronic Arts and Disney. In 2009 G5 changed the business model to become a publisher of original games developed by G5 and over 30 partner studios in Eastern and Western Europe and the U.S.  G5 owns a number of successful game franchises, including Virtual City Playground and Mahjongg Artifacts.