2013/05/28

[n7]ソフトの改造をしよう (1)

今週は、毎日定時で仕事が終わりそうな予感がする。
こういうときに、勉強をしておかねば。

そんなわけで、Nexus7の改造をすることにした。
改造、といっても分解するわけではなく、ソフトウェアの改造に留まる。

目的がないと勉強してもつまらない。
まずは「かざしている間だけNFCが動作する」にしよう。


前に、「かざす」という動作をどうやって端末で実現させるか検討したが、一番楽なのはハードウェアキーを押している間だけにする、というものだった。
まあ、かざす、というには弱いが、人間の意思をどこかに入れたいので、それをハードウェアキーに託したというところだ。

Nexus7には、ハードウェアキーが3つしかない。

  • 電源ボタン
  • 音量アップボタン
  • 音量ダウンボタン

ホームボタンなどはソフトウェアキーなので、対象外だ。

この3つのうち、自由に使えそうなのは音量ボタンだと思う。
つまり、こうしようと考えている。

音量ボタンを押している間だけ、NFCの動作ができるようにする

 

音量も変更させたいだろうから、どうにかして動的な切替ができるようにせんといかん。
そこは・・・あとで考えよう。


Froyo時代に調べた資料があったのだが、さすがにパスなどが変更されている。
仕方なく、今の動きから調べることにした。

入力イベントをさばいているのが、frameworks\base\services\input\EventHub.cppのようだった。
ここのEventHub::getEvents()だ。
gdbclientを使ってブレークポイントを設定すると、何度も止まった。

(gdb) bt
#0  android::EventHub::getEvents (this=0x65336af0, timeoutMillis=-1,
    buffer=0x65336ea0, bufferSize=256)
    at frameworks/base/services/input/EventHub.cpp:646
#1  0x67f0162a in android::InputReader::loopOnce (this=0x65336d98)
    at frameworks/base/services/input/InputReader.cpp:268
#2  0x67f02dd8 in android::InputReaderThread::threadLoop (this=0x6533a3f8)
    at frameworks/base/services/input/InputReader.cpp:838
#3  0x401cfc76 in android::Thread::_threadLoop (user=0x6533a3f8)
    at frameworks/native/libs/utils/Threads.cpp:796
#4  0x4022c1f2 in android::AndroidRuntime::javaThreadShell (
    args=<optimized out>) at frameworks/base/core/jni/AndroidRuntime.cpp:991
#5  0x401cf7cc in thread_data_t::trampoline (t=<optimized out>)
    at frameworks/native/libs/utils/Threads.cpp:132
#6  0x40143a54 in __thread_entry (
    func=0x401cf739 <thread_data_t::trampoline(thread_data_t const*)>,
    arg=0x653402b8, tls=0x6acf5f00) at bionic/libc/bionic/pthread_create.cpp:92
#7  0x40143bd0 in pthread_create (thread_out=0x697f5bac, attr=<optimized out>,
    start_routine=0x78, arg=0x653402b8)
    at bionic/libc/bionic/pthread_create.cpp:201
#8  0x00000000 in ?? ()

さかのぼってみたが、どうもスレッドでぐるぐる回っているところらしく、イベントの発生地点はこれからではわからなさそうだった。

電源ボタンを押したときの処理は、policyのPhoneWindowManager.javaだったよなぁ、と思って音量ボタン押しにブレークポイントを設定してみたが、止まらず。
これは、アタッチしたプロセスが悪いのかもしれない。
けど、その部分をまるまるコメントアウトしても音量ボタンの操作ができたので、ここではないみたい。

 

面倒になったので「KEYCODE_VOLUME_UP」でjgrepすると、media/java/android/media/AudioManager.javaが出てきた。
handleKeyDown()やhandleKeyUp()があるので、処理をコメントアウトすると音量ボタンを操作しても何も起こらなくなった。


今日の調査は、ここまで。

手を加えるなら、AudioManager.javaではなく、これを呼び出した上位層にしたいものだ。
電源ボタン+音量ダウンボタン同時押しでスクリーンショット撮影とか、ああいうのと同じ階層にできるのが望ましいところだ。

