Antidote port to Android ICS
Since Android 4.0.x (Ice Cream Sandwich -- ICS) has native support and APIs to Bluetooth HDP, Antidote can be compiled with NDK and bundled in a regular application package (APK). No need for superuser or flashing.
Antidote core library https://gitorious.org/antidote/antidote You can use either the stable version 2.0.0 or the CVS version.
Antidote sample service for Android (HealthService) https://gitorious.org/antidote/android-sample
Sample client for Android service (HealthServiceTest) https://gitorious.org/antidote/antidote-sample-client
We don't provide stable packages or APKs for above Android applications because they are meant as exemples for developers, not production code.
The Antidote core library must be checked out under HeathService/jni folder, and built with NDK in there.
Due to a bug in Eclipse, the aidl/ folder must be added manually to .classpath in Android projects. Symptom of the problem is not finding HealthServiceAPI class. (Some online source say that a simple clean solves this, too.)
Another thing that may cause errors is the Java compiler compliance level, that must be 1.6, not 1.5. Check this in Project Properties.
HealthService supplies a Service whose API is very similar to "healthd", the D-Bus service which is bundled with Antidote (and runs on Linux).
Android does not have D-Bus, but it has the Service/Intent framework for the IPC tasks.
NDK (Native Development Kit) does not expose the whole Android API to C code. Because of this, and because it is much easier to write Android-specific code in Java, the HealthService service uses a hybrid approach in HealthService:
- The executable and main loop are Java-based. The port is not a native Service implementation.
- The native part (Antidote core library, red in chart) is responsible by IEEE 11073 and Manager;
- The Java part takes care of Service API, HDP communications and timers;
- JNI is employed to call native Android functions;
- Antidote calls Java back via a proxy JniBridge object.
- The native communication plug-in simply delegates requests to Java level.
- JniBridge does not interact directly with HDP. The data flow between JniBridge and HDP (dashed, curved arrow in chart) is indirect and intermediated by HealthService.
JniBridge has front-end methods for all native methods, and all of them are synchronized. This guarantees that only one thread is on native code at any given time, and makes things much easier at native code side.
Even though the native part depends on application support, it is not particularly tied to HealthService application. The native part can be used with any other application. The only Java source code that is heavily coupled with native part is JniBridge.java, which can simply be copied.
The Bluetooth HDP code is written in Java and it is heavily based on Android SDK's BluetoothHDP example. It has many improvements (e.g. concurrency support). Native code does not care about this; any other transport could have been used, provided that it "talks" IEEE 11073.
HealthService has an Activity but it does nothing. HealthServiceTest is the test UI. The UI borrows from (obsolete) AntidoteClient that ran on Android 2.3.
These Android samples are for developers, so the UI is very simple. In the other hand, LogCat shows a lot of information.