Android一覧

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


NVIDIA Nsight Tegra がすごい その3

今回はNDKの開発で、割と使われるJNIProxyという手法で Nshight Tegra のデバッグブレーク機能は有効になるか?を確かめてみたいと思います。

このJniProxyという方法は、Android上ではアプリケーションの実行体イメージがメモリ上にまだ存在する場合、再利用してアプリケーションが動く、という挙動に対して解決する方法の1種です。
C/C++ネイティブ開発者の間では、.so 内のグローバル変数が初期化されずにアプリケーションが起動したように見えます。

詳しくはこちら(ホイール欲しい ハンドル欲しい: Android NDKの初期化とdllの分離)で説明されている内容です。

Java – JniProxy.so — Application.so というように、
JavaからはJniProxy.soを操作し、JniProxyが本当の意味のアプリであるApplication.soをロード・アンロードします。

Nsight Tegraを導入した Visual Studioでこのようなプロジェクトを作成するには、前回説明した複数のライブラリを用いて .so を作成するという方法に近い物があります。1点違う点があるのは、両者が so となっている点です。まずは、2つのプロジェクトを作成して、今回の概観を作ってみます。

  • NativeAppMain (ネイティブアプリケーションの本体)
  • JavaJniApp (JniProxy.soをもつJavaアプリケーション)

プロジェクトのタイプは、JavaJniApp は Android Application With Native Code で作成し、
NativeAppMainは Android Native Application で作成します。
これらをまとめるソリューションは testJniProxy として作成しました。

作成して、とりあえず必要なファイル名を変更したものが以下のようになります。

続いてプロジェクトの設定を変更します。
NativeAppMain は今回は .so 形式となるので Configuration Type を Dynamic Library(*.so)に変更します。
また JavaJniApp は NativeAppMain に依存するようにしておきます。
そして、JavaJniAppのプロジェクトの設定では、ライブラリ dl を使用するように変更しておきます( -l”dl” を追加のライブラリに入れる)

ここまで設定できたら、各ソースコードを編集します。
ほぼ上記で紹介したサイトのコードのままなのですが以下のようになります。
まずは動作確認の意味もかねて、onCreateでロードして、onPauseで終了が呼ばれるだけの単純なものにしてあります。

JniProxy.cpp

JavaAppMain.java

NativeAppMain.c

ここまででとりあえず必要な物はそろってはいるのですが、このまま実行するとNativeAppMainのロードが実は出来ません。
その理由は、NativeAppMain.so が JavaJniApp の apk の中に取り込まれないからです。
ちなみに libNativeAppMain.so は ソリューション以下の Android/Debug の中に存在はしているのですが、
今回のケースでは取り込まれないんですよね・・・。
VisualStudioのビルド前後のイベントを使用しても、取り込まれるようには設定できませんでした。

(解決策は次回へ続く。)


NVIDIA Nsight Tegra がすごい その2

NVIDIA Nsight Tegra 検証の第2弾です。
前回はほぼデフォルトで作成される状態のサンプルプログラムを実行させての動作確認だったので、今回はもう少し実際にあり得るケースで正常にデバッグが出来るのか、を試してみたいと思います。

今回のケース想定

 

2つのスタティックライブラリを使用して、.so を作成し、Javaから利用する。
要は libXXXX.a を複数リンクして、アプリケーション本体となる.soを作成、Javaはその呼出までの役割に過ぎない、というケースです。
ほぼ定番のケースだと思います。これで実用になるのか、試してみたいと思います。

こんなフォルダ構成で作成します。AppMainは Java+Native の「Android Application with Native code」タイプで作成します。

NVIDIA Nsightでスタティックライブラリ用プロジェクトはどう作成するか、ここが問題です。
現時点では、ウィザード等では設定できないようだったので、やや強引ですが既存のプロジェクトタイプで作成した後、設定を変更して対応することにします。

スタティックライブラリ用プロジェクトの作成方法

 

