I have also been playing around with BLE, and decided to go with the Nordic nRF8001 chip because it looked easier to work with and didn’t require expensive IAR tools. nRF8001 is slightly cheaper than the CC2540 part in BLE112, but it is slave-only.
I bought Nordic’s nRF8001 development kit for $99, which includes nRF8001 samples and several nRF8001 boards (one with a trace antenna and one with an SMA connector) with standard 0.1" header for easy interfacing with your microcontroller development board. The documentation assumes that you have the $399 nRFgo development board and want to use the included nRF8200 microcontroller. I didn’t, so instead I wired an nRF8001 board directly to an Arduino.
You speak SPI to nRF8001, but basically with 2 different slave select-like pins. One pin (REQN) is a traditional slave select which is brought low to indicate that the master (you) want to send a message. The other pin (RDYN) is for the slave (nRF8001) to indicate that it received something over RF that it wants to send to the master, or that it is ready to receive a command from master. Master then brings REQN low and starts receiving.
The protocol is very concise and well documented (in the Product Specification PDF provided by Nordic) and I wrote an Arduino sketch to setup the nRF8001 and have it talking to my iPhone 4S in an afternoon. The format is basically one length byte, one command byte, and then optional command-specific arguments.
You will need Nordic’s nRFgo Studio software to create a configuration specifying the services your device will support; it will then include a services.h file containing the setup messages you need to send to nRF8001. I finally managed to emulate a heart rate monitor and display numbers in Nordic’s iOS demo app.
One big benefit of nRF8001 compared to BLE112 is that, apart from the proprietary setup messages generated by nRFgo Studio, you only deal with a well documented serial protocol. No firmware upgrades! It’s very cool that the CC2540 has an on-board 8051 microcontroller, but you’ll either need to pay thousands of dollars for the IAR tools or deal with the limitations and annoyances of BlueGiga’s software stack. A raw CC2540 is cheaper than nRF8001 plus a microcontroller, but BlueGiga’s boards are not cheap.
(There is a UART on the nRF8001 that is brought out on the boards included in the development kit, but it’s only for Bluetooth’s Direct Test Mode and isn’t ordinarily used.)
I know this is an old thread, but it might still deserve some attention...
Bluetooth on Android is mainly used for connecting to wireless headsets. Wireless headsets are slave (not master) devices. This means you'll be able to connect to your slave-only cheap-o Bluetooth module. In fact, I have one of those modules ($6 on Ebay), and I just successfully paired with it from my Nexus S.
It also seems like you can program your Android phone to do anything you want with a Bluetooth link (see this question on StackOverflow for instance). The slave-only Bluetooth module should be sufficient for your needs: you do not need Master mode to transfer data bi-directionally.
Best Answer
I've tested the Bluegiga bluetooth modules with iwrap ascii interface and they allow allow you to open "raw" rfcomm connections.
The most basic one is the WT12 which has the rfcomm features you need. WT11i is a longer range version and WT41 is a super long range version. WT32 has more advanced audio features such as A2DP.
You need to create an account on their techforum in order to get access to the latest iwrap user guide>(https://techforum.bluegiga.com/protectedstore/29110/8424/127/bluegiga_1698/193d9e1a2cdeccd840dd613f9f3262e5/iWRAP5_User_Guide.pdf)
The process is slightly different depending on weather you are opening an rfcomm channel from the module to the external device, or the external device is opening the connection to you.
As you probably know, when opening a new connection, the normal way for discovering what RFCOMM channel should be used, is to check in the SDP entries for a service and the RFCOMM channel for it.
However with iwrap you can skip the SDP discovery step if you know the RFCOMM channel to call. In order to open an rfcomm channel to another device the command you need to give is "CALL 00:07:80:80:52:27 1 RFCOMM". For further details check the documentation for the CALL command.
You can still do a manual SDP queries as well to discover the rfcomm channel of any service or even the l2cap channel for services which don't use rfcomm.
Communication over the rfcomm can be in "transparent" mode in which case every letter you send over UART will be transmitted over bluetooth. Alternatively you can use a simple binary packet format called mux frame. In either case you can configure gpio pins to toggle when you have a connection and when you don't and even use autocall to make the rfcomm connection open automatically when you boot up the module.
If you need the external device to call the module, the other device can call the rfcomm channels directly as well. There is an incoming rfcomm channel already initialized for the SPP profile which has the number 1. And don't get scared about the SPP part in the incoming call, the SPP for the module just means that the correct sdp entry is registered, but any external device capable of calling an rfcomm channel directly (like another iwrap module) can call the rfcomm directly without reading the sdp entries.
Edit: Oh, and if you are looking for a breakout board, here's one: http://www.inmojo.com/store/jeff-rowberg/item/wt12-bluetooth-breakout-board/ (though you really shouldn't be putting any pcb or metal infront of the antenna like in that design, the range will be affected according to Bluegiga RF layout guidelines, but not function so works for testing).