2012年10月6日

[android]intent-filterのマッチング(URI)

intent-filterがよくわからなくなったので、昔の記事を見直していると、2年前に書いたのがあった。
今も当てはまるのかわからんが、載せておこう。

どうやら、EjectSDを作るときの調査のようで、SDのマウントを見つつ、intent-filterの実装を読んでいたようだ。
当時の私は、やる気があったなぁ。


(2010/08/21)

intent-filterのマッチングは複雑だが、Uriだけのマッチングはもう少しシンプルで、hostやportの一致を見ている。

つまり、こう言えよう。
intent-filterの比較は、intent-filterごとに行われる、と。
今回でいえば、

<intent-filter>
<action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
<action android:name="jp.typepad.hirokumaEjectSD.WIDGET_CONTROL"/>
</intent-filter>


と、

<intent-filter>
<action android:name="android.intent.action.MEDIA_UNMOUNTED"/>
<action android:name="android.intent.action.MEDIA_EJECT"/>
<action android:name="android.intent.action.MEDIA_REMOVED"/>
<action android:name="android.intent.action.MEDIA_UNMOUNTABLE"/>
<action android:name="android.intent.action.MEDIA_MOUNTED"/>
<data android:scheme="file" />
</intent-filter>


だ。
前者はactionのみのため、match()はどれかのactionと一致し(matchAction)、dataはないのでMATCH_CATEGORY_EMPTY+MATCH_ADJUSTMENT_NORMALとなり(matchData)、categoryもないのでmatchData()の結果がそのまま戻り値となる。
MATCH_ADJUSTMENT_MASK でANDとって非0だからマッチした、となるのかな。
後者はactionとschemeがあるので、まずactionがどれかと一致し(matchAction)、schemeがあるのでどれかと一致してMATCH_CATEGORY_SCHEMEとなり(matchData)、categoryはないのでmatchData()の結果がそのまま戻り値となる。
これは MATCH_CATEGORY_MASK でANDするのか?
match()の戻り値をどう使うか、よくわからん。
が、そこはいいとしよう。
intent-filterの分け方としては、
actionのみのintentを受け付けるのであれば、同じintent-filterにまとめてよい
actionとschemeがあるintentを受け付けるのであれば、同じintent-filgerにまとめてよい
categoryを含む場合は完全一致となるので注意すべし
ということになるだろうか。
試していないので、そうなるかわからんが、そうなるんではないかね。
--------------------------------------------------------------------------------
MOUNT/UNMOUNTなどのintentは、schemeとして"file"が付加されている。
送信されるintentはこんな感じだ。

in = new Intent(Intent.ACTION_MEDIA_MOUNTED, Uri.parse("file://" + path));

むむ、ということは、schemeだけでなくpathもあることになる。
しかしご安心を。
matchData()でpathが比較されるのは、addDataAuthority()した場合のみだ。
XMLだと、<auth>タグがそれに該当するはずなのだが・・・ドキュメントにはないな。
ちなみに、IntentFilterクラスには、writeToXml()というメソッドがある。
試してないけど、どうやらXMLに吐きだしてくれるみたいだ。
何か使えるかな?
--------------------------------------------------------------------------------
なお、MOUNT/UNMOUNTを受け付けるには許可が必要となる。
AndroidManifest.xmlに、


<uses-permission android:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS" />

がいるのだ。
まあ、忘れていてもlogcatで例外を投げてくれるので、わかりやすいがね。

[n7]Androidアプリを作ろう (1)

一応、数年前はAndroidをごにょごにょと触っていたのだが、しばらくはまったく使っていなかった。
せっかくNexus 7も来たことだし、Androidアプリを作ってみよう。


ひとまず、Windows XPでつくる。
Linux環境は、どうしてもテキストエディタとIMEに慣れないのだ。

久しぶりにインストールしたAndroidのアプリ開発環境は、ハイカラだった。

  • プロジェクトのウィザードが親切!
  • アイコンがある程度自動生成される!

 

他にもありそうだが、よくわからないので適当に試してみよう。
失敗しても死ぬわけじゃないしね。


Manifest

image

 

Application

image

 

image

 

Permissions

image

 

それっぽいところを設定してみた。
ApplicationのPermissionとPermissionsの違いがよくわからんな。
それと、Intent Filterを複数Actionでまとめるのか、1つのIntent Filterに1つのActionにするのか、などがあまりわかってない。
以前作ったサイトがなくなったのが、痛いな。

 

ここまででファイル保存すると「プロローグにはコンテンツを指定できません」と出てきた。
なんだろうね。
まあ、それを調べるのも、またいいものだ。

