Using leJOS with Android
leJOS can be used in Android applications (.apks) via the leJOS PC API that communicates using Bluetooth with either:
This tutorial is not a complete explanation of how to create Android applications which can quickly become far more complicated than the normal difficulty of using leJOS. Three leJOS sample programs have been included in one Android .apk, and this tutorial will explain the most relevant aspects of getting them to work under Android. Please note: The robotics package is not supported.
There is an Eclipse Plugin or a Netbeans Plugin to simplify developing and building .apks. The LeJOSDroid sample project was set up using the Eclipse Android Plugin and can be imported into Eclipse by selecting File --> Import --> General --> Existing Projects into Workspace and selecting the android/leJOS-Droid folder
To use leJOS in your own Android project within Eclipse (same principles apply for Netbeans), make sure:
Sdcard Cache File
leJOS uses a nxj.cache file to record the MAC addresses of
paired NXT devices. Running the sample LeJOSDroid.apk will set this
up for you. To enable this otherwise, create a
To develop with an Android device, which is necessary for anything involving a BlueTooth connection to the NXT, you will need to set up your Android device for debugging. The Android emulator can be used to develop the GUI of your application, but the emulator can not do bluetooth connections.
Logging can be seen in the Eclipse window or via a shell by using logcat via adb
The LeJOSDroid.apk Android application includes three leJOS samples modified from /pcsamples that typically run on your PC or MAC:
The samples have been tailored for Android, and it is important to understand the modifications required by Android Application Fundamentals
The LeJOSDroid.apk can be installed with the adb tool in your-android-sdk-location/platform-tools/. Please uninstall the distributed LeJOSDroid.apk from your Android device (via Settings --> Applications --> Manage Applications) before reinstalling a new LeJOSDroid.apk or there will be an error about conflicting signatures. How to sign an Application.
TachoCount works with either LEGO or leJOS firmware via LCP. Nothing needs to be uploaded to or run on your brick.
The BTSend example requires that samples/BTRecieve must be uploaded and running on a NXT with leJOS firmware. See the section on flashing the leJOS firmware in getting started for your OS, and compiling and running leJOS programs on the NXT.
The BTSend example requires that samples/RCNavigator must be uploaded and running on a NXT with leJOS firmware. See the section on flashing the leJOS firmware in getting started for your OS, and compiling and running leJOS programs on the NXT.
Below are some Android application fundamental considerations:
Further details on the topics touched on below, as well as complete information on UI design and other topics are available from the Android Developer Site
You will need to pair with the NXT from your Android device before being able to connect.
leJOS connection is done via the standard
You'll notice the LeJOSDroid method is static and returns a connected NXTConnector. The reason is that the two examples which use this code (BTSend and TachoCount), call it from another thread that those examples create. The reasons will be discussed in the next section on threading.
Example -- LeJOSDroid connection method:
Most work in Android must be done off the main UI thread, otherwise the user will see a ANR (Android Non-Response) message when there is no response to an input event (e.g. key press, screen touch) within 5 seconds.
For this reason, the BTSend and TachoCount samples are run in their own thread. In
It should be noted that while the
The RCNavigationControl example has a more complex UI which isn't easily combined with LeJOSDroid and so is run as a new activity. This new activity is, in fact now, the UI thread that creates other threads to handle the connection and reading which block. If an ANR message appears from work done on the main UI thread, that work too will need to be threaded. In actuality, the code to connect for RCNavigationControl works fine even if it is taken out of it's own thread because in all likelyhood the user won't be creating an input event (via a key press or screen touch for example) while waiting for a connection to be made.
RCNavigationControl is extremely illustrative of this point.
In the original
In comparision, the RCNavComms class for the Android example uses a Handler that was passed in through the constructor (instead of the RCNavigationControl instance).
Please see the documentation to learn more about Handlers. While the RCNavigationControl example does in fact work even without using a Handler and passing in an instance to use to update the UI, it's very true that Threads will run briefly as the UI thread if you try to update the UI by passing in an instance and modifying the View (as would be done by using the PC or MAC example). Views in Android are decidedly single threaded and sanity checks may not catch what you are doing, and thus lead to unpredictable behavior. Also, there is a risk of memory leaks.
Many of the LeJOSDroid methods such as
For instance, some essential setup is actually done in