Amazon Kindle Fire cheat sheet for Android developers

My company recently published our Android app on the Amazon app store for Kindle Fire tablets. While getting ready to publish the app on the store, I realized that the list of Kindle Fire specifications that Amazon has here is neither developer nor customer support friendly.

Kindle Fire devices show system version in this format: 7.5.1_user_5170020. 


This does not convey the Android OS version at first glance. So, if a user or a customer support representative says that your app is not working on a Kindle and they only give you the system version, you as a developer are not sure which version of Kindle it's failing on.

If you are also debugging via USB on a Kindle device, Android Studio only shows you the Build Model and not the OS version.

To solve these issues, I made the cheat sheet below to help Android developers quickly determine which Android OS version a Kindle is on. Hope this helps!

Note: This table is as of March 28 2015.


Build Model Name Screen Size Status Android OS Fire OS Device -> Latest System Version Screen density
KFSAWA or KFSAWI HDX 8.9" 4th gen 8.9 New 4.4.2 4 22.4.5.3_user_453011120 xhdpi
KFASWI HD 7" 4th gen 7 New 4.4.2 4 20.4.5.3_user_453011120 hdpi
KFARWI HD 6" 4th gen 6 New 4.4.2 4 20.4.5.3_user_453011120 hdpi
KFTHWI or KFTHWA HDX 7" 3rd gen 7 New 4.4.2 4 updated from 3 13.4.5.3_user_453011120 updated from
13.3.2.5_user_325001120		 xhdpi
KFAPWA or KFAPWI HDX 8.9" 3rd gen 8.9 Legacy 4.2.2 4 updated from 3 14.4.5.3_user_453011120 updated from
14.3.2.5_user_325001120		 xhdpi
KFSOWI HD 7" 3rd gen 7 Legacy 4.2.2 4 updated from 3 11.4.5.3_user_453011120 updated from
11.3.2.5_user_325001620		 hdpi
KFJWA or KFJWI HD 8.9" 2nd gen 8.9 Legacy 4.0.3 N/A 8.5.1_user_5156520 hdpi
KFTT HD 7" 2 gen 7 Legacy 4.0.3 N/A 7.5.1_user_5170020 hdpi
KFOT 7" 2nd gen 7 Legacy 4.0.3 N/A 10.5.1_user_5170120 mdpi
Kindle Fire 1st gen 7 Legacy 2.3.3 N/A 6.3.3_user_4112920 mdpi

References:
Downloadable Kindle Fire System Updates
Kindle Fire Specifications

Popular posts from this blog

Communicating Paid Time Off and Coverage Plans

Image
As an engineering manager, I often ask people to take at least a week off every quarter depending on the PTO (Paid Time Off) policy at their workplace. This comes up to 4 weeks or 20 business days in a workplace with unlimited PTO which is pretty good for US-based companies, where the standard is usually 2 weeks or 10 business days of PTO.  It’s also important to me to communicate to my teammates and people across the organization that I will be out of office and they can reach out to others in that situation. “How we vacation” is a section that I like to add in my Team Charter which is a document that contains all the rules of engagement on a team - how we do retrospectives and team meetings, how often we meet, how we take time off, how we track metrics, our scope of work, and so on. 🌴 Paid Time Off Here are some of the places I update at my workplace if I am going to be out on vacation for a few days: Slack status Company Time Off calendar My work calendar My Google workspace o...
Read more

Team Charter and Norms: Working together

Image
In my previous blog post , I wrote about setting up a Team Charter and Team Norms on a team. In this post, I elaborate on some of the rules of engagement that teams I have worked on have generally used. Most software development teams that I have worked on have used some sort of Agile practices like the Scrum framework where cross-functional teams use iterative and incremental processes to improve their software delivery process. I have always used Agile in a way that works best for my team and the company’s culture at that time.  🧱 Team Structure I have had to occasionally run Scrum meetings as an Engineering leader since I have been on teams without dedicated Scrum Facilitators or Product Owners. Each Scrum team usually includes an Engineering Manager, Scrum Facilitator or Project Manager, Product Manager and Developers. In the absence of dedicated Project Managers or if there is leadership interest on the team, I make the Scrum lead role rotational so that every person on the t...
Read more

Team Charter and Norms

Image
A Team Charter in the context of a software engineering team is a team document that lists their goals, objectives, scope of work, and rules of engagement. This is a working agreement between all members of the team on how the team collaborates and communicates, and how they hold each other accountable while working towards common goals. Here are some areas I like to cover in a team’s Team Charter. This can be at the team level or the organization level.  Goals: This is a one-line sentence that explains the goal(s) of this team.  Objectives: This section links to the team or organization's objectives, key performance indicators (KPI) or Objectives and Key Results (OKR) which can be quarterly, semi-annual or annual. Organization Chart and Team Structure: This helps people know where they are in the organization and what teams and people they interact with regularly. Helpful Resources: This links to the team’s Request For Comment or Technical Design Documents, Slack channels, me...
Read more