Knowledge Base Kindle

From Injoit
Jump to: navigation, search

Contents

Kindle

Summary of Kindle Device Types


Active Content Basics


File Size
The main binary file for the active content has an .azw2 extension. The file is just a JAR file that contains additional metadata necessary for the active content to run. The maximum allowed size is 100 MB. But it is better to keep the file size less than 1 MB; the vast majority of the published active content titles have a file size less than 1 MB.

Other Items
Here are several other important things to know about active content titles:


Kindle Device Types


Active content titles are available on the following E Ink Kindles:


Note: Some of the devices are available with different networking options, in different colors, or with special offers. Although the different variations are not included in the preceding list, active content is available on those devices.

The following table shows basic characteristics of each Kindle type.

Device Screen Resolution Keyboard Type Network
Kindle Touch 600 x 800 pixels overall

600 x 700 available to your title

Onscreen, with different layouts 3G (global) and Wi-Fi, or Wi-Fi only
Kindle 600 x 800 pixels overall

600 x 760 available to your title

Onscreen, with tabs Wi-Fi
Kindle Keyboard 600 x 800 pixels overall

600 x 760 available to your title

Physical (no numbers) 3G (global) and Wi-Fi, or Wi-Fi only
Kindle (2nd Generation) 600 x 800 pixels overall

600 x 760 available to your title

Physical 3G
Kindle DX (Graphite or White) 824 x 1200 pixels overall

824 x 1160 available to your title

Physical 3G (global)


About the Kindle Names
The official names for the different Kindle devices have evolved as newer Kindles have been released. For example, the official name of what we commonly refer to as Kindle (3rd Generation) is now Kindle Keyboard; in the past it has been known as Kindle (Wi-Fi, 6") and Kindle (Free 3G + Wi-Fi, 6"). The currently available low-priced Kindle is simply called Kindle on Amazon.com; the other devices with different features are named Kindle Touch and Kindle Keyboard to distinguish them from the low-priced Kindle.

To clarify differences between Kindle device types please refer to Kindle and E Ink Basics, Active Content Basics, Kindle Device Matrix pages of the KDK developer portal.



link title===Development Considerations for E Ink Displays===

Screen Updates


Latency of screen updates is one of the most important considerations to think about when designing the title.

LCD and other displays can change the contents of a screen in 30 milliseconds, whereas E Ink displays can take from 200 milliseconds to almost a full second, depending on the grayscale palette used.

Ghosting

Ghosting is a faint E Ink residue that remains visible when drawing over previously black or gray areas of the screen. Ghosting can look a little like screen burn-in, but it's easily fixed by flashing the display (see the next section for more information). A gray or black background causes more ghosting, so use a white background where possible. Black and white designs are more resistant to ghosting than gray designs. Ghosting is worse with fine checkerboard patterns or stippling (i.e., dithered images).

Flashing


You can update the screen with or without forcing a flash. Flashing is when the Kindle repaints the entire screen (or just a section you specify) black for a moment to fully clear the area before drawing the same (or newly updated) contents again. Flashing helps manage ghosting, which is the appearance of E Ink granules left behind over time after non-flashing changes to the screen (see the previous section). A region of the screen becomes noticeably dirty after six to ten updates in that same area without a flash . Also, the amount of time since the last flash plays a role in the amount of ghosting.

Flashing adds to the screen update latency and consumes additional power compared to a non-flashing screen update. Frequent flashing can also be distracting to the user. Therefore, it's important to devise a strategy for managing flashes in the application to give the overall best user experience. The device itself flashes the screen at certain times such as:

The developers of an application might insert their own flashes at certain points in your application.

Color Palette and Refresh Speed


The Kindle E Ink display supports 16 levels of gray (including black and white). However, it's faster to draw black and white on the screen than other shades of gray. Therefore, the grayscale color palette should be used very careful in UI of an application. It is recommended to use primarily black, white, 0xAA and 0x55 in an application. Here are more details about colors and refresh rates:


Correct Color Depth and Compression

For all images:

