Friday, April 23, 2010

Nexus One MMS まとめ

メモ。おもしろくないので興味ある人だけどうぞ。
※(2010/05/05追記) 下記修正はすべてAndroid Open Source Projectにマージしてもらえました。AOSPをベースに開発されているCM-5.0.7にも取り込まれてます。


まず純正ファームウェアでの問題点。

SoftbankのMMSサーバはUser-Agentにより接続を拒否するので、MMS本文のダウンロードができない。
これは、CyanogenMod 5.0.6 (5.0.5以降?)を導入することにより解決する。(User-Agentを変更できる)

さて、以下はAOSP Android2.1,CyanogenModに共通する問題点。

1.WAP DataにMMSの仕様で定められているPduHeaderに準拠しないバイトデータが現われる。
WAPではデータを短く表現するために、ヘッダを1バイトのデータで表現し、続くバイトデータをそのヘッダの仕様に沿って解析する。
が、SBMのMMSサーバはそのヘッダオクテットを付けずにいきなり文字列ヘッダを送ってくる。
その中身は "X-Mms-Vodafone-Notif-Text" であり、続くデータは端末上で通知に使う本文の冒頭部分と思われる。
この冒頭文に、PduHeaderでつかわれるバイトデータと同じものが含まれていると、解析済みのヘッダデータを破壊する。
結果、Content-Locationヘッダ("0x83")のデータを破壊し、本文のダウンロードができなくなる。
あるいはMMSアプリが強制終了したりする。(冒頭文の内容による)

例: logcatしながらMMSを受信すると
D/WAP PUSH(  188): Rx: 0f0603beaf848c82984a42414141473338496f526c59553478675173313868722f47665233416741414141414141414141
008d928914806e756c6c406578616d706c652e636f6d009606ea546573740086818a808f818e019388058103278d008368
7474703a2f2f6d6d732f4a42414141473338496f526c59553478675173313868722f476652334167414141414141414141
4100582d4d6d732d566f6461666f6e652d4e6f7469662d54657874006d65737361676520626f647900582d4d6d732d566f
6461666f6e652d4e6f7469662d454f4c003100

のようなデータを受けとる。
この文字列は次のようなコードと人力でデコードできる。
#!/usr/bin/ruby
WAP =
"0f0603beaf848c82984a42414141473338496f526c59553478675173313868722f476652334"
"16741414141414141414141008d928914806e756c6c406578616d706c652e636f6d009606ea"
"546573740086818a808f818e019388058103278d0083687474703a2f2f6d6d732f4a4241414"
"1473338496f526c59553478675173313868722f476652334167414141414141414141410058"
"2d4d6d732d566f6461666f6e652d4e6f7469662d54657874006d65737361676520626f64790"
"0582d4d6d732d566f6461666f6e652d4e6f7469662d454f4c003100"
char = false
a = WAP.scan(/../).each do |x|
c = x.hex & 0xFF
if c >= 32 && c <= 126
print "%c" % c
char = true
else
print "\n" if char
print "0x%02x\n" % [x.hex & 0xFF]
char = false
end
end
print "\n"

結果と意味(文字列は便宜上quoteした)
0x0f 0x06 0x03 0xbe (SMS header?)
0xaf (START) 0x84 (ShortInt: 0x84 & 0x7F = 4)
0x8c (MESSAGE_TYPE) 0x82 (MESSAGE_TYPE_NOTIFICATION_IND)
0x98 (TRANSACTION_ID) "JBAAAG38IoRlYU4xgQs18hr/GfR3AgAAAAAAAAAA" 0x00 (NULL)
0x8d (MMS_VERSION) 0x92 (ShortInt: 0x92 & 0x7F = 18: (18 >> 4 = 1).(18 & 0x0F = 2) = 1.2 )
0x89 (FROM) 0x12 (Length:18) 0x80 (FROM_ADDRESS_PRESENT_TOKEN) "null@example.com" 0x00 (NULL)
0x96 (SUBJECT) 0x06 (Length:6) 0xea (Charset(ShortInt: 0xEA & 0x7F = 0x6A) = UTF-8) Test 0x00 (NULL)
0x86 (DELIVERY_REPORT) 0x81 (octet)
0x8a (MESSAGE_CLASS) 0x80 (MESSAGE_CLASS_PERSONAL)
0x8f (PRIORITY) 0x81 (PRIORITY_NORMAL)
0x8e (MESSAGE_SIZE) 0x01 (COUNT:1 (next 1byte)) 0x93 (LongInt: 0x93 = 142)
0x88 (EXPIRY) 0x05 (Length: 5) 0x81 (VALUE_RELATIVE_TOKEN) 0x03 (COUNT:3) 0x27 0x8d (((0x27 << 8) + 0x8d) << 8 = 2592000) 0x00 (NULL) (2592000secs = 30days)
0x83 (CONTENT_LOCATION) "http://mms/JBAAAG38IoRlYU4xgQs18hr/GfR3AgAAAAAAAAAA" 0x00 (NULL)
"X-Mms-Vodafone-Notif-Text" 0x00 (NULL)
"message body" 0x00 (NULL)
"X-Mms-Vodafone-Notif-EOL" 0x00 (NULL)
"1" 0x00 (NULL)

