2011年9月19日

署名用のPK8とPEMをつくる

keytoolでつくったkeystoreからpk8とpemをつくろうとしたけど、断念した。
opensslを使って変換させたりしたけど、どうもうまくできていないようだ。

もう、keystoreは忘れよう。
eclipseでやるときはkeystoreを使い、Android.mkでやるときはpk8とpem。
割り切ろう。


pk8とpemを作るのに、スクリプトを作った。
コマンドを打ち込むだけだと、忘れるからファイルにしてしまうのだ。

#!/bin/sh
development/tools/make_key foobar  '/C=JP/ST=nnn/L=mmm/O=xxx/OU=yyy/CN=zzz’

こうすると、foobar.pk8とfoobar.pemができるので、build/target/product/securityにコピーする。

Android.mkに追加。

LOCAL_CERTIFICATE := foobar

これだけ。
いつものようにmmなどでビルドすると、out以下にapkがコピーされる。
そのときには、すでにfoobarで署名済みだ。

make_keyするとき、パスワードはつけない方がいいかも。
署名時にキー入力を求められるので、mでビルドさせたまま外出、なんてことができなくなりそうだ。

AppWidgetのアイコンは難しい

あれからEjectSDのアイコンを描き続けているが・・・難しい。

アイコンの中に文字を入れる

画像として文字を入れてしまうと、dpiの違いによって文字がつぶれてしまう。
それよりなにより、読みにくい。
うまい方法はあるのかもしれんが、私の技術では無理だ。

周りとバランスがとれない

アイコンだけ描いていて「おっ、これでいいかも」と思って実機で動かしてみると、アイコンが浮いて見える。
Androidのアイコンルールに従ってみたつもりなのだが・・・。
ようやく気づいたのだが、周りはアプリのショートカットなので、アイコンの下に文字があるのだ。
私はアイコンだけで、しかもfill_parentしているので、枠いっぱいに画像が広がっている。
だから、バランスがあわないのだ。
アイコンをアプリのショートカットに近くするなら、文字を下に入れた方がよい。
そうでなければ、枠をきっちりつくってしまうか、枠がまったくなくてアイコンがあるような形がいいのかも。
意識してアイコンをみてみるように心がけようかね。

2011年9月18日

AppWidgetにアイコンを表示させたいときは、大きめにするか、fill_parentにするのがよさそうだ

以前作ったAppWidgetのEjectSDは、アイコンを作り直そう。
そう思ってあれこれやっている。

まあ、デザインどうのこうのは、もうあきらめよう。センスの問題だ。
今気にしているのは、アイコンのサイズ。
これは技術でカバーできる話だ。

 

なにかというと、A500にAppWidgetを表示させた際、アイコンが小さくなってしまうのだ。
しかも、寄ってる。。。
これは確かに、イマイチといわれても仕方あるまい。


EjectSDは、おおきさが1x1だ。
本によると、1x1のAppWidgetは72x72[dp]とのこと。

dpは「density-independent pixel」ということで、とにかく160dpiの場合に1dp = 1pxという関係になるとのこと。
A500は、画面は広いけど160dpiだ。
リソースなら、res/drawable-mdpiを使うのかな。

そう思って、ldpi、mdpi、hdpiのためにそれぞれ36x36、48x48、72x72のアイコンを用意した。
が・・・アイコンは小さい。

じゃあ、とldpi、mdpi、hdpiをなくして、drawableに72x72pxのアイコンを作った。
が・・・これも小さい。
なんじゃこりゃ?


アイコンをどうやって表示させているかというと、ImageViewにsetImageViewResource()を使って貼り付けているだけだ。
ImageViewにサイズ指定なんてしてないのになあ、と思うと、ガイドラインがあった。

縦置き(portrait)と横置き(landscape)で違うのか・・・。
デザインについては、知っておかないといかんことがいろいろあるんだなぁ。

それはともかく、今は縦画面で確認しているので、AppWidgetとしては80x100pxだ。
作ったアイコンは、72x72だからこれよりも小さい。
そして小さいまま表示されるのだから、アイコンの拡大なんかはしないみたいだ。