It is better to use file compression if possible, i.e. to use GIF, JPEG, or PNG file formats for images. These different file formats have different characteristics, so the highest compression file format that meets the quality requirements for the specific image should be used.

Dithering

Drawing images in grayscale is typically slower than drawing them in black and white. One potential solution to this problem is to dither grayscale images. Dithering converts an image into black and white by spacing out black pixels on a white background to give the appearance of having different shades of gray. Dithering produces best results when used for images without gradual color transitions (gradients).

Quick Screen Updates

Any portion of the screen that need to be updated quickly should be pure black and white, with a 4-pixel margin to the nearest gray. This means that an anti-aliased font (which has gray elements) or have gray graphics can't be used too close to the area to be updated. For example, a pure black font on a white background is okay, but a gray frame around it could be a problem if the frame is too close to the font.
It is recommended to draw a black line on the selected white button. The worse cast scenario would be to repaint the button gray and the text white, which would result in a slow repaint and ghosting issues, and thus a poor user experience.

Best Practice: For areas on the screen that need to be quickly updated, better to use a pure black font without anti-aliasing on a pure white background. But no gray in the background within 4 pixels of the region to be repainted can be used.

Battery Usage


Long battery life is an important feature for Kindle users. As a result, when designing the title it's very important to pay attention to battery usage. Achieving long battery life is not simply about optimizing code; it is often that the entire user experience need to be crafted to enable great battery life..

Versioning


The first release of the title will always be 1.0. For subsequent updates, it is better to version the title as 1.1, 1.2, etc. It is recommended to add a version number and build number to the title

If the title has an About page, that's a good place to put the build number. If it doesn't, the version and build number should be putted at the end of any instructions the title may have.

For more information about versioning see Versioning Your Active Content Title page of the KDK developer portal.


To find more information about important considerations related to E Ink that need to be kept in mind when developing the title see the Title Development Best Practices page of the KDK developer portal.



How to design UI for Kindle and Previous Generations



For clarification on designing any element for Kindle and Previous Generations, please refer to the API 1.x: User Interface Guidelines for Kindle and Previous Generations page of the KDK developer portal.

Introduction to the Devices


For a summary of basic differences between Kindle devices, see the Kindle and E Ink Basics page of the KDK developer portal.


Screen Sizes and Orientation
All Kindle devices, except Kindle Touch, support API 1.x. The Kindle devices that API 1.x supports come with different screen sizes: either a 6" screen or the larger Kindle DX screen. Therefore, an API 1.x application must be prepared to handle two screen sizes. An application can determine whether the device has a 6" screen or the larger DX screen by checking the size of the root container.

In addition, for an API 1.x application must be decided how to handle orientation. Because Kindle is primarily a reading device, the default orientation is portrait. However, the user may rotate the device so the screen's orientation changes to landscape.



To get information on how the Kindle device controls should behave see the API 1.x: User Interface Guidelines for Kindle and Previous Generations page of the KDK developer portal.


General Design Guidelines for Kindle and Previous Generations


1. Follow the Native Kindle Experience
Kindle users are familiar with the reading experience on the device and expect the application to look similar and function in a similar manner. They'll also understand the application's interface more quickly if it feels familiar.

2. Make the UI Easy to Follow
When designing the application, it is recommended to think carefully about the different ways users can move through it, and what the user can and should do on each screen. Cluttering the screen with too many items should be avoided. The number of controls on each screen should be limited, and they need to be clearly and succinctly labeled.

3. Use Simple But Informative Labels, Text, and Symbols
To help users easily understand how the application works, it is better to use consistent, user-friendly terminology throughout the application. If the application uses any icons, they should to be intuitive and consistent in design, but easily distinguishable from each other.

4. Provide an Attractive but Simple Title Menu
Upon launch, applications typically display a title menu, often with graphics and a main set of options that includes things like Instructions, Options, etc. This menu doesn't include items typically available during title use (i.e., during game play). Any usage-related menu items should be displayed when the user presses the Menu button.

