「 NDK 」一覧

NVIDIA Nsight Tegra 3.0


NVIDIA Nsight Tegra を更新しました

AndroidWorks なるパッケージが NVIDIA から公開されて、その中に NVIDIA Nsight Tegara 3.0 なるものが入っていました。以前にも Nsight Tegra は Android 開発において、デバッグ効率を上げる可能性を秘めていることは説明しました。ただし当時は TEGRA 専用という制約がありました。
今回、AndroidWorks の説明の中で、 Tegra に限定しないというような文章があったので再び試してみることにしました。

インストール

以前と同様ですが登録して AndroidWorks をダウンロード&インストールします。ほぼ全自動で Android の開発環境がインストールされます。
 だいたい問題なくいくのでしょうが、自分の環境では VisualStudio でのプロジェクト作成時に Min Target が選べないという症状に出遭ってしまいました。一応 NVIDIA のTegra Android Development Pack (TADP) をインストールした後で、 NVIDIA Nsight Tegra をインストールするという方法で、対処を行っています。もし同症状に見舞われたら TADP をインストールしてみると解決するかもしれません。 続きを読む


VS-Droidを試してみる


前回概要だけだったので今回は早速VS-Droidを触ってみようと思います。

VSDroidのインストール

vsdroid
インストール画面ではこのように表示されました。
Visual Studio 2005 から 2012 まで対応しているようです。またMSBuildを使ったビルドシステムのために VS-Android をインストールできるようになっているようです。ただここでは素のVSDroidを確認したいので、導入しないでおきます。

動作確認

Visual Studio 2012 を起動して結果を確認してみます。
下記に示すように構成が増えていました。また上部のメニュー部分にも VSDROID という項目が見えます。

vsdroid-visualstudio-1

HelloJni のサンプルをまずインポートしてみようと思います。
「Import Java+native Android project」の構成を選んで実行します。

するとインポート元の Android.mk を指定するように聞かれるので、Android NDKに含まれていた hello-jni(android-ndk-r9b\samples\hello-jni\jni) を開くことにします。

下記のような画面が現れて、各ファイルをread-only にするかどうか選択できます。
ここではチェックを入れずに続行してみました。

vsdroid-visualstudio-2

最後にソリューションファイル(sln)の保存場所を聞かれるので、そもそも最初の段階で決めて vcxprojが保存される場所に一緒に保存されるようにしました。

てっきりコピーされるかと思ったのですが、Importではあくまでインポート位置のものが使用されるようです。とりあえずここでは気にしないことにして各ファイルを開いてみたのが以下の図になります。

vsdroid-visualstudio-3

まずはVSDROIDの設定をするために、メニューからVSDROID/Preferences を開きます。
すると下記のような画面が出てきます。

vsdroid-preferences

CygwinのパスやJDKのパス、Android SDK,NDKのパス, Antのパスを入力していきます。
このことからわかるように現在の状態では Cygwin,Ant が必要ということですね。

これらの設定が終わったらプロジェクトをビルドしてみます。

error: Target id 'android-3' is not valid. Use 'android.bat list targets' to get the target ids.
Error: could not prepare project for build.TestVSDroid-1 - 3 error(s), 0 warning(s)

このようなエラーが発生してしまいました.

TestVSDroid-1のプロジェクトのプロパティを開いて、Common/Target platform で示される項目を編集します。
下記に示すように手元では android-10 と入力して、再度ビルドを実行したところうまくいったようです。

vsdroid-visualstudio-4

実行&デバッグ

ビルドができたところで実行をテストしてみます。
端末を接続して、プロジェクトの設定から Configuration内の Debug を開き、Debug target device で目的のデバイスを選択しておきます。デバイスが1種しかない場合には device を選択しておけば良さそうです。
また、Target 内にある Optimization の項目を No にしておきます。

vsdroid-visualstudio-5

設定できたらそのまま F5(デバッグ開始) で実行してみます。
すると下記のような画面に遷移しました。また実機上ではプログラムが起動してHello from JNI の文字列が表示されていました。

vsdroid-visualstudio-6