では、大きいアイコンだったらどうなる?
512x512pxのアイコンにしてみると、AppWidget1つ分の枠にみっしり入って表示された。
横画面にしても、みっしりだ。
ということは、縮小はしてくれるらしい。
ImageViewの指定がwrap_contentだからか?

fill_parentにして72x72アイコンに戻すと、みっしり表示された。
なーんだ、そういうことか。
そんなわけで、AppWidgetにアイコンを表示させるときは、wrap_contentにしてアイコンを大きめに作って縮小してもらうか、fill_parentにしておくのがよさそうだ。
デザインのどこをいじるとどうなるかわかってないので、時間がかかって仕方がない。

2011年9月17日

Android 3.1以上でPaSoRiを動かせそうなライブラリを公開

JavaもAndroidもFeliCaもNFCも、なんとなく中途半端な知識しかない。
ないのだが、せっかく作ったので公開してみたくなるのは仕方ないだろう。
githubに、Android 3.1以上でPaSoRiを動かせるんじゃないかな、と思うライブラリを公開しました。

git clone git://github.com/hirokuma/NfcPcd.git

 

ProGuardをかけてみたので、うまく動くかどうかわからんです。


プロジェクトの設定で、ライブラリを追加

Java Build Path > Libraries

libnfcpcd.jarを追加。

 

AndroidManifest.xmlに、以下が必要。

manifest内

<uses-feature android:name="android.hardware.usb.host"></uses-feature>

activity内

<intent-filter>
    <action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" />
</intent-filter>

<meta-data android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" android:resource="@xml/device_filter" />

 

ソースファイルにも手が入る。

Activityソース

Activityクラスに「implements com.blogpost.hiro99ma.pcd.UsbHost.UsbListener」を付ける。
USB挿抜検知用(動くと思う)。

eclipseでやっていると、メソッドが足りん、といわれるので、いわれるままに追加。

@Override
public void inserted() {
    // 挿された!    
}
 
@Override
public void removed() {
    // 抜かれた!
}

やってみたけど、挿された方はうまくいかんかったです。

onCreate()で、UsbHostのonCreate()を呼んでやるのも必要。

・・・
説明が面倒になったので、サンプルも置きました。
はてさて、どうなることやら。

[ビルド]antとProguard

過去記事:2010/09/23 16:53


「俺はミドルなんて知らねえ! アプリに生きるぜ!!」という方もおられよう。

私はeclipseが、というよりも、eclipseの自動補完とかがないととてもJavaでアプリを作ることができない。
Ctrl+Oがなかったらと思うと、そら恐ろしい。

ただ、eclipseなしでも、コマンドラインから開発はできる。
つまり、ビルドできる。
今日のAndroid Developer Blogに、Proguardを使う場合にはコマンドラインでビルドせんといかん、とあったので、Proguradはやってないけど(やれよ)コマンドラインでのビルド手順を書いておこう。

今回はWindowsでやったので、コマンドプロンプトは「>」です。



まず、プロジェクトの作成。

の前に、自分の環境を知っておこう。

> android list targets

これで、自分がビルドできるターゲット一覧が出てくる。

うちは全部はインストールしていないので、こんだけだ。

いるのは、赤文字の部分。
プロジェクト作成字に指定するのだ。

Available Android targets:

id:
1 or "android-4"

     Name: Android 1.6

     Type: Platform

     API level: 4

     Revision: 3

     Skins: HVGA (default), QVGA, WVGA800, WVGA854

id:
2 or "android-8"

     Name: Android 2.2

     Type: Platform

     API level: 8

     Revision: 2

     Skins: HVGA (default), QVGA, WQVGA400, WQVGA432, WVGA800, WVGA854

id:
3 or "Google Inc.:Google APIs:8"

     Name: Google APIs

     Type: Add-On

     Vendor: Google Inc.

     Revision: 2

     Description: Android + Google APIs

     Based on Android 2.2 (API level 8)

     Libraries:

      * com.google.android.maps (maps.jar)

          API for Google Maps

     Skins: WVGA854, WQVGA400, HVGA (default), WQVGA432, WVGA800, QVGA


