Build OpenNI apk in Ubuntu shell

You should have AndroidManifest.xml in the APK root first and use the following command to generate build.xml

~/ADT/android-sdk-linux/tools/android update project --target android-18 -p .

Now you can build

 ant debug/release -Dsdk.dir=/home/stevenchiu/ADT/android-sdk-linux/

Easy~

To run OpenNI Simple Viewer wth Kinect in BeagleBone Black Android

 1. Build OpenNI

git clone git://github.com/OpenNI/OpenNI

git checkout -b 1.5.4.0 Unstable-1.5.4.0

 checkout to tag 1.5.4.0, only this tag works for me

cd Platform/Android/jni

${NDK_ROOT}/ndk-build

 You have to define your NDK_ROOT of course. I use NDK r7

 If you encountered cpu_set_t can not be recognized in  NiSkeletonBenchmark.cpp, simply ignore this behaviour

 -#if (XN_PLATFORM != XN_PLATFORM_MACOSX)       
+#if (XN_PLATFORM != XN_PLATFORM_MACOSX && XN_PLATFORM != XN_PLATFORM_ANDROID_ARM)      ^M
     //we want out benchmark application will be running only on one CPU core
     cpu_set_t mask;



 2. Build SensorKinect 

export NDK_MODULE_PATH=/path/to/openni/Platform/Android/jni

git clone git://github.com/avin2/SensorKinect.git

git checkout -b unstable origin/unstable

cd Platform/Android/jni

${NDK_ROOT}/ndk-build

 3. Upload your libraries and binary to Android
    Now we have to upload the libraries located in Platform/Android/libs/armeabi-v7a/*.so to android /system/libs. We have to upload OpenNI libraries first and then SensorKinect since some libraries should be replaced according to the HW.


i.e. Kinect in this case.
    
    Please remember to upload the Sample-SimpleRead binary to /system/bin/



 4. Mount USBFS to grant USB device permission
   mount -o devmode=0666 -t usbfs none /proc/bus/usb


 5. Push xmls to /Data/ni
     adb push SamplesConfig.xml /Data/ni
      adb push modules /Data/ni
      adb push GlobalDefaultskinect.ini /Data/ni
      adb push License.xml /Data/ni

6. Run Sample-Read under /Data/ni
    You should be able to see the middle point and frame rate

#Trouble shooting
    USB open fail => sudo rmmod  gpsca_kinect

Android radio interface layer

    其實Android很奇怪，明明是linux系統，ap卻偏偏要跑java。也因此，硬要多一層java與底層api間的橋樑，作為轉化劑，其中的目的就是透過android制定好的api去執行不同解決方案的modem。也因此多了很多麻煩。當然也是有他的好處，就是既然介面都訂好了，剩下的就是去配合不同的方案而產生不同的程式碼。

    底下是一張google自己的投影片，搜尋anatomy-google-io就找的到了。

    可以看到jave跟底層的溝通是透過socket和中間一個叫做rild的daemon program，這個daemon到也沒做什麼事情，只是init自己的event thread，這裡的event就是指每個socket listen到的結果，就是用select()去聽socket，有結果就做對應的事情。說穿了也就是收jave來的request和要送給java的request result。然後呢，他會去load oem的radio library並且做library的init，除了初始library的狀態之外，還會得到一組library必須提供的call back function的address然後利用這組call back functino跟library溝通。定義了五支call back。ex: onRequest(); onRequestComplete()之類的。

    如果是我，在這樣的情形之下，我會怎麼設計我的radio library呢?首先一定是來兩個queue，伴隨著相對應的兩支worker thread，一個處理daemon送來的request，然後往下送，另一個則相反，處理底層來的事件然後回送給daemon。這樣雖然複雜，但是萬無一失，屬於標準設計，library自我隔離於外界，專心於處理本份之上。

    所以每個onRequest()都會把資料put到library中處理request的queue然後給library的thread去按照順序楚哩。因為有了queue所以每個request會是mutual exclusive，因為我們可以等該request處理完畢之後，才去處理下一個。這樣也模擬了android原本對底層telephony的精神，也就是at command，而at command是mutual exclusive的。
    否則的話，如果有某個request的執行必須依賴之前的request的執行的結果的話，會有可能的錯誤發生，好比說在end call之後來一個switch call，那這個switch的request要不要被執行呢??
    而這，就會是推託爭執與各說各話的起點了。
    讓我想到夫妻與男女朋友的相處之道。