という具合になり、ヘッダオクテットなしにテキストデータおくってくる。
これはWAPというかMMSの仕様よく読めばなんかわかりそうだけど。
この"message body"の位置に0x83だとかヘッダ意味をもつオクテットが含まれる文字(日本語によくある)がくると、parserがヘッダだと誤認し、データがぶっこわれる。
ヘッダ部分にUTF-8の1st byte(32-127)がきたらとりあえず文字列として処理することでうまくいく。
というかiPhoneはこんな特殊なケースもちゃんと処理してるのがえらいなぁ。たぶんこの文字つかって通知に本文だしてる。
いろいろためしたが、この修正でたぶんOK. Review:14446


2.マルチパートメッセージの入れ子に対応していない。
これはHTMLメールや携帯のデコレーションメールなどによく見られるのだが、multipart/mixed中にmultipart/alternativeのパートがあり、これによりMMSアプリが本文の解析に失敗する。
つまり
- multipart/mixed
-- multipart/alternative
---- text/plain
---- text/html
-- image/gif
-- image/gif

というような構成になっているメール。
例えば、デコレーションメールは本文をHTMLで表現し、添付している画像をHTML中で参照するという仕組みなのだが、HTMLメールを表示できない端末向けにとりあえず本文だけでも表示できるように、multipart/alternative で text/plain を追加している。(alternativeというのはそういうためのもの)
frameworkのMMS本文解析がこれに対応していない(multipartの入れ子を解析していない)ので受信できても表示できないままとなる。
multipart/alternative があらわれたら中身を再帰的に解析し、1番目のパートを本文として使用することで解決。 Review:14466
ただし、デコメはそもそもMMSアプリでHTMLメールを表示できないので、送信者の意図通りに表示できるわけではない。


3.「"<>'&」を含む添付ファイルがある場合、添付ファイルのパートをescapeXML()した後で探すので、実際のパート名とマッチせず表示できない。
ようするに、<テスト>.gifなんてファイルが添付されいてると、添付ファイルがあるパートデータを&lt;テスト&gt;.gifで探すので表示でない。
明かにバグなのだけど…。どうするのがベストなのかわからないので、とりあえず、findPart()するときにunescapeするようにした。 Review:14523
なんでescapeXML()してるかといえば、表示するためのマークアップ(Smil)がXMLだから。

Tuesday, April 13, 2010

続: SBM MMSをNexus Oneで使う

※ このエントリはカスタムROM(CyanogenMod)導入を前提にしてあります。カスタムROMに疎い方は読まない方がいいです。

※ 追記(04/16):CM-5.0.6がリリースされたので差分だけをupdate.zipにしたのを作りました。CM-5.0.6を導入後にリカバリよりFlashしてください。ダウンロード

前回のエントリはいやはや不完全でありました。
実際のところ、Mms.apkのUser-Agentを変更すればMMSを受信することはできたのですが、完全ではなく、受信通知はされるが「ダウンロード」表示になったり、通知すらされないこともありました。

で、いろいろ調査した結果、問題はframeworkのPduParser.javaにありました。
説明すると長くなるので端折りますが、SBMのMMSはMMSの仕様に合ってない文字列を送りつけており、そのせいでメッセージヘッダの解析に失敗し、OSへの通知までいかない、もしくは本文のダウンロードができない事象が発生していました。
こう書くとSBMが悪いように思えますが、そうでもないかもしれません。実際iPhoneでは受信できますし。

そんなわけで、そのへんを修正することで、問題なく受信ができることを確認しました。
ただし、当方ではsmile.worldの環境しかありませんので、open.softbankのMMSでは確認していません。

手順
. CyanogenMod 5.0.6-test3.jrf.2をダウンロードする
. CyanogenModを導入済みならば、いつも通りリカバリからFlashする。(gappsも必要ならFlashする)
. その他のROMの場合はwipeしてからFlashする。
. カスタムROMを導入したことがなければ、Googleで調べる。
導入するとこうなります


. メッセージアプリ(Mms.apk)の設定でUser-Agentを設定する

smile.world(黒SIM)なのでiPhoneにします。


ちなみに、このROMは5.0.6-N1-test3のソースコードをベースに日本語リソースの追加と、上記MMSの修正をしてあります。(Mms.apkのソースには手を入れていません)
また、APNリストにSoftbankとNTT DoCoMoを追加しておきました。
それ以外はCMそのものと思ってよいです。

手元では何度となくテストをして問題がなかったのですが、これでダメだったりすると結構手をいれないといけなさそうです。
あと、iPhoneにある新着MMS受信アプリ的なものがないので、そのへんは別途考慮しなくてはならなさそう。

※ 追記: Desire Camera(r1)など、framework.jar を上書きするModを導入すると使えなくなりますのでご注意を。
※ 追記: Desire Camera(r2)はframework.jarを弄らないので大丈夫そうです。