2013/05/26

なぜType 3 TagのAttribute Informationブロックに可変情報が含まれているんだろう

「なぜ」で始めると、その説明をするように見えるかもしれないが、そうではない。
純粋な疑問として書いているのだ。

何かというと、FeliCa LiteなどのType 3 TagのNDEFについてだ。
PAD0にはAttribute Informationということでいくつか情報を書くのだけど、そこにNDEFメッセージのバイト数を書き込むことになっている(書き込み中フラグもあるけど・・・まあそれは置いておこう)。

Type 2 Tagには、そういう可変情報はあまりない。
CC0にマジックナンバーを書き込むことで、NDEFのデータを含んだタグ、という意味になる。
CC0はCCブロックにあり、他にCC1~3もあるのだが、ここに書き込む値も固定値でよい。
だから、CCブロックに固定値を書き込んでブロックを書き込み禁止にすると、このタグはNDEF用にしてしまえるのだ。

しかし、Type 3 Tagのそういう情報はAttribute Informationにあり(といってもマジックナンバーなどはないが)、書き込むたびに更新せんといかんので、めんどくさい。
ただでさえシステムコードとかブロックリストとかでめんどうなのだから、もうちょっとデータ自体へのアクセスを簡単にできたら、Type 3 Tagも使いやすくなるんじゃなかろうか。

 

と思ったが、NXPのMIFARE Classicもアクセス方法は十分面倒だと思うが、かなり普及している。
やっぱり、最後は値段なのか。。。

そんなわけで、早くFeliCa Lite-Sがスイッチサイエンスさんから販売されないかな-、と期待している私であった。
ほら、Lite-Sの方が安価にできるという話だし。
そうじゃないとしても相互認証ができるんだから試したくなるではないか(片側認証とは違うアルゴリズムっぽいが)。

NFP + NDEF Library

WindowsのNFP(Near Field Proximity)により、Windows8ではNFCをOSレベルで扱うことができるようになった。
が、取得したデータの解析はあまり楽にできないようだ。

それじゃつらかろう、と思ったかどうか知らないが、NDEFライブラリがCodePlexにある。

NDEF Library for Proximity APIs (NFC)

まだ読む方しか試していないが、自分でbyte[]を解析しなくてよいので、楽そうだ。

久々に、hiro99ma siteにも追加した。
ソースも置きたいところだが、なんか出来が悪すぎて置いてない。
ストアアプリ自体をわかってないので、画面も真っ黒だし、ダイアログを出そうとするとコンテキストがよくないのか例外が発生するしで、さんざんなのだ。

 

Windows8はインストールされているものの、ストアアプリを全然使っていないので、あんまりやる気が出ないのだな。
デスクトップアプリからだと、NFPは使えなさそうだし。。。

いや、普段はWindowsを使うことが多いので、Windowsで動くNFCアプリを作ることができた方がよいことはよいのだ。
ただ、

  • NFPはWindows8以降でしか動かなさそう
  • NFPはストアアプリでしか動かなさそう
  • Windows7以前では、共通のAPIがなさそう(PC/SC?)

と思っているからなのだが、実際はどうなんだろう?
Windows8以降しか動かん、というのは仕方ないとしても、ストアアプリでもデスクトップアプリでも動いてくれるようにならんかなぁ。

2013/05/23

[android]AAR (2)

意外なことに、AARの続きだ。

packages/apps/Nfc/src/com/android/nfc/NfcDispatcher.javaのtryNdef()。
ここでAARの処理を行っている。

  1. NDEFメッセージの先頭から順にActivityを起動していく。
    起動できるものがあれば、そこでおしまい
  2. 起動できるActivityがなかった場合、NDEFメッセージの先頭に入っている要素を取ってきて、PackageManager.getLaunchIntentForPackage()でIntentを取得して、それを起動させようとする。
    起動できたら、そこでおしまい。
  3. "market://details?id=パッケージ名"のインテントをIntent.ACTION_VIEWで作って、起動させようとする。
    起動できたら、そこでおしまい。
  4. NfcRootActivityを起動

