Android 4.2 Hits AOSP, Broadcom Replaces NXP with NCI Stack for NFC

Yesterday source code for Android 4.2 was pushed to AOSP (Android Open Source Project), paving the way for other developers to begin building their own Android images and looking through the source code changes made in Android 4.2 to the core of the Android OS. In conjunction with AOSP push, the Android 4.2 platform highlights page went live with more detail about new features in the point update from 4.1 to 4.2. We went over a number of the major user-facing features in our Nexus 4 and Android 4.2 review but there are a bunch of other noteworthy features outlined in the platform highlight details, including even more improvements made to the 2D rendering engine, WebView rendering engine (which doesn’t apply to Chrome unfortunately), and the new inclusion of GPU compute for Renderscript Compute which is an Android API for running code on CPU, GPU, and DSP. I’m sure we’ll be hearing even more about Renderscript Compute in the coming weeks. I’m burying the lead a bit here, because today Broadcom confirmed some observations I made about the Nexus 4 and Nexus 10 and their NFC solutions.

In the Nexus 4 review I noted that Broadcom’s BCM20793 appeared to have taken the slot of the up until now relatively ubiquitous NXP PN544 controller, which debuted with the Nexus S and has since been the go-to NXP controller for OEMs. In addition to taking the hardware slot, in the platform highlights page there’s a note about Broadcom also fully open sourcing its NFC NCI (NFC Controller Interface) stack which is a new NFC Forum specification designed to standardize the abstraction layer between NFC controller and SoC. Back when the Nexus S launched Google licensed and open sourced the NXP software stack for their NFC controllers, which has been inside Android ever since. I’m told that the NXP stack was previously tailor made to their hardware, and that with an NCI compliant stack OEMs will have greater flexibility when choosing an NFC controller. It makes sense that Google would want a stack with as much flexibility as possible and this gets changed up with 4.2.

I learned some details about BCM20793 as well. Broadcom’s NFC controller is built on a 40nm process and is compatible with both SIM and embedded secure elements (the Nexus 4 uses an embedded SE). In addition Broadcom believes its low power detection mode offers significantly lower idle power consumption than other solutions. Rather than inducing a field and polling for a tag or nearby device on a slotted cycle while the device is on, Broadcom’s “low power target detection” detects the change in antenna load caused by another NFC antenna being brought in proximity, and then polls. I’m told that this results in their controller inducing a field and burning current orders of magnitude less than other readers, and thus giving a fairly large power savings, in addition to the process advantage from 40nm. The obvious next step for Broadcom is to integrate this IP into a Wi-Fi, Bluetooth, FM combo like BCM4334, I wouldn’t be surprised to see something happen like that in the near future.

When I saw the BCM20793 in close proximity to the TI BQ51051b Qi wireless power receiver inside the Nexus 4, I suspected that part of the NXP shakeup might also involve some coexistence communication between the two. While there was RF planning involved (thankfully Qi works at a lower frequency than NFC), the NXP and Qi charging solutions still use different inductive loops and don’t need any collaborative communication. We haven’t talked a lot about the Nexus 10 or formally reviewed it yet, but interestingly enough has multiple NFC points of interest and is able to communicate through the front in addition to the back, and also appears to be BCM2079x based.

Source: Android Building, Android Platform Highlights, BCM2079x Family