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だから。

続: 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を弄らないので大丈夫そうです。

How to create signed update.zip

カスタムROMを導入してシステム全体をアップデートする度にcacerts.bksやフォントをpushするのが面倒なので自前のupdate.zipを作っておいて、リカバリーモードで一緒に更新することにした。

署名付きzipじゃないとあかんぽいので、下記の手順を踏む。

なにはともあれAOSPをビルドする。
部分的にビルドするのでもいいのかもしれないけど。

適切にディレクトリを構成する。

$ mkdir ~/update
$ cd ~/update
$ mkdir -p system
$ mkdir -p META-INF/com/google/android

必要なファイル(自前で更新するファイル)を放り込む。

 $ find .
.
./META-INF
./META-INF/com
./META-INF/com/google
./META-INF/com/google/android
./system
./system/fonts
./system/fonts/DroidSansJapanese.ttf
./system/etc
./system/etc/security
./system/etc/security/cacerts.bks

META-INF/com/google/android/update-script ファイルを書く。

show_progress 0.1 0
copy_dir PACKAGE:system SYSTEM:
set_perm 0 0 0644 SYSTEM:etc/security/cacerts.bks
set_perm 0 0 0644 SYSTEM:fonts/DroidSansJapanese.ttf
show_progress 0.1 10

zipる。

$ zip -r ~/update.zip system META-INF

署名する。

$ java -jar ~/android-source/out/host/linux-x86/framework/signapk.jar \
~/android-source/build/target/product/security/testkey.x509.pem \
~/android-source/build/target/product/security/testkey.pk8 \
~/update.zip ~/update-signed.zip

update-singed.zipをsdcardにいれといてカスタムROM導入後にリカバリで適用してやれば終わり。
一度zip作っておけばあとはリカバリモードだけで完結するので楽チン。

iPhoneで時刻自動設定

先日のNexus One時刻同期記事のおまけなんですが。
iPhoneでの時刻自動設定の話。

iPhoneには時刻の自動設定機能があります。
この機能は携帯電話キャリアが携帯電話ネットーワーク上に流しているNITZ(Network Identity and Time Zone)というものを使って実現されています。
つまり、携帯電話キャリアがNITZを流していないと利用できません。

日本で正規にiPhoneを購入するとキャリアはソフトバンクモバイルになりますが、ソフトバンクはNITZを流しておらず、時刻の自動設定はできません。
実際、ソフトバンク用のCarrier Bundleファイル(/System/Linrary/Carrier Bundles/Softbank_jp.bundle/carrier.plist)ではNITZサポートを使わないような設定になっており、設定画面には自動設定の項目が表示されません。

さて、ここでiPhoneをjailbreak, sim unlockしてdocomo SIMを使ったらどうなのかという実験をしました。
(jailbreakやunlockは自己責任でどうぞ)

iPhone 3GS OS 3.1.2をPwnage Tool 3.1.5 でJB, Cydia から blacksn0w, NTTdocomo Carrier bundleをインストール。
docomo SIMを差して通話ができることを確認したものの、CydiaにあるCarrier bundleはNITZが無効になっているので、時刻の設定に自動設定がでてきません。

iFileなどをつかって/System/Library/Carrier Bundles/docomo_jp.bundle/carrier.plistを編集します。
SupportsNITZていうkeyのがあるのでfalseをtrueに変更し、保存します。
(※ 2010/04/05 追記: 現在CydiaにあるNTTdocomo Carrier bundle 0.8-0で有効(true)になっているようです)


設定に自動設定がでてきます。

適当に時計をずらしてから、オンにすると直ちに時刻が修正されるのがわかります。

というわけで、iPhoneでもdocomo SIMなどNITZに対応したキャリアなら時刻の自動設定ができました。
まぁiPhoneはiTunesと同期するときに時刻も同期するし、JBしているならばOpenNTPdだとかいくつか時刻同期ツールもあるわけですが…。

Nexus One(Android携帯)の時刻同期のしくみ