2012年10月5日

EjectSD4のインストールエラー -24

充電できたので、Nexus 7でlogcatした。

I/qtaguid ( 2177): Failed write_ctrl(u 51) res=-1 errno=22
I/qtaguid ( 2177): Untagging socket 51 failed errno=-22
W/NetworkManagementSocketTagger( 2177): untagSocket(51) failed with errno -22
D/Finsky  ( 1120): [1] DownloadQueueImpl.notifyProgress: com.blogpost.hiro99ma.EjectSD4: onProgress 39548/39548 Status: 200.
D/Finsky  ( 1120): [1] DownloadBroadcastReceiver.onReceive: Intent received at DownloadBroadcastReceiver
D/Finsky  ( 1120): [1] DownloadImpl.setState: com.blogpost.hiro99ma.EjectSD4 from DOWNLOADING to SUCCESS.
D/Finsky  ( 1120): [1] DownloadQueueImpl.onComplete: com.blogpost.hiro99ma.EjectSD4: onComplete
D/Finsky  ( 1120): [1] DownloadQueueImpl.remove: Download com.blogpost.hiro99ma.EjectSD4 removed from DownloadQueue
I/installd(  128): free_cache(0) avail 13832962048
D/PhoneStatusBar(  465): addNotification score=0
W/ActivityManager(  343): No content provider found for permission revoke: file:///data/data/com.android.providers.downloads/cache/downloadfile.apk
W/ActivityManager(  343): No content provider found for permission revoke: file:///data/data/com.android.providers.downloads/cache/downloadfile.apk
D/dalvikvm(  343): WAIT_FOR_CONCURRENT_GC blocked 0ms
W/PackageManager(  343): Package couldn't be installed in /data/app/com.blogpost.hiro99ma.EjectSD4-1.apk
D/dalvikvm(  343): GC_EXPLICIT freed 795K, 18% free 12719K/15495K, paused 5ms+4ms, total 64ms
D/Finsky  ( 1120): [134] 1.packageInstalled: Package install status for "com.blogpost.hiro99ma.EjectSD4" is -24
D/Finsky  ( 1120): [1] InstallerTask.cancelCleanup: Cancel running installation of com.blogpost.hiro99ma.EjectSD4

 

-24というエラーがわからなかったが、今もよくわからん。
permissionがないというやつがだめなのか?

 

/data/data以下はパスが見えないので、よくわからない。
悔し紛れに、/のlsだけとっておいた。

shell@android:/ $ ls
ls
acct
cache
config
d
data
default.prop
dev
etc
fstab.grouper
init
init.goldfish.rc
init.grouper.rc
init.grouper.usb.rc
init.rc
init.trace.rc
init.usb.rc
mnt
proc
root
sbin
sdcard
storage
sys
system
ueventd.goldfish.rc
ueventd.grouper.rc
ueventd.rc
usbdrive
vendor

 

busyboxがないと見づらいなぁ。

SDK for NFCの記事を見た

あまり記事に出てこないSDK for NFCのこと。
久しぶりにサンプルソースまで作ってある記事があった。
http://bs-nfc.blogspot.jp/2012/10/nfc-idwindows.html

私が苦労して(そしてできていない)Windowメッセージのところが、なんだかさっぱりと書かれていて悔しい。
ちなみに、私のはこんなの。
これに山下さんのをパクって参考にしてWindowメッセージのところを処理するといいのかも。

あ、このサンプル、かざしたNFCカードは早めに取り除いた方がいいですよ、ふふふ。

さて、SDK for NFCはどういう方向に向かっていくのだろうか。
だって、NPFだっけ、Microsoftも自分でAPIを提供しようとしているではないか。
まあ、過去資産があるし、NPFも普及にどれくらいかかるかわからないから、しばらくはいいのだろう。
でも、.NET対応していないし、今から始める人は「NPFまで待つか」という気分になってしまわないだろうか(せめて.NET対応はサンプルじゃなくてDLLレベルで出した方が…)。
SONYさんはSONYさんの思惑があるからいいんだろうけど、私みたいに事情をよく知らん身からすると「なんか行動が重たいなあ」という気になってしまう。
とにかくまあ、SONYさんには世話になってるし(R/Wとかで)、がんばってもらわにゃ困る。
そんな風に見えないけど、密かに応援している私だった。

2012年10月3日

[n7]自作SNEP v.s. Nexus 7 (2)

前回の動きが気になったので、自作SNEP側を変更して試した。
自作SNEPのいいところは、Initiatorのみとか、Targetのみとかにできることだ。
Initiatorになれるということは、相手がどういうTargetになっているか調べることができるということになる。