こんな感じみたいだ。

複数のAARを含んだNDEFメッセージの場合には、注意が必要だ。
どれか1つでもアクティビティ起動できたら、そこでマーケットまで行かずに終わってしまうからだ。
どういう用途があるかわからないけど、そういう動きになるようだ。


さて、ここからは私がよく知らないところだ。

インテントだから、指定できるものはなんでもいいんじゃないのか?と思ったのだ。
でも、Intent.setPackage(String)だから、やっぱりパッケージ名しかだめなのか。

PackageManager.queryIntentActivitiesAsUser(intent)でアクティビティが見つかるならばいいようだ。
試してみねばならぬのぅ。

2013/05/22

名刺とNFC

私は、個人用の名刺を持っていない。

まあ、持っていたからといって渡す相手もいないのだが、名前を覚えるのが苦手な私としては、「せめて、せめてお名前だけでも・・・」という気持ちだ(そして、名前しか残らなかったりする)。

 

そして、このサイトの特徴からすると、名刺にはNFCタグが貼られている方がよいだろう。
では、どのタグがよいのだろうか?

私の中では、今のところMIFARE Classic 4Kだ。

たとえば、次の画像を見ていただきたい。

image

これはサイズが128x128なのだが、これでもJPEGで11.3KBある。
さすがに大きいので、2値化してみる。

image

これで3.3KBくらいだ。
2値Windows Bitmapの方が軽いかも、と思ったが、そうでもなかった。
ある程度のサイズからはBitmapの方が有利になるかもしれんが、このサイズでは無理そうだ。
JPEG2000のコーデックを今もってないので試せないが、IC運転免許証でも使われているくらいなので、このサイズでもいい圧縮率かもしれん。

ともかく、画像をこの半分くらいにしても、4KBあれば格納できそうだ。
64x64くらいのサイズでも、その人の面影はわかるんじゃなかろうか。

というわけで、4KBくらいのNFCタグがあるとよいだろう。
そうなると、今のところMIFARE Classic 4Kしかないかな、と。
残念なことに、NFC Forumの対象外だがね。


名刺用のNDEF、というものは、今のところないだろう。
Signatureがあるが・・・あれはどうなんだ?
調べていないものをあれこれ言うことはできないのだが、今のところNDEFには「お墨付き」のような署名機能がないから、Signature NDEFもどこまで効力があるかわからんな。

デファクトスタンダードを作り上げるというのが、業界としては面白いところなのかもね。

2013/05/21

[android]AAR

「AARとかどうですか?」というコメントをいただいた(ここじゃないどこかで)。

うーむ、Androidのみか・・・。
とはいえ、現在の人口に膾炙された開発環境の中で一番自由にNFCを扱うことができるのはAndroidだと思っている。
そりゃ、Arduino + NFC Shield、なんてのもあるのだろうが、OSというかプラットフォームがサポートしている方が「標準」って感じがする。

そんなわけで、AARを知っておいても問題はなかろう、と勝手に判断し、調べることにした。


Android Application Record、の略で、特にNFCとかいう言葉はついていない。
なので、私の知らないところでNFC以外のAARがあるかもしれないし、将来的に取ってあるのかもしれない。

とりあえず、AARはNFCのもの、という前提で話を進めよう。
あ、AARの「Record」は、NDEF Recordのことかもしれない。
なぜなら、AARを作るためのAPIはandroid.nfc.NdefRecordが持っているからだ。

Android Developersによると「AARは、NFCタグを読んだときにアプリを起動させるしくみ」らしい。
ということは、普通のアプリはAARのNDEFを読むことができないんじゃなかろうか?

追ってみよう。


タグの処理は、external/libnfc-xxxでやっているはず。
追うのが面倒なので省略すると、次はpackages/apps/NfcにあるNfcDispatcher.javaだ。