今度はブレークポイントを仕掛けてみることにします。
Java側では、HelloJniクラスの onCreate に、ネイティブ側では、Java_com_example_hellojni_HelloJni_stringFromJNI 関数に仕掛けておきます。設定はいつものVisualStudioの使用時と変わらない設定で F9 にてブレークポイントを仕掛けました。

これで F5実行 で実行してみます。

vsdroid-visualstudio-7
上記の図を見てわかるとおり、ネイティブ側のブレークポイントで停止しました。
混在のケースではまだ開発途中ということもあり片方で(この場合ネイティブ側)で止まるようです。

ウォッチで変数の値を見ることはできますし、呼び出し履歴についてもそこそこ見られるようです。

vsdroid-visualstudio-8

ただ気になった点としては、デバッグの停止で Visual Studio が応答停止する状態になることです。自分の端末(GalaxyS2)の問題なのかもしれませんが・・・。


WinGDB MSE から VS-Droid へ


WinGDB for Mobile Systems はプロダクトが変わって、VS-Droid for Visual Studio というプロダクトになったようです。しかも色々とあってフリーのリリースとなっている模様です。その色々については本家ページの方を参照してください。

特徴・機能について

  • Visual Studioのプロジェクト統合.
  • AndroidManifest.xmlに記述されるプロジェクト構造だけでなく、ネイティブのサブプロジェクトの情報もまたソリューションエクスプローラーに表示可能. アクティビティは現在デバッグ可能
  • 標準のNDK-Buildのビルドシステムを使用します。WinGDBは *.mk や *.xml のファイルを参照して、他のツールとの連係動作が可能なようにしている。そのため変換は不要.
    ただ独自の設定を保存する wgaproj ファイルをプロジェクトに追加する。
  • エミュレーター上でアプリケーションのデバッグ.起動中のアクティビティへのアタッチや起動時からのデバッグができる。デバッグにはVisual Studioのものが使用できる
  • 物理デバイスで非root取得状態でのデバッグが可能。Nexus Oneをリファレンスとして使用している。全てのデバイスで動作を保証するものではないが、VS-Droidは標準のSDK,adbを用いているのでこれらがうまく動作するのであれば動く
  • 限定的ではあるが Java のサポート。現バージョンでは構文ハイライト機能と簡単な編集が利用可能で、ビルド&実行ができる。
  • まだ実験段階のJavaデバッガを持っており、Java,ネイティブどちらのデバッグセッション開始も可能である
  • ただし、混在するデバッグはできず現在作業中である
  • デバイスモニター機能。接続先デバイスの情報を取得&表示するための機能

ざっくりですが本家ページの内容を意訳してみるとこのような感じかと思います。
まだ開発途中とのことではありますが、これらの機能をフリーで提供する方針に変わってくれたことは開発者としてとても嬉しく思います。

次回以降インストールしてみて使用してみた感じをお知らせできればと思います。


Z1 Compact で ndk-gdb を試す


XPERIA Z1f というか Z1 Compact を接続できるようになったので、早速ネイティブデバッグができるかどうかを試してみたいと思います。
一番の心配事はこの端末が Android 4.3 を標準で採用しており、以前の記事にもあったように 4.3 では複数の端末でデバッグできないという状況になっている点です。

早速 hello-jni サンプルを用いて、デバッグ接続がうまくできるか確認してみます。
Java側でブレークポイント設定しておいて、そのときに ndk-gdb を起動させてみたのがこちらになります。

xperia-z1comact-1

予想に反して、うまくndk-gdb 接続できており、ネイティブデバッグが使用可能でした。gdbコマンドを実行してブレークポイントを設定して、そのときのコールスタック情報を確認することもできました。

xperia-z1comact-2

一応、/proc の下を確認してみたいと思います。前回と同様に調査してみます。