NFC-Aのみ・・・SNEPできず
NFC-Fのみ・・・SNEPできる

というわけで、Nexus 7のAndroid BeamはNFC-Fのみのようである。

 

そして、もう1つ。
NFC-AのSNEPになるならないの前に、SDD(Single Device Detection)してNFCIDを取得するようにしているのだが、それにも引っかからない。
つまり、(少なくともうちにある)Nexus 7はNFC-AのTarget動作をしていないということになる(NFC-Aができない、という意味ではないよ)。

まあ、私のソフトにバグがある可能性もあるがね。


NFC-AのTarget動作をしてないと言うことは、Secure Elementを搭載していないのだろうか。
しかし、EEの記事では「PN65というSE」って書いてあった。
PN65って、PN544の後継機とかじゃなかったの?

 

英語の記事だと、どうも苦手だ・・・と思ったら、日本語にできた。
そうか、PN65はSE内蔵のNFCチップということか。
じゃあ、とりあえず機能を使わないようにしているのだろうな。

 

Nexus7のアップデートでGoogle Walletが使えるようになった、という記事もあったので、使いたい場合にはそういう形を取るということか。

まあ、なんとなくすっきりしたので、よしとしよう。


そういえばTech-On!の記事にも書いてあったが、うちのNexus 7も認証マークがはがれそうだ。
はがれそうというか、いっぺん剥いで貼り直したように見える。
なんか、間違って、みんなで貼り直し作業でもしたのかしらね。

[n7]自作SNEP v.s. Nexus 7 (1)

そういえば、対決シリーズ?も記事から消してしまったので、よくわからなくなってしまったな・・・。
仕方ないので、その記事は元に戻そう。

 

というわけで、自作のSNEPをNexus 7のAndroid Beamに向けてPUTさせた。


Nexus 7は、確かNXPのPN65が載っていたと思う。
アンテナは、先っちょにあるらしい(保護ラップに「NFC」って書いてあった)。

 

うちで作ったSNEP箱にNexus 7を近づけると、ときどき失敗するものの、だいたいNDEF TEXTを送信することができた。
ふう、よかったよかった。

 

感触からすると、失敗しているのはアンテナ位置の不整合というか、ポジショニング不良というか、ずれてるときに起こるようだ。
試作端末だからエラーが起こるとすぐにわかるようにしているが、実際にはリトライをうまいこと行うようにしておかないといかんな。

 

もう1つ。
数回やったのだが、通信はNFC-Fでの通信になっていた。
SNEP端末がどういう動きをしているかというと、

  1. NFC-F, A, Bの順でポーリング
  2. ポーリングに応答したらNFCIDを読んで、DEPしそうだったらSNEP突入

となっている。
なので、少なくとも私が試したとき、Nexus 7はNFC-Fのターゲットになっていたということになる。

 

さて、私のNFC-Fのポーリングだが、最初424kbpsで実施し、だめだったら212kbpsで実施するようにしている。
確認はしていないが、カード捕捉時の通信速度で処理すると思われるので、まずは速い方で試しているのだ。
ちゃんとやるなら、212kbpsで通信速度を取得して424kbps対応だったら、424kbpsで捕捉し直す、というやりかただろうと思う。
思うけど、めんどくさかったのだ。

 

海外ではNFC-Aしか対応していない端末も考えられるので、Nexus 7がNFC-FでしかSNEPしていないというわけではないんじゃないか、と推測している。
やってみればいいんだけど、ちょっと環境を用意せんといかんけんね。

やつが来た

来る来るシリーズの最終回です。

image
Nexus 7が来た。
残業ばりばりの計画を立てていたのだが、「今日は帰らんと」と会社を追い出されたので、急いで宅配の会社に電話したら間に合ったのだ。
ありがとう、西部運輸。

私が最初に買ったAndroid端末は、SmartQ5。
その次が、A500。
これが3台目になる。
2台目から覚えたのは、設定アプリの画面で、Androidバージョンの列を連打すること。
3.1はゾンビが、3.2はハチが出てきた。
さて、今回は・・・、ああ、なるほど、というものが出てきた。

端末のことはどうでもいいのだが、せっかくなので感想を少しだけ書いておこう。
  • 片手で持てるし、滑りにくい
  • 2000円分のGoogle Play買い物ができるので、ATOK(\1,500)を買った
  • 自分の作っていたEjectSD4をインストールしたら、パッケージが変って言われた
そう、感想とは関係ないのだが、自分が作っていたアプリがインストールできなかったのだ。

