2011年7月31日日曜日

EclipseのResource is out of sync with the file system対応

特別な話では無いのですが、設定方法を忘れてしまってあたふたしたので備忘録として記載。

ライブラリソース内デバッグとかを行う際、Resource is out of sync with the file systemのエラーがEclipseから出てしまい、その対処方法です。

[Windows]->[Preferences]で設定ダイアログを表示します。



この画面通り、チェックを付与すればOKですね。

※Eclipse 3.5系が中心で作業しているので、以降は違う箇所とかに変更されているかもしれません。(^^;

2011年5月24日火曜日

Android JNIライブラリの利用<その1>

Android JNIライブラリの作成で開発したライブラリプロジェクトを、そのままEclipseから利用する方法です。
<その1>ではJNIを対象としていますが、利用方法はJavaプロジェクトも全く同一です。<その2>はJNI専用になります。

<Android JNIライブラリ利用側>
  • ライブラリプロジェクトが完成したら、今度は利用するプロジェクト側を用意します。これは例ですが、特別なことはしていません。

  • プロジェクトプロパティの[Android]にあるLibraryの[Add...]ボタンでAndroidライブラリを選択します。ライブラリ登録したプロジェクトが選択できるようになります。設定完了した[Android]タブ

  • 同じくプロジェクトプロパティの[Java Build Path]のProjectsタブにある[Add...]ボタンを押下します。すると、Workspaceにある自分を除く全てのプロジェクトが選択できますが、JNIライブラリを選択します。この例では2つしか無いのでJNIライブラリだけ選択候補になっているように見えますが、間違えないでください。

  • Librariesタブに移動し[Add Class Folder...]ボタンを押下します。ここで、ライブラリ側のJavaソースがあるsrcフォルダを選択します。

  • Order and Exportタブに移動し先程追加したソースのクラスフォルダにチェックを入れます。一応これで準備完了です。後は好きにライブラリを利用したプログラムを開発すれば良いです。

  • ちなみに、Project Explorerで確認するとライブラリが追加されていることが分かると思います。ついでですが、説明しませんでしたがプロジェクトプロパティの[Java Build Path]にあるSourceタブは完了すると勝手にソースが追加されます。これを削除するとライブラリをコンパイルしませんので注意してください。

設定のみなので簡単でしたよね。後はJava実装を行なって実行すれば良いです。
ただ、初心者はJNIライブラリは利用側を実装するまでビルドしないことをお勧めします。というのも、ビルド結果がライブラリフォルダ内で行われてしまい、ライブラリ利用側のbinにコピーされない現象が発生しました。私が行なった対処方法は、binフォルダやgen、Libs、obj配下のディレクトリやファイルを削除することで対応できたように記憶しています。

上記のJNIライブラリ利用は、ライブラリ開発者とアプリ開発者が同一の場合に利用できます。しかしながら、他人にバイナリを配布する際はどうするのか?
これを<その2>に記載したいと思います。

2011年5月17日火曜日

Android JNI で C++ を利用する<その2>

単純なC++の場合には問題無いのだけれど、JNIフォルダの中に複数のフォルダを配置した階層構造とした場合に少々嵌ったので備忘録として記録。

この図のようなJNIディレクトリ構造を持つJNIを開発すると仮定する。
CソースとCPPソースが混在したとしても、Application.mkはJNI直下で無ければならない点に注意。次に、JNI直下では各ディレクトリ毎にAndroid.mkを配置するようにした場合(JNI直下でも良いがその場合には全て指定)には、次の一行をAndroid.mkに記述しておく。
include $(call all-subdir-makefiles)
これに気がつくまでに、時間がかなり掛かってしまったので注意してください。

2011年5月16日月曜日

Android JNIライブラリの作成

Androidの開発を行なっていく上で、避けて通れないのがライブラリ化でしょう。開発していく中で再利用ソースが増えてくるので、他プロジェクトでも利用したいって気持ちが増えます。
かといって共用部分をコピー&ペーストする方法もありますが効率的ではありませんし、なによりプロっぽくありません。ご存知だとは思いますが、アマチュアとプロフェッショナルの決定的な違いは仕事でお金を貰えるか否かになります。作業の効率化もそうですが、メンテナンスも常に意識し他者に継承出来ることが重要視されます。

#企業では同じ仕事を延々に同一担当者が行うことは出来ませんし。
#簡単なメンテナンスとかは、徐々に後輩に移行させる会社を想定しています。

御託はこの辺で終わりにして、本題のJNIライブラリ作成です。
実はAndroidのJavaライブラリ作成方法と全く同じで作成出来ましたってことで終わりにしても良いのですが、それだとやや酷いので、私の作業過程とちょっとしたトラブルの備忘録って趣旨で記載します。

この記事ではAndroid JNIをEclipse CDTの設定方法等は説明しません。それは、以前の記事であるAndroid JNI を Eclipse CDT でプロジェクト統合する<ubuntu 10.10編 その2>を見てください。


<Android JNIライブラリ作成>
  • Androidプロジェクトを生成します。この図のように、ライブラリ専用プロジェクトにActivityが不要な場合にはチェックを外しておきます。
    ☆上図では誤ってパッケージ名をタイプミスしたため、実行エラーとなってちょっと焦りました。こういった配慮も必要ですね。

  • 不要なファイルを削除します。リソースファイルは自動的に作成されますが、特に必要無いので削除しています。

  • Android Manifestの修正を行ないます。
    図の通り、Define an・・・の箇所のチェックを外すことでアプリケーションタグが削除されます。ライブラリは外部から直接起動されない(組み込まれる)ので、必要がある場合には組み込み先側での指定になります。

  • クラスファイルの作成を行ないます。ここでは、JNIの呼出元となるJavaクラスとしてsamplelibクラスを生成しています。内容は以下の通りとしました。
    package jp.co.anaheim_eng.teslib;

    public class samplelib {

    static {
    // ライブラリロード
    System.loadLibrary("testjni");
    }

    // JNIのネイティブメソッド
    public native String GetStringJNI();

    /**
    * デフォルトコンストラクタ
    */
    public samplelib() {
    }

    /**
    * 単なる文字列をJNI経由で返却するファンクション
    * @return
    */
    public String getString() {
    return GetStringJNI();
    }
    }
    この辺りで、前述リンク先の<AndroidプロジェクトのC/C++プロジェクト化>を終了しているものとします。

  • プロジェクトプロパティの[Android]にある[Is Library]をチェックを入れます。

  • JNI側のプログラムは以下の通りとしました。
    ヘッダーファイル[jp_co_anaheim_eng_testlib_samplelib.h]
    #include <jni.h>
    #ifndef _Included_jp_co_anaheim_eng_testlib_samplelib
    #define _Included_jp_co_anaheim_eng_testlib_samplelib

    /*
    * DEBUG パラメタ 0: Releaseビルド, 1: Debugビルド
    */
    #define DEBUG 1

    #ifdef __cplusplus
    extern "C" {
    #endif

    /*
    * Class: Java_jp_co_anaheim_1eng_testlib_samplelib
    * Method: GetString
    * Signature: ([II)Ljava/lang/String;
    */
    JNIEXPORT jstring JNICALL Java_jp_co_anaheim_1eng_teslib_samplelib_GetStringJNI
    (JNIEnv *, jobject);

    #ifdef __cplusplus
    }
    #endif

    #endif
    cppファイル[TestJni.cpp]
    #include <string.h>
    #include "jp_co_anaheim_eng_testlib_samplelib.h"
    #include <android/log.h>

    #include <iostream>
    #include <string>

    #if DEBUG
    # define DebugLogInfo(...) ((void)__android_log_print(ANDROID_LOG_INFO, "TestJni LIB", __VA_ARGS__))
    #else
    # define DebugLogInfo(...) do{}while(0)
    #endif

    JNIEXPORT jstring JNICALL Java_jp_co_anaheim_1eng_teslib_samplelib_GetStringJNI
    (JNIEnv *env, jobject thiz)
    {
    std::string strRtn = "Hello JNI Library";
    return env->NewStringUTF(strRtn.c_str());
    }
    [Android.mk]
    LOCAL_PATH := $(call my-dir)

    include $(CLEAR_VARS)

    LOCAL_MODULE := testjni
    LOCAL_SRC_FILES := TestJni.cpp
    LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)
    LOCAL_LDLIBS := -llog

    include $(BUILD_SHARED_LIBRARY)
    [Application.mk]
    APP_STL := stlport_static
    これでJNIライブラリの準備は完了となります。次からはJNIライブラリをどのように利用するかについて記述します。