> android create project --target "android-8"
   --name AntTest --path .\AntTest --activity AntTestActivity
   --package jp.typepad.hirokuma.AntTest

 

長いので改行させたが、本来は1行で書く。
実行すると、

  • --targetで指定したターゲット向けに、

  • --nameで指定したプロジェクト名で、

  • --pathに指定したディレクトリを作成し、

  • --activityで指定したアクティビティ名の、

  • --packageで指定したパッケージで

プロジェクトを作成する。

--targetは文字でなく数字でもよい。

あとは、できたディレクトリに移動して、ビルドするだけ。

> cd AntTest

> ant

お手軽。



eclipseで作ったプロジェクトと違うのは、たぶんbuild.xmlというファイルが作成されることだろう。

これに従ってantはビルドしているようだ。
たぶん、Proguardを使うときは、build.xmlに細工をするのだろうな。

「もう既にeclipseで作ったプロジェクトをantでビルドしたいんだけど…」という場合が、たぶんAndroid Developer Blogに書かれている方法だな。
うん、そうだ。
ant releaseとすると、ビルドできるな。

なになに、local.propertiesというファイルもできるので、そこにkeystoreとかを登録しておくと署名済みのapkファイルができるだと?

これも試しておくか・・・。

Windowsの場合は、パスのデリミタが\\となるので注意が必要だな。

ファイルのパスを取得することが多いので、ツールを入れておくと便利。

私はFileMenu Toolsというものを使っている。

Explorerの右クリックで「ファイルパスをコピー」ということもできるのだ。

local.propertiesを編集してからant releaseすると・・・
おお、パスワードを訊かれるようになった。
打ち込むと(「***」とはならず、普通の入力なので注意)、できたような気がする。

むむ、ちょっと待て!

2回パスワードを訊かれたので、打ち間違えたのかと思っていたのだがそうではない。

1回目はkeystoreのパスワードで、2回目はaliasのパスワードだ。

そして、keystoreのパスワードが違うとビルドエラーになるのだが、aliasの方は特に文句をいわれない。

そんなものなのか・・・?

> jarsigner -verify -verbose -certs XXX.apk

とすると、署名済みかどうかわかるそうだ。

署名はできていたのだが、aliasのパスワードは、そのときに付けるものなのか?

いや、eclipseからやると確認されるな。

うーむ。。。
まあいいや。

 

local.propertiesにProguardをインストールしたパスを追加。

パスは、proguard.jarの入っているlibまでを書かねばならん!

気付くのに時間がかかったわい。

 

次は、2つのファイルをサイトからダウンロードして、build.xmlと同じ場所に置く。

最後に、build.xmlへの編集が必要。

先頭の<?xml・・の次の行に追加。

<!DOCTYPE project [

       <!ENTITY add-proguard-release SYSTEM "add-proguard-release.xml">

]>

<project name・・・の次の行に追加。

&add-proguard-release;

これで終わりらしい。

ant releaseすると、時間がかかりながらもビルドできた。



特にLVLが入っていなくても、使えるみたいだ。

が、Blogを読むと、このまま動かしてもCRASHすることがあるらしい。

procfg.txtを編集して、-keep public classとして登録するようだ。

よくわからんので、読んでおきたまえ。

 

登録はめんどくさいなぁ。

が、やらんと動かんなら、仕方ないな。

実際に動かさないとわからんのだったら、全classを試してみないといかんことになるが、事前にわからんのかいな?

ある程度はprocfg.txtに登録してあるので、外部から呼ばれることがあるclassだけを追加すればよさそうな気がするが・・・。

 

obf/mappin.txtに、どのようにobfされたかが出ているみたいだ。

何かなと思ってみると、このクラスはこの名前に変更しました、というものみたい。

そういえば、Javaって名前がそのままファイルサイズにつながるという記事をどこかで読んだことがある。

難読化するのとサイズを小さくするのを兼ねているのだな。

とまあ、あまり興味がないわりには最後までやってみましたとさ。
めでたしめでたし。

[java]引数にfinalをつけるとどうなるのだろう (2)

http://hiro99ma.blogspot.com/2011/09/javafinal-1.html

なんだかよくわからなくなってきた。