最初のプロジェクト作成で 「Android Native Application」を選択します。これはNativeActivity用の設定ですが、
ファイルの削除と設定変更だけで割と簡単にネイティブのスタティックライブラリ用に出来るので利用させて貰うことにします。

パッケージ名を聞かれますが、スタティックライブラリには不要なので適当に入力しておきます(例:org.aaa)。
プロジェクトが作成できたら、下記画面の通り、native_app_glue 関連のコードを削除し、デフォルトで作成される main.c の名前を変更しておきます。また、main.c の中身も全部削除して、動作検証用のコードにしておきます。
すでに既存のソースコードを持っているなら、main.cを削除して、それを登録しておくのでも問題ないでしょう。

そして、出力するタイプを “Make Application” から ”Static Libaray(.a)” に変更します。

ここまでの作業を同じように繰り返して、lib2を作成します。

lib1のソースコード内容例

lib2のソースコード内容例

続いて、「Android Application with Native Code」タイプで AppMain を作成します。
AppMain.java の onCreateメソッド内で、既に作成されている appmainNative() を呼び出すようにしておきます。
その後、AppMainのネイティブコード部分(AppMain.c)で、今用意したlib1,lib2の関数を呼出して、ブレークポイントがはれるかを確認してみます。
作成したら、AppMainのプロジェクトをスタートアッププロジェクトに指定しておきます。

AppMain.cのコード内容例

コードを作成したら、プロジェクトの設定を開いてで liblib1.a と liblib2.a をリンクするように修正します。
今回のフォルダ構成では、testTwoLibsフォルダ以下に Android/Debug というフォルダが作成され、この中に .a のファイルが出力されるようになっています。
“構成プロパティ” / Linker / Additional Library Directories の部分にこのフォルダを指定します。

そして、リンクするライブラリの指定は、“構成プロパティ” / Linker / Additional Dependencies の部分に指定します。
このときに、従来のVCではライブラリファイル名を設定していましたが、Nsight Tegraの場合では、-l”(ライブラリ名)” と指定するようです。(このやり方がわかる以前は、CommandLineで直接設定してました・・・)
うまくいかない場合には、CommandLineで直接指定するなどで対処できそうです。
gcc環境であることもポイントで、ライブラリファイル名が、libhoge.a の場合、上記のライブラリ名では hoge と指定する点に注意してください。

今回の例では、-l”lib1″ -l”lib2″を指定しておきます。

続いて、ブレークポイントを下記のように設定しておきます。今までの経験から Java – C の接続部である上記のコードにブレークポイントが張れて機能することはわかっているので、次の2点を確認したいと思います。

  • 外部ライブラリへのステップインは出来るか?
  • 直接外部ライブラリのブレークポイント設定は有効になるか?

ここで、外部ライブラリとは AppMain.so が利用している .a のファイルを指しています。

実行して、上記の1つめのブレークポイントで停止した後は、ステップインで lib1 のソースコード内へ突入できるかを確認してみます。

F5で実行して、mylib1Test関数にステップイン(F11)してみると、下記のように正常にステップインできました。

さらにこの後、F5で実行を継続させて様子を見ていると、下記のように正常に lib2 の関数内でブレーク発動できました。

まとめ

複数のスタティックライブラリを使って、soファイルを生成するタイプのアプリケーション開発では、今回試した内容からほぼストレス無く開発が出来るのでは無いかと思います。
また、記事で詳細に触れてはいないですが、lib1,lib2をソリューションから除外して、AppMainだけをリビルドして同様のことを試してみたところ、こちらも正常に関数内へステップインできました。
Nsight Tegraの出来の良さに感激です。

気になった点とか躓いた点とか

上記のテストで、アプリケーションが起動できない、妙な動きをするような場合は以下の点を確認してみてください。
自分でも陥ったポイントです。他にも発見&解決できた人は是非コメントくださいませ。