2011年5月4日水曜日

Android JNI でのファイルの取扱と脆弱性

日本Androidの会 セキュリティ部で私が投稿した内容を纏めます。(^^;

事の発端はSkypeの脆弱性が指摘された件は、SQLiteのパーミッションに問題があったことから始まっています。
#パーミッションが開放されたとしても暗号化されていればまだ良かったのですがね。

「kaito」さんも指摘されていますように、一般的なAndroid APIを利用してファイルを作成する場合には、other権限で読み書きできるパーミッションが付与されることは無いからです。

「kaito」さんの解析成果によりSkype同梱されている「libpcmhost.so」が問題であるとの推測されましたので、JNI側でファイルを作成するとどうなるかを調査しました。

JNI側で一般的な入出力関数である「fopen」「open」の2つを調査しました。ファイルの中身は問題ではありませんので、単なるファイルをopenしcloseすることでファイルを生成させるというものです。ソースサンプルは以下の通り。

#include <stdio.h>
#include <fcntl.h>
#include <jni.h>
#include <android/log.h>

#define DEBUG 1
#if DEBUG
# define DebugLogInfo(...) ((void)__android_log_print(ANDROID_LOG_INFO, "TestOpen", __VA_ARGS__))
#else
# define DebugLogInfo(...) do{}while(0)
#endif

JNIEXPORT jint JNICALL Java_jp_co_anaheim_1eng_MainActivity_testOpen (JNIEnv *env, jobject thiz)
{
//fopen関数は最も一般的
FILE *fp;
fp = fopen( "/data/data/jp.co.anaheim_eng/testfile0.txt", "w+" );
if( fp == NULL ) {
DebugLogInfo("File cannot open error.");
return 1;
}
fclose(fp);

//open関数でパーミッションを指定しない状態で実行
int fd;
fd = open("/data/data/jp.co.anaheim_eng/testfile1.txt", O_CREAT | O_RDWR);
if (fd == -1) {
DebugLogInfo("testfile1.txt File cannot open error.");
return 1;
}
close(fd);

//ここは敢えてパーミッションを666に設定している
fd = open("/data/data/jp.co.anaheim_eng/testfile2.txt", O_CREAT | O_RDWR, 0666);
if (fd == -1) {
DebugLogInfo("testfile2.txt File cannot open error.");
return 1;
}
close(fd);

return 0;
}

このソースをJavaから呼び出して見た結果は以下の通り。

エミュレータはこの結果になるが、ひょっとすれば実機なら変わるかも?ってことでAndroid 2.3.3搭載している開発標準端末であるNexus Sで実行してみた。結果は以下の通り。
#ちなみに私のNexus Sはroot化していませんので。


Skypeの脆弱性はパーミッションを意識しない状態というか、AndroidのNativeで作成されるパーミッションを調査しなかっただけなのだろう。解決方法は?というと、open関数であれば適切なパーミッションを付与させれば良い。その他の場合には自分でパーミッションを設定させる命令を追加すれば良いだけ。

#include <sys/stat.h>

//パーミッションとして660に設定した
if (chmod("/data/data/jp.co.anaheim_eng/testfile0.txt", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP) != 0) {
DebugLogInfo("File cannot change chmod.");
return 1;
}

この処理を追加して実行した結果が以下の通りとなる。


<雑感>
Android NativeであるNDKを利用してファイル操作を行った場合には特にパーミッションを注意しなければならいと思う。因みにUbuntu上でfopenを利用した場合のパーミッションは644になっているので、666のAndroidはややどうかなぁって気はする。
デフォルトパーミッションはJavaと同様に660にして欲しい気もするのだが、最低でも664 or 644になっていることを望みます。

root化された端末では、パーミッションによるセキュリティ担保が出来るということは期待しない方が良いから暗号化等の配慮が必要にはなる。であるとするとJNIで666となるパーミッションの標準もこのままでも良いのかも?って気がしないでもないなぁ。(^^;

2011年3月17日木曜日

Ubuntu 10.10 に Nexus S と XOOM を接続する

東北関東大震災(東北地方太平洋沖地震)で被害にあわれた皆様方に心よりお見舞いを申し上げるとともに犠牲になられた方々、遺族の皆様にはお悔やみを申し上げます。

私も東京にいますので、地震発生直後はいつもの地震だなって思っていましたが次第に大きくなり本棚等が倒れそうになり必死で抑えるのが精一杯でした。最初はTwitterで地震コメントを呟いたのですが、途中からは本棚を抑えながらも大量の地震コメントが流れてきました。
この時こそネットワークで繋がっているっていいなぁって思った改めて実感しました。

まだまだ被害の全容や刻々と変化する情勢に予断を許せる状況ではありませんが、災害に悲観しているだけでは復興の役にも立たないのでポジティブに仕事をすることで、僅かながら社会貢献することにしたいと思っています。


<Ubuntu 10.10 on VMWare Workstation>
私の環境はUbuntu 10.10をWindows 7 Pro 64bitのVMWare Workstationで稼働させています。この環境にNexux Sを接続します。とはいえ、普通に接続すれば問題ないのですが、物忘れが多い私の備忘録として記載します。

1)環境の準備
  • Ubuntu 10.10
  • Nexus S

 これだけなんですが、VMWare WorkstationはWindows 7 64bitで稼働させています。VMWare Playerでも同様に稼働できると思います。Nexus Sを例にしていますが、取り敢えずAndroid端末ならなんでも良いです。
 Android端末はUSBデバッグをONにしておきましょう。(笑

2)情報収集
  • Ubuntu 10.10上のAndroid端末情報を取得する。
    $ sudo lsusb
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 001 Device 004: ID 18d1:4e22 Google Inc.
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    この結果からIDの隣である18d1がUSB Vendor IDになります。隣にある4e22は何だ?ってことになると思います。分かり難いですよね。詳しく見るには以下のコマンドを入力すると分かります。
    $ sudo udevadm info --query=all --name=/dev/bus/usb/001/004
    P: /devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/1-1
    N: bus/usb/001/004
    S: char/189:3
    E: UDEV_LOG=3
    E: DEVPATH=/devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/1-1
    E: SUBSYSTEM=usb
    E: DEVNAME=bus/usb/001/004
    E: ID_VENDOR=Samsung
    E: ID_VENDOR_ENC=Samsung
    E: ID_VENDOR_ID=18d1
    E: ID_MODEL=Nexus_S
    E: ID_MODEL_ENC=Nexus\x20S
    E: ID_MODEL_ID=4e22
    E: ID_REVISION=0227
    E: ID_SERIAL=Samsung_Nexus_S_xxxxxxxxxxxxxxxx
    E: ID_SERIAL_SHORT=xxxxxxxxxxxxxxxx
    E: ID_BUS=usb
    E: ID_USB_INTERFACES=:080650:ff4201:
    E: ID_MEDIA_PLAYER=google_nexus-s
    E: MAJOR=189
    E: MINOR=3
    E: DEVTYPE=usb_device
    E: DRIVER=usb
    E: PRODUCT=18d1/4e22/227
    E: TYPE=0/0/0
    E: BUSNUM=001
    E: DEVNUM=004
    E: DEVLINKS=/dev/char/189:3
    ID_MODELにNexus Sを記載されていますし、ID_VENDOR_IDには先の値が入っています。(x16桁は端末シリアル番号です。)

3)udevのルール編集と
  • 51-android.rulesを新規で作成します。
    $ sudo vi /etc/udev/rules.d/51-android.rules
    SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", OWNER="ユーザ名", GROUP="ユーザ名"
    上記の"18d1"がID_VENDOR_IDになります。Android機器が異なる場合にはベンダ毎に変わります。Nexusシリーズの場合、Googleが製造していないのでNexus Sの場合にはサムソンになるのですが、サムソンは"04e8"なので別IDを利用していることになります。

  • udevの再起動
    $ sudo restart udev
    これで設定自体は完了しています。

  • adbの再起動
    ここで、一旦Android端末をUSBから接続を外し、再度接続し直します。
    $ adb kill-server
    $ adb start-server
    $ adb devices
    List of devices attached
    emulator-5554 device
    端末シリアル番号 device
    これで完了です。



