Android一覧

XPERIA Z1 Compact の初期イメージ取得&リストアについて

Z1 Compact を用いて初期イメージの取得&リストアをやってみました。
自分が辿った記録を残しておきますが、この手順は推奨するものではありません。同じようにやる方も自己責任において作業するようにしてください。
起動しなくなったとか破壊されてしまったとか、そういった症状が出てしまっても当方は一切の責任を負いません。

初期ロムイメージの取得&作成

色々と実験するまえには、初期イメージを取得&作成しておき、いざというときに元に戻せるように準備しておきます。これらには以下のソフトウェアを使用します。

  • Sony Mobile Update Service
  • FlashTool

Sony Mobile Update Service のインストール

http://www.sonymobile.co.jp/support/software/updateservice/
ここから Sony Mobile Update Service と呼ばれるソフトウェアをダウンロードして、インストールします。「Xperia SO-01BおよびスマートワイヤレスステレオヘッドセットMW1用」とかありますが、気にせずにインストールします。

sony-update-service-1

以下の画面が現れたら、Z1f を選択します。
最近ダウンロードしたものだと Z2 すら候補にでているようです。

sony-update-service-2

画面の指示に従い、XPERIA Z1f を操作してPCに接続します。
(ボリュームダウンのボタンを押しつつ、PCと接続するらしい)

接続後、同意するにチェックを入れて続行します。

sony-update-service-3

sony-update-service-4
インストールしたフォルダ内を確認してみます。

(インストールした場所)\Sony Mobile\Update Service\db\13740270\blob_fs
このフォルダの中に、FILE_**** というファイルが存在していると思います。
これらを適当な場所にコピーしておきます。

自分の場合には、以下の4つのファイルができていました。

  • FILE_279914849
  • FILE_280597449
  • FILE_280611813
  • FILE_280734528

FlashToolのインストール

http://www.flashtool.net/index.php
ここから、FlashTool をダウンロードします。
試したバージョンは、 flashtool-0.9.14.0-windows.exe です。
FlashToolを起動して、 メニューの Tools/SEUS Decrypt を選択します。
なお起動する際には、32bit/64bitで実行体が違うようなので環境にあった物を起動してください。

flashtool-1

メニュー選択後には、先ほどの FILE_**** をコピーしたフォルダを選択するウィンドウが表示されます。
ファイル項目が出てくると思いますので、これを全て右側に移して、convertボタンを押します。ここでしばらく時間がかかることがあります。

ファイルの解析が終わるとファイル選択の画面が出てきます。
ここで、 Branding, Version の部分に任意の文字列を入力します。
Deviceの部分はダブルクリックすると候補を選べるようになっています。

まず左側に出ているファイル名を全て右側に移します。
その後、下記に示す一部のファイルを除外(左側へ戻す)します。

  • partition-image.sin
  • simlock.ta (存在すれば)

ここまでの作業をやった結果の状態は以下のような感じになります。

flashtool-2

そして、Createボタンを押します。
しばらく待っているとログの中で Bundle creation finished と表示されると思います。
これが出たら完了です。
FlashToolのインストールフォルダの中に firmwares というフォルダがあり、この中にftf というファイルができているかと思います。
自分の環境では、以下のファイルができあがっていました。

  • D5503_14.2.A.1.114_unbrand.ftf
  • D5503_14.2.A.1.114_unbrand.ftf.torrent
  • X10_V1_BLRelock.ftf

・・・おそらく torrent ファイルは不要だと思います。

ここまでの作業で、初期ファームウェアのイメージファイルが完成です。

リストアの確認

よくバックアップだけ取得して、リストアの確認をしなかったりします。
リストアの処理まで確認できてようやく意味あるバックアップとなるので、ここで確認しておきます。

FlashTool を起動します。
起動後、稲妻のアイコンをクリックします。
続いて、Flashmode を選択します。

flashtool-3

うまくいっていれば Firmware の項目で先ほど入力したものが並んでいると思います。
ここでは D5503 デバイスを選択して、Wipe 項目全てにチェックを入れてリストアを行ってみます。

flashtool-4

Flashボタンを押します。ちょっと準備に時間がかかるようです。
準備ができると以下のような画面になるので、電源をOFFにした状態のデバイスを
ボリュームダウンボタンを押しながら、microUSBを接続します。

flashtool-5

データ復旧(リストア)作業中は以下のような感じです。
緑のバーが右側に到達し、Flashing finished と表示されれば処理完了です。

flashtool-6

最後に、端末の電源を入れて正常に起動するかを確認して作業完了です。
これでいざというときに、元に戻す準備が整いました。

参考

これらの作業を行う際には、下記のサイトを参考にさせてもらいました。
http://blog.redbox.ne.jp/xperia-z1f-so-02f-root.html


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では今現在どのくらい使い物になるのか、確かめてみたいと思います。


NVIDIA Nsight Tegra がすごい その4

前回、JniProxyタイプではうまくいかないです~の続きです。

動作させるためには、JavaJniAppのパッケージ(APK)に libNativeAppMain.so を含められればそれで完了です。
これをどうやって行うかですが、強引には以下の手順で実現することが可能です。

  • NativeAppMainをビルド。soファイルが出来る
  • JavaJniAppのビルド1。まず libJavaJniApp.soが作成される
  • JavaJniAppのビルド2。Java部分のコンパイルが実行される

上記のJavaJniAppのビルド1 or 2のタイミングで NativeAppMainの so ファイルを JavaJniApp/libs/armeabi-v7a の中にコピーしてあげればよいです。

成功すれば Apkファイルの中に libNativeAppMain.so が入っています。

一度実行してログを確認してみます。(起動後、戻るボタンでホームに戻るという操作を行っています)
うまく動いていればこのようにログが出ているはずです。

この時に、アプリケーション本体である nativeappmain.c の各関数にブレークポイントを仕掛けて、同じように実行してみます。
下記のスクリーンショットに示すように、ちゃんとブレークポイントが有効となって停止します!すばらしい。

タイミングコピーの自動化を狙う

先ほどの、手動でlibNativeAppMain.soを強引にタイミングを見計らってコピーするという方法はちょっと手間です。
タイミング失敗によるとまたビルドし直しになるし、ここは何とかして自動で解決するようにしたいです。

Nsight Tegra は、どうやら vs-android をも取り込んでいるようです。vs-androidではAntを使用していましたし、よくよく動作を見るとビルドのタスクをこなしているのはAntのようです。
ということは Ant の設定やスクリプトを変更すれば、この自動化も出来そうな気がします。

そこで build.xml の中身を覗いてみると、以下のようになっており、どうやらカスタマイズの余地がありそうです。

まずは JavaJniApp の build.xmlと同じ場所で custom_rules.xml を作成して、中身を以下のように設定します。

そうして、ビルドを実行してみると、以下のように上記の設定が実行されたことが確認できます。

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を準備すると幸せになれると感じました。