ここ最近Nexus Oneの時計がずれるという話題があったのです。
それはCyanogenMod-5.0.4.1というカスタムロムに採用されいている2.6.33カーネルが原因だということが判明してます。(詳細はくろぺんさんが書かれています)

しかしながら、単純にカーネルのせいでずれるにしてもずれっぱなしとはなんとも解せない話でありまして、時刻同期のしくみを調べましたのでまとめることにします。
ちなみに、遅れるのはカーネルクロックだけで、デバイスクロックは遅れていないので、再起動時にカーネルがデバイスが取得する時に元に戻ります。(カーネルは起動時に物理デバイスから一度だけ時刻を取得し、以降は自前のロジックで時を刻む)

結論から申し上げまするに、Nexus One,あるいはHTCのAndroid携帯,もしくはAndroid携帯全般について言えば、NTP(SNTP)を使った時刻同期のしくみは用意されていません。(Nexus One, HT-03Aで確認)
つまりは、WiFiのみで運用している場合、時刻同期の手段がありません。
もっというなれば、SBM(少くとも黒SIM)で運用している場合も時刻同期の手段がありません。

勘違いされがちなのが、設定にある「日付と時刻」の「自動(ネットワーク自動設定)」というもの。
これはNTPなどインターネット経由での時刻同期のしくみではありません。携帯電話のネットワークで流れている時刻情報を元に時刻設定するもので、日本の場合、SBMはこれに対応していません。(NITZというらしい)
(仮にNTP機能だとしたら、NTPサーバを設定する項目がないのもおかしな話です)
実際のところ、docomoのSIMを差してこの機能を有効にすれば時刻同期はされます。OFFにして、時計をずらし、再びOにすると修正されるのがわかります。(no-SIMやSBMのSIMでは修正されない)
※ 実はiPhoneにも同様の機能がありますが、販売しているSBMで対応していないため、日本向けのiPhoneでは設定自体が表示されないようになっています。
ただし、この機能も端末起動時あるいは機内モードからの復帰時にしか時刻を取得しません。(トグルで調整されてるように見えるのはデバイスクロックと時刻取得時の差分をカーネルクロックに再適用しているだけっぽい)

さらに勘違いの元になっている /system/etc/gps.conf というファイル。
このファイルの中にはNTP_SERVER=north-america.pool.ntp.org などと記載されており、いかにもNTPで時刻あわせをしているかのように見えますが違います。
じゃぁこれはなんなのかと言われれば、GPSの原理の話になるんですが、かいつまんで言うとGPSってのは衛星から光の速さで送られてくる、衛星に搭載された原子時計の時刻情報と、それを受けとった地表での時刻情報を比較して衛星との距離を割りだし、位置を特定するというテクノロジらしい。(詳細)
つまり、地表での正確な時刻を知らなければ正しく測位できませんが、その時刻のためのNTPサーバを設定するファイルなのです。
Androidではこの時刻をデバイスクロックあるいはカーネルクロックには適用せず、GPSハードウェアへ知らせているだけです。(ちなみに4時間に一回問い合せており、失敗した場合は5分間隔でリトライしてます(ハードコード))
実際のところ、詳しくないのでよくわかりませんが、カーネルクロックと同期してないだけで、デバイスクロックは同期されているのかもしれません。(GPSデバイスがクロックソースなのかも)

そんなわけで、Nexus OneあるいはHT-03AなどたいしてカスタマイズされていないAndroid端末では、時刻同期の手段は携帯キャリアを使うしかないと思われます。

追記: 現在はNTPクライアントアプリがいくつかあります。

Nexus One (Android端末) に CA証明書をインストールする

オレオレ証明書でSSLサイトを運用してるような人向けの話題です。

どうやらNexus OneというかAndroidは任意のCA証明書をインストール出来ない様です。
実際に cert ファイルをダウロードなりすると、証明書インストールツールが起動しますが、これはサイト証明書をインストールして次回以降この証明書を信頼するというようなもの。


CAの証明書をインストールしてもそのCAから発行した証明書は信頼してくれません。


ではどうするのか。cacerts.bksに手で追加するしかありません。