アプリケーションが起動できない(onCreate以降すすまないっぽい)
純粋にApplication with Native Code のプロジェクトを作成して、それが起動できるかどうかを確認。うまくいけばそれ以降の部分で問題があることになります。この後確認するのは lib1, lib2 が 正しく .a を出力する設定になっているかどうか、です。
自分の場合には、変更することを忘れて、ここを .so のままにしていたことがありました。このとき問題発生でアプリケーション終了という流れで、すごく悩みました。

他には、スタートアッププロジェクトをlib1やlib2のままになっていないかを確認。元々がNativeActivity用のプロジェクトを流用しているので、実は実行させようとすればできちゃうようで・・・。


NVIDIA Nsight Tegra がすごい

NVIDIA Nsight Tegra を導入してみました。これは Tegra Android Development Pack に含まれています。
これが結構便利で、Android のNDK開発では個人的には最有力候補になると思っています。
一昨年くらいの TADP は個人的にはマイナス評価で検証後見送ったのですが、今回は多少のデメリットがあってもこれを選択したい勢いです。

さて入手には登録を必要とするのですが、ちょっとややこしい感じだったので、まずはそれについて説明しておきます。
NVIDIAのDeveloper Programに登録し、ログインを行います。
そして、Tegra Registered Developer Program と Nsight Visual Studio Edition Registered Developer Program の2つを有効化します(ApprovedステータスになっていればOK)。
注意するのはさらに、有効化されたよメールが手元にくるまで、実際には有効化されていないということです。
このメールがくるまでしばらく待ちましょう。

Tegra Android Development Packは今現在 2.0 で、ダウンロードできた物は 2013-02-06 リリースのもののようです。
これをインストールすると Nsight Tegra もインストールされました。

Nsight Tegra は Visual Studio 2010 SP1 に統合され、対象とするAndroidのバージョンは 4.0以降に対応するようです。
先日のICONIA Tab A500 をICSアップデートの真の目的はこのためだったのです!

Nsight Tegra で出来ること

 

Visual Studio 2010 上で、JavaもC(ネイティブ)も同時に開発可能です。
そしてすごいのはビルドはもちろんのこと、待望のデバッグも可能となっています。今まではEclipseで何とかがんばっていたソースコードデバッグも、これだけで可能になります。Javaの部分ですらブレークポイントが設定できます。そしてデバッグ出力ウィンドウで、”Android Logcat”を選択すれば、ログの確認もVisual Studioで行えます。
ただ、Visual Studio だから仕方の無いことなのかもしれませんが、Javaに対するサポートは弱いようで、インテリセンスが効きませんでした。

インストールして試してみる

 

まずはプロジェクトを新規作成して出来るテンプレで設定および動作の確認をしてみます。
ここでは、Java+Nativeの構成をとれる Android Application with Native Code を選択します。プロジェクトの作成する場所は、スペースを含まないパスにする必要があるようなので、この点にだけ注意します。

続いて、パッケージ名を指定します。

logcatの出力をVisual Studioで確認出来るように有効化します。有効化した後は、出力ウィンドウで 「Android Logcat」 が選べるようになります。

最後に、プロジェクトの設定を開き、Javaもネイティブも両方ともデバッグブレークできるように設定を変更します。

これでひとまずの設定は完了です。

動作を確認するために、Java部分とC言語部分をちょっとコードを変更しておきます。
また、コードを編集した後には、ブレークポイントを仕掛けておきます。

C言語部分

それぞれにブレークポイントを仕掛けて、いつも通り F5 を押してデバッグ実行させてみます。もちろん、対象となるデバイスをUSBで接続しておいてください。

実行開始状態の図。ちょっと時間がかかるようです。

そして、実行後ブレークポイントで停止している図。

まとめ

このNsight TegraはAndroid開発、特にネイティブに重点を置いて開発する場合には、現時点では最強を狙える拡張だと思います。もうしばらく試用&検証してみてどのくらいのポテンシャルを秘めているか、探ってみたいと思います。WinGDB for Mobile Systemsが Androidのネイティブ開発で最強と思っていたのですが、なかなか製品として出てこないですね。そんな中このNVIDIA Nsight Tegra の登場は非常にうれしい限りです。