mmでビルドしてapkファイルだけアップしていたのだが、どうもmmでビルドした場合にはodexというものも一緒にできるらしい。
確かにできていた・・・が、全然気にしていなかった。
検索すると、kinnekoさんのところに書いてあった。
WITH_DEXPREOPTをfalseにするといいらしい。
Android.mkに「WITH_DEXPREOPT := false」と書いておくと、今度はapkだけになった。
なるほど、そういうことか。
って、前も同じことをやったような気がしてきた。

そしてアップし直したのだが、それはそれでエラーになった。
「エラー-24」って言われるけど、なんだ??
エミュレータにadbでインストールしてエラーを見てみようとしたら、こっちはうまくいった。
???のままだ。

そんなところか。
3.2まではなんとかついて行っていたつもりだが、そこからずいぶんと取り残されてしまったようだ。
まあ、逃げていくわけでもないから、ゆっくりやろう。

NFC ?
ああ、そんなのもあったね。
・・・嘘です。最初に試したのはAndroid Beamでした。
それはまた、次回に。

うちのは、10時くらいにちょっと寄っていったらしい

さて、会えそうで会えないNexus 7だが、今日の10時くらいにうちに寄ったらしい。
ね「よっ、いるかい?」
店「今、でかけてるよ」
ね「てやんでぃ」
といったかどうか知らんが、南区の方に帰っていった。
ここまで秘密にしていたが・・・うちは福岡にあるのだ。
だから、この南区というのも、福岡市南区なのであった。

さて、この配達だが、FedExではない。
FedExから依頼された西武運輸からになっている。
あまり流通のしくみは知らないのだけど、いくらFedExといえども日本国内に配達するような網を持つよりも、依頼した方が安いってことなのかね。

再配達は、電話でお願いするみたいだ。
そういえば、しばらく前まではどこもそういうシステムだったなぁ。

2012年10月1日

うちのNexus 7は泉南市まで来たらしい

わざわざ遠くから、すまんね・・・。
image
SENNAN-SHIってどこだろうと思ったら、泉南市だった。
泉南市ってどこだろうと思ったら、大阪だった。
うむ、しかさんの予言通りだ(預言ではないよ)。

水曜日、ちゃちゃっと仕事を終わらせて帰ってみようかと思ったが、全然そんな感じじゃない。
目からAndroid Beamが出そうなくらい、切羽詰まってる(Beamの使い方がおかしい)。
なので、もうちょっと泉南市でゆっくりしててもいいですよ。

Fukuoka NFC Hack 5に途中参加しました

今日は、Fukuoka NFC Lab(NFC Labの福岡支部ではない)の5回目に参加した。
途中参加なのは・・・疲れ果ててたから。
来週からいろいろあるので、殺気立ってるといったほうがいいかもしれん。
まあ、これは個人的な話だ。

朝から始まっていたのだけど、参加したのはたぶん14時くらいからか。
参加者は私も含めて7名(だったはず)。
初めて、こういうのに参加して「みんな知ってる」という状態だった。
しかさんに、久しぶりにお会いしたのがよかったですな。
Androidのとき以来だなぁ。

今回はハッカソンということで、着いたときにはみんな何か作っていた。
私もなんかせんと、ということで、ARMのCortex-M3(FM3)で動かしていたNFCライブラリのSNEPを整備することにした。
幸い、私もようやくNexus 7という人並みのものを手に入れていたので、会話に多少はついていくことができた。
Nexus7がなかったら、危ないところだった・・・。

と書くと、すごく堅苦しいように見えるかもしれないが、特にそういうことは無い。
わからんところはスルーするし、知らない話も聞けてなかなか面白い。
こういう集まりって、似たようなことに興味を持ってるけど違うことをしている人達が集まるから面白いのだよな。
私も何かネタを提供したいのだが、まあ、そんなん無いしね。

最後に、何をしてたか軽く発表しておしまい。
お疲れ様でした~。

私が何をやってたかというと、SNEPでPUTする環境だけ作っていて、それに載せるNDEFとしてURIを追加した、というところだ。
今まではTEXTのみだったのだ。
TEXTができるならURIはすぐだろう、と思っていたのだが、なかなかうまくいかんかった。
理由は、
  1. URIを受信したときの動きがわかってなかった
  2. URIを作り間違えていた
だ。
2番目は、単なる実装ミス。
1番目は今もまだちゃんとわかっていない。
Beamを送信するときはスクリーンをタップするのだが、PCからNexus7に受信させようとしているのに、Nexus 7がタップ待ちのような画面になるのだ。

まあ、そういうのは余力があるときに調べよう。