root化必須で、Java実行環境とAndroid SDKが必要です。
まず http://bouncycastle.org/download/bcprov-jdk16-141.jar をダウンロード。

$JAVA_HOME/jre/lib/ext にコピーします。
Macだと /Library/Java/Home/lib/ext/ あたり?
Debian だと/usr/lib/jvm/java-1.5.0-sun/jre/lib/ext/ とか /usr/lib/jvm/java-6-sun/jre/lib/ext/ あたり

android端末からCA証明書ストレージファイルを取り出します。

$ adb pull /system/etc/security/cacerts.bks cacerts.bks

ストレージファイルに CA cert ファイル(cacert.pem)を追加します

$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -importcert -trustcacerts -alias OREORE_CA -file cacert.pem

keytoolはJREに含まれてるはずです。
OREORE_CA は適当な名前をつけたらいいです。

ストレージファイルを戻します。

$ adb remount
$ adb push cacerts.bks /system/etc/security/

これで、このCAから発行した証明書を信頼するようになり、エラーがでなくなります。

ここからは蛇足。
Androidのブラウザか、SSLのframeworkかはわかりませんが、サイト証明書のsubjectAltNameを見ない仕様(RFC的には見るべきなはずですが)のようで、
具体的にはサイト名が証明書と一致しない旨のエラーがでます。


そういうサイト運用の場合はCNを複数定義しておかねばならないようです。
証明書を発行する際の openssl.cnf [ req_distinguished_name ] で、

0.commonName                    = Common Name (eg, YOUR name)
0.commonName_max                        = 64
1.commonName                    = Common Name (eg, YOUR name)
1.commonName_max                        = 64

のようにしておけば、二つのCNを定義することができます。

続: Nexus One と iPhone を SIM 1枚で運用する(MyWi編)

先日は Nexus One を親にしたテザリングでiPhoneを使ってましたが今回は逆になります。
この方法は iPhoneをjailbreakする必要があり、Nexus OneもカスタムROMにしなくてはならないため、積極的にオススメはできません。
が、既に条件を満たしているのであれば試してみるのもよいかと思います。

さて、Nexus One はカスタムROM CyanogenMod 5.0 beta3以降にします。 (参考)
それだけで準備OKです。

iPhoneのほうはJBアプリのMyWi (No Rock)というのをCydiaから入れます。しかしながらこれは有料で$9.99かかります。

MyWiはadhocネットワークでテザリングを可能にするアプリで、テザリングは純正同様にバックグラウンドで動作するので、テザリング中でも電話やネットワークが通常通りに利用できます。


また、純正テザリングは3.1.2で使えなくなってしまいましたが、MyWiをインストールすることにより再び有効化することが可能となりますので、そのために購入するのも悪くないかもしれません。

MyWiを起動したらSSIDとWEPを適当に設定して ON にします。

するとNexus Oneの無線LAN設定のところにSSIDが現れます。

WEPキーいれて接続するだけでOK。

さて、このCM5.0で実装されてるadhocネットワークのコードをみて比較してみますと、オリジナルのコードではどうやら意図的にadhocを無視して、関連するコードも省いてるようです。

抜粋

@@ -1147,9 +1167,10 @@
                      * Ignore adhoc, enterprise-secured, or hidden networks.
                      * Hidden networks show up with empty SSID.
                      */
-                    if (AccessPointState.isAdhoc(scanResult)
-                            || TextUtils.isEmpty(scanResult.SSID)) {
-                        continue;
+                    //if (AccessPointState.isAdhoc(scanResult)
+                    //        || TextUtils.isEmpty(scanResult.SSID)) {
+                    if (TextUtils.isEmpty(scanResult.SSID)) {
+                       continue;
                     }

大して難しくない内容なので移植してCM不要でできないかやってみようとしましたが、frameworkまで入れ替えねばならなくなり、この部分だけピンポイントで入れ替えるのが難しそうなので断念しました。


そんなわけで、今はiPhoneにSBMのSIMを差して2台を1枚のSIMで運用しております。
Nexus OneでのSBMのMMSがどうにも安定しないのでしばらくこの体制でいきます。