u0_a210   16498 398   859000 20328 ffffffff 00000000 S com.example.hellojni
u0_a210   17151 10691 592    316   ffffffff 00000000 S lib/gdbserver
shell@D5503:/ $ run-as com.example.hellojni
run-as com.example.hellojni
shell@D5503:/data/data/com.example.hellojni $ cd /proc/16498
cd /proc/16498
shell@D5503:/proc/16498 $ ls -l
ls -l
dr-xr-xr-x u0_a210  u0_a210           2014-03-15 13:00 attr
-r-------- u0_a210  u0_a210         0 2014-03-15 12:41 auxv
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 cgroup
--w------- u0_a210  u0_a210         0 2014-03-15 13:00 clear_refs
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 12:40 cmdline
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 comm
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 coredump_filter
lrwxrwxrwx u0_a210  u0_a210           2014-03-15 13:00 cwd -> /
-r-------- u0_a210  u0_a210         0 2014-03-15 13:00 environ
lrwxrwxrwx u0_a210  u0_a210           2014-03-15 12:41 exe -> /system/bin/app_process
dr-x------ u0_a210  u0_a210           2014-03-15 13:00 fd
dr-x------ u0_a210  u0_a210           2014-03-15 13:00 fdinfo
-r-------- u0_a210  u0_a210         0 2014-03-15 13:00 io
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 limits
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 loginuid
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 maps
-rw------- u0_a210  u0_a210         0 2014-03-15 12:41 mem
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 mountinfo
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 mounts
-r-------- u0_a210  u0_a210         0 2014-03-15 13:00 mountstats
dr-xr-xr-x u0_a210  u0_a210           2014-03-15 13:00 net
dr-x--x--x u0_a210  u0_a210           2014-03-15 13:00 ns
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 12:40 oom_adj
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 oom_score
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 oom_score_adj
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 pagemap
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 personality
lrwxrwxrwx u0_a210  u0_a210           2014-03-15 13:00 root -> /
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 sched
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 schedstat
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 sessionid
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 smaps
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 stack
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 12:40 stat
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 statm
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 status
dr-xr-xr-x u0_a210  u0_a210           2014-03-15 12:40 task
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:00 wchan
shell@D5503:/proc/16498 $
shell@D5503:/proc $ cd ../17151
cd 17151
shell@D5503:/proc/17151 $ ls -l
ls -l
dr-xr-xr-x u0_a210  u0_a210           2014-03-15 13:06 attr
-r-------- u0_a210  u0_a210         0 2014-03-15 13:06 auxv
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 cgroup
--w------- u0_a210  u0_a210         0 2014-03-15 13:06 clear_refs
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 12:41 cmdline
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 comm
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 coredump_filter
lrwxrwxrwx u0_a210  u0_a210           2014-03-15 13:06 cwd -> /data/data/com.example.hellojni
-r-------- u0_a210  u0_a210         0 2014-03-15 13:06 environ
lrwxrwxrwx u0_a210  u0_a210           2014-03-15 13:06 exe -> /data/app-lib/com.example.hellojni-2/gdbserver
dr-x------ u0_a210  u0_a210           2014-03-15 13:06 fd
dr-x------ u0_a210  u0_a210           2014-03-15 13:06 fdinfo
-r-------- u0_a210  u0_a210         0 2014-03-15 13:06 io
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 limits
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 loginuid
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 maps
-rw------- u0_a210  u0_a210         0 2014-03-15 13:06 mem
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 mountinfo
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 mounts
-r-------- u0_a210  u0_a210         0 2014-03-15 13:06 mountstats
dr-xr-xr-x u0_a210  u0_a210           2014-03-15 13:06 net
dr-x--x--x u0_a210  u0_a210           2014-03-15 13:06 ns
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 12:41 oom_adj
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 oom_score
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 oom_score_adj
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 pagemap
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 personality
lrwxrwxrwx u0_a210  u0_a210           2014-03-15 13:06 root -> /
-rw-r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 sched
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 schedstat
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 sessionid
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 smaps
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 stack
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 12:41 stat
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 statm
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 status
dr-xr-xr-x u0_a210  u0_a210           2014-03-15 12:41 task
-r--r--r-- u0_a210  u0_a210         0 2014-03-15 13:06 wchan

正常なパーミッションとなっていることが確認できました。
当然この maps を確認してみると・・・(一部抜粋)