dispatchTag()は、たぶんlibnfcからjavaに処理が渡される最初の方だったと思う。
あまり内容を読まずに判断するなら、こういう順で判定しているようだ。

  1. オーバーライドできるか(知らん。。)
  2. Bluetooth Handoverかどうか
  3. NDEFかどうか
  4. ふさわしいTechnologyかどうか
  5. アクティビティを開始できるか
  6. マッチしなかった

AARかどうかは、3番で判定している。
処理の最初でNDEF Record Layoutの、

  • TNFはexternal type(0x04)か?
  • TYPEは"android.com:pkg"か?

を見て、両方trueだったらペイロードをUS_ASCIIでデコードしてパッケージ名としてリストに詰める。
詰められたパッケージ名は、先頭から順にdispatch.intent.setPackage(パッケージ名)とされる。

Android Developerに「AARのみのNDEF Messageじゃないなら、AARは先頭に置いたらいかんよ」といっているのは、こういうわけだ。先頭がAARだったら、後のレコードがどうなっていてもAARとして扱ってしまうからだろう。


AARの実装を斜め読みしたが、なんとなくわかっていただけただろうか?

私の期待としては「AARにはアプリ起動以外になにかできることが隠されているのでは・・・」なのだが、ぱっと見たところそういうのはなさそうだった。

しかし、なにか面白い使い道があるかもしれんので、もう一度どこかで見直すことにしよう。

 

あ、最初に書いた「普通のアプリはAARのNDEFを読むことができないんじゃなかろうか?」は、インテントフィルタなどを書けばできる、みたいなことを書いてあった。
まあ、あまりそういうのは興味がないので、いいや。

2013/05/19

RTD TEXTを読み返す

なんだかんだで、2ヶ月くらいNFCやってない。
まずい、まずい。。。
このままフェードアウトしそうな気がしてならないが、まあそれはそれで悪くはない。
が、もう少しあがいてみよう。


slideshareは縦長の資料には向かないなぁ。
でも月刊NDEFは印刷をメインに考えたものだから、A4縦になってしまったのだ。
まあ、そんなことよりも、内容の薄さの方が気になって仕方がない。
やっぱり気が抜けてきたのかなぁ。

2013/05/12

「かざしてない」問題

NFCを搭載した端末に対して不満に思うことがある。
それは「かざしてないのに反応する」というところだ。

かざしてない、というのは変かもしれない。
「かざす」という意思がないのに、端末が「かざした」と判断して動作してしまう、ということだ。
今のところ「かざす」のところに、人間の行動の意思が入っていないので、こうなってしまうのだろう。

Android端末だと、ロック状態になればNFC動作は止まるものの、それまでは動いている。
だから、何気なく机の上に置いたりすると、そこにちょうどNFCタグがあって反応することがある。
これがどうしてもいやでねぇ。


かざす、というのは非常に簡単な動作のため、端末自身では判別することが難しいと思う。
NFCだけでなく、別のセンサを使って解決するしかないのではなかろうか。

まずは、スイッチ系だろう。
「かざす=スイッチが押されている」ということだ。
端末の左右にボタンを付けて、それを挟むようにしてかざす、というイメージだ。
まあ、これは左右じゃなくてもいいけど、押したままかざすのだ。

 

熱センサとかもありかも。
特定の位置に指を当てて熱を与えているときだけ搬送波が出るとか。
「かざす=特定の位置に熱を与えている」ということだ。
まあ、これは手が冷たかったら使えないから、無理か。

なら、指紋センサみたいなものならよいか。
あれも、指をなぞらせるタイプじゃなくて、置くだけでよいならいいのかも。
「かざす=特定の位置に指を当てている」か。
そういう部品もあるのかな?

 

ちょっと割り切りが必要だが、加速度センサでもいいかもしれない。
左右に振っているときだけ搬送波が出るのだ。
「かざす=端末を振っている」だが、これはカバンの中とかでも反応してしまうかもしれないし、そもそも別の機能が加速度センサを使うかもしれない。
これは無し、かな。


