[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を読むことができないんじゃなかろうか？」は、インテントフィルタなどを書けばできる、みたいなことを書いてあった。
まあ、あまりそういうのは興味がないので、いいや。