<追記>
2月下旬に発注していたMotorola XOOMが2011/3/15に到着しました。レポートは後日としますが、Windows 7 64bit上でVMWare Workstationで稼働していますUbuntu 10.10でNexus S同様に接続しました。
上記ど同様にlsusbコマンドで調査し下記設定で問題なく動作しています。
$ sudo vi /etc/udev/rules.d/51-android.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="22b8", OWNER="ユーザ名", GROUP="ユーザ名"
Eclipse上のDDMSから画面キャプチャも問題なく出来るのですが、速度が遅いので
$ adb shell screencap -p /mnt/sdcard/capture.jpg
$ adb pull /mnt/sdcard/capture.jpg
で行う方がかなり速く取得できました。コマンド操作が面倒な方は通常通りで良いですが。(笑)

2011年3月10日木曜日

Android JNI で C++ を利用する

Android JNIでって話だとC言語サンプルはNDKにも付いてくるのだけど、C++となると情報が結構少ないので、備忘録として記載。

基本的に拡張子をcppにすることでコンパイルすることは出来ます。私のC++での開発経験はVisual C++(今はVisual Studioですよね)ではほとんど無い経験がありません。Borland Delphiを1.0から開発していたことが長かったので、C++はBorland C++ Builderだったのです。
#昨年はC++ Builderの講師の仕事もしていましたので・・・