とにかく、これを解決しないことには、NFCが「かざして使う」ということにはならんのじゃないか、と心配している。

[android]AOSPのアプリをEclipseでデバッグできる

昨日あきらめたAOSP(って呼び名かどうかも自信がなくなってきた。素のmasterね)のJavaアプリデバッグ。
調べるといろいろ出てきた。

たぶん、ポイントはこんなところか。

  • EclipseのJava Projectを作って(Android Java Projectではなく)、AOSPの頭から全部をソースの対象にする(Use default locationをはずして、AOSPの頭にした)。
  • EclipseのDDMSを開いて、Deviceからデバッグしたいプロセスを選択しておく。そこにポート番号が書いてあるので、覚えておく(2つ書いてあって、たぶんもう片方は8700だと思う)。
  • Debug Configurationsで「Remote Java Application」をつくり、作ったプロジェクトを選択し、Portに8700を設定する。
  • デバッグを実行すると、警告とか出てくるが、気にせず進める。
  • ソースを開き、ブレークポイントなどを設定する。
  • Android側アプリを操作すると、たぶん停止してくれる。

Java Projectを作るのに時間がかかる。
そしてエラーが大量に出るのだが、気にしなくていいようだ。

AOSPのソース全部をプロジェクトに置かなくてもできるのでは・・・とやってみたが、だめだった。
ブレークポイントに止まらなかった。
全部置けばいいやん、と思うかもしれんが、時間がかかるのよ。。。
それに、Windowsからでもできるらしいのだが、そうそうソースファイル全部なんて取って来れないしね。

まあ、できることがわかっただけでも、よしとしよう。

Eclipseの自動ビルドは、はずしておいたほうがよいよ。
ビルドしたいわけじゃないのでね。

[android]AOSPのアプリをEclipseではデバッグできないのか?

どうでもいい話を先にするが、前のサイトと移転してきたこのサイトは、どちらも「技術ブログ」を目標に書いてきた。
私はだいたい、役に立つとか立たないとか、そういうのはあまり気にせず、調べたことや思ったことを各人間のようである。
なので、今はNFCのことが多くなっているが、あまりそこにはこだわっていない。

が、だ。

せっかくこんだけ書いているので、Google AdSenseをやってみるといいのでは!と思ったのだが、審査でNGになってしまった。
理由はわからんのだが、私は「内容がいろいろあって絞ってないからでは?」と思っている。
NFC以外の記事を削除しようかと考えたこともあるが、それも私らしくないのでこのままにしている。


さて、前口上はこのくらいにして、記事を書こう。

Nexus7に、repo syncしてきたmasterのソフト一式を焼けるようになった。
ふつうにinitして、syncして、mビルドして、fastboot flashallする、というところだ。
lunch full_grouper-eng、とすることで、デフォルトがroot状態になるのもありがたい。
(adb remount、で済むから。)

さて、では/system/app/にあるアプリをデバッグすることはできるのだろうか?
ローカルアプリなら、Eclipseであーだこーだすればできるのだが、/system/appとなると敷居が高そうだ。
プロセスとして動くものなら、gdbでアタッチすると行けそうな感じはしている(『組込みプレス』No16を読んで)。
では、Javaアプリはどうだろうねぇ。

 

いろいろ検索したが、本家に書いてあった。
http://source.android.com/source/using-eclipse.html

「The Eclipse build is just for error checking」と書いてあるから、エラーチェックだけには使えるよ、ということだろう。
うーん、目標達成できずか。。。
printfデバッグ(Log.dデバッグか)は、けっこうめんどくさいんだよな・・・。

 

でも、と私は思った。
ビルドするための情報はすべてこちらにあるのに、デバッグがまったくできないなんてことはあるのだろうか?と。
JavaもAndroidもLinuxもよくわかってはいないのだが、Eclipseでアプリビルドするのと、mmでビルドするのとでそこまで大きく違った生成物ができるわけでもないだろう。
ならば、条件さえ整えば、いけるんじゃなかろうか?

 

