Recent changes to Android

WikiPage Android modified by Mark Heily

Mark Heily — Fri, 20 Jul 2012 00:51:44 -0000

--- v9
+++ v10
@@ -1,5 +1,10 @@
 OpenGCD on Android
 ===
+
+HOWTO
+---
+
+First, read the [HOWTO] instructions on how to setup a build and test environment for Android.
 
 Status
 ---

WikiPage Android modified by Mark Heily

Mark Heily — Tue, 03 Jul 2012 02:05:55 -0000

--- v8
+++ v9
@@ -9,7 +9,7 @@
 Action item | Status 
 ---- | -----
 Port libBlocksRuntime | Done
-Port libkqueue | Mostly done, but EVFILT_TIMER is broken
+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

WikiPage Android modified by Mark Heily

Mark Heily — Sun, 01 Jul 2012 22:17:14 -0000

--- v7
+++ v8
@@ -4,7 +4,16 @@
 Status
 ---
 
-In the design and planning phase.
+Implementation in progress. 
+
+Action item | Status 
+---- | -----
+Port libBlocksRuntime | Done
+Port libkqueue | Mostly done, but EVFILT_TIMER is broken
+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
 ---
@@ -19,7 +28,7 @@
 
 Long-term:
 
- * Incorporate GCD into the core Android API
+ * Incorporate GCD into the core Android native API
  
 Problems
 ---
@@ -48,9 +57,6 @@
 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.
- * 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).
  * Port libpthread_workqueue to Android.
  * Port libkqueue to Android.
  * Port libBlocksRuntime to Android.
@@ -58,7 +64,12 @@
  * 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 Android device -- sounds like somebody is getting a new Android tablet, mmmmm :)
+ * 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

WikiPage Android modified by Mark Heily

Mark Heily — Thu, 07 Jun 2012 04:09:24 -0000

--- v6
+++ v7
@@ -47,17 +47,19 @@
 
 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.
  * 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).
+ * Port libpthread_workqueue to Android.
+ * Port libkqueue to Android.
  * Port libBlocksRuntime to Android.
- * Port libkqueue to Android.
- * Port libpthread_workqueue 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 Android device -- sounds like somebody is getting a new Android tablet, mmmmm :)
- * Create an OpenGCD project definition in Makeconf that combines all the separate components. 
- * Use Makeconf to generate an Android.mk makefile for OpenGCD.
+
 
 Phase 2: Performance analysis and tuning

WikiPage Android modified by Mark Heily

Mark Heily — Thu, 07 Jun 2012 02:50:25 -0000

--- v5
+++ v6
@@ -6,6 +6,21 @@
 
 In the design and planning phase.
 
+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 API
+ 
 Problems
 ---
 
@@ -13,7 +28,7 @@
 
  * ** 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.
- * **Limited usefulness for Java-based applications -** Most applications for Android are written in Java and have no need for GCD. 
+ * ** 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](http://publib.boulder.ibm.com/infocenter/realtime/v1r0/index.jsp?topic=%2Fcom.ibm.rt.doc.10%2Fuser%2Fnative_signals.html)
@@ -30,6 +45,8 @@
 
 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.
+
  * 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).
@@ -43,6 +60,8 @@
  * Use Makeconf to generate an Android.mk makefile for OpenGCD.
 
 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.

WikiPage Android modified by Mark Heily

Mark Heily — Thu, 07 Jun 2012 01:13:08 -0000

--- v4
+++ v5
@@ -47,7 +47,7 @@
  * Analyze code and look for performance issues
  * Optimize libpthread_workqueue for uniprocessor Android devices.
 
-Phase 3: Add simple Java interfaces
+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.

WikiPage Android modified by Mark Heily

Mark Heily — Thu, 07 Jun 2012 01:12:06 -0000

--- v3
+++ v4
@@ -48,11 +48,13 @@
  * Optimize libpthread_workqueue for uniprocessor Android devices.
 
 Phase 3: Add simple Java interfaces
+
  * 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

WikiPage Android modified by Mark Heily

Mark Heily — Thu, 07 Jun 2012 01:11:30 -0000

--- v2
+++ v3
@@ -23,26 +23,42 @@
 
  * 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 ](http://hawtdispatch.fusesource.org/) that could possibly benefit from being built on top of a "real" GCD/OpenGCD foundation.
+ * 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](http://hawtdispatch.fusesource.org/) 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
+
  * Add support to Makeconf for generating Android.mk makefile fragments.
- * Port libBlocksRuntime
- * Port libkqueue
- * Port libpthread_workqueue
- * Port libdispatch
+ * 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).
+ * Port libBlocksRuntime to Android.
+ * Port libkqueue to Android.
+ * Port libpthread_workqueue to Android.
+ * Port libdispatch to Android.
+ * Test everything on the Android device emulator.
+ * Test everything on a real Android device -- sounds like somebody is getting a new Android tablet, mmmmm :)
+ * Create an OpenGCD project definition in Makeconf that combines all the separate components. 
+ * Use Makeconf to generate an Android.mk makefile for OpenGCD.
+
+Phase 2: Performance analysis and tuning
+
+ * Analyze code and look for performance issues
+ * Optimize libpthread_workqueue for uniprocessor Android devices.
+
+Phase 3: Add simple Java interfaces
  * Generate JNI bindings for all GCD API functions.
- * Create an OpenGCD project definition in Makeconf that brings in all the other dependencies. 
- * Use Makeconf to generate an Android.mk makefile for OpenGCD.
  * Create a "Hello World" Android project in Eclipse that demonstrates how to load libdispatch and run a few functions.
- * ???
- * Profit!
+ * 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()](http://stackoverflow.com/questions/8828559/loading-3rd-party-shared-libraries-from-an-android-native-activity) in a particular order, which sounds painful. 
  * Do we need to require [NEON intrinsics](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s04s02.html)?

WikiPage Android modified by Mark Heily

Mark Heily — Thu, 07 Jun 2012 00:48:06 -0000

WikiPage Android modified by Mark Heily

Mark Heily — Thu, 07 Jun 2012 00:10:04 -0000

OpenGCD on Android === Status --- In the design and planning phase. 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. * **Limited usefulness for Java-based applications -** Most applications for Android are written in Java and have no need for 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](http://publib.boulder.ibm.com/infocenter/realtime/v1r0/index.jsp?topic=%2Fcom.ibm.rt.doc.10%2Fuser%2Fnative_signals.html) 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 ](http://hawtdispatch.fusesource.org/) that could possibly benefit from being built on top of a "real" GCD/OpenGCD foundation. Tasks --- * Add support to Makeconf for generating Android.mk makefile fragments. * Port libBlocksRuntime * Port libkqueue * Port libpthread_workqueue * Port libdispatch * Generate JNI bindings for all GCD API functions. * Create an OpenGCD project definition in Makeconf that brings in all the other dependencies. * Use Makeconf to generate an Android.mk makefile for OpenGCD. * Create a "Hello World" Android project in Eclipse that demonstrates how to load libdispatch and run a few functions. * ??? * Profit! Questions --- * 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()](http://stackoverflow.com/questions/8828559/loading-3rd-party-shared-libraries-from-an-android-native-activity) in a particular order, which sounds painful. * Do we need to require [NEON intrinsics](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s04s02.html)? References --- * [Howto for using clang with the NDK](http://clang-developers.42468.n3.nabble.com/Clang-amp-Android-td4005109.html)