情報元: https://developer.nvidia.com/nvidia-nsight-tegra


linuxによるAndroid開発環境を整える(NDK編)

前回でNDKの手前まで環境構築が終わったので今回はNDKに関する部分の設定を行っていきます。

ネイティブ開発用の準備をする

NDKを用いるとC/C++で開発を行うことが出来ます。ここからはNDKをインストールして環境を整えていきます。

http://developer.android.com/tools/sdk/ndk/index.html からNDKのアーカイブをダウンロードします。
この記事を書いている時点では r8b というバージョンのものになります。

ダウンロードしたら、ホームディレクトリで展開しておきます。

環境変数を設定します。
.bashrcを開いて末尾に設定を追加します。今までの分もちょっとだけ整理してみて、以下のようになっています。

設定したら再読込を行っておきます。

eclipseを起動します。そして Sequoyahプラグイン群をインストールを行います。
より丁寧な解説は過去の記事を参考にお願いします。

以前のものはWindows環境で書かれているので、多少違うかもしれませんが大体は同じです。

Sequoyahプラグインのインストール

メニューの Help / Install New Softwareを選択して、Work Withの部分に、”http://download.eclipse.org/sequoyah/updates/2.0/”を入力します。
そのときに、”Group Items by category”のチェックを外しておきます。

現れたプラグインのリストを全てチェックを入れて、インストールを行います。インストール後には、eclipseの再起動が必要となります。

再起動したら、Preferences より Android のカテゴリを開き、”Native Development”を開きます。ここにNDKの展開先を入力する部分があるので、そこに先ほど展開したディレクトリを設定します。

動作チェック その1

新規にプロジェクトを作成して “Android Project from Existing Code” を選び、NDKのサンプル内に含まれているhello-jni からプロジェクトを作成します。

プロジェクトを右クリックして Android Tools/Add Native Support を選択します。
その後、Run as / Android Application で実行してみます。
うまく設定されていれば、C/C++のソースコードがコンパイルされ、Android端末上に Hello from JNI!の文字が表示されていることと思います。

ndk-gdbの設定など

続いてC/C++側に任意のブレークポイントを設定して使えるようにするための設定を行います。
まずDebug Configurationsを開きます。そこで C/C++Applicationを選択し、新規作成を行います。

作成した構成を選択し、画面中央部分の、”Using GDB(DSF) Create Process Launcher “の部分のリンクできる場所をクリックします。新しいウィンドウが開くので“Standard Create Process Launder”を選択します。

Mainタブの部分では、デバッグ対象の .so 名が表示されていますがこれをプロジェクトのパス内の obj/local/armeabi/app_processというパスに変更します。

Debuggerタブの部分では、Debuggerが gdb/mi になっているので、 gdbserver に変更します。
GDB debugger の部分には、android-ndkに入っていたgdbを選択させます。
linuxの場合、android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-gdb というファイルになります。

GDB command file の部分には後ほど作成する gdb2.setup を設定します。
これも obj/local/armeabi の中にできあがる予定となっています。

Debugger Optionsの中のConnection タブを開きます。
この中の Type を TCP に変更します。そしてPort number を 5039 に変更します。

android-ndk-r8bに含まれているndk-gdbファイルを編集します。

ファイル中で、

となっている部分を、以下のようにコメントアウトしておきます。

続いてapp_process, gdb2.setupのファイルを用意します。
まずJava側のonCreate関数でブレークポイントを設定して、デバッグ実行を行います。
このとき、ブレークポイントで停止したら、端末(Terminal)を起動します。

作業を行っているプロジェクトのディレクトリまで移動し、(jni,objディレクトリらがある場所)、そこで ndk-gdb-eclipse スクリプトを実行します。
実行後、obj/local/armeabiディレクトリに移動します。

この場所にapp_process, gdb.setupファイルが出来ていると思います。gdb.setupはコピーして中身を編集します。

gdb2.setupを開いて、末尾の “target remote :5039” を削除します。

ここまで出来たら、一度デバッグ実行を終了させておきます。

