非ドコモ端末でb-mobileなどドコモMVNOのデータSIMを利用すると、様々な不具合が出ることが知られています。
ドコモの電波を受信できるが「Emergency Calls Only」になってしまい通信できなかったり、通信できても不具合が出る(テザリングができない、など)ことがある、といったものです。
Motorola Milestoneを購入した際はそのためにb-mobile 3G/U300が使えず(その後Android 2.2.1にアップデートしてようやく制限はあるものの使えるようになった)、結局ドコモデータ回線を契約するハメになりました。
そして「Cell Standby」が異常にバッテリーを消費するために端末の稼働時間が短くなる、という問題も発生するそうです。
しかし少し前にそれを解決する方法がある、という情報を入手。
ブローヴちゃん: Android + データ専用 SIM での動作修正パッチ
ただしこの方法はdeodexed環境(平たく言うとカスタムROM環境)でしか利用できません。
しかしdeodexedでなくても手作業でパッチを適用する方法があるという情報を入手したものの、コマンドプロンプト上での作業が多くかなり面倒、ということで躊躇していました。
非Deodex環境 (SO-02C) でセルスタンバイ問題を解決する - nunnun's weblog
私のGalaxy S II(GT-I9100)では確かに上の画像のようにCell Standbyのバッテリー使用率が高いですが、バッテリーの持ちが悪くなる、といった症状はなく(自覚してないだけかも)、問題といえばパケット通信で標準ブラウザやBBC公式アプリを利用する際に「No Connection」のエラーが出て利用に支障が出るぐらいなので、そのままでもいいか、と思っていましたが、意を決してやってみました。
odexed環境でのパッチ適用法についての詳細は上記情報元を参照、ということで割愛しますが、簡単にまとめると
framework.odexを逆アセンブルしてバラし、その中にあるGsmServiceStateTracker.smaliをゴニョゴニョ(deodexed環境向けのパッチで「モード0」を選択するのと同じ状態にする：今回パッチを適用する端末がGalaxy S IIなので)。
それを再アセンブルしてclasses.dexを作成し、それをframework.jarに統合してゴニョゴニョ済、deodexedのframework.jarを作成。
(framework.odexを逆アセンブル→再アセンブルしてframework.jarに統合してdeodexedにする手順はこちらを参考にしました：英語ですがこちらの方が分かりやすかった)
このframework.jarを端末に転送し、dexopt-wrapperを使いodexファイルに変換。
そのodexファイルにオリジナルのframework.odexから署名をコピーし、ゴニョゴニョ済framework.odexを作成。
CWMで起動した状態でadb shellを使いオリジナルのframework.odexとゴニョゴニョ済framework.odexを置き換える。
再起動後キャリア名表示が出て、パケット接続アイコンが点灯するようになれば成功。
なのですが、私のGalaxy S IIだとframework.odex置き換え後起動せず文鎮化してしまいました。
当然Nandroid Backupは取ってあったのでそれを使ってリカバリー、と思ったら「バックアップファイルが見つからない」というエラーメッセージが出てリカバリーできない。
「ヤバいな」と思いましたが、これまた当然ですがオリジナルのframework.odexをバックアップしてあったので、CWMで起動した状態でadb shellを使いオリジナルのframework.odexに戻したら無事起動。
何とか最悪の事態は免れました。
それでもダウンロードモードで起動してOdinでROM焼きすれば大丈夫なんですけどね。
ゴニョゴニョ済deodexed framework.jarからframework.odexを作成する手順でエラーは一切出ておらず、入力したコマンドに対するレスポンスも情報元と全く同じものだったので、そこで失敗しているとは思えない。
となるとやはりGsmServiceStateTracker.smaliをゴニョゴニョする際に失敗している、としか考えられない。
ここでは「":pswitch_1d"に書き換える」となっていますが、この通りにすると私の環境では再アセンブル時に「":pswitch_1d"という値は定義されていない」というエラーメッセージが出てclasses.dexの作成に失敗します。
そのため":pswitch_1d"ではなく":pswitch_1f"に書き換えて再アセンブルし、classes.dexを作成しました。
それが失敗の原因、というわけです。
しかし「":pswitch_1d"または":pswitch_1f"と書き換える」となっていますから、これでも問題ないはずですが…
もしかすると書き換えている場所が違う、もしくは書き換える項目を追加する(deodexed環境向けのパッチで「モード99」を選択するのと同じ状態にする)必要がある可能性もありますが。
deodexedなカスタムROMを焼けばバッチファイルで一発なので楽なのですが(でも文鎮化するリスクは変わらない)、FOMAプラス対応のためのバンド切り替えがどうなるかといったことを考えると私としてはできれば(今のところ)確実にFOMAプラス対応にできるストックROMにしておきたい。
というわけでこの件に関しては新たな情報/手法が出てくるまで待ちですね。