5. Use Grayscale Appropriately
The Kindle E Ink display supports 16 levels of gray (including black and white). However, it's faster to draw black and white on the screen than other shades of gray. For more information on how Kindle devices reproduce colors and they refresh rates see Color Palette and Refresh Speed subsection of Development Considerations for E Ink Displays section.

6. Provide Tutorials and Help
Ideally users should be able to use the application without having to read help pages. However, if the application must have help pages, they should be kept succinct and not too dense. The content must be grammatically correct and free of spelling and punctuation errors.


UI Components for Kindle and Previous Generations


The Kindle user interface is built on top of the Personal Basis Profile (PBP), which is a subset of Java 1.4 designed for embedded devices. The PBP provides basic support for AWT, but does not provide any actual graphics components. For API 1.x applications, the KDK provides user interface components that are built as standard AWT Component and Container implementations.

Text Components

Text is used on many components of a KDK application, such as button labels, dialog box messages, contextual help, notifications, page content, and menu items.

Types of Text Components
The following table describes commonly used text components.

Type of Text Description
Labels Read-only text. A text label can precede a text field (as in a confirmation dialog box), or simply be a one-line message inside a dialog box. Labels that are not full sentences should use initial capitalization ("Account Type";), but labels that are full sentences should use sentence capitalization ("Enter the name of Player 1:").
Text input fields Single-line area where the user can supply information by entering or modifying text. One example is in input dialog boxes (see Dialog Boxes). Text fields can be empty or contain hint text.
Text areas Multi-line region of either read-only or editable text. These are found in contextual help (read-only) or in Notes & Marks (editable) when reading a book with Kindle.
Password fields Text field that echoes a symbol character rather than the text being typed.



Text Specifications
Here are some general specifications and recommendations for a text:


Buttons

Buttons are controls that perform an action when the user selects them. Buttons can be used to complete or acknowledge an action defined by a dialog box. Buttons on the Kindle interface contain a brief command label on a black or white background.

Button Specifications


Dialog Boxes

Dialog boxes and menus are the only types of software-instantiated pop-up components allowed. Dialog boxes on the Kindle display one at a time on the interface, rather than stacked or staggered. Dialog boxes display messages or options, either as part of the user flow, or to interrupt and block further interaction with the application until the user reads and dismisses the dialog box. The default, selected button in a dialog box is black.

There are three kinds of dialog boxes available:


Pages of Content

Often, a user interface needs to display more information than fits on a single screen. The Kindle is designed to organize content into pages, and information that overflows a single screen is generally arranged into a series of pages that the user can switch between. The KDK does not provide any default containers to handle scrolling.

Color and Fonts

Note that anti-aliased fonts look best on black, white, light gray and dark gray backgrounds. The recommended font sizes are 17, 19, 21, 25, 31, 36, 60, and 86 (in points). They've been optimized for the Kindle (3rd Generation) devices.

Important: Font sizes might vary between Kindle types.


How to design UI for Kindle Touch



For clarification on designing any element for Kindle Touch, please refer to the API 2.0: User Interface Guidelines for Kindle Touch page of the KDK developer portal.


Introduction to the Kindle Touch Interface


Overall Layout



W toolbar with callouts.gif

The toolbar that is shown when the application is open includes these three items:


Onscreen Keyboard.
Kindle Touch has an onscreen keyboard that displays at the bottom of the screen when text input is required. The keyboard background is black, and the buttons are white with black text. The onscreen keyboard is 275 pixels high and spans the width of the screen.

Screen Orientation.
Currently KDK API 2.0 supports applications that use portrait orientation only.

Device Controls.
Kindles other than Kindle Touch have several physical buttons for navigation and other actions. Kindle Touch has only a Power switch and a Home button:


For more information on the introduction to the Kindle Touch interface see the API 2.0: User Interface Guidelines for Kindle Touch page of the KDK developer portal.


General Design Guidelines for Kindle Touch


1. Follow the Native Kindle Touch Experience
Kindle users are familiar with the reading experience on the device and expect the application to look similar and function in a similar manner. They'll also understand the application's interface more quickly if it feels familiar.