何故こんな話をしているかというと、C++でclass定義というと「.h」にはクラス定義のみで、コンストラクタやデストラクタ、各メソッドは「.cpp」ファイルに記述していました。
#というか、勝手にテンプレートでそのように作られるんですね。

兎も角、「.h」「.cpp」のソースファイルを用意します。コンパイルするためには「Android.mk」を作成します。およそ以下のような感じになります。
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := 「JNIライブラリ名」
LOCAL_SRC_FILES := $(call all-java-files-under, src)
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)
include $(BUILD_SHARED_LIBRARY)

ヘッダーファイルが無い場合には良いのですが、定義する場合には「LOCAL_C_INCLUDES」を記述しなければなりません。
Android.mkファイルの各パラメタの詳細については、Android NDKでJNIを使用してアプリを高速化するには3/3を参照してください。

とまぁ、これで普通は終わりなのですが、Android NDK r4以降でC++特有のSTL(標準テンプレートライブラリ)が利用できるようになりました。とは言っても、βとのことなのですが。STLが利用できるようになると、なにかと便利になるのでこれを利用しないでC++を利用する価値はありません。
手元にNDK r4が無いので分かりませんがr5以降(r5bも含む)には2つのSTLが同梱されています。ひとつはGNU libstdc++ STLとSTLportです。どちらが良いかは各自の判断に任せるとして、利用方法は以下の通り。
「Application.mk」を作成します。
APP_STL := stlport_static
#APP_STL := gnustl_static

2行目をコメント化(#の付いた行)しているので、この場合にはSTLportを静的ライブラリ組み込みしてコンパイルします。たったこの一行で終わりです。
サイト検索すると、過去のNDKではSTLportを実行するためにソースをダウンロードしてコンパイルしてって作業が必要だったそうなのですが、現在はこんなに簡単になっています。

コンパイルは良いけど、ソースを記述する際にSTLportのインクルードヘッダーファイルは何処にあるのかって話になる。場所は「android-ndk-r5b/sources/cxx-stl/stlport/stlport」がヘッダーになります。
Eclipseでコーディングする際には、プロジェクトプロパティの「C/C++ General」->「Path and Symbols」->「Includes」のC++に追加することになります。

因みにgnu libstdc++を利用する際は「android-ndk-r5b/sources/cxx-stl/gnu-libstdc++/include」ですね。