Creating your Own Android Gingerbread ROM

I've recently been coding away at the Android Gingerbread Kernel, mainly to activate some of the unsupported features of the Near Field Communications Chip on the Nexus S phone.

Here are some links I'd like to share on how you can create your own custom kernel! I did this on a Macbook and it is certainly easier on a Linux based machine like OSX or Ubuntu. You can always create a Linux VM on your Windows machine if needed.

1.Root Your Handset
Rooting you handset will give you 'superuser' access to the phone's features, so well worth doing. Previously, to root your phone meant loosing all data on it. This is now not needed, so here are some links to how this can be done.

** Take a Full Backup First as non of us can guarantee this always works! **

Get the Clockwork Recovery tool from this URL and save it on your computer:
http://koush.tandtgaming.com/recoveries/recovery-clockwork-3.0.0.5-crespo.img

Get the superuser tool from here too and place it on your phone's SD card:
http://bit.ly/su2361ef

Boot your phone into recovery mode by powering it off, then hold down the volume up button and the power key together until the phone boots up.

Use the Android SDK fastboot tool from your computer to put the phone into clockwork recovery mode:
fastboot boot recovery-clockwork-3.0.0.5-crespo.img

e. On the phone:

i. Select 'Install ZIP from sdcard' using the power button to apply the selection
ii. Select 'Choose zip from sdcard', again using the power button to apply
iii. Select 'su-version#-signed.zip' file you downloaded earlier, and apply it
iv. Select 'Yes - install su-version#-signed.zip'
v. Confirm the screen shows "Install from sdcard complete" and Select go back
vi. Select reboot

2. Download the Kernel Code and Edit, build and Flash

a. Get the Android SDK from Google from this link and install:
http://developer.android.com/sdk/index.html

If you don't already have Eclipse IDE and XCode, get them too as they will be useful for your Apps development and Java RTE. You can get an Apple Dev Account for free for XCode. Follow the Android SDK instructions to set up a partition to work in.

b. I had an issue with elf.h.  It seems to be missing and needed for the builds, so get a copy from here to compile on a Mac, saving the file to the scripts/mod folder and edit references to to be "elf.h":
http://www.rockbox.org/tracker/9006?getfile=16683

c. Look no further than this posting.  It says it all:
http://forum.androidcentral.com/samsung-nexus-s-rooting-roms-hacks/48675-how-compile-nexus-s-kernel-source.html

I would recommend not doing a flash ROM until you are sure on your build.

It is quite satisfying to do this and see the Kernel ID with your name on it on the handset.

Good Luck!

Cloud Based NFC Services

Forum Based Approaches
The NFC Forum is a group of organisations and individuals who are involved in Near Field Communications services.  Traditionally, their members were from SIM Card vendors, banks, mobile phone companies and NFC hardware vendors.

So, on the whole you would expect them to promote NFC using these building blocks.

NFC for years promised to be the next big thing and for years it disappointed, mainly due to the lack of handsets, which meant no customer adoption, which meant no retailer support.

Any company operating outside the restrictions of SIM/Smart card based services (mobile operators, banks and hardware suppliers) has found the lack of handsets to limit the services they can give.

No retailer is going to support a service which is only available to a limited number of its customers.

The Cloud is your Platform
So, many of these NFC service providers, such as ZAPA and PayPal, have moved towards Cloud Based NFC instead of the established NFC Forum view of NFC.

In Cloud Based NFC, the handset and the point of sale merely become on-line devices, accessing cloud based services for balances, coupons, payment, etc.  The handset memory just becomes a means to store a simple customer specific identification (i.e. a mobile PAN number). 

The point of sale can capture the mobile PAN in a simple RFID exchange and from there on, it accesses the same cloud services to perform transactions such as loyalty, pre-pay, couponing, etc.  If the customer looses their phone or RFID device, no problem.  Just reassign your cloud account to a new device and move on.

NFC Forum Methods
The standard NFC Forum view would be that these balances and coupons are stored locally on the handset in a secure memory area.  But, when some of your key members supply SIM and Smary Cards, then of course you are going to promote this type of solution.

A by-product of this is that once a SIM card is the secure memory element in an NFC solution, then you need secure protocols to access it over the air, which just so happens to be based on the same Global Platform standards that the same SIM companies use for mobile SIM cards and payment card Smart Card chips.  It is all a bit....close.

Stick to the Cloud!
So, even though NFC enabled handsets are not appearing in volume on the high street, why don't we all just stay with the Cloud NFC model?

Point of Sale systems and handsets are now on-line systems, so let's not ignore this.  Let's use these channels as a means to expand on cloud based services and release retailers and consumers from the restrictions of SIM based NFC.

Google dropping Barcodes for NFC?

News on the boards is that Google are dropping support for barcodes from their retail and location services (e.g. Places).  Interesting stuff and that would hint that they favour the use of NFC, this being their other big focus on identification in the real world.  This is as a result of field trials in local retail deployments in the US.

This news kind of plays into the hands of those of us involved in NFC deployments, where there is a constant reference to QR codes and 1D barcodes as a 'universal' solution for customer identification.

Of course, the truth is that there is no universal solution for using a mobile phone as an identification device as there is such a large legacy of older handsets with neither have screens that can support a barcode display, nor have the chips that are needed for NFC.

So, where is Google going on this in the short term?

Options include the use of RFID Stickers, which emulate the NFC experience through the same radio link from an ID card to the point of sale.  These can be attached to any handset and mimic the same 'tap' action by the customer and so can be seen as an aid to transition people from today to the eutopia of universal NFC enabled handsets....

Others include 'bump' technology, with a cloud server linking your phone's physical bump to a similar sensor on the point of sale - OK if your phone has an accelerometer, but then we are back to the whole smart phone scenario, so it is not mass market.

My personal view (which is skewed by the business I am in of course!) is that Google will go for the NFC/RFID option as in time this is the technology that all point of sale PIN Pads will support.  You cannot ask a retailer to put in hardware that only supports a minority of their customers, so by deploying PIN Pads and readers that support both normal payment cards (Chip & PIN and Magnetic Strip) as well as NFC Phones and RFID Stickers, the merchant can be sure that they will get a return on investment, especially if they use the RFID for non payment services today, such as loyalty and couponing across their customer base.

This approach also fits in well with their Android platform, who's recent 2.3.3 release had NFC API support as it's headline addition.  Handsets such as the Nexus S, Galaxy S II and the Wave are all smart and desirable handsets, with an increasing number of social and commercial applications appearing on the Market.

Let's hope Google share this technology and provide a means for third parties to access the keys that enable these phones to join the growing number of services out there.