2. Make the UI Easy to Follow
When designing the application, it is recommended to think carefully about the different ways users can move through it, and what the user can and should do on each screen. Cluttering the screen with too many items should be avoided. The number of controls on each screen should be limited, and they need to be clearly and succinctly labeled.

3. Exploit Touch in Your Application
Kindle Touch provides a more interactive experience than other generations of Kindle. Therefore, the touch screen interactivity should be embraced and exploited for the application.

4. Use Intuitive Gestures
Kindle Touch has a default set of gestures that users are familiar with. It is recommended to stick to those default gestures, and don't remap them to other actions. In general, defining new gestures should be avoided. However, if it is necessary to create new gestures, they should be made intuitive and correspond to the action in some way because users must learn and remember them. It's a bad experience if users must read the help content to determine the available gestures.

5. Use Simple but Informative Labels, Text, and Symbols
To help users easily understand how the application works, it is better to use consistent, user-friendly terminology throughout the application. If the application uses any icons, they should to be intuitive and consistent in design, but easily distinguishable from each other. If the user needs to tap or touch the icons for the purposes of navigation or game play, it is recommended to adhere to the touch target size guidelines.

6. Make Touch Targets Fingertip-Size
Users of the application must be able to accurately hit small UI elements such as buttons or icons. Note: Users of API 1.x applications (for other Kindles) are able to navigate and select items by using physical buttons instead of tapping the screen, therefore elements of API 1.x applications can be smaller and more closely spaced than on Kindle Touch.

Here are the guidelines for the touch target size for interactive UI elements in the application:

If necessary, size of the visible UI element can be smaller than the element's touch target area. For example, a radio button is smaller than the 40 pixel minimum width, but the touch target area for the button would still be the full 40 pixels.

7. Make Text Input Efficient
Kindle Touch has an onscreen keyboard for input. The text input process should be as efficient for users as possible. It can be achieved by minimizing the number of taps that is required.

8. Provide an Attractive but Simple Title Screen
Upon launch, applications typically display a title screen, often with graphics and a main set of options that includes things like Instructions, Options, etc. The list of options should be short and simple, with fewer than seven items. The user simply taps one of the items to get started using the application.

9. Make Settings Simple to Understand and Use
If the application has settings or options, it is recommended to use controls that users are familiar with, such as radio buttons, check boxes, and toggles. It's rare that an application has a list of options longer than the screen; however, it is better to keep the settings to a single page, or two at the most.

10. Use Grayscale Appropriately
The Kindle E Ink display supports 16 levels of gray (including black and white). However, it's faster to draw black and white on the screen than other shades of gray. For more information on how Kindle devices reproduce colors and they refresh rates see Color Palette and Refresh Speed subsection of Development Considerations for E Ink Displays section.

11. Provide Tutorials and Help
IIdeally users should be able to use the application without having to read help pages. However, if the application must have help pages, they should be kept succinct and not too dense. The content must be grammatically correct and free of spelling and punctuation errors.


UI Components for Kindle Touch


The Kindle user interface is built on top of the Personal Basis Profile (PBP), which is a subset of Java 1.4 designed for embedded devices. The PBP provides basic support for AWT, but does not provide any actual graphics components. To implement the UI for Kindle Touch, the standard Java components are used, they were found in the Advanced Graphics and User Interface (AGUI), which is a subset of Swing.

1. Text Components

This section describes commonly used text components. Note: the tutorial on the KDK Developer Portal covers Swing, therefore some capabilities or components discussed in the tutorial and in this section might not be available to your API 2.0 application.


Text Specifications
Here are some general specifications and recommendations for the text:


2. Buttons

Buttons are controls that perform an action when the user taps them.

Button specifications:


3. Dialog Boxes

Dialog boxes display messages or choices, either as part of the user flow, or to interrupt and block further interaction with the application until the user reads and dismisses the dialog box. They include a message in text and at least one button that dismisses the dialog box. Some dialog boxes can also take text inputs. All dialog boxes have rounded corners. There are three kinds of dialog boxes available:


4. Menus

