At Google I/O 2012 in June, developers from the Android group spent a good amount of time describing the latest move forward for OEMs/silicon vendors: the Partner Development Kit (PDK). Prior to the PDK, OEMs and silicon vendors that were not involved in one of Google’s exclusive launch devices had to wait for the open source release of Android for each version of Android before they could begin any device/processor specific engineering. The PDK changes that: it is a cool move by Google to facilitate and accelerate broader adoption of each future Android release.

google's-android-pdk-could-mean-quicker-updates-for-consumers_-defs_0

The first PDK actually started just before Google I/O 2012 with the Jelly Bean release, Android 4.1. OEMs and silicon vendors were offered a chance to execute a license for access to the PDK for Jelly Bean before the open source release. This allowed OEMs and silicon partners to build their device-specific hardware drivers in to prebuilt binaries provided by the PDK. This enabled them to create and test device-specific drivers and optimizations. The intent, of course, was to shorten the time required by the OEM or silicon vendor to bring up new releases of Android on their respective devices.

(The license is required since the software involved in a PDK has not been formally released as a version of Android, and therefore access to it has to be restricted and somewhat controlled.)

The provison OEMs and silicon vendors must live with is that the contents of the PDK might turn out to be “slightly” different from the final release. However, the PDK is created during the final stages of the release process – during the test phase – and so there really shouldn’t be any major changes or additions between the PDK version of Android and the final open source release.

The Jelly Bean release essentially represented the beta for the PDK concept. As such, there were several issues with the PDK due to some version skewing and also due to varying degrees of support for the three application processor architectures – MIPS, Intel and ARM. However, a number of third parties signed up for the PDK, and they certainly did get a jump start on being ready for Jelly Bean.

MIPS immediately joined the PDK program at that time, as did MIPS’ architectural licensee, Ingenic Semiconductor of Beijing. Working with the excellent Ingenic engineers, we were quickly able to bring up Jelly Bean on several Ingenic-based tablets. As a result, when Jelly Bean was officially released, it was an Ingenic/MIPS-based tablet that was actually first in the world (after Google’s own Nexus 7) to ship out to customers via an OEM in India, Karbonn Mobiles.

That is the power of the PDK concept from Google. No longer do OEMs have to trail Google’s choice of exclusive “launch partners.” In fact, only Google’s own Nexus branded devices now have the potential to beat others to market – and even that advantage is not assured since there will be many agile OEMs with access to the PDK.

The first maintenance release of Android Jelly Bean is expected soon. Already a PDK is being prepared for that release. The good news is that Google has fixed many, if not all, of the teething problems in the original PDK. MIPS is fully supported of course, at complete parity with Intel and ARM, in the PDK that is coming.

About the author: MIPS Developer Team

Profile photo of mipsdeveloperteam