- Research Notes
- Open Source
- SSD Linux benchmarks
- Git cheat sheet
- Home directory version control
- Austrian "Buergerkarte" under Linux
- Debian on a Thinkpad T42p
- (K)Ubuntu on a Dell Latitude XT
- Debian on a Gericom Phantom
- Encrypted home directories
- Automounting with hotplug
- Aladdin eToken under Linux
- Encrypted container under Linux and Windows
- SpeedTouch 330 ADSL USB modem with kernel 2.4
- Combining an open WLAN hotspot with private IPsec
- How to make a USB stick bootable
- Encrypted suspend-to-disk with Debian
- Import old emails into a Cyrus spool
- IPsec/L2TP gateway for Android and iPhone
- Nokia N900 synchronization with Egroupware
- Suspend and wakeup under Linux
- Android applications
- Debian Root CAs for KDE4
How to run Java programs on Windows Mobile with JSR82 for Bluetooth
Running Java programs on Windows Mobile devices may or may not be easy, depending on the installed JVM and its libraries. However, if some support is missing, it can get tricky... This page aims to show a few options for installing JVMs and especially for adding Bluetooth support in the form of a working JSR82 API implementation.
Which operating system does it run?The first question one has to ask when it comes to "small" devices running any version of Windows CE is about the platform. Unfortunately, many (sometimes only subtly) different names make it hard to answer this (see here, here, here, and here for a start). Generally, the kernel is based on "Windows CE", but the application stack on top of it makes the difference - this used to be called "Pocket PC" and is now called "Windows Mobile". For the whole system (kernel plus application stack), we nowadays distinguish among:
- A PDA without phone functionality will probably run "Windows Mobile for Pocket PC". It has a touch screen, reasonable Flash and RAM space, mobile office applications, full ActiveSync support and typically Bluetooth and/or WLAN support.
- A "small" phone without a touch screen will probably run "Windows Smartphone" or "Windows Mobile for Smartphones". These are limited devices and often not open to serious development.
- A reasonably modern "smart" phone with touch screen will probably run "Windows Mobile for PocketPC Phone Edition", at the time of this writing (December 2008) typically version 5 or 6. It will typically use an "ARM" processor architecture.
The upshot of this is that, confusingly, a high-level smartphone with Windows on it will typically not run anything called "Windows Smartphone", but will run "Windows Mobile for PocketPC Phone Edition". All of the following text is concerned with this version of Windows CE. On other variants, the described JVMs may or may not work. It has been specifically tested with two fairly recent smartphones, the "HTC Touch Diamond" and the "Samsung i-900 Omnia", both running "Windows Mobile for Pocket PC Phone Edition version 6.1" but different GUIs on top of it to deal with finger-touch and accelerometer sensors.How to find out which version your device runs?If there is a "Start" link in the top left corner, then it is some "Pocket PC" version and not "Windows Smartphone"/"Windows Mobile for Smartphones". Then, under "Settings" / "System" / "Info", the exact OS and kernel version can be checked (e.g. "Windows Mobile 6.1 Professional", which is again another name for "Windows Mobile 6.1 for Pocket PC Phone Edition", and kernel "CE OS 5.2.20270" indicating a Windows CE version 5.2 kernel that also points at a Pocket PC version 6.1 application stack).Which Bluetooth stack does it use?To make matters even more complicated, Windows Mobile devices may have different Bluetooth stacks. I know of two stacks that seem in common use:
- the Microsoft Bluetooth stack (also called "Winsock"): very basic with limited functionality
- the Broadcom WIDCOMM Bluetooth stack: implements many of the Bluetooth profiles
Not having found a good way to distinguish the stacks from a user interface point of view, I can only suspect that the Samsung i-900 Omnia uses the Microsoft (Winsock) stack, while the HTC Touch Diamond uses the WIDCOMM one. Don't take this for granted, though - I'm not completely sure! There are differences in the Bluetooth settings dialog, although some of the tabs are equivalent. One difference is that the HTC has a "Profiles" tab while the Samsung doesn't have that (which is the reason I suspect the former to have the WIDCOMM stack). Another is the "FTP" tab, which shows a "Bluetooth Explorer" tickbox on the HTC but not on the Samsung. Fortunately, the very nice, open source BlueCove JSR82 implementation supports both on the Windows Mobile platform (any many other stacks on different platforms).Pre-installed Java virtual machinesBoth phones I tested this on already come with a JVM pre-installed, the HTC with an "Esmertec Jbed" while the Samsung doesn't give any hint to its manufacturer (it just says "Java" in the menu claims to be MIDP2.0 and CLDC1.1 in its "Info" menu). This JVM on the Samsung i-900 Omnia already supports JSR82, so no additional tricks are necessary on to use Bluetooth in Java programs on this phone. I have verified that it works with my own "BluetoothDemo" MIDlet that is included in the current OpenUAT release. Another MIDlet to test it with is the bluecove-tester.Mysaifu J2SE virtual machineAt the time of this writing, the open source Mysaifu JVM seems to be the only actively maintained JVM for Windows Mobile devices that supports J2SE. Installing this on the HTC Touch Diamond (tested with version 0.4.1) allows to get JSR82 support with BlueCove. Note that the most recent release 2.0.3 does not work on Windows Mobile due to some bug. A snapshot of the newer 2.1.0 version (tested with bluecove-2.1.0-20081117.151123-14.jar), however, works almost out-of-the-box:
- Push jvm.Release.CAB (extracted from the jvm.0.4.1-bin.zip archive) to the phone and install it.
- Push bluecover-tester.jar, bluecove-2.1.0-20081117.151123-14.jar, and junit-3.8.2.jar (extracted from JUnit 3.8.2) to the phone.
- Start the Mysaifu JVM on the phone:
- "Type" should be set to "Class"
- "Name" must be set to "net.sf.bluecove.se.Main"
- Unter "Options", add the blucove-tester.jar, bluecove-2.1.0-20081117.151123-14.jar, and junit-3.8.2.jar (from whichever directory the Bluetooth push sent put them in) to the "CLASSPATH" and exit this screen with "OK".
- Finally, "Execute" will run the bluecove-tester and allow to test most aspects of JSR82 on the HTC Touch Diamond.
(The good thing is that the above steps only need to be done once, Mysaifu will remember the settings when selecting this class name again from the "recent" list.)
The combination of Mysaifu JVM and BlueCove seems to work nicely with J2SE applications (i.e. with an AWT GUI). However, Mysaifu doesn't come with MIDP/CLDC support and will therefore not directly execute MIDlets. I have tried to run them with MicroEmulator (a J2ME implementation written in J2SE), but have not had success so far because MicroEmulator doesn't run correctly on Mysaifu (at the time of this writing - please send me an email if it starts to work and I'll update this page). phoneME J2ME virtual machineThe (Sun-supported) open source phoneME JVM is another alternative that is currently available for Windows Mobile (including versions 5 and 6 for Pocket PC). Pre-compiled binaries are available here, and I have tested phoneME Advanced Dual Stack - Foundation b97 (with MIDP support).The following steps have been compiled from this thread, without which I would not have gotten it to run - big thanks to the original authors!Related workThis is just a loose collection of other hints and links relevant to Bluetooth and/or Windows Mobile devices that may be relevant:
- Windows Mobile (unsure about the stacks, but verified both on HTC Touch Diamond and Samsung i-900 Omnia) do not mark their Bluetooth services (i.e. profiles) as browsable (for some reason unknown to me). The effect is that browsing for services will not work with most tools (at least not with the excellent Bluez Linux Bluetooth stack)! This can be easily verified:
- hcitool scan finds Windows Mobile phones if their Bluetooth stack is set to be discoverable
- sdptool browse <MAC address> does not show any services even when paired
- sdptool records <MAC address> however, does return many services registered with the phone SDP service
Using JSR82 from Java, the same effect can be witnessed. When searching for Bluetooth services on "standard" devices (e.g. Symbian OS based phones), the full services list can be found, both when searching from a desktop/laptop and when searching from another phone. But searching services on a Windows Mobile phone will return the DiscoveryListener.SERVICE_SEARCH_NO_RECORDS error code. A workaround for this is not to include UUID(0x1002) in the set of UUIDs passed to DiscoveryAgent.searchServices. Using e.g. UUID(0x0100) (which describes L2CAP services, which is ok because we usually can't access SCO services from Java anyways) works and returns all registered SDP services even from Windows Mobile devices. An implementation working on any JSR82 capable mobile phones and desktops/laptops (and being able to search services on all phones I've tried it with so far) can be found in the latest OpenUAT release (see classes org.openuat.util.BluetoothPeerManager and org.openuat.apps.j2me.BluetoothDemo).
- The Samsung i-900 Omnia phone (and most probably other Windows Mobile 6 devices) does not accept OBEX push of files with default options even when already paired with the sending device. To get it working, add the (undocumented) options "-U NONE -H -S" to the Linux bluez obexftp call as documented here. That is, instead of using "obexftp -b <Bluetooth MAC address> -p <file to push>" (which works for all other devices that I've tried so far, including the HTC Touch Diamond), use "obexftp -b <Bluetooth MAC address> -U NONE -H -S -p <file to push>". It would be interesting to know why this is necessary and what Samsung/Microsoft did to break the standard.
- Using (e.g. HSDPA) connection sharing via WLAN instead of Bluetooth
- Switching from Microsoft to WIDCOMM stack
- Enabling PAN without connecion sharing on the Microsoft stack