The toolbar on Kindle Touch has a Menu button that invokes a menu of options. New items can be added to the menu. Note: The KDK currently doesn't support the use of sub-menus in active content titles.

5. Lists

With a list, a user can select one or more objects from a group. Separators of the list can be turned off entirely, displayed in between the list items only, or displayed both in between the list items and at the top and bottom of the list.

6. Controls

This section covers several commonly used controls and what they look like on Kindle Touch.

Type of Control Description
Toggle Buttons A toggle button is a button that has two possible states.
Radio Buttons A radio button lets you create a group of options where a user can select only one option.
Progress Bars A progress bar indicates the progress of some type of work.
Sliders A slider lets the user specify a value by tapping a specific point within a bounded interval.
Spinners A spinner lets users choose from a range of values that are in an obvious sequence (e.g., dates).


7. Pages of Content

Often, a user interface needs to display more information than will fit on a single screen. The Kindle is designed to organize content into pages, and information that overflows a single screen is generally arranged into a series of pages that the user can switch between. This is a very different way of thinking than in many environments where the normal mode of interaction is scrolling.



SUBMIT: upload to Kindle Store



Here are some details about the steps of developing and submitting the title.

Step Description
1 Build and test on the Simulator and devices: Work on developing the title while iteratively testing on the Simulator and different types of Kindles.
2 Pass the pre-submission assessment tests: The title must pass all the tests described in the Pre-Submission Assessment Guide.
3a Submit your beta candidate:The beta candidate along with the merchandising assets can be submitted through the KDK developer portal. They'll take a first functional and editorial look at them and give the feedback. It might be needed to submit multiple builds to fully address the issues that is identified during this phase. Each time when submitting a build, it must pass the pre-submission assessment tests described in the Pre-submission Assessment Guide. Note: the title is not being fully tested during this phase of the submission/feedback cycle.
3b Submit your launch candidate: This is the version you feel is ready to go to customers. Full QA cycle will be done, which includes both technical and functional tests. The cycle of feedback/fix/test/resubmit will be repeated until the title passes QA. After the title passes QA, it will be putted through beta testing and once again the feedback provided. When any issues have been fixed, the title must pass (as usual) all the pre-submission assessment tests before it can be moved forward.
4 Publish your title: After everything is ready to go, the title can be made available for purchase. After the title is published, you can get sales reports and manage all your active content titles in the developer portal.



There are multiple options for you to submit the title:



The first phase in the publishing process is pre-submission assessment, which is a series of tests that must be done to make sure your title is ready for evaluation.

In general, the title is evaluated on these areas:


For clarification on pre-submission assessment process, please refer to the Pre-submission Assessment Guide page of the KDK developer portal. Aside from giving details about the key evaluation areas, the guide also describes the tests that the title must pass each time when submitting a build.

When your title's test results are all PASS/NA, your active content title can be submitted for review, along with the required merchandising assets, etc. It can be done on the Your Active Content page of the KDK developer portal.


for the submission we need


Note: To find information on how to prepare merchandising assets see SUBMIT: how to prepare Merchandising Assets section or Merchandising Assets Guide page of the KDK developer portal.


Submitting process
After the title binary has been received, KDK account manager will put it in the queue for an automated QA testing process that runs an extended battery of code and procedural tests. Because the pre-submission assessment tests have already been completed, the automated testing should be completed within 4 business days from title submission. KDK account manager will send a feedback on the tests results. If the title fails any of the tests, KDK account manager will provide information and guidance on possible solutions. Note: If changes to the title were made (based on the QA feedback), the pre-submission assessment tests must be re-run before resubmission of the title.

Securing Assets
Protecting digital assets is an important aspect of application development. When an active content JAR (.azw2) file is submitted through the developer portal, the compiled class files are encrypted with Amazon's digital rights management (DRM) scheme, which is intended to hinder unauthorized copying and distribution of files. However, non-class files are not encrypted with DRM and can be extracted from an active content JAR file simply by unzipping the JAR file. To prevent this, an active content non-class files must be encrypted prior to inclusion in the active content JAR file, and decrypted on the Kindle while executing. To this end, encryption credentials need to be secured. Encryption credentials stored in a class file will be encrypted with Amazon DRM.


