メモ。おもしろくないので興味ある人だけどうぞ。
※(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:144462.マルチパートメッセージの入れ子に対応していない。これは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なんてファイルが添付されいてると、添付ファイルがあるパートデータを<テスト>.gifで探すので表示でない。
明かにバグなのだけど…。どうするのがベストなのかわからないので、とりあえず、findPart()するときにunescapeするようにした。
Review:14523なんでescapeXML()してるかといえば、表示するためのマークアップ(Smil)がXMLだから。