shell@D5503:/proc/16498 $ cat maps

70d6a000-70d6d000 r-xp 00000000 b3:19 292071     /data/app-lib/com.example.hellojni-2/libhello-jni.so
70d6d000-70d6e000 r--p 00002000 b3:19 292071     /data/app-lib/com.example.hellojni-2/libhello-jni.so
70d6e000-70d6f000 rw-p 00003000 b3:19 292071     /data/app-lib/com.example.hellojni-2/libhello-jni.so

shell@D5503:/proc/17151 $ cat maps
cat maps
00008000-00046000 r-xp 00000000 b3:19 292072     /data/app-lib/com.example.hellojni-2/gdbserver
00047000-00049000 rw-p 0003e000 b3:19 292072     /data/app-lib/com.example.hellojni-2/gdbserver
00049000-0004d000 rw-p 00000000 00:00 0
00966000-0097a000 rw-p 00000000 00:00 0          [heap]
b6f57000-b6f58000 r--p 00000000 00:00 0
b6f58000-b6f70000 r--s 00000000 00:0c 6131       /dev/__properties__

このようになっており、自身のsoの情報も確認できました。どおりで正常にデバッグできる訳です。

Android 4.3 搭載で初めてネイティブデバッグ(ndk-gdb)が動く端末に出逢いました。運がよかったと思います。


Xperia Z1fというかZ1Compact 到着


愛用していた GalaxyS2 もそろそろ限界を感じ始めたので、とうとう XPERIA X1f に乗り換えてみることにしました。今回もまたグローバルモデルを購入したので、Z1f は海外版では Z1 Compact という名称となっておりこちらを購入しました。

ちなみに限界を感じ始めた、というのはあくまで開発者視点で、という意味で、単にメールやブラウザといった日常用途では全然問題は無いです。OpenGL ES 3.0 や豊富なGL拡張、クアッドコア、といった点で使ってみたい!と思っている自分にとっては、ということなので一般ユーザーはまだまだS2で十分かもしれません。

早速 XPERIA Z1Compact について環境セットアップなどしてみました。
まず搭載されているAndroidのバージョンは 4.3 でした。
また変な言語ロケールでしたが、日本語も選ぶことができたのでこの点は問題ないようです。Android 4から国際版でも日本語が入るようになった、とか聞いたような。

開発者モードを有効にすべく、ビルドバージョンを連続タップして、開発者向けオプションを出現させます。
その後 USB デバッグを有効にしておきます。

adbで接続するために、ドライバのinfを書き換えておきます。
手元の端末では下記のような記述を android_winusb.infに追加して、ドライバインストールを行いました。

;SONY XPERIA Z1 Compact
%SingleAdbInterface%        = USB_Install, USB\VID_0FCE&PID_51A7
%CompositeAdbInterface%     = USB_Install, USB\VID_0FCE&PID_51A7&MI_01

ここまでは割と一般的な内容ですが、一応VID,PIDなど inf をさらしてみました。

次回は開発者用としてどこまで動くか?を調べてみたいと思います。


Galaxy S4 (GT-I9505)に Kitkat をいれてみた


以前 Android 4.3 (JB) を入れてしまった Galaxy S4 でデバッグができない!と嘆いていましたが、最近 KitKat (4.4) のファームウェアが公開されたのでこれを導入してみることにしました。

4.3が入った状態のものについて、もう少し状況を説明しておきます。工場出荷状態では 4.2 だったようですが、これを 4.3へと上げてしまったところ、ダウングレードできない状態となっていました。また、ダウンロードモードに入ったときでも、”Write Protection: Enable” という表示が出るようになってしまい、ネイティブデバッグを必要とするような状況で開発機として使うには向かない状態となっていました。

KitKat のインストール

先に結果ですが、バージョンアップは成功しました。その結果 Kitkat(4.4.2)がインストール成功しました(Write Protection: Enableと表示されている状況のまま更新はできた)。
かるく作業の流れを書いておきますが、詳しくは検索してもっと親切なサイトをみたほうがよいと思います・・・。