TEST: Install the .azw2 file


While developing the application, the Kindle Simulator is commonly used for its testing. The Kindle Simulator is a Java application execution environment that approximates the behavior of the Java Virtual Machine found on Kindle devices and provides most of the same resources, restrictions, and characteristics.

To get more information about testing your application using the Kindle Simulator please refer to the Kindle Simulator User Guide page of the KDK developer portal.

The Kindle Simulator provides a convenient environment for testing, but it's important that your application was tested on Kindle itself. We highly recommend to test the application on all Kindle types that the application can run on.

To test your active content title on Kindle, the application must be signed with your private key, and the Kindle device must be registered for testing.

If your application is not signed with the private key or your Kindle device is not registered for testing please contact the developers of the application, or follow the instructions on the Testing Your Active Content on Kindle page of the KDK developer portal.

Testing on Kindle

Testing on the Kindle device consists primarily of running your signed application on the Kindle and observing that it behaves as you expected. To put your application on the Kindle device for testing:



Enjoy it!


SUBMIT: how to prepare Merchandising Assets



For more recommendations on how to prepare merchandising assets for your title and the examples please refer to the Merchandising Assets Guide page of the KDK developer portal.


Main Product Image


This is the image customers see when they shop for your title on Amazon.com. It plays an important role in selling your title, so create an attractive color image that stands out in the crowd and represents your product well. The same image is displayed on both the Amazon website (in color) and on Kindle (in grayscale), so it's critical that you create this image to look good both as a large color image and as a 75 x 75 pixel grayscale image.

The following image illustrates some of the main guidelines to follow.
Merchandizing product image.png

Main Product Image Specifications


Screenshots


A Kindle screenshot or screen capture is a static picture of your Kindle's display. You must provide three screenshots per general device type that the title supports. The screenshots are displayed on the product page in the Kindle Store (both on the Amazon.com website and on Kindle). These screenshots help customers visualize your product before purchase.

Rule of thumb: don't show the exact (or similar) screen more than once. Carefully review for written content that may not be suitable to share with customers. Don't forget to crop the Kindle status bar (and toolbar on Kindle Touch) out of your images.

Screenshot Specifications


Taking a Kindle Screenshot

Use the following procedures to take a screenshot. You can take many screenshots before downloading them to your computer; they will be saved under different file names on your Kindle.
To take a screenshot on devices other than Kindle Touch:

  1. While on the screen you want to capture, do one of the following depending on the type of Kindle:
    • Kindle Keyboard or previous generation: Simultaneously press Alt+Shift+G.
    • Kindle: Simultaneously press Keyboard+Menu.
  2. Connect your Kindle to your computer using USB.
  3. Find all the screenshots in the documents directory.
  4. Crop the status bar from the top of each screenshot.


To take a screenshot on Kindle Touch:

  1. Press and hold the Home button for two seconds.
  2. While still pressing the Home button, tap the screen (anywhere in the middle is fine).
  3. Release the Home button.
  4. Connect your Kindle to your computer using USB.
  5. Find all the screenshots in the device's root directory.
  6. Crop the status bar and the toolbar from the top of each screenshot.


Note: If you're not careful, the device might interpret the button press and the tap gesture as separate inputs, which means you might end up on the Home screen instead of taking a screenshot.

Product Description


To enable Kindle customers to make an educated decision about purchasing your product, you should provide a product description with the most complete but concise information possible. The tone should be trustworthy, fun, smart, casual, helpful, and intelligent. Before you write your product description, we suggest you review published examples at http://amazon.com/kindleactivecontent.

Product Description Specifications

Note: We reserve the right to exercise editorial discretion in reference to all content submitted to us.

Search Keywords


To help customers find your title, provide search keywords that are relevant (these could include associated slang words, gaming vernacular, etc.). Amazon's search logic already includes generic terms specific to the Kindle store: Kindle, active content, etc. The publisher and product title are also automatically incorporated into search keywords, so you don't need to add those. Five keywords are allowed.

