2014年9月14日日曜日

android usbserial

   

usbserialの作り方

if (manager == null)
{
    manager = (UsbManager) getSystemService(this.USB_SERVICE);
}
if (manager != null)
    usb = UsbSerialProber.findFirstDevice(manager);
if (usb == null)
{
    Toast toast = Toast.makeText(this, "USB接続がありません", Toast.LENGTH_LONG);
    mainMessage("USB接続がありません");
    toast.setGravity(Gravity.TOP, 0, 50);
    toast.show();
    return;
}

if (usb != null)
{
    try{
        usb.open();
        usb.setParameters(MONI_BPS, usb.DATABITS_8, usb.STOPBITS_1, usb.PARITY_ODD);
        start_read_thread(); // シリアル通信を読むスレッドを起動
    }
    catch(IOException e){
        e.printStackTrace();
    }
}

読み取りスレッド

static int nMaxR = 0;
    static private byte buf[] = new byte[1024];
    public void start_read_thread(){
          new Thread(new Runnable(){
            public void run(){
              try{
                while(!bUsbClose){
                  int num = usb.read(buf, 256);
                  for (int i = 0; i < num; i++)
                  {
                      if (mWcnt >= mRecBuf.capacity())
                          mWcnt = 0;
                      mRecBuf.put(mWcnt, buf[i]);
                      mWcnt++;
                      if (mWcnt == mRcnt)
                      {
                          mOver++;
                          Log.d(TAG,"mOver = "+ String.format("%d", mOver));
                      }
                  }
                  if (num > nMaxR)
                      nMaxR = num;
                  if (num == 0)
                      Thread.sleep(10);
                }
              }
              catch(IOException e){
                e.printStackTrace();
              }
              catch (InterruptedException e) {
                e.printStackTrace();
              }
            }
          }).start();
        }

2014年9月13日土曜日

Eclipse Android 無関係なプロジェクトを閉じる

Android Private Librariesにある android-support-v7-appcompat.jar はライブラリなのだけれどもこれはプロジェクトインポートしている。AndroidDependenciesにも表示されている。

しかし、Eclipiseは『無関係なプロジェクトを閉じる』を行うとappcompat_v7_5.jarのあるプロジェクトを閉じるので、コンパイルエラーが発生することになるようだ。

このappcompat_v7はプロジェクトインポートなので不便極まりない。何とかならないのかな。

以下に代表的なエラーを示す。

ActionBarActivity <==これが未定義になってしまう。

#import android.support.v7.app.xxxxxx   <==これらが全てエラーになる。

もともとはEclipseのプロジェクトの自動生成機能で作ったのに、一旦全てのプロジェクトを閉じて、アプリケーションプロジェクトを開くとエラーのオンパレードになってしまうなんて。。

修正方法は、
  Android Private Libraries
     ここにv7が現れていないなら、、、、
  自分のWorkSpaceのandroid_v7_X を順に開いてみれば良い。
  どれかを開くと、上記にv7が現れるので、そのプロジェクトを
  閉じないようにすればエラーは無くなるが、、、不便極まりない。

Min SDKを4.0以降にすればv7は要らない。

MinSDKが3.2以下だとv7が必要のようだ。

2014年9月7日日曜日

Androidのメモリ アロケート量

知らないことが多いんだな-、と反省。

Dalvik VMはメモリサイズ量の管理が特殊なのかな。大容量をAllocateできない。JNI内でAllocateすると大量のメモリを確保できる。プロセスが終われば解放されるのであれば、それで良いのではないかと思う。

DalvikVM(JVM)は一定量以下のJAVAで利用するメモリを操作するのに向いていて、GCも効率よく出来ているようだが、メガバイト単位の領域を確保するようにはなっていないようだ。メガバイトを確保すると、他のアプリに迷惑がかかるだろうが、業務で利用することを考えたら、そんなことは関係無い。速く動く方が良いに決まっているし、機種も限定される。

JNIはVMの外側でアロケートできるようで、VMが管理している全メモリ量くらいまでアロケート可能なようだ。VMはBitmapをこの外部メモリにアロケートするようだが、Bitmap以外でもアロケートして欲しいものだ。

しかし、Javaの処理速度から考えれば、現在のメモリ管理量は妥当なのかもしれない。

16MBのデータファイルを5個開こうとしている事に無理があるのかな。それでも80MBなんだが。メインメモリは2GBもあるのに。

C言語(JNI側)

for (int i = 0; i < 5; i++)
  K[i].pDataBuffer = (char *)malloc(1024 * 1024 * 16);

同じバッファをJava側で確保しようとしたら、3個目でOutOfMemoryした。

変な考えを起こさないで最初からC言語で確保すれば良かった。この領域、プログラム終了まで解放しないので、問題ないみたい。最初、JNIで確保するとリークするのかと思っていた。そんなことは無い。JNIは単にNativeなだけで直接Linuxを呼び出しているだけのようだ。

