GALAXY Note のアンテナピクト問題, その後...
私のところでも盛大に発生している SAMSUNG GALAXY Note SC-05D と 富士通 ARROWS Me F-11D (双方白ロム品。) でのアンテナピクト問題ですが, 殆ど情報が得られない ARROWS Me は別として, GALAXY Note については, Android 2.3.6, Android 4.0.4 といった OS の版にかかわらず, 比較的情報が得やすい状況となっています。 前々から書いているように, メーカー品については root 化等を行いたくないのですが, あまりにもバッテリーの減りが速く「背に腹は代えられない」ということで, この週末を利用して弄ってみました。 最初から弄りすぎると文鎮化の危険性が高まりますので, まずは なるべく弄らずに済む方法を採ることにします。 (笑)
というわけで, まずは ここまでのおさらいで設定を確認しておきます。 「今では その方法でも特に問題なし」というわけで, 初回起動の初期設定に引き続き, 即 Android 4.0.4 へのアップグレードを設定画面から WiFi を利用して行っています。 以前なら Kies を使わないとアップグレード自体に失敗するわ, root 化等でも失敗するわ…と, 散々な結果を招くところですが, 2 ヶ月経った今では改善しています。 その上で, DEBUG SCREEN を利用してサービスドメインを PS ONLY――つまりパケット通信サーバーのみ使用――とし, 使用バンドも 3G のみとしてあります。 職場では Xi が有効ですが, 150k な データー専用 b-mobile SIM なので Xi の恩恵に浴することがありませんから。 (^^;)
顛末を語る前に, 今回使用したツール等は以下のとおりです:
- GALAXY Note SC-05D: 本体。 はっきり言って生け贄に捧げるわけなので, 文鎮化した場合の覚悟をもって挑んで下さい。 ぶっちゃけ, 今なら まだ最高で 26k ほども出せば白ロム品を手に入れることが可能です。
- 作業を行うための PC: adb を使えるのであれば Win でも Mac でも linux でも構いません。 スマートフォン系の USB ドライバーは何かと問題を起こすので注意。 良くあるのが「スマートフォンを更新したら繋げなくなった」というケース。 もちろん, その機器用のドライバーを導入しての話です。 というわけで, ある意味こちらも生け贄組。
- ES ファイルエクスプローラー: ファイル操作全般を行うのに使用。 マーケットからインストールしておきます。 システム周りを弄るわけですから, 当然ながら root 化を行った後には, ルートオプションの指定を行ってホームディレクトリを "/" にしておく必要があります。 全てのファイル操作を adb で行うなら不要です。
- Android JDK: 他のツールに adb 等が含まれていることが多いので, 必ずしも必要ありませんが, 初期装備的武器ということで…。 必要なら適当にぐぐって落としておきます。 既に持っていますので, 今回は落としていません。 ここに一覧しているツールにも含まれていたような気がします。 Windows 環境であれば adb.exe と dll があれば事足りるので, JDK までインストールするのは大げさな気がします。
- SAMSUNG Kies: GALAXY Note 純正のツールです。 USB ドライバー導入のため, 一度だけインストールして, すぐに (ドライバーだけ残す設定で) アンインストールしておきます。 本家に導入させておくのが一番確実なので。 (笑) >USB ドライバー
- Check Fus Downloader: 純正 ROM をダウンロードするのに使います。 「文鎮化なぞ有り得ぬわ!!」という強者には必要ありません。 これで, Android 4.0.4 の ROM を落としておけば, 何かあっても出荷状態相当へ戻せます。 パーティション自体が飛んだりすると詰みますけれど。 (^^;) ググって落としておきます。 Check Fus Downloader 2.1 を使用。
- Odin 3: GALAXY Note 用の定番 ROM 焼きツールです。 この手のツールは機種によって使用するツールが概ね決まってきます。 使い方自体は どれも似たようなものなので, 他の機種で ROM を焼いたことがあれば, 難しいことは何もないです。 ググって落としておきます。 Odin3-v1.85 を使用。
- ClockworkMod Recovery: リカバリーツールです。 純正リカバリーツールでは制限があるので, 別口のリカバリーツールを使用します。 リカバリーツールには「これを使えば確実」というものが存在しないので注意して下さい。 使用する方の好みもありますが, それ以上に当該機の状態が大きく影響しますので, どのツールを使用したところで問題の出る可能性は避けられません。 SC05D-ICS-KBC-CWM-V6.0.1.2_r12-recovery.7z を使用。 何故か このツールについては「これ」という固定リンクが存在しないので, 何とか探し出して落としましょう。
- superuser: su 等が含まれた ZIP 書庫のほうです。 別途 su を用意した上でシステムフォルダーへ導入できるのであれば, apk ファイルや普通のインストールでも構いません。 …それが可能なら, そもそも superuser を必要としないでしょうけれど。 (^^;) OS が 4.0.4 なので ICS 用である Superuser-i717-ICS-signed.zip を ググって落としておきます。
- smali / baksmali: Android dex のコンパイラーと逆コンパイラーです。 framework.odex を改変する場合に必要となります。 ググって落としておきます。 現在は 1.4.1 のようですが, 1.3.2 辺りより以降の版であれば同じものが出来上がると思います。 「ダメなら最新版で」ということで…。 1.4.1 を使用。
- Java: smali, baksmali が Java スクリプトなので, 何らかの Java 実行環境が必要となります。 x64 環境なら x64 用が必要となりますので注意。 必要ならググって落とした上でインストールしておきましょう。 (過去のしがらみでインストール済の方も多いかと思います。)
- ZIP 書庫を操作可能なアーカイバ-: 何でも良いのですが, 何も考えず自作の LHMelt を使用します。 (笑)
- dexopt-wrapper: jar ファイルから dex (odex) を作成するためのツールです。 ググって落としておきます。
- busybox: 署名を書き込むためのツールです。 root 化を行った後にマーケットから落としてインストールしておきます。 (root 化されていないとインストールできない。)
- ググって手に入れた SC-05D 用の対策済 framework.odex: 「改善した」という報告も上がっているブツなので, これに入れ替えることで改善する…はず。 (^^;)
ここからは顛末です。 何はともあれ, まずは必要なツール類のダウンロードを行いました。 この中で, 「ES エクスプローラー」は普段から使っていますので, GALAXY Note へ導入済みです。 もちろん, 非 root 化状態ですので「インストールしてあるだけ」です。 また, PC (メイン使用している東芝 Qosmio T851/D8CR。) へは Java (x64 版。) が導入されています。 ちなみに, MSDN 版な Windows 7 Ultimate (x64) 環境ですが, 64 ビットの Windows 7 環境であれば どれでも同じはずです。 あと, 上でも書いたように Android JDK は使用していません。 Allwinner Essential 辺りを落としてくれば, adb.exe と dll が手に入りますので, そちらから引っ張ってくると良いでしょう。
基本的にはググるだけで落とすことが可能なのですが, ClockworkMod Recovery だけは入手に苦労しました。 版を合わせたかったので SC05D-ICS-KBC-CWM-V6.0.1.2_r12-recovery.7z を探したわけですが, 出てくるのは無効リンクばかり。 30 分ほど探し回って ようやくの入手と相成りました。 結果論としては, 他のリカバリーツールを使ったほうが速かったかもしれませんね。 (笑) 「キャッシュパーティションのクリアー」 「Dalvik キャッシュのクリアー」 「ZIP ファイルからのインストール」の処理が必要となりますので, これらを行えるものであればツールは問わないはずです。
いよいよ作業となるわけですが, 「その前に保険をば…」というわけで, 純正 ROM を落としておきます。 使用したのは Check Fus Downloader 2.1 です。 起動して, Advanced タブに以下の情報を入力します:
OS = Android
Model = SC-05D
Product Code = SGH-NO14UWNDCM
Hidswver(PDA/CSC/PHONE/PDA) = SC05DOMLPL/SC05DDCMLPL/SC05DOMLPL/SC05DOMLPL
これだけでは例外が発生するケースがある (私も該当。 ^^;) ようなので, Standard タブの OS 項目でも「Android」を指定しておきます。 入力が終わったら「Check firmware」ボタンで ROM の存在チェックをし, チェックが通ったら「Download」ボタンでダウンロードを行います。 落としたファイルは大事にとっておきましょう。 パーティションが飛ぶなどの致命傷を負わなければ, 落としたイメージを使用して出荷状態相当へ戻すことが可能です。 ちなみに, 「SC05DOMLCE/~」の情報も載っていたりしますが, そちらは別の版なので注意。 9 月以降に公式筋で OS の版を上げたのなら, SC05DOMLPL が必要になります。
「保険が掛け終われば準備完了」ということで, 最初に行うのは root 化です。 別の手段も存在しますが, ここは普通に行っておきます。 ここからは一歩操作を間違うと完全文鎮化へ直結しますので注意。 …と, その前に USB ドライバーを導入するために, SAMSUNG Kies をインストールしておきます。 USB ドライバーが正常に導入されたら Kies は必要ありませんので, Kies 使いでなければ USB ドライバーだけ残してアンインストールしても構いません。 …といいますか, アンインストールを進めるサイトが多いです。 (^^;) ドライバーだけ手に入れて導入する方法もありますが, Kies を使ったほうが簡単でしょう。
次に, 落としておいた Superuser-i717-ICS-signed.zip を GALAXY Note の外部ストレージ (以前から存在する「work」フォルダーを使用。) へ置いておきます。 micro-SD カード経由でも, メディアモードで PC と繋いでコピーを行っても構いません。 方法は何でも良いです。 あ, そうそう。 接続を行おうというのですから, 前もって開発オプションでデバッグモードを有効にしておいて下さいね。 (笑) adb を使うなら, こんな感じ:
adb push C:/TMP/Superuser-i717-ICS-signed.zip /sdcard/external_sd/work/Superuser-i717-ICS-signed.zip
PC 側については, ダウンロードしたツールやファイルなどを全て「C:/TMP」上に置いてあり, かつ ここがカレントディレクトリーになっているものと仮定しています。 また adb での操作については, あらかじめ「/system」と「/data」, それと「/sdcard」が RW でマウントされた状態を想定しています。 必要なら適宜マウント操作を行って下さし。 あと, 特に説明していませんが, PC と やりとりする際には当然ながら USB ケーブルで接続することになりますので, 念のため。
準備が出来たら, まずは GALAXY Note をダウンロードモードで起動します。 「ボリュームダウン + ホーム + 電源ボタン」の同時長押しで起動するやつですね。 「おらーっ!! カスタム OS 使って問題出ても知んねぇーぞっ!!」と警告してきますが, 「ここから先一連の操作による結果は全て自己責任となる」と頭に叩き入れた上でボリュームアップボタンを押して続行します。 次に PC のほうで Odin3 を立ち上げ, 「PDA」の項目で, 落としておいた ClockworkMod Recovery (CWM) のイメージ「SC05D-ICS-KBC-CWM-V6.0.1.2_r12-recovery-odin.tar.md5」を指定しておきます。 あ, CWM は書庫で落としているはずなので, ちゃんと展開しておいて下さいね。 その他のツール等についても以下同文。 (^^;)
指定が終わったら, GALAXY Note と PC を USB ケーブルで繋ぎます。 GALAXY Note が認識されたら進捗バーの背景がイエローになりますので, それを確認した上で「Start」ボタンで ROM を焼きます。 グリーンのバーが延びていき, 正常に焼ければ背景がブルーに変わってリブートが掛かります。 さらに, GALAXY Note がリブートした時点でグリーンの背景になり正常終了となります。 そこまで辿り着くことを祈りつつ待ちましょう。 OS 自体の ROM 焼きと異なり, 速攻で終了するとは思いますけれど…。 再起動したら, 一旦シャットダウンして電源を切っておきます。
今度はリカバリーモードで GALAXY Note を起動します。 「ボリュームアップ + ボリュームダウン + 電源ボタン」の長押しで起動するやつですね。 短くブルブル繰り返し震えだすので, そこまで待ってから電源ボタンだけ離します。 残りのボタンを押したまま しばらく待つと, CWM が立ち上がりますので, 「install zip from sdcard」メニューを使って, 外部ストレージに置いてある Superuser-i717-ICS-signed.zip を指定して, Superuser のインストールを行います。 無事に終了したら, トップメニューへ戻りリブートを選択して再起動を行います。
起動したら, Superuser がインストールされていることを確認した上で起動します。 大抵は su の版が古くて赤色表示になっているはずなので, とりあえず版は気にせずに, su の更新を行っておきましょう。 これで root 化は終了です。 もののついでに, ここで ES エクスプローラーでルートオプション指定と, busybox のインストールを行っておきましょう。 busybox をマーケットから落とした場合, 再度 busybox 自身でインストールを行う必要があるので注意。 (^^;)
…と, 故意にメニュー選択などの手順を一部端折ってありますが, ここまでが解らないようだと間違いなく文鎮化が待っていますので, 手を出すのは諦めましょう。 あと, GALAXY Note でのアンテナピクト問題や root 化についての有名どころのサイトくらいは, 目を通しておくようにして下さい。 それらを踏まえた上での顛末談なので。 (書きぶりは操作手順式。)
さて, たまたまではありますが対策済 framework.odex (署名済のもので「C:/TMP/test」に置いてある。) を入手していますので, まずは これに置き換えてみます。 ファイル操作は adb を使ったほうが効率はよいのですが, 慣れていない方は「ES エクスプローラー」辺りを使ったほうが安全です。
まずは保険を掛けておきます。 「/system/framework」上の framework.jar と framework.odex を PC へコピーしておきます。 その上で, 判りやすいように「framework.jar.orig」とでもしておきます。 さらに, 入手した対策済 framework.odex を オリジナルの framework.odex と置き換えます。 最後に今し方置き換えた framework.odex のアクセス権を 644 にしておきます。 手順を惜しんで ここで安易に直接コピーを使わないように。 わりと高確率で, 途中でハング (半文鎮化) します。 (純正 ROM へ焼き直すなど復旧できないなら本当の詰み。(=真の文鎮化。))
adb なら以下のような感じ:
cd C:/TMP
md org
adb pull /system/framework/framework.jar org/framework.jar.orig
adb pull /system/framework/framework.odex org/framework.odex.orig
adb push test/framework.odex /system/framework/framework.odex.new
adb shell rm /system/framework/framework.odex
adb shell mv /system/framework/framework.odex.new /system/framework/framework.odex
adb shell chmod 644 /system/framework/framework.odex
framework.odex を置き換えたので, リカバリーモードで起動し直して, 「Wipe cache partition」でキャッシュパーティションのクリアーを, 「advanced」の中の「Wipe Dalvik Cache」で Dalvik キャッシュのクリアー (要は dex ファイルの削除。) を行っておきます。 終わったらリブートします。
リブートして通常起動した結果は…。 「S」マークの表示で無限ループに陥ることなく普通に立ち上がりました。 ちなみに, framework.odex (といいますか一連のシステムファイル。) が不正な状態だと, 無限ループに陥ります。 文鎮化の一種ですね。 リカバリーモードで立ち上げた上で「/system」をマウントし, adb を使って保険を掛けておいた framework.odex.orig を生け贄に復旧すれば復活が可能です。 (リカバリーモードでも PC と接続しての adb 使用は可能。) それでダメなら, 落としておいた純正 ROM イメージを Odin3 を使って焼きましょう。 パーティションが飛んだりといった致命傷を負っていなければ, リカバリーモードやダウンロードモードが使えます。
無事 framework.odex の置き換えが終了したので状況を確認してみたのですが…, 何も変わっていませんでした。 通信ピクトは表示されませんし, 100% 圏外のままです。 後で逆アセンブルして分かったことですが, 全然 GALAXY Note 用の変更になっていませんでした。 当該ファイルを使った方は漏れなく無駄足となっていることでしょう。 (笑)
対策済ファイルが使えないとなると, 直接 framework.odex を改変するしかありません。 というわけで, まずは「/system/framework」配下を PC へコピーしておきます。 adb を使えば簡単でしょう。 ここでは「C:/TMP/framework」ということにしておきます。 あと, オリジナルの framework.jar と framework.odex だけは, 「C:/TMP/workspace」上にもコピーしておきます。 これを生け贄に改変することになります。 ついでに, 作業しやすいように smali と baksmali も「C:/TMP」に置いておきます。 smali と baksmali は Java スクリプトなので, 必要なら Java を使えるようにしておいて下さい。 最後に「C:/TMP」ディレクトリーへ移っておきます。
md workspace
adb pull /system/framework framework
adb pull /system/framework/framework.jar workspace/framework.jar
adb pull /system/framework/framework.odex workspace/framework.odex
さて, odex ファイルが存在することで お判りのように, SC-05D の純正 ROM は非 Deodex 環境なので, 例のバッチは使えません。 まあ, 使えたとしても adb root が前提だったりと, 作業する環境によっては多少敷居が高かったりしますが…。 (その辺りをクリアーできるユーザーなら, 少なくとも操作手順目的で この記事を見ることはないはずです。)
それはともかく, 次のコマンドを実行して framework.odex の逆アセンブル (odex ファイルの展開。) を行います:
java -jar baksmali-1.4.1.jar -a 15 -d framework -x workspace/framework.odex
昔と違って, 最近の baksmali は最低限のスイッチ指定しか必要としません。 「-a」スイッチは API レベルの指定なので, Android 4.0.3~4.0.4 用の 15 を指定しておきます。 「-d」スイッチは, 指定したディレクトリー上のファイルを情報として利用することを指定するものです。 要は必要なクラスファイルなどを適当に補完してくれるわけですね。 「-x」スイッチは後で smali を使ってアセンブルするのに必要となるスイッチです。 これを忘れるとアセンブルに失敗します。 少々時間を要しますが, 正常終了すると, 「C:/TMP/out」配下に逆アセンブル結果がドババーっと出力されます。 えっと…。 少なくとも今回使用したツールと環境では, 警告すら何も表示されないはずなので, 警告はともかく, エラーが出たら適宜対応して下さい。 (^^;)
逆アセンブルが終了したら
「C:/TMP/out/com/android/internal/telephony/gsm/GsmServiceStateTracker.smali」をエディターで開きます。 開いたら, 5279 行目以降を表示します:
5279: :pswitch_data_22
5280: .packed-switch 0x0
5281: :pswitch_1c
5282: :pswitch_1d
5283: :pswitch_1c
5284: :pswitch_1c
5285: :pswitch_1c
5286: :pswitch_1f
5287: :pswitch_5
5288: :pswitch_5
5289: :pswitch_5
5290: :pswitch_5
5291: :pswitch_1c
5292: :pswitch_5
5293: :pswitch_1c
5294: :pswitch_1c
5295: :pswitch_1c
5296: .end packed-switch
行が違っている場合は "pswitch_data_22" の文字列で検索して下さい。 表示されたら, 何も考えず以下のように 5284 と 5294 の 2 行だけ変更して保存します:
5279: :pswitch_data_22
5280: .packed-switch 0x0
5281: :pswitch_1c
5282: :pswitch_1d
5283: :pswitch_1c
5284: :pswitch_1d
5285: :pswitch_1c
5286: :pswitch_1f
5287: :pswitch_5
5288: :pswitch_5
5289: :pswitch_5
5290: :pswitch_5
5291: :pswitch_1c
5292: :pswitch_5
5293: :pswitch_1c
5294: :pswitch_1d
5295: :pswitch_1c
5296: .end packed-switch
次のコマンドを実行して, 先ほど展開した framework.odex をアセンブルして deodex 化を行います:
java -jar smali-1.4.1.jar -o classes.dex out
baksmali で正常に展開できていれば, ここでエラーは発生しないはずです。 エラーが発生するようなら逆アセンブルから やり直しましょう。 エラーなしで正常終了したら, 「C:/TMP」上に作成されている classes.dex をアーカイバーを使って workspace/framework.jar へ格納します。 (jar ファイルの実体は お馴染みの ZIP 書庫です。)
zip workspace/framework.jar classes.dex
ここでは zip を使っていますが, 7za を使うなら以下のとおり:
7za u -tzip workspace/framework.jar classes.dex
「-tzip」スイッチはなくても大丈夫なはずですが, 付けておいても損はないでしょう。 あと, 純正 ROM では大丈夫ですが, 使っている ROM によっては「-mx0」で無圧縮を指定しておかないとダメかもしれません。 あ, 私は当然ながら LHMelt を使っていますよ。 (笑)
出来上がった書庫 (workspace/framework.jar。) と落としておいた dexopt-wrapper を GALAXY Note の適当な箇所へコピーします。 ここでは「/data/local/tmp」として説明しますが, ここには init.rc 辺りも存在するので注意。 コピーには adb を使うのが普通ですが, コピーできれば何でも良いです。 置き場所によっては「PC と接続した上で Explorer で…」なんてことも可能でしょう。 コピーし終わったら, /data/local/tmp/framework.jar のアクセス権を 644 にしておきます。
adb push workspace/framework.jar /data/local/tmp/framework.jar
adb push dexopt-wrapper /data/local/tmp/dexopt-wrapper
adb shell chmod 755 /data/local/tmp/dexopt-wrapper
さて, 巷では ここから dexopt-wrapper を使って直接 jar から odex へ変換する手順で説明されているところもあるのですが, 何故か「全く同じ操作を行っても大丈夫だったりダメ (「S」表示で無限ループ。) だったりと不安定」だったので, dexopt-wrapper を使わない方法を採ります。 それは…「GALAXY Note (Android OS。) 自身に odex を作らせる」方法です。
先ほど「/data/local/tmp」へコピーした framework.jar を framework.jar.new へリネームした上で, 「/system/framework」上へ移動します。 次に「/system/framework」上の framework.jar を framework.jar.old へリネームし, 先ほど移動した framework.jar.new を framework.jar へリネームします。 続けて同じ「/system/framework」上の framework.odex を framework.odex.old へリネームします。
adb shell mv /data/local/tmp/framework.jar /system/framework/framework.jar.new
adb shell mv /system/framework/framework.jar /system/framework/framework.jar.old
adb shell mv /system/framework/framework.jar.new /system/framework/framework.jar
リカバリーモードで起動し直して, 「Wipe cache partition」でキャッシュパーティションのクリアーを, 「advanced」の中の「Wipe Dalvik Cache」で Dalvik キャッシュのクリアーを行っておきます。 終わったらリブートして通常起動を行います。
通常起動を行って起動しかけますが, 先ほど置き換えた framework.jar が署名済でないことから, 「S」が表示された状態で無限ループに陥り起動に失敗します。 所謂半文鎮化の状態ですが, とりあえず保険で 1 分ほど放置します。 すると USB ケーブルで接続して adb を使用できるようになるので, そのまま作業を続けても良いのですが, 念のためリカバリーモードで起動し直しても良いです。 (ボタンを長押しし続けると再起動されます。) 起動し直した場合は, 「mounts and storage」から「mount /system」を選んで /system をマウントします。 続けて USB ケーブルを接続します。 (起動し直す前の接続でも可。)
次のコマンドを実行して, オリジナルの framework.odex へ戻してあげます:
adb shell mv /system/framework/framework.odex.old /system/framework/framework.odex
先ほどの起動で書き換えた framework.jar から framework.odex (の実体。) が作成されたわけですが, それが署名なしの不正ファイルで使えないため起動できなかったわけです。 なので, 元に戻してあげるわけですね。 つまり, オリジナルを何らかの形で残しておけば, この方法で元に戻すことで半文鎮化を避けられるわけです。 これでダメだった場合は ROM を焼き直すしかありません。 (といいますか, それが近道。) ともあれ, オリジナルへ戻し終わったらリブートします。
今度は普通に起動しますので, 先ほどの起動で改変された framework.jar から作成されているはずの, framework.odex の実体を次のコマンドを実行して, /data/local/tmp へ移します。 続けてオリジナルの framework.jar へ戻しておきます:
adb shell mv /data/dalvik-cache/system@framework@framework.jar@classes.dex /data/local/tmp/framework.odex.new
adb shell rm /system/framework/framework.jar
adb shell mv /system/framework/framework.jar.old /system/framework/framework.jar
ここまでの, odex 作成の手順については, dexopt-wrapper を使えば以下のような操作となります:
adb shell /data/local/tmp/dexopt-wrapper /data/local/tmp/framework.jar /data/local/tmp/framework.odex.new
この 1 行だけで済めば良かったのですが, 先に書いたように不安定なフシがあったので, 半文鎮化を含む手数を惜しまず, GALAXY Note 自身に作らせる確実な策を採ったわけです。
新たに作成した framework.odex.new は このままでは やっぱり使えないので, busybox を使用してオリジナルの framework.odex を生け贄に署名を付けてあげます:
adb shell busybox dd if=/system/framework/framework.odex of=/data/local/tmp/framework.odex.new bs=1 count=20 skip=52 seek=52 conv=notrunc
署名を付け終わったら, その framework.odex.new を「/system/framework」へ移動します。 次に「/system/framework」上のオリジナル framework.odex を framework.odex.old へリネームした上で, 今ほど移した framework.odex.new を framework.odex へリネームします。
adb shell mv /data/local/tmp/framework.odex.new /system/framework/framework.odex.new
adb shell mv /system/framework/framework.odex /system/framework/framework.odex.old
adb shell mv /system/framework/framework.odex.new /system/framework/framework.odex
最後の仕上げです。 リカバリーモードで起動し直して, 「Wipe cache partition」でキャッシュパーティションのクリアーを, 「advanced」の中の「Wipe Dalvik Cache」で Dalvik キャッシュのクリアーを行っておきます。 終わったらリブートして通常起動を行います。
…という一連の作業で framework.odex の改変を行えるわけですが, 上のほうで書いたように, adb を使ったほうが, 頭から「/system/framework」上で作業できたりと, かなり効率に違いがあるはずです。 しかし, リカバリーモードで作業する必要があったり, 適宜 adb root やマウントが必要だったりと, 慣れていない方には辛いところなので, 非効率ではありますがファイラー (ここでは「ES エクスプローラー」を想定。) を使ったほうが良いでしょう。 もっとも, 嫌でも確信半文鎮化の後など一部の操作だけは adb で行う必要がありますけれど。
あ, そうそう。 アクセス権の絡みで思わぬところでエラーになったりすることが ありますので, その際は当該ファイルのアクセス権を一時的に 666 にでもして切り抜けて下さい。 作業後は ちゃんと 644 へ戻しておくように。 (笑)
という手作業の結果, 冒頭右画像のような感じとなりました。 3G ハイスピードでの通信を示す「H」の通信ピクトが, ちゃんと表示されるようになっています。 続けてバッテリー関連の情報を表示させてみると:
セルスタンバイの割合が低いため, すでに一覧には表示されない状況で, 同様に圏外時間も 2% と非常に低い数値となっています。 「お? これは改善したかしら?」というわけで, 翌日 LTE 圏内の職場で確かめてみたところ:
LTE 圏外では期待どおりの動作となるのですが, LTE 圏内では通信ピクトが表示されず, セルスタンバイも圏外となってしまいます。 ステータス画面で確認してみると, 3G ではサービス中 (圏内。) となるのに対して, LTE では使用不可 (圏外。) となっています。 どうやら「Searching」ステータスの場合にも STATE_IN_SERVICE を返すようにしないとダメのようです。 そちらの変更を行ってもダメなようなら, framework.odex の別の箇所か framework2.odex を弄らないとダメなのでしょう。
というわけで, 昨日の夜に再度修正を行った上で置き換えてみました。 変更箇所は以下のとおり:
5279: :pswitch_data_22
5280: .packed-switch 0x0
5281: :pswitch_1c
5282: :pswitch_1d // 1 is "in service"
5283: :pswitch_1d // 2 is "searching"
5284: :pswitch_1d // 3 is "registration denied"
5285: :pswitch_1c // 4 is "unknown" no valid in current baseband
5286: :pswitch_1f // 5 is "in service, roam"
5287: :pswitch_5
5288: :pswitch_5
5289: :pswitch_5
5290: :pswitch_5
5291: :pswitch_1c // same as 0, but indicates that emergency call is possible.
5292: :pswitch_5
5293: :pswitch_1d // same as 2, but indicates that emergency call is possible.
5294: :pswitch_1d // same as 3, but indicates that emergency call is possible.
5295: :pswitch_1c // same as 4, but indicates that emergency call is possible.
5296: .end packed-switch
例のバッチでいえば, 0 の代わりに 99 を指定したことになります。 その日は 3G 回線で問題が生じないことを確認して そのまま就寝しました。 そして, 今日の朝 LTE エリア内である職場で確認してみた結果は…:
LTE でも圏外時間が増加しないようになり, 無事アンテナピクト問題が改善されたようです。 が, 下の画像を見ると解るのですが, LTE エリア内でのスリープでは かなりバッテリーの減りが早くなってしまうようです。 大きく 3 つに分かれていますが, 最初の緑が前回の変更後, 次の濃い黄色が今回の変更後 (LTE エリア外。), 最後の黄色が LTE エリア内です。 同じ「殆どスリープ状態」にもかかわらず, たった 4 時間弱の LTE エリア内でのスリープの間に, それまでの丸 1 日の 3G エリアでのスリープ状態より遙かに多くバッテリーを消費してしまっています。 少々差が大きすぎますので, 昼休みに自動機内モードに再びお出まし願いました。 (^^;)
結果として, SC-05D の Android 4.0.4 純正 ROM においては, 「Searching」と「Regstration denied」の際にも STATE_IN_SERVICE を返すようにすれば, アンテナピクト問題を改善できるようです。 LTE エリア内で依然としてバッテリーの減りが少々早い点については しばらく様子見が必要ですが, サービス状態が「サービス中」となっていますので, 別の要因である可能性が高いです。 少なくとも, 今回の変更とは別の箇所か framework2.odex を弄る必要があるでしょう。
Nov.29,2012 追記
手元でバッチ化が成功した上で要望があれば, そのバッチを公開する…かもしれません。 最終的には例のバッチを参考に一般化したいところですが, とりあえずは自環境専用で編集が手動のベタなものからですね。 それが動作しないことには始まりませんので…。 改変済の framework.odex については, 「ブラックに限りなく近いグレーを突き抜けたブラック」 (by 紗弓実) なので公開できません, あしからず。 バッチが動けば必要ないわけですし。
問題となるのは dexopt-wrapper による dex の作成でしょうか? 手元では不安定な印象なのですが, GALAXY Note (に搭載されている Android 4.0.4) に作成させたものと比較した限りにおいては, かなりサイズの異なるものが作成されている辺りが影響していそうです。 とりあえずは, dexopt-wrapper で必要そうな jar ファイルをひととおり指定するところから確認ですね。
Dec.6,2012 追記
ふむ。 やはり PS と CS での場合分けをしないと, 機内モードからの復帰時にアンテナピクトが表示されなくなりますね。 当たり前といえば当たり前の挙動なので, 暇なときにでも修正しておきましょう。
|