動作確認 その2

C/C++側のコードにブレークポイントを設定してみます。ここではとりあえずNewStringUTFを呼び出している部分にブレークポイントを設定します。そして以下の手順を実行します。

  1. 先ほどJava側のonCreateにブレークポイントを設定してあるので、まずここまでをデバッグ実行します。
  2. 停止したら端末で ndk-gdb-eclipse を実行します。(エラーが出るようなら –forceオプションを付けます)
  3. eclipseでDebug As/debug configurationにて、先ほど作成した構成を選択して Debugボタンを押します。先ほどはHelloJNI-NativeGDBという名前で構成を作成してあります。
  4. Java側のonCreateで停止している部分を解除し、実行を継続します。
  5. C/C++側のブレークポイントを設定してある部分でデバッガが停止することを確認します。

まとめ

ここまでの手順にてUbuntuを用いて NDK環境の C/C++ソースコードのデバッグが出来るようになりました。VMwareを用いてのLinux環境なので、Windows環境を汚さずにAndroidのネイティブ開発を行うことが出来ます。開発PCのリソースは結構高めに必要になりそうですが、開発効率という面で十分に効果を発揮してくれるものと思います。

C/C++ソースコードの警告エラー

その他、こまるようなポイントとして C/C++側のソースコードについて警告が消えてくれないことがあります。
一度ソースコードを開いてしまうとどうも駄目なようです。
そのためプロジェクトの設定で、”C/C++ General”/”Code Analysis”内のチェックボックスを全てOFFにして対処しています。
また、この後既に検知された警告エラーをDeleteで削除しています。

その後で、プロジェクトを右クリック “Clean Project”を実行し、”Build Project”を行うと、.soファイルが生成されることを確認できました。


linuxによるAndroid開発環境を整える(NDKの手前まで)

Ubuntu Desktop 12.04 LTSを使ってAndroid用の開発環境を準備してみます。

その環境ですが、実PCではなく仮想マシンに構築してみることにします。
ここでは VMware Workstation 8.0 を使用し、仮想マシンの設定はUbuntu 64bitのデフォルトで構成しています。

仮想マシンを構築したあとで、Ubuntuのディスクイメージをセットして、
“Ubuntuをインストール”を選択します。
仮想マシンなので、ディスクを全削除してインストールにしておきます。

Dashホームから”Terminal”と入力すると、”端末”アプリケーションが見つかるので、起動させます。
その後、VMwareToolsをインストールします。
(tar展開&インストールスクリプトの実行)
注意点としては、sudo ./vmware-tools-install.pl というように sudo コマンドで実行することくらいでしょうか。

今64bit Linuxを使用しているので下記のパッケージをインストールします。

AndroidSDKのインストール

Java(JDK)をまずインストールします。

javaがインストールされたことを確認します。

このような状態になっていたら大丈夫です。

Android SDKをダウンロードしてきます。
ここでは android-sdk_r20.0.3-linux.tgz というファイルで作業しています。
また他のユーザーに影響を与えないために、ホームディレクトリ以下にSDK群を配置する方法をとります。

SDK Toolsを PATH に追加します。

vi で .bashrc を開き末尾に以下の内容を追記します。

現在の環境で反映されるように、再読込させます.

Eclipseのインストール

Eclipseをインストールします。ここではちょっと前のバージョンの 3.8.1 64bit版を使用します。

このバージョンのものをダウンロードするのにちょっと手間取りました。
Eclipse Downloadsから Packages ではなく Projects を選び、その中にある”Eclipse Project”を選ぶことでようやく任意の過去のバージョンのものへアクセスできるようになります。

以下のようにしてホームディレクトリ以下にeclipseというディレクトリが出来るようにファイルを展開します。

一度eclipseが起動するかを確認しておきます。
下記コマンドではなく、ホームディレクトリ内eclipseディレクトリを開いたウィンドウからeclipseを実行してもかまいません。

起動が確認できたら終了しておきます。

ADTのインストール

