Menu
▾
▴
Android
OpenGCD on Android
HOWTO
First, read the [HOWTO] instructions on how to setup a build and test environment for Android.
Status
Implementation in progress.
| Action item | Status |
|---|---|
| Port libBlocksRuntime | Done |
| Port libkqueue | Done |
| Port libpthread_workqueue | Done |
| Port libdispatch | Need to support Android atomic operations, and implement POSIX semaphores for Android |
| Combine all OpenGCD components into a single library | TBD |
| Commit all Android-specific patches to the upstream source repository | TBD |
Goals
Short-term:
- Allow existing C/C++ code that uses GCD to be ported to Android.
Medium-term:
- Create Java bindings for GCD
Long-term:
- Incorporate GCD into the core Android native API
Problems
Here are some potential problems that may affect this effort:
- Limited SMP support in current hardware - The majority of Android-powered devices today are single core, so they will not see any immediate benefits from the parallelism of GCD.
- Power usage is a concern - There is a tradeoff between performance and battery life. Spreading work across multiple cores may negatively impact battery life, while the user may not notice the increased performance.
- Language barrier - The vast majority of applications for Android are written in Java and cannot directly make use of GCD.
- Potential toolchain issues - Using clang instead of GCC may lead to various hard-to-debug toolchain issues.
- Limited backwards compatibility - The majority of deployed Android devices (90% by some estimates) do not support running native code via the NativeActivity API.
- Signal handling - libkqueue might interfere with JVM signal handling. This can supposedly be solved with signal chaining
Opportunities
- Using lock-free dispatch queues instead of mutexes may be a performance "win" for ARM devices.
- The availability of GCD should make it easier to port apps from MacOS or iOS to Android.
- Having a JNI bridge to libdispatch may be the first step in creating Java bindings for libdispatch. There is already a libdispatch style API for Java and Scala that could possibly benefit from being built on top of a "real" GCD/OpenGCD foundation.
Tasks
Phase 1: Port existing C sources to Android platform
The goal is to build the existing C sources "as is" on Android with minimal modifications.
- Create a modified Android build environment that uses Clang instead of GCC.
- Port libpthread_workqueue to Android.
- Port libkqueue to Android.
- Port libBlocksRuntime to Android.
- Port libdispatch to Android.
- Create an OpenGCD project definition in Makeconf that combines all the separate components.
- Use Makeconf to generate an Android.mk makefile for OpenGCD.
- Test everything on the Android device emulator.
- Test everything on a real multicore Android device
Deferred tasks, not in the critical path:
* Add support to Makeconf for generating Android.mk makefile fragments.
* Add support to Makeconf for building multiple projects.
* Add support to Makeconf for generating an Android.mk file containing multiple projects ("modules" in Android parlance).
Phase 2: Performance analysis and tuning
The goal is to asses the performance of OpenGCD/android and make any necessary fixes or improvements.
- Analyze code and look for performance issues
- Optimize libpthread_workqueue for uniprocessor Android devices.
Phase 3: Create Java bindings
- Generate JNI bindings for all GCD API functions.
- Create a "Hello World" Android project in Eclipse that demonstrates how to load libdispatch and run a few functions.
- Investigate the possibility of mapping Java closures to C blocks.
Phase 4: Integrate with the Android API
- TBD -- Needs discussion with Android development community
Questions
- Can OpenGCD be installed in a system-wide location and made available to all Android applications? Or will users be forced to bundle a private copy of OpenGCD with their app?
- The dynamic linker in Android doesn't handle inter-library dependencies in an automated fashion. Should libdispatch build a private copy of it's dependencies (libBlocksRuntime, libkqueue, libpthread_workqueue) and statically link them into libdispatch.so? Otherwise, the user must manually call System.loadLibrary() in a particular order, which sounds painful.
- Do we need to require NEON intrinsics?