前回、JniProxyタイプではうまくいかないです～の続きです。
動作させるためには、JavaJniAppのパッケージ(APK)に libNativeAppMain.so を含められればそれで完了です。
これをどうやって行うかですが、強引には以下の手順で実現することが可能です。
- NativeAppMainをビルド。soファイルが出来る
- JavaJniAppのビルド１。まず libJavaJniApp.soが作成される
- JavaJniAppのビルド２。Java部分のコンパイルが実行される
上記のJavaJniAppのビルド１ or ２のタイミングで NativeAppMainの so ファイルを JavaJniApp/libs/armeabi-v7a の中にコピーしてあげればよいです。
成功すれば Apkファイルの中に libNativeAppMain.so が入っています。
一度実行してログを確認してみます。(起動後、戻るボタンでホームに戻るという操作を行っています)
うまく動いていればこのようにログが出ているはずです。
I/jniproxy( 7905): JavaJniApp_init I/nativeappmain( 7905): app_init called I/jniproxy( 7905): JavaJniApp_quit I/nativeappmain( 7905): app_quit called
この時に、アプリケーション本体である nativeappmain.c の各関数にブレークポイントを仕掛けて、同じように実行してみます。
下記のスクリーンショットに示すように、ちゃんとブレークポイントが有効となって停止します！すばらしい。
タイミングコピーの自動化を狙う
先ほどの、手動でlibNativeAppMain.soを強引にタイミングを見計らってコピーするという方法はちょっと手間です。
タイミング失敗によるとまたビルドし直しになるし、ここは何とかして自動で解決するようにしたいです。
Nsight Tegra は、どうやら vs-android をも取り込んでいるようです。vs-androidではAntを使用していましたし、よくよく動作を見るとビルドのタスクをこなしているのはAntのようです。
ということは Ant の設定やスクリプトを変更すれば、この自動化も出来そうな気がします。
そこで build.xml の中身を覗いてみると、以下のようになっており、どうやらカスタマイズの余地がありそうです。
まずは JavaJniApp の build.xmlと同じ場所で custom_rules.xml を作成して、中身を以下のように設定します。
そうして、ビルドを実行してみると、以下のように上記の設定が実行されたことが確認できます。
2> 2> -pre-build: 2> [echo] hogehogehoge 2>
JavaJniAppのsoが出来たタイミングが良さそうだろうと思うので、post-complie タイミングで実行されるように、下記の設定を custom_rules.xmlに記載します。
これで JavaJniApp をビルドして、既にできあがっている本体のsoをコピーすることが出来るようになります。
改善点は、上記の場合コピー元フォルダが Debug と決めうちしてあるため、構成に応じて変更できればさらに便利になりそうです。
改良した custom_rules.xml を下記に示します。これでビルド構成Debug/Releaseに対応できます。
まとめ
Eclipse+NDKでは苦しい JniProxy タイプのソースコードレベルのデバッグもNsight Tegraならば可能でした。
最近のWinGDB for Mobile Systems では試していないですが、このタイプのデバッグも出来るとなるとかなり便利です。
個人的には開発においては、Tegra(ICS以降)のAndroidを準備すると幸せになれると感じました。