Note: We reserve the right to exercise editorial discretion in reference to all content submitted to us.

Videos


Videos are encouraged for all titles. Videos can be in the form of gameplay teasers or trailers, raw or unedited game play footage, or special highlights. Amazon is not allowed to use videos that display logos, watermarks, or other external identifiers. Video players on Amazon usually render videos at 320 x 240 or 368 x 276. However, since we allow customers to view videos at full screen, we generally encode to a higher quality than this to ensure videos still look good at full screen resolutions.

Note: If you create a video for your title, please provide it directly to your KDK account manager. The title submission page on the KDK developer portal does not accept video uploads.

Video Specifications



Useful resources



For getting accesses to the documentation about Kindle devices please register into KDK developer portal: https://kdk.amazon.com/gp/vendor/kindlepubs/kdk/log-in?ie=UTF8&%2AVersion%2A=1&%2Aentries%2A=0


Useful documents on KDK developer portal:

Introduction to the KDK
Kindle and E Ink Basics
Active Content Basics
Kindle Device Matrix
Title Development Best Practices
API 1.x: User Interface Guidelines for Kindle and Previous Generations
API 2.0: User Interface Guidelines for Kindle Touch
Pre-Submission Assessment Guide
Merchandising Assets Guide
Testing Your Active Content on Kindle




Kindle Fire

Introduction to the Kindle Fire


This is a description of Kindle Fire for Injoit's clients to understarnd how their apps will be able to behave. Updated: 05 Dec 2011.

Supported formats

Kindle Fire supports the following formats:


Specifications of Kindle Fire

For the app to work on Kindle Fire, it needs to be compatible with the device's specifications

  1. At a high level, it must be optimized for non-Google Mobile Services (GMS) Android 2.3.4 (Gingerbread) and a 7" screen with a resolution of 1024 x 600.
  2. It should specify support for large screens.
  3. The app cannot require a gyroscope, camera, WAN module, Bluetooth, microphone, GPS, or micro-SD to function.
  4. It must not be a theme or wallpaper that manipulates the user interface of the device.
  5. As with any other app submission to the Amazon Appstore for Android, the app is also need to comply with Amazon's Content Guidelines that you can find in the Approval Process and Content Guidelines section of the FAQ on the Amazon Appstore developer portal.


Dimensions of the status bar. The status bar is 40px high.
Google Mobile Services. Apps that run on Kindle Fire do not currently have access to Google Mobile Services (GMS).
Google's in-app purchasing technology. Because Google's in-app purchasing technology requires access to Google Mobile Services, it will not work on Kindle Fire.
E-mail client. 
Kindle Fire has a pre-installed e-mail client that will respond to both mailto links and e-mail intents.
SD card. Kindle Fire has an internal SD card that your application can write to. Kindle Fire's SD card is internal and is not removable.
Third-party keyboards. Third-party keyboards are not compatible with Kindle Fire.
Root access. Kindle Fire does not support apps that require root access.
Adobe AIR. Adobe AIR is pre-installed on Kindle Fire. Adobe AIR 3 applications can be published for the Kindle Fire by packaging them as ‘captive runtime’ applications. However, these captive runtime applications will not support on-device debugging.


Specific features that Kindle Fire supports

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.

Feature Type
1 An accelerometer Sensors
2 A light sensor Sensors
3 Landscape mode Screen
4 Portrait mode Screen
5 Touchscreen capabilities that are more interactive than basic touch events Touchscreen
6 Basic two-point multi-touch capabilities Touchscreen
7 The ability to track two points fully independently Touchscreen
8 The device or the app itself can behave as a USB device (and connects to USB hosts) USB
9 802.11b/g networking Wi-Fi




To learn more about making your apps available at the Amazon Appstore and on Kindle Fire please visit the Kindle Fire FAQs.


DESIGN: how to prepare resources for Kindle Fire apps


Kindle Fire is Android based device so for information on preparing UI elements for Kindle Fire please refer to the DESIGN: how to prepare resources for Android apps section of the Knowledge Base for Android Apps. Note: The Supporting multiple resolutions subsection is not applicable for Kindle Fire.