final byte[] a = new byte[5];

こんなことをしても、バイトコードでは変化がなかった。
もしかすると、finalはバイトコードに現れる類のものではないのかもしれない。

上記のコードに続けて、

a = new byte[3];

などとすると、こっちはエラーになる。
そうなると、finalはバイナリレベルではなくコンパイルレベルでやっているだけということか。


これでようやく、議論の意味がわかった。

引数にfinalをつけても、確かに意味がない。
私みたいにfinalをよくわかってない人にとっては「書き換えないんだろう」とすら思ってしまう。
そう考えると、引数ではfinalを付けない方が親切かも。

もし、「a = new byte[3]」みたいにしないことでコンパイル時の最適化が狙えるのであれば、それは関数内で最初に「final byte[] b = a;」のように引き取った方がいいのかもしれん。

C/C++のconstとは違うもの、という認識を強く持っておかねば。

 

IBMの記事があったので、載せておかねば。

http://www.ibm.com/developerworks/jp/java/library/j-jtp1029/

 

あれ・・・ということは、戻り値をfinalで戻す、ということはできず、それはメソッドがfinalってことになるのか??
ってことは、static classのフィールド(オブジェクト型)を返す関数なんて、最悪ではないか!

ライブラリを作り直さねば・・・。

SDK for NFC Starter Kit β版のドキュメントを見る

M575_NFCAccessLibraryFunctionOverview_1.1j.pdf

概要が書いてあるので、まず目を通す。

ライブラリにはプラグインがあって、そのパスはレジストリに書く。
インストーラがやってくれるのだが、再頒布可能なファイルにはインストーラが入ってなかった。
だめなのかな?
でも、Lite版のアプリとともにライブラリを頒布する場合のライブラリインストールにはインストーラを使ってくださいと書かれている。
なら、いいのかな?

 

また、注意事項がいくつか。

まず、捕捉コマンドの発行ができないとのこと。
ん? InListPassiveTargetを投げられないということですかい?
しくみとしては、poll mode開始関数を実行すると、定期的に裏でポーリングされ、捕捉されたらWindowメッセージで通知されるとのこと。
何気なく使っているポーリングだけど、SONYさん(FNさん?)としては使われたくないコマンドってことなのかなぁ。

 

R/Wは複数のアプリで共有できるとのこと。
「1つのR/Wは、最大8個のアプリで共有できる」とある。R/W複数接続もあり(もってないけど)?
アプリごとのアクセス権(排他制御)もライブラリでできるらしい。
たぶん、アプリはライブラリにアクセス権を獲得しにいき、とれたらアクセスできるのだろう。
んで、アクセスはプロセス単位とのこと。
Windowsのしくみは詳しくないが、アプリケーション=プロセス、でいいのかな。
なお、マルチスレッドには対応してない。

複数で共有したとき、捕捉したら誰に通知が行くかというと、登録が早いひと。プロセスが使用権を解放しないと次のプロセスが使えないので、必ず解放せよ、ということだ。


M579_PC_SC_1.1j.pdf

これは、PC/SCについての資料で、TypeBのはなしらしい。
PC/SCはわからん・・・というよりも、知らないと潔く言わねばなるまい。

Personal Computer / Smart Cardの略。
WindowsでICカードを使うための標準APIらしい。
http://developers.orangetags.jp/words/pc-sc

TypeBチャレンジするときに、また読むかもしれない。
今は、おいておこう。


M577_NFCAccessLibrary_1.2j.pdf

ライブラリの詳細。
といっても、30ページほどしかないのでそこまで身構えることはない。

さっき「捕捉したらWindowメッセージで通知」と書いたが、あれはコールバックのことらしい。
WinProc()がコールバックされて、そこのメッセージによって処理を切り分けるというやり方なのかな。
(Windowsに詳しくないので、基本がわかってない。)

API一覧は17個。
API仕様には18個。差は、一覧にfelicalib_nfc_poll_and_start_dev_access()が漏れているからだ。
そして、2.1.9, 2.1.10が欠番だ。