android 端末のgoogle drive の不思議

nexus7でgoogleDriveを使っている。

abc.XXXXzというファイルと130716A.XXXXzというファイルがある。

abcはタップしても『ファイル形式abc.XXXXzは非対応です』と表示される。130716Aはアプリが起動される。この違いは何だろうか。拡張子が同じなのに片方だけがアプリ起動されるのは何故だろう。

-----------------------------

検証1:アプリからそれぞれのファイルを開けば、正常に開くことができる。

検証2:グーグルドライブ上のアイコンが異なる。abcは横棒3本の下に▼、130716aはドキュメントページのような青いアイコン。

検証3:プロパティに違ったところは見受けられない。種類は共に不明な種類

-----------------------------

abc.XXXXzをGmailで自分宛に送った。

受信したメールの添付ファイルabc.XXXXzをタップ=>アプリが起動される。

ドライブ上のabc.XXXXzを削除。

受信したメールの添付ファイルabc.XXXXzをドライブに保存。

-----------------------------

グーグルドライブ上のアイコンが青いアイコンになった。

グーグルドライブでタップするとアプリが起動されるようになった。もう一つのファイルと動きが同じになった。

-----------------------------------------------------------------

結果の推測

・google driveに格納する際に、何かしらのMimeTypeが付けられるのかもしれない。最初にあったabc.XXXXzはUSBのデバッガ経由でコピーしたものを入れたような気がする。コピーの仕方によってはMimeTypeが付加されないのかもしれない。これはGoogleDriveのファイルは格納時にMimeTypeを記述するという前提(推測)。

・XXXXzは 内容はGZ圧縮してあるため、Gmailから起動すると、application/x-gzip-compressed となっているようだ。このMimeTypeが有効ではなかったのか。しかし、driveアプリでファイルの情報を見ても、種類は不明な種類という表示になっている。ここにMimeTypeが表示されていれば判りやすいのに。でもここはGoogle形式以外は全て『不明な種類』という表示になっているようだ

------------------------------------------------------------------

独り言:googleのMimeTypeや拡張子に関する文書は無いのかな。英語でもいいんだけど、、、、探しきれていないだけなのかな?

2014年9月5日金曜日

Android 開発 Uriで受け取ったファイルの元のファイル名とサイズの取り出し方

ContentResolver cr = getContentResolver();
String[] projection = {MediaStore.MediaColumns.DISPLAY_NAME, MediaStore.MediaColumns.SIZE};
Cursor metaCursor = cr.query(uri, projection, null, null, null);
if (metaCursor != null) {
    try {
        if (metaCursor.moveToFirst()) {
            orgFileName = metaCursor.getString(0);
            orgSize = metaCursor.getString(1);
        }
    } finally {
        metaCursor.close();
    }
}

ずっと悩んでいたが解決した。そうだよね、取り出し方が無いなんてことはないでしょ。

2014年7月26日土曜日

android jni bitmapの並び

unsigned int RGB(unsigned char r, unsigned char g, unsigned char b)
{
    return 0xff000000 | (b << 16) + (g << 8) + (r );
}

RGBA_8888はWindowsのビットマップと同様の並びになっている。

unsinged intの 4バイトに収めた時に、右端のバイトからR,G,B,Aの順という意味。

16進数なら0xAABBGGRRという形式ということで、メモリ上に展開されているのはもちろん、インテル方式である。私はリトルエンディアンとビッグエンディアンという言い方が嫌いだ。憶えられないからだ。リトルエンディアンはインテル方式、ビッグエンディアンはモトローラ方式と記憶しているので、どっちがどっちなのか忘れてしまう。インテル方式で良いでしょ。卵を想像して、もともとどちらが上、右とか判らないでしょ。それとも、あの、エッグスタンドには卵の上下があるのでしょうか。誰か教えてください。

今の所、問題は無いけど、モトローラ型のAndroidが出るかもしれませんね。あるのかな?

2014年7月10日木曜日

えー、GZIPInputStreamって

zip = new GZIPInputStream(new BufferedInputStream(fis));

int nLen = 0;
while(true)
{
    int nLen2 = zip.read(babuf, nLen, babuf.length - nLen);
    if (nLen2 <= 0)
        break;
    nLen += nLen2;
    Log.d(TAG, String.format("zip read length = %d this time %d bytes", nLen, nLen2));
}

read時にどんなに大きなバッファを用意していても、Open時のバッファ指定より大きいデータを読み取ってくれないのね。知らんかった。内部バッファと外部バッファの差を吸収してくれないのかよ。

zip = new GZIPInputStream(new BufferedInputStream(fis), 0x10000);

で64kまでは1回で読み取ってくれるね。

あー、気づかなかった。30分は悩んだね。だからJavaは嫌いよ。ライブラリの中身がどうなってるか判らないからね。サンプルも嘘ばっかりだし。愚痴っても仕方ないね。みんなよくやってるね。