使用したのは odin 3.09 です。また使用したファームは、I9505XXUFNB8_I9505OXAFNB8_DBT.zip です。
このzipを展開して I9505XXUFNB8_I9505OXAFNB8_I9505XXUFNB8_HOME.tar.md5 というファイルができあがるので、これをodinの AP ボタンを押してファイル選択しておきます。

Galaxy S4をダウンロードモードにして PCに接続してデバイスマネージャーから確認しておきます。?マークが出ていたりしてデバイスが正常に認識できていない場合、ファームの更新は行えないので対象となるUSBドライバをインストールして認識できるようにしておきます。(SAMSUNG USB Driver for MobilePhones というものがあるので).
adbが使えるようになっているからこのドライバも適用済み、とは限らないので開発者であってもドライバインストールすることになる可能性があります。

うまくいくと、odin3 の画面で COM:** というような表記で認識していることがわかります。これが出ていない場合認識されていないので認識できるように設定して下さい。

認識できていればあとはSTARTボタンを押して、しばらく放置します。
うまくいくと書き込み終了後にはデバイスがリブートして、新システムで起動してきます。

書き込み成功したときには odin はこんな感じで表示されています。

odin3-kitkat

また起動後の Galaxy S4 のほうでのOSバージョン確認画面ではこんな感じです。

galaxy-s4-kitkat

ndk-gdb の動作確認

hello-jni のサンプルを起動させて ndk-gdb-py にて接続してみたときを前回と同様に確認してみます。

$ adb shell
$ run-as com.example.hellojni
$ ls -l
ls -l
drwxrwx--x u0_a202  u0_a202           2013-01-10 21:12 cache
srwxrwxrwx u0_a202  u0_a202           2014-03-08 21:05 debug-socket
lrwxrwxrwx install  install           2014-03-08 19:09 lib -> /data/app-lib/com.
example.hellojni-1

$ ls -l /proc/19315  # gdbserverのPIDが 19315 だったので.
dr-xr-xr-x u0_a202  u0_a202           2014-03-08 21:10 attr
-r-------- u0_a202  u0_a202         0 2014-03-08 21:10 auxv
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 cgroup
--w------- u0_a202  u0_a202         0 2014-03-08 21:10 clear_refs
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:05 cmdline
-rw-r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 comm
-rw-r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 coredump_filter
lrwxrwxrwx u0_a202  u0_a202           2014-03-08 21:10 cwd -> /data/data/com.exa
mple.hellojni
-r-------- u0_a202  u0_a202         0 2014-03-08 21:10 environ
lrwxrwxrwx u0_a202  u0_a202           2014-03-08 21:10 exe -> /data/app-lib/com.
example.hellojni-1/gdbserver
dr-x------ u0_a202  u0_a202           2014-03-08 21:10 fd
dr-x------ u0_a202  u0_a202           2014-03-08 21:10 fdinfo
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 limits
-rw-r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 loginuid
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 maps
-rw------- u0_a202  u0_a202         0 2014-03-08 21:10 mem
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 mountinfo
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 mounts
-r-------- u0_a202  u0_a202         0 2014-03-08 21:10 mountstats
dr-xr-xr-x u0_a202  u0_a202           2014-03-08 21:10 net
dr-x--x--x u0_a202  u0_a202           2014-03-08 21:10 ns
-rw-r--r-- u0_a202  u0_a202         0 2014-03-08 21:05 oom_adj
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 oom_score
-rw-r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 oom_score_adj
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 pagemap
-r--r--r-- u0_a202  u0_a202         0 2014-03-08 21:10 personality
lrwxrwxrwx u0_a202  u0_a202           2014-03-08 21:10 root -> /

以前の4.3の時と比べてうまくパーミッションの設定ができているようです。
これなら ndk-gdb の接続がうまくいくのも納得です。
(記事中では書いていませんが、ちゃんとブレークポイントを設定できることも確認してみました)。

まとめ