ヘッダにあるLIBRARY_APIは22個。
載っていないのは、以下の4つ。

  • felicalib_nfc_set_pnp_callback_parameters
  • felicalib_nfc_start_plug_and_play
  • felicalib_nfc_stop_plug_and_play
  • felicalib_nfc_set_watching_interval

最初3つは、R/WのUSB挿抜を監視できるのかな。
最後のは、何のwatchingかわからんな。ヘッダの最後にあるから、pnpの監視間隔ではなくポーリングの間隔のような感じがする(試してない)。

 

私が一番気になるのは、API説明に「S_OK」「E_FAIL」とあるけど、ヘッダファイルには定義がないことだ。
API概要には「true/falseです」と書いてある。
Win32のS_OKは0らしいので、C++のtrueは1扱いとなることを考えると、S_OKではだめだ。
サンプルソースを見ると、戻り値を反転したものが真だったらエラーにしているので、true/falseを使っているということになる(戻り値0を反転したら真になるからね)。

SDK for NFC Starter Kit β版来たる

「来る」は、こういうとき「きたる」と読む。
「夜来る」とか。
でも「夜来たる」の方がわかりやすいよな。

そんなわけで、噂のあれが出た。
SDK for NFC Starter Kitだ。

http://blog.felicalauncher.com/?p=3264

商用利用はできないが、私は売ったりしないからいいや。


ダウンロードしたzipを解凍すると、ファイルがたくさんできる。
今、見ながらやっているので、行きつ戻りつすると思うが我慢しておくれ。

 

英語版と日本語版の両方が入っているので、ドキュメントは半分のファイルしか見ないと思えばよさそうだ。

サンプルのバイナリがあるので、NDEFのType3 Tagを読むexeをWindows XP SP3 32bit版で動作させた。
コマンドプロンプトから実行するタイプで、引数にREADとかWRITEなんかを指定する。
PaSoRi RC-S370を接続し、zipに入っていたドライバもインストールし、コマンドプロンプトからType3Tag.exeを実行すると、PaSoRiの上に置いたNDEFフォーマットされているFeliCa Liteからの情報が標準出力に現れた。

 

というところで、今日は力尽きた。

2011年9月14日

Androidのアイコンについて調べてみた

風呂に入って冷静になってみると、アイコンが今ひとつなのは致命的だ。

機能がよくても使ってもらえないとかいうよりも、ウィジェットのようにホーム画面に置くアイコンが貧弱だと、周りとの調和を乱してしまうからだ。

調和を乱すのは、いかん。
和をもって尊しとなす、だっけ。
自重せねば。


アイコンについて調べると、ガイドラインについて説明してくださった人がいた。
ありがたい。

http://blog.asial.co.jp/693

おっと、元のガイドラインを載せておかねば。

http://developer.android.com/guide/practices/ui_guidelines/icon_design.html

 

EjectSDで私が使っているのは、48x48のみ。
こりゃいかんな。
hdpi~ldpiまで取りそろえねば。
launcherにあたるのかな? ならば 36x36、48x48、72x72だ。

 

そしてルールは・・・守ってない項目がほとんど。
がんばろう。

 

しかし、「設定」のアイコンは、なんかわかりにくいと思った。
私はさっき眺めるまで、車のタイヤだとばかり思っていた。
矢印が付いていて、なにかを設定するツマミのようなものなのだろうな。
うーん、まあそれ以外はわかるからいいか。

2011年9月13日

[app]アイコンは大切だ

久しぶりにAndroid Marketを見ると、コメントが増えていた。
うれしいかぎりである。

 

SD Ejectのアイコンが残念、というコメントがあった。
うーむ、私としてはシンプルで気に入っていたのだが。
とはいえ、ICONIA A500で作っているにもかかわらず、アイコンのサイズが合ってないのはいかんと思っていた。
アイコンは大切だ。

 

あと、アイコンの再描画がうまくいってない、というのが気になった。
むむむ、それはいかん。
直したい。


が・・・
今週からとても忙しく、そして今週はとても体調が悪い。
仕事は休まずに済んでいるが、土日は高熱で寝込んでいたせいか、頭は痛いわ、なぜか鼻が痛いわ、肩も痛いわ、口内炎も2箇所できるわ、もうさんざんだ。