前回の記事に対する訂正だ。
FeliCa LiteでNDEFデータが113~127byteのときにはNDEF_DISCOVEREDが上がってこない、という話をした。
しかし、NDEF_DISCOVEREDを指定していてもTECH_DISCOVEREDが来ることがある、というのが前回の話。
じゃあ、TECH_DISCOVEREDが返ってきてもNDEFとして処理すればいいやん、と思ってやっていたのだが、113~127byteのNDEFデータだと、
Parcelable[] pac = intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES);
としてもpacはnullになってしまったのだ。
やっぱり、ちゃんとAndroidが「NDEFだ」と思っているときにしか使えないようだ。
すまん、みんな。
まあ、考えてみればそうよね。。。
NDEFと認識しているから、NdefMessageを作って返しているのよね。。。
Nexus7しか今のところ発生する機種がわかっていない、今回の現象。
logcatには、こう出てくる。
D/NfcDispatcher(8422): dispatch tag: TAG: Tech [android.nfc.tech.NfcF, android.nfc.tech.Ndef] message: null
NfcDispatcherが出している。
SmartPosterだと、こういうログになった。
D/NfcDispatcher(8422): dispatch tag: TAG: Tech [android.nfc.tech.NfcF, android.nfc.tech.Ndef] message: NdefMessage [NdefRecord tnf=1 type=5370 payload=91xxx(略)]
この出力のフォーマットは、こうだ。
"dispatch tag: " + tag.toString() + " message: " + message
だから、messageがnullなのだ。
messageは、
- Ndef.get(tag)がnullでないなら、ndef.getCachedNdefMessage()
- Ndef.get(tag)がnullなら、null
のどっちかだ。
getCachedNdefMessage()は持っている値を返すだけ。
Ndef.get(tag)は、tagがTagTechnology.NDEFを持ってなかったらnullになる。
やっぱり、よくわからんな。
よくわからんので、もうちょっと値で攻めることにした。
まず、ヘッダのNDEFデータ長だけを変えてみよう。
NDEFとして読み込めるデータを、ヘッダに113byteとして登録すると・・・messageはnullになった。
では、NDEFとして読み込めないデータを、ヘッダに128byteとして登録すると・・・同じくnullだ。
つまり、NDEFかどうかはヘッダだけを見ているのではなく、データも確認しているということがわかる。
「チェックサムでは?」と思ったが、データ長が128byteのときは0x00A3、127byteのときは0x00A2と別に変わった値でもない。
(libnfc-nxpでは、uint8_tバッファをuint16_tで加算していってるので、負の数とかは関係ない。)
じゃあNDEFデータのせいかというと、そんなこともないと思う。
それなら、NFC-Fだけじゃなくて他のTechnologyでも発生しそうではないか。
何が起こっているのか確認したい気持ちと、確認しても回避するしかないやんという気持ちがあって、それに加えて「どこがどう動いているのやら」があって、調査打ち切りの方向に進んでいる。
簡単にやるなら、自分でNexus7のソースをデバッグコードを埋め込んでビルドして焼いてみる、なんだけど。。。
リカバリーで元に戻せるという話は知っているのだが、まだちょっと気が引けているのだ。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。