無事にネイティブデバッグができる端末として復活できた Galaxy S4 で、一安心です。4.3バージョンでは色々と問題があちこちで起こっているようなので、どの端末も 4.4 が使えるようになるといいなと思います。
また、この S4 ですが実は友人のもので、快くfirmwareの更新を許可してくれたことにとても感謝しています。



最近のAndroid開発環境(NDK r9b)の構築


最近NDKのほうも更新が進んで r9b が出ているようです。
以前の状況と結構変わっているようなので再度セットアップしてみました。

googleからダウンロードしたら、前回ADT bundleのeclipseの場所に展開します。
sdkフォルダがあるところに、android-ndk-r9b として展開します。
そして、環境変数 NDKROOT を作成し、この場所をセットしておきます。
環境変数 PATH に、このパスを追加しておきます。
ユーザー環境変数PATHが存在しなければ、作成して%NDKROOT% と入力しておきます。

env-ndk-root

そして、eclipseを起動して、Window/Preferences を開いて、Android/NDK の項目を開きます。
ここに NDK Location とあるので、先ほどNDKを展開したパスを設定します。

ひとまず設定はこれでOKです。
続いてサンプルの動作を確認してみようと思います。

サンプルの動作確認

NDKの中にはsampleが入っているので、これをeclipseで読み込ませて、ビルド&実行をしてみたいとおもいます。実行できる環境(エミュレーターやデバイス)を準備しておいて下さい。

メニューFile/New/Otherを選び、Android Project from Existing Code を選びます。そしてNDKに含まれているsampleを指定します。ここでは定番のhello-jni サンプルを指定したとします。
Projects でtestsは今不要ということでアプリ本体だけ使うので、こちらだけにチェックを入れてプロジェクトを作成します。
また、自分はNDK展開先フォルダが汚れるのがいやなので、対象をコピーするように設定しました。これが Copy projects into workspace にチェックが入っている理由です。

import-project-ndk

これでプロジェクトを作成し、Java パースペクティブで開くとこのようになります。

hello-jni

コマンドプロンプトでこのプロジェクトのフォルダを開きます。上記の通りにインポート時にコピーしていれば自分のWorkspaceフォルダの中に HelloJni フォルダができていることとと思います。ここをコマンドプロンプトで開きます。
そして、ndk-build とタイプして実行します。これでC/C++コードのコンパイル&リンクが実行されます。
うまくいかない場合には、環境変数 NDKROOTやPathに設定したものを確認して下さい。また、コマンドプロンプトをスタートメニューから開きなおしてみて下さい.
ndk-build-result

そして、Eclipseで F5(Refresh)を押すと、HelloJniの中に obj,libsの項目が増えています。これを開いてみると、libhello-jni.so ができていることがこちらでも確認できます。

実行するには、プロジェクトを右クリックして Run As/Android Applicationを選びます。

・・・

しかし、現在の状態ではこんなエラーが発生しました。

Unable to execute dex: java.nio.BufferOverflowException.
 Check the Eclipse log for stack trace.
Conversion to Dalvik format failed: Unable to execute dex:
 java.nio.BufferOverflowException. Check the Eclipse log for stack trace.

どうやら最新のSDKパッケージだとこのエラーが出るようです。
Android SDK Build-tools Rev 19でエラーが出るようで、これを 18.1.1 あたりに戻すことで回避できるとのことです。Android SDK Managerを開いて、18.1.1をインストールし、19を削除しておきます。

再度 Eclipseでメニューから Project/Cleanを実行します。
そして、Run As/Android Application で実行を行います。まだダメなようならばeclipseを一度終了し、再度eclipseを起動してリトライしてみて下さい。

自分の環境ではこれでHello-Jniが実機上で動作するところを確認しています。


Androidネイティブデバッグ再び


Nsight Tegraがあまりに強力だったので、逆に標準のndk-gdbではどこまで出来るのだろうとテストしてみることにしました。

以前にLinux(Ubuntsu)環境でAndroid開発用の環境を作った記事(ここ)がありました。この環境を使ってテストしてみます。
当時はNDK r8bを使用していましたが、あれから結構時間も経ったので進化している部分もあると思い、現在の最新 NDK r8e を用いてみることにしました。