eclipseを起動し、メニューから “Help / Install New Software” で ADT をインストールします。
Addボタンを押して、Nameに ADT, Locationに https://dl-ssl.google.com/android/eclipse/ を入力して、OKを押します。

すると、情報が取得されてインストール可能な一覧が出てくるので、
チェックボックスにチェックを入れてインストールを行います。
“Developer Tools”にチェックを入れるだけでOKです。最近はネイティブ用のプラグインも追加されたようです。これにチェックをいれておいてもよいでしょう。

チェックを入れたら Next ボタンを押してインストールを行っていきます。
途中でeclipseの再起動が行われます。
そのときに、新規にAndroidSDKをインストールするか、既に置いてある場所を入力するかを確認するダイアログが出てきます。

ここではUse existingSDKsを選択し、先ほどのandroid-sdk_r20.0.3-linux.tgzを展開した場所を入力します。
(例: /home//android-sdk-linux)

その後 SDK Platform Toolsが見つからない!とエラーが出てきます。
そのウィンドウに Open SDK Managerというボタンがあるのでこれをクリックして起動します。

開いたウィンドウで Android SDK Platform-tools という項目にチェックを入れておきます。
このときに開発したい対象の Androidバージョンにもチェックを入れておきます。

チェックを入れたらインストールボタンを押してインストールを行います。

(何も考えずにチェックしてインストールしてしまうとそれなりに時間がかかります、ご注意を。対象のバージョンをトップカテゴリで丸ごと選択するのではなく個別に選択しておくと多少は時間が少なくてすむかもしれません。SDKとsamplesだけをとりあえずインストールしておいて、あとで必要になったときに追加するという方法でもよいかと思います。)

端末(terminal)を開いてパスの設定を変更します。
先ほどの PATHの設定に下記の内容を追加します。

ADBの再起動

ADBを管理者権限で動かしておかないとデバイスの認識が出来ないようなので…。
下記の手順で、adbを管理者権限で起動させます。

ここでAndroid端末を接続してみます。
VMware側に接続されるようにしてください。
(VMwareウィンドウの右下にUSB用のアイコンがあるのでそれで適切に接続してください)

接続してデバイスを認識しているか表示させてみます。

一部伏せていますが、上記のように表示されればOKです。
またEclipseを再起動し、LogCatのウィンドウを開いてみると、デバイス中のログメッセージが流れていく様子を確認することが出来ます。

動作確認 その1

とりあえずここまででJavaによるAndroidの開発環境は準備できたことになるので、
うまく動作するかを確認してみます。

eclipseを起動して、New Project/Android ApplicationProject を選択します。
各項目は適切に設定してください。一応こちらの画面を参考までに下記に示します。
表示していない部分に関してはデフォルト設定のままです。

上記の設定でプロジェクトを作成しようとした際に、足りないパッケージをインストールするか聞かれたので、そこはInstallを行っています。

onCreateの中にブレークポイントを設定し、Debug As / Android Application でデバッグ実行をしてみます。
うまくいけば、このブレークポイントで停止します。
うまく行かない場合には、まず端末上に今実行したアプリケーションが表示されているか、Debugで実行を行っているかを確認してみてください。Run Asではブレークポイントで停止しませんので・・・。


ネイティブデバッグのためにADT r20をインストールする (うまく動作せず)

ADTのr20からネイティブ部分のデバッグをサポートしたとのことで試してみました。
ここではADT r20をインストールして使えるようにするための手順を書いておきます。
基本的には、以前に説明してあるネイティブデバッグの手順を終わらせている前提です。

現在、デバッガ機能がうまく動作しないため試行錯誤中。以下の内容はメモという感じです。
この通りやってもうまくいかない可能性が高いです。 

事前条件

  • eclipseはインストールされていること
  • Android SDK, NDK が既にインストールされていること(r20以上)
  • cygwinがインストールされていること
ここでは、Android SDK 20.0.3,  NDK r8b を使用して確認しています。

ADTのインストール

eclipseを起動して、メニューから”Help”/”Install New Software”を選択します。選択すると下記のような画面が開きますので、Addボタンを押して、下記の情報を入力します。

  • NAME: ADT
  • Location: https://dl-ssl.google.com/android/eclipse/

そしてOKボタンを押してしばらく待ちます。待っていると下記のような画面が出てくるので、項目にチェックを入れてインストールを継続します。

さらに途中でライセンス同意のための画面が出てきます。このときには下記の画面に示すようにaccept側を選択するようにします。

インストールが終わってeclipseの再起動をしたら、NDKのパスを設定する必要があります。
メニューの”Window”/”Preferences”を選択して、”Android”のカテゴリを選択して開いてください。その中に、”NDK”という項目があるので、NDKを展開してあるフォルダを選択します。

サンプルで動作確認

メニューから “File”/”New”/”Other” とたどって、”Android”/”Android Project from Existing Code”を選びます。そしてNDKに入っていたサンプルを選ぶのですが、最初と言うことで”hello-jni” を選んでみました。

もしここで、Finishボタンを押しても次へ進まないようなことが起こった場合には、環境変数を再確認してください。
環境変数 ANDROID_NDK_ROOT が今回使用している物と一致していない可能性があります。
自分はこのトラブルにあたってしまったので・・・いったいどこが悪いのかとても悩みました。

生成されたプロジェクトを右クリックして、”Android Tools”/”Add Native Support”を選択します。

ここまで出来たら一度ためしに実行してみます。うまく実行は出来たでしょうか?
自分の環境ではC/C++のコードにブレークポイントを置いてみたりしているのですが、うまく動作しませんでした。
NativeActivityなら動作するとか聞きましたが、そちらのほうもダメっぽい。まだ何か見落としている設定があるのかも知れません。


ソフトキーボード出現時のリサイズ

Androidアプリで、キーボード表示時には、対象とする部分を表示させたまま、全体をスクロールさせたり移動させたりという挙動させているものがある。
これには、AndroidManifest.xml で  adustResize と設定だけすればいいと思っていたが、実はそれだけではないようだ。

AndroidManifest.xmlのactivityタグの属性として、「android:windowSoftInputMode=”adjustResize” 」と追加してやって、さらに、キーボード表示にはどの部分を縮小するか、という部分も必要の模様。
レイアウト設定時に、余白をこのコントロールに割り当てる、といった設定をしていると思うけど、この設定こそが、縮小されるべき点を示しているという感じだろうか。

だから、android:layout_weightの設定が存在しないと、adjustResizeの効果も出せず、うまく再レイアウトできない。
この結論に行き着くまで結構かかったので、こうしてメモってみました。


Modified UTF-7について

IMAPでのフォルダ名が見たこともないエンコードで返ってきたので調べてみました。
その結果このエンコード方式は、修正UTF-7というものらしいです。IMAP-UTF7とも表現するみたいです。

当然ながら、Javaなどの言語で標準的な解釈器が用意されているわけでもないので、自分でデコード処理を行わないと、本来の文字列を得ることはできません。

この修正UTF-7は、次のようなデータとなっています。
・ “&”以外の文字列はそのまま格納されている。
・ “&”を表現したい場合には、”&-“として格納される。
・ “&”と”-“で挟まれているデータは変則的なBase64としてエンコードされている。
・ この変則的なBase64は通常のBase64と比べ、”/” と “,” が置き換わっている点と、Base64のパディング”=”は含めない点が異なる。

さて、このような特徴があるので、”&”の出現でASCII処理モードとBASE64処理モードを切り替えて実装することで、割と楽なデコーダーを作ることができそうです。BASE64の処理モードでは、”,”を”/”に置き換えてからすでにあるBase64のデコーダーに処理させます。

感想

初めてUTF-7なんてものを知りました。いいきっかけだったと思います。
エイプリルフール時のネタで作られたRFCで、UTF-9なんてものがあったのは知っていたのですが…。
まだまだ知らないことで一杯ですが、このようなチャレンジを通して知識を広げていけたらいいなと思います。