Amazon returns to GDC in 2014, offering technical and business-related sessions on building and monetizing apps, fast-track app publication into the Amazon Appstore, and partner showcases.

Learn about cross platform services: from AWS to Analytics

It’s no secret that the most profitable games are the ones that keep their players engaged—usually through a combination of great content and the best use of technology.  On Tuesday, March 18, Amazon is sponsoring a day of eight sessions at GDC, on topics like game architecture, design, technology, and monetization strategies.  You will gain insights whether building a backend, expanding to additional platforms, scaling to handle more players, or exploring new revenue streams. Anyone with an Expo pass can attend, so plan to join us today!

Amazon Appstore Blast: Get your app published in as fast as two hours

In addition, Android developers who have Expo passes will be able to submit an app to the Amazon Appstore for Android and have it reviewed for potential publication in as fast as two hours. Bring your APK file to the Amazon Appstore Blast, side load it for testing and submit the app for expedited publishing.  Amazon evangelists and testers will be on hand to help check compatibility and answer any questions. (Usually no changes are necessary—75% of apps we’ve tested just work.) Come to meeting room 2546 in the North Hall to publish your app and reach millions of new customers.

Hear from successful Amazon partners

Amazon partners will also be present at GDC to show off exciting new projects and advanced features related to Amazon devices and services. Dolby Laboratories will showcase the Dolby Audio API, which helps developers create truly immersive game experiences with enhanced Dolby sound.  Marmalade, the cross-platform SDK and game development ecosystem, will highlight their new platform support for Amazon GameCircle on booth 2510, which makes it fast and easy to incorporate Achievements, Leaderboards and Whispersync for Games into your Marmalade-based game.  In addition, Amazon staff will be on hand in the Marmalade booth to answer questions about Amazon’s developer services.  Amazon’s framework partner GameSalad will also be attending GDC.  Creator of a rapid development platform, GameSalad recently debuted drag-and-drop integration with Amazon GameCircle and our In-App Purchasing API.

Session schedule

10:00 - 10:30 am Introduction
10:30 - 11:30 am AWS Architecture
11:45 - 12:45 pm Game Analytics
12:45 - 1:45 pm Engaging Your Audience with Mobile Push Notifications (w/lunch)
1:45 - 2:30 pm Amazon AppStream - New Gaming Experiences Using the Clouds for Game Streaming
2:30 - 3:30 pm What's Working in In-App Monetization
3:30 - 4:30 pm A/B Testing with Air Patriots
4:45 - 5:45 Large Scale HTML5 Games on Desktop, Mobile & Tablets with KANO/APPS

Register now to attend the Amazon Developer Day at GDC 2014 and come meet the Amazon team.

The manifest of your Android app provides essential information about the app to the Amazon Appstore for Android. Your app must include an “AndroidManifest.xml” file in the root directory.

The Amazon Appstore uses the app manifest file to ensure we merchandise apps appropriately. Prior to submitting your app to Amazon, please ensure the manifest is packaged with your app and includes the following elements and data:

• VersionName: A string value that represents the release version of the application code, as it should be shown to users. The value is a string so that you can describe the application version as a <major>.<minor>.<point> string, or as any other type of absolute or relative version identifier. There is a hundred-character maximum on the length of the version name string.

• Uses-sdk: Tells us which OS the app runs on.

• Uses-configuration: Tells us which configuration is required by the app. (This element may be left empty if nothing is required.)

• Uses-feature: Tells us which features of the phone are used, such as the camera. (This section may be left empty if there are no required features.)

• Supports-screens: Tells us if the app supports large and/or high-intensity screens

• Uses-permissions: These are Android permissions and are required by the platform. (This should NOT be present if your app does not require permissions.)

Below is an example manifest structure with required elements in red:

<manifest versionName="string">

    <uses-permission />

    <permission />

    <permission-tree />

    <permission-group />

    <instrumentation />

    <uses-sdk />

    <uses-configuration />

    <uses-feature />

    <supports-screens />

     <application>

        <activity>

            <intent-filter>

                <action />

                <category />

                <data />

            </intent-filter>

            <meta-data />

        </activity>

         <activity-alias>

            <intent-filter> . . . </intent-filter>

            <meta-data />

        </activity-alias>

         <service>

            <intent-filter> . . . </intent-filter>

            <meta-data/>

        </service>

         <receiver>

            <intent-filter> . . . </intent-filter>

            <meta-data />

        </receiver>

        <provider>

            <grant-uri-permission />

            <meta-data />

        </provider>

         <uses-library />

    </application>

</manifest>
 

If you do not have any data for a certain element--for instance, if your app does not utilize any permission--you should remove that element entirely instead of leaving it empty.  Empty elements can cause issues in the ingestion process.  Also, make sure your app only requests permissions that it actually needs to function properly.  Unnecessary permission requests can cause a spyware or malware concern from a customer’s perspective.

If your manifest does not comply with this set of rules, it may be rejected directly by the Developer Portal or in the app approval phase.

You can find more information about the AndroidManifest.xml File on the Android Dev Guide:

http://developer.android.com/guide/topics/manifest/manifest-intro.html

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.