というわけで、情報があれば教えてください・・・。

2013/05/09

FeliCa StandardとFeliCa Liteの見分け方

むりやり、ネタを作った感じで申し訳ない。

世の中には、FeliCa StandardとFeliCa Liteというものがある。
おそらく、FeliCa Standardに類するものを持っている人が多数だと思う。
nimocaしかり、Suicaしかり。

しかし、NFC Forum的には、FeliCa Liteの方が使いよい。
なぜなら、NDEF対応するのが簡単だからだ。それに、入手しやすいし。

そんなわけで、NFC開発をやっている人のところには、FeliCa StandardとFeliCa Liteがたくさん集まっている可能性が高い。
もしかすると「このカードって、FeliCa Liteだっけ、Standardだっけ?」となるかもしれない。
まあ、ならないのが普通なんだけど、そうなった将来に備えておいてもいいんじゃないかと思った。


答は簡単で、「システムコード0x88B4を指定したポーリングに応答があるかどうか」で決まる。
応答があればFeliCa Lite、そうでなければ、それ以外だ。

 

これで決まりだ、と思いたいのだが、実はそこまで確信が持てない。
FeliCa Liteのシステムコードは仕様として決められているが、FeliCa Standardのシステムコードが「0x88B4を使わない」という記述を読んだことがないからだ。
使うことはないと思うのだが・・・。

 

念のため、システムコード以外の区別方法も説明しておこう。
それは、FeliCa Standardにはあって、FeliCa Liteにはないカードコマンドを発行することだ。
FeliCa Liteに使えるコマンドは3つだけである。

  • Polling
  • Read Without Encryption
  • Write Without Encryption

FeliCa Standardともなると、コマンドはかなり増える。
「Request System Code」なんかは発行しやすいコマンドじゃなかろうか。
FeliCa Liteにはないコマンドが使えるなら、それはFeliCa Standardと考えてよかろう。

2013/05/03

[n7]Nexus7のroot化をしてみた

「助さん、格さん、もういいでしょう」というわけで、Nexus7のroot化なるものをしてみた。

やりたかったのは、repo syncでとってきたmasterをビルドして焼いて、あとはデバッグするところまでだ。
既に情報があるので、ビルドして焼くところまではうまくいった。
おおざっぱに手順を書き残しておく。
ほとんど、穀風さんのところで事足りた。

穀風: Nexus7 用に Android をビルドしてみた (1)
穀風: Nexus7 用に Android をビルドしてみた (2)
穀風: Nexus7 用に Android をビルドしてみた (3)

 

ビルドまで

  1. repo syncでとってくる
  2. Googleのバイナリ提供ページからNexus7のものを持ってくる
  3. make

 

焼くためにbootloaderのunlock(1回だけ)
コマンドを打つと、Nexus7側に画面が立ち上がって、確認を求められる。
unlockすると、起動時に鍵の外れたアイコン表示が出る。
あと、データが全部消されるみたいなので、バックアップしておこう(まあ、焼くから全部消えるんだけど)。

  1. fastboot oem unlock

 

焼く
Nexus7はbootloaderモードというのか知らんが、緑の彼がおなかを開いている画面にしておく。
Linux側は、lunchしておかないと環境変数設定が足りなくなるようだ。
USBをPCの前に挿してやってたのだが、途中で止まってしまった。
後ろから挿すとうまくいったので、そういうのがあるようだ、ということは覚えておこう。

  1. out/target/product/grouperまで移動
  2. fastboot -w flashall


これで焼くことはできるのだが、デバッグのためにapk差し替えなんかがやりづらい。
そのため、root化することにしたのだった。
lunchのとき、full_grouper-userdebugを指定したのだが、full_grouper-engとかだったらrootになってくれるのかもしれん(てきとう。。)。

nexus7、android4.2.2でroot取得 - 横章きままにガジェットライフ

recovery modeなるものがあり、そこをカスタム品に置き換えるようだ。
置き換えると、zipファイルからインストールするしくみができるようで、suするアプリかなんかをインストールしてくれるようだ。

