It's certainly possible to develop on a Windows machine, in fact, my first application was exclusively developed on the old Dell Precision I had at the time :)
There are three routes;
- Install OSx86 (aka iATKOS / Kalyway) on a second partition/disk and dual boot.
- Run Mac OS X Server under VMWare (Mac OS X 10.7 (Lion) onwards, read the update below).
- Use Delphi XE4 and the macincloud service. This is a commercial toolset, but the component and lib support is growing.
The first route requires modifying (or using a pre-modified) image of Leopard that can be installed on a regular PC. This is not as hard as you would think, although your success/effort ratio will depend upon how closely the hardware in your PC matches that in Mac hardware - e.g. if you're running a Core 2 Duo on an Intel Motherboard, with an NVidia graphics card you are laughing. If you're running an AMD machine or something without SSE3 it gets a little more involved.
If you purchase (or already own) a version of Leopard then this is a gray area since the Leopard EULA states you may only run it on an "Apple Labeled" machine. As many point out if you stick an Apple sticker on your PC you're probably covered.
The second option is more costly. The EULA for the workstation version of Leopard prevents it from being run under emulation and as a result, there's no support in VMWare for this. Leopard server, however, CAN be run under emulation and can be used for desktop purposes. Leopard server and VMWare are expensive, however.
If you're interested in option 1) I would suggest starting at Insanelymac and reading the OSx86 sections.
I do think you should consider whether the time you will invest is going to be worth the money you will save though. It was for me because I enjoy tinkering with this type of stuff and I started during the early iPhone betas, months before their App Store became available.
Alternatively, you could pick up a low-spec Mac Mini from eBay. You don't need much horsepower to run the SDK and you can always sell it on later if you decide to stop development or buy a better Mac.
Update: You cannot create a Mac OS X Client virtual machine for OS X 10.6 and earlier. Apple does not allow these Client OSes to be virtualized. With Mac OS X 10.7 (Lion) onwards, Apple has changed its licensing agreement in regards to virtualization. Source: VMWare KnowledgeBase
This thread may be long dead but for those who might be trying the same thing, some notes from the AudioManager docs may be useful. It looks like the missing element is the startBluetoothSco() command but there are restrictions on the use of this channel. From the Android Dev site here:
public void startBluetoothSco () Since: API Level 8 Start bluetooth SCO
audio connection.
Requires Permission:
MODIFY_AUDIO_SETTINGS.
This method can be used by
applications wanting to send and
received audio to/from a bluetooth SCO
headset while the phone is not in
call.
As the SCO connection establishment
can take several seconds, applications
should not rely on the connection to
be available when the method returns
but instead register to receive the
intent ACTION_SCO_AUDIO_STATE_CHANGED
and wait for the state to be
SCO_AUDIO_STATE_CONNECTED.
As the connection is not guaranteed to
succeed, applications must wait for
this intent with a timeout.
When finished with the SCO connection
or if the establishment times out, the
application must call
stopBluetoothSco() to clear the
request and turn down the bluetooth
connection.
Even if a SCO connection is
established, the following
restrictions apply on audio output
streams so that they can be routed to
SCO headset: - the stream type must be
STREAM_VOICE_CALL - the format must be
mono - the sampling must be 16kHz or
8kHz
The following restrictions apply on
input streams: - the format must be
mono - the sampling must be 8kHz
Note that the phone application always
has the priority on the usage of the
SCO connection for telephony. If this
method is called while the phone is in
call it will be ignored. Similarly, if
a call is received or sent while an
application is using the SCO
connection, the connection will be
lost for the application and NOT
returned automatically when the call
ends.
See Also stopBluetoothSco()
ACTION_SCO_AUDIO_STATE_CHANGED
Note that I have not tested this, I'm just passing along a lead I found in researching a similar project. I think Jayesh was close to the solution and the restrictions above may have been what was keeping it from working.
Best Answer
This little test worked for me... it involves setting up the bluetooth headset as the input also (not sure if that's what you want). Sorry about the crappy formatting on the code...
Hope that helps!