以前でもブレークポイントはひとまず張れること、変数がみれることは確認していました。
そこで Nsightで出来たことが ndk-gdb では出来るかという点で見てみたいと思います。

Jni Proxyタイプのアプリケーションで、ネイティブアプリ側にブレークポイントを指定できるか?

いきなり一番難しいケースにトライしてみます。これが出来ればかなり優秀かと。
以前はコツがあったのですが、今回はそれ無しでいきなりブレークポイント指定してみます。

ソースコードは先日のものを使用し、ネイティブアプリ側のapp_init関数にブレークポイントを指定してみます。
Java側でjniInitを呼ぶ直前でブレークポイントを設定してデバッグ実行し、停止した後で ndk-gdb を起動してみます。
このあたりはいつもの手順となっています。

ndk-gdbを起動した後で、ブレークポイントを指定しますが、このときネイティブアプリ側のsoがまだロードされていません。そのためロードされたときにブレークポイントが指定されるよう、pendingの問い合わせについては “y” を答えてあります。

この後、”c” で実行を継続し、Java側でも実行継続させて、ブレークポイントで停止するかどうかを見てみたいと思います。

・・・

無事に停止しました!!!以前はそれなりに大変だったのになかなかやるじゃないか ndk-gdb

メモリの表示と変数の表示について

JniProxyタイプのデバッグがNsight Tegraで出来たことで最強と思っていたので、ndk-gdbが出来るとは思っていませんでした。
なかなかやりおるのでコード追加して、前回NVIDIA Nsight Tegraで確認したメモリ表示や変数の表示についてチェックしてみたいと思います。

1つめのforが終わったところで v の中身やメモリ番地の中身を覗いて見た図。無事に変数やその確保したメモリの周辺状況を見ることが出来ています。

続いて、Nsight Tegraで出来なかった動的確保配列の中身表示と条件付きブレークポイント。
以下のように、うまく動作していることがわかります。
(条件付きで止まったことを確認するため、i の値を最後に確認してます)

逆アセンブルも出してみる。

gdbなのでコマンドを叩く手間はありますが、うまく動いているようです。
ここまで動いていたので、いざeclipseでソースコード見ながらステップ実行、としてみました。
ただ若干不安定で関数のステップインの挙動が怪しい状態でした。ndk-gdb直接触っていたらうまく動くのに。
機能的にはgdbが備えていてもそれをユーザーフレンドリーに操作する部分はまだまだのようです。

そういえば、ADTの新しい物は NDKのデバッグもサポートしたとか話があったので、最新状態で環境構築して再度トライしたらこの問題解決していたりしないかな~とおもっている次第です。


NVIDIA Nsight Tegra がすごい その5


あれからもうちょっとだけ、Nsight Tegra を触ってみました。
今回はデバッグによく使うであろう機能についてチェックしてみます。

ブレークポイントが張れて停止するのは今までにしっかりと確認してきました。
今回は、条件付きブレークポイントやメモリ領域の表示、使い慣れたVisualStudioでの変数表示形式指定などを見てみたいと思います。

早速下記のコードを書いてチェックしてみました。

まずメモリ領域の表示について。これは v を確保したときに、メモリウィンドウで表示させてみました。

メモリの表示はうまく動いているようです。
しかし、ウォッチウィンドウでポインタを要素数指定して配列のように表示する機能については、うまく機能しないようです。
画像では、”v,10″としていますが、配列表示できていないことがわかります。

続いて条件付きブレークポイント。
2つめのforの中で、i == 6 の時にブレークするようにして実行してみました。
このときは以下の画像のような結果となり、条件で停止してくれませんでした。

Visual Studioのデバッガを深く慣れていて機能を使いこなしている人にとっては、ちょっと不満が残りそうです。
その一方で、単純にブレーク設定できればいいという人にとっては十分役立ってくれそうです。

gdb を直接触るタイプ(ndk-gdb)との差が付いてきてしまったように感じました。
そこでそろそろndk-gdbでは今現在どのくらい使い物になるのか、確かめてみたいと思います。