Everything you need to know about releasing Android products (Part 2)

In part 1 , we described the dynamics of the Android market – the breakneck speed of innovation and the challenges faced in keeping up with this exponential growth. In this post, we discuss the challenges in greater detail.
Android development and release teams are spending enormous amount of resources refining their processes to bring out quality devices/application in the shortest periods of time. While the discussions with these vendors almost always start with the goals of improving speed and quality, as we delve deeper into their concerns, we see common technology challenges across all these vendors. Here are some the common themes we have come across with all of these vendors:

• It’s hard to keep up with break-neck releases (in-market and new OS versions): The rapid revisions of the OS create challenges for device markers to constantly support their existing matrix as well as the next version right around the bend. As seen in the chart , there are 4 versions of the OS with over 10 market share and vendors must continue to support, patch, and fix bugs in all of these in-market versions. As a device vendor, supporting one matrix is hard enough; now imagine having to build, test, and release your application across many matrixes at the same time.

• There’s complexity in managing the tools and best practices: The Android development process introduces new tools–GIT, Geritt, Compatibility Test Suite (CTS) – and best practices. When added to vendor legacy tools (ALM/Agile tools, SCM tools, testing tools, release tools), you can see they now have to manage many tools and systems. Integrating, operating, and collaborating across these tools require new skillsets and capabilities that can add more complexity to the process.

• Differentiated add-in capabilities introduce quality issues: The base Android OS is open source and has been well optimized for the standard software delivery process (build, test, etc.). However, the vendor differentiation value is in the special sauce (applications, capabilities) that the vendors overlay onto the Android OS. These differentiations can be large and complex in their own right. It’s these additions and their dependences to Android and other libraries that cause latency and quality issues in the Android device/solutions.

• Delivering at scale is hard: It’s relatively easy to cobble together a small Android project, but the compelling value of this OS almost guarantees instantaneous proliferation across the organization. Pretty soon, tens of teams are gung ho on Android, without any standardization on version or processes. How can you possibly standardize and manage the development and release processes and resources across the organization?

These are the challenges that have led customers to talk to us. Are you facing similar challenges?
In the next few posts, we will explain the delivery process challenges – building, testing, releasing process challenges in greater detail. And by the end, you will know what it takes to deliver these devices with high quality and impeccable TTM.
PS: BTW, if you are going to be attending the Android Builders Summit 2013 (http://events.linuxfoundation.org/events/android-builders-summit ), check us out there.