今の最新版っぽいファイルを使うことにした。

  • recovery-clockwork-touch-6.0.3.1-grouper.img
  • UPDATE-SuperSU-v1.25.zip

touchがつくのとつかないのがあるけど、まねしてtouchがつく方にした。

ZIPは、/sdcard/の下に置いたけど見えず。。。
でも、/sdcard/0/の下にいるようだった。
ふーん。

 

SuperSUまでインストールはできたようだ。
で、そっからどうしたらいいのだ?
adb shellでremountしようとしたけど、permissionが足りんとか言われるのはそのままだし。。。
じゃあsuすればいいかと思ってやったけど、コマンドプロンプトで止まってしまうし(Nexus7画面には、何か認証したっぽいメッセージが出てきた)。。。
うーむ。。。

めんどくさくなってきたので、engでビルドし直すことにした。
逃げている感じがかなりするのだが、まあいいや。

2013/05/01

[nfc]NFCの検知

NFCの検知は、いくつかタイプがある。
たまには、そんな地味な話を書いてみよう。


タグ側にとっては、基本的に搬送波がトリガとなる。
だいたいのタグは受け身なので、自分からは搬送波を探しに行ったりしない。
「パッシブ」というやつですな、たしか。

NFCのアクティブタグってのは知らないので、割愛。
やればできるとは思うのだが、電源がいりますな。

 

NFC Dynamic Tag(SONY)とか、Panasonicさんのもそうだけど、あれもパッシブタブだ。受け身だ。
にもかかわらず電源がいるのは、マイコンを動かすほどの起電力を搬送波から得ることができないからだろう(Panasonicさんのは、一部電源不要だけど、マイコンを使うなら必要になったはず)。


R/W側はいろいろとやりようがある。

一番すぐに思いつくのが「ポーリング」だろう。
定期的に搬送波を出して、探すやり方だ(「ポーリング」は一般用語のポーリングと同じ意味)。
Androidも、Windows PCに接続してFeliCaランチャーが起動しているPaSoRiも、Windows8でNFPしているR/Wも、ポーリングしている。

ただ、搬送波をただ出せばいいというわけではなく、NFC-AならNFC-Aの、NFC-BならNFC-Bの、もちろんNFC-FならNFC-Fの搬送波を出さないといけない(NFC-Bは、私はまだ成功したことがないのでよくわからん)。
搬送波を出す、というか、搬送波に答えてもらうためのコマンドを出すというところだ。

AもBもFもコマンドが違うので、3種類を検知しようとしたら、定期的に3種類のコマンドを織り交ぜながら搬送波を出すことになる。
頻繁に搬送波を出すと、検出までの時間は短くなるけど、電源の消費も激しくなる。
AndroidでNFCを有効にしておくと、多少なのかしっかりなのか知らないけど、電源の消費は大きくなってるだろう。

 

じゃあ、タグみたいに待ち受けとくわ、となるのがカードエミュレーションモードだろう。
まあ、モードの意味としては「カード(タグ)をエミュレーションする」なので、やりたいことはちょっと違うのだけど、結果としてそうなってしまう。

おサイフケータイなんか、そうなってんじゃないかね。
うちのP906iはそうだ。
搬送波を検知して(というよりも、搬送波によって電流が発生したことを検知するんだろう)、それをトリガにして動き出す、というところだろう。
トリガの代表格は、駅の改札だろうね。
これだと、自分では無線を出さないから、電池の持ちはよくなる。

 

別の切り口もある。
タグが金属を持つのであれば、金属センサーをトリガにして搬送波を出し始めるとか。
無線を出すのは結構な電力を食うので、物理的なアクションを待つというわけだ。
これは、製品として既にあるのだ(RC-S710)。
こういう「ああ、こういう見方もあるのか」的なものは、好きですな。

 

あれ、いろいろある、とか言っておきながら、3つくらいしか思いつかなかった。
まあ他にもあるとは思うが、このくらいにしといてやるわ、ということで。