SUBMIT: upload to Amazon Appstore


There are multiple options for you to submit the application:

  1. we tell you how to do it or you do it following manuals from Amazon Appstore Developer Portal (this is difficult for most clients).
  2. we go share screen with you and you log in from your computer, but we take control over it and submit everything while you watch.
  3. you give us your login and password for Developer Portal Account into Amazon Appstore Developer Portal and we do the submission.


Note: If you submit an application for the first time you must open your Developer Portal Account. To open your Developer Portal Account, please, refer to: https://developer.amazon.com/welcome.html. Click the Get Started button and the Developer Portal will guide you through account creation. Once you complete your account creation and accept the Appstore Distribution Agreement, you can start submitting your applications.


To find information on how the app approval process goes and the content guidelines of Amazon please refer to the Approval Process and Content Guidelines section of the FAQ page on the Amazon Appstore Developer Portal.


for the submission we need



additional info:


Amazon Appstore encourages you to submit as many merchandising assets as possible.


The assets must conform following specifications:

Asset Type Description Specifications
Icon A representative icon for display on the desktop of the mobile device after app installation
  • 114 x 114 pixels
  • PNG with transparent background
  • SRGB or CMYK
Thumbnail A larger version of the icon image (this should be the same image as the icon) for use in search results and on product detail pages
  • 512 x 512 pixels
  • PNG with transparent background
  • SRGB or CMYK
Screenshots A minimum of three app screenshots and a maximum of 10 for use on Amazon.com product detail pages
  • While standard device resolutions between 100 and 2048 pixels are accepted, we recommend 480 x 800 pixels or 800 x 480 pixels before removal of the OS status bar
  • PNG or JPEG
  • SRGB or CMYK
Promotional For use in promotional placements (apps cannot be featured on the homepage without these images)
  • 290 x 140 pixels (landscape only) or 512 x 512 pixels
  • PNG, JPEG or GIF (no animation)
  • SRGB or CMYK
Video When available, up to 5 videos about your app are placed on product detail page. Videos will be embedded so it's important that you meet these specifications
  • At least 720 px wide (4:3 or 16:9)
  • 30 megabytes (maximum)
  • 1200 kbps or higher
  • MPEG-2, WMV, Quicktime, FLV, AVI, H.264 MPEG-4


Thumbnails


Screenshots


Videos


Screenshots

Here are some recommendations for creating great images for all your submissions:


Here’s an example of good icon image:

Icon.png


TEST: Install the APK file



To install the application on your Kindle Fire you need to prepare your device first. The Kindle Fire needs to be configured so that is can allow the installation of apps from unknown sources.

Preparing your device

  1. Tap on the Settings icon located at the top right corner of the home screen.
  2. From the menu that will come up, go to More.
  3. On the main Settings screen you have to tap Device.
  4. Set “Allow Installation of Applications From Unknown Sources” to On.


Installing app using a PC

  1. You have to install a file manager into your Kindle Fire. You should be able to find several at the Amazon Appstore. Just search the app store for “file manager”.
  2. Connect the device to your PC using a USB cable.
  3. Tap on the Connect button which will automatically appear on the screen of the device once connected.
  4. Copy the APK file.
  5. Browse the directories or folders of the Kindle Fire from your PC and paste the APK file on one of the device folders.
  6. Disconnect the tablet from your PC. Tap the disconnect button first before pulling out the cable from your PC.
  7. Open the file manager app on your Kindle Fire and look for the directory where the APK file was stored.
  8. Tap on the APK file to install the app.



For testing your app on standard Android emulator, to simulate the Kindle Fire device platform, you should configure your emulator with the following characteristics:

¹Note: The device will reserve 20px to display a soft key menu, making the effective portrait resolution 1004px high x 600px wide and the effective landscape resolution 580px high x 1024px wide.


Enjoy it!

Retrieved from "http://wiki.injoit.com/Knowledge_Base_Kindle"
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
Admin