Xperia acro odex/deodex
個人的なメモなので、他人が読む事を想定してない。
はじめに
odexとかdeodexってなんぞ
apk の実行可能コードには二種類ある。
- odex: 端末最適化済
- deodex: 汎用コード (de-odex?)
※適当な事書いてたらごめん。正直自信ない。
純正ROMの /system/framework/ 以下等に含まれる、odex化された .apk のカスタマイズには、.odex をかき回して一度 deodex 化する必要があるらしい。というわけで一連のメモ。
smali, baksmali
odex/deodex の assembler/disassembler。javaで動くぞよ
こんな感じで動かす。正直実行用のスクリプト要らん気が‥
あるいは、Windows 環境なら実行用に .bat 作っておくと便利かも（以下は smali.bat の例）。
@echo off
java -jar smali.jar "%1" "%2" "%3" "%4" "%5" "%6" "%7" "%8" "%9"
ポイント
[odex] META-INF とかの設定が入ってる .apk/.jar と、実体である .odex が分離してる(Classes.dexに相当)。
[deodex] .apk/.jar の中に Classes.dex という実体が入っている(.apk/.jar は署名付きZIP形式？)。
odex と deodex
- odex を deodex 化する場合
odex の展開 ⇒ deodex 化の手順でおｋ。
- deodex を odex 化する場合
deodex を端末に転送 ⇒ .odex の生成 ⇒ deodex を分解してスマートな .jar/.apk を生成
- odex を編集する
odex の展開 ⇒ 書き換え ⇒ deodex化 ⇒ odex化
やべぇ‥odexだかdeodexだか、書いてる本人が何書いてるのか分からなくなってきたぞ。。
odex の展開
カレントディレクトリ上に .odex や .jar 等のファイルが配置してあり、その上に baksmali.jar, smali.jar が配置してあるという想定。たぶん framework のファイルとか全部抜き出しておくのが吉。
java -jar ../baksmali.jar -a 10 -x framework.odex -o ../framework.odex.out/ -c :core-junit.odex
deodex 化
展開したフォルダに対してsmali.jarを実行してやる。具体的にはこんな具合。
java -jar ../smali.jar -o classes.dex ./framework.odex.out/
classes.dex が生成されたら、framework.odex と共に抜き出しておいた framework.jar にZIPで突っ込む。
これだけでは端末できちんと動かんらしいので、必要に応じて編集前の framework.jar から署名部分をバイナリで抜き出し、新しい framework.jar に付加してやるとよいらしい。詳しい手順はddとかbusyboxで調べて。
今回は odex のまま編集することが目的だったので、署名は行っていない。
deodex の odex 化
要は、deodex 化した .jar/.apk を端末に転送してやり、そっちで最適化すればよいとのこと。
おそらく端末標準で dexopt コマンドが入っている（？）が、署名なしでは動かんらしいので、dexopt-wrapper なるスクリプトのご紹介。
解凍して deodex な .jar/.apk と共に端末の /data/local/tmp とかに展開。chmodして実行できるようにしてこんな具合で動かす。
# cd /data/local/tmp
# dexopt-wrapper framework.jar framework.odex
# dexopt-wrapper android.policy.jar android.policy.odex
こんな具合にして署名を追加。
# busybox dd if=/system/framework/framework.odex of=framework.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
実行後、deodex化した .jar/.apk は classes.dex が入っててスペース的に無駄なので、こいつは使わずに素の .jar/.apk (classes.dexを含まない) との組み合わせで動かすと幸せになれるかもしれないとの事。
もちろん、単に deodex から odex 化した場合はそういうわけにはいかないので、きちんと classes.dex を抜いた .jar/.apk を作るとよさげ。（こっちも署名いるのかな？）
置換の際は、owner と permission の変更も忘れずに。
その他
odex と deodex のどっちがいいの？
/system/app/ 以下に関しては、端末ごとに最適化される deodex の方が幸せだと思う。
そもそも deodex なアプリケーションは、実行時に dalvik-vm が裏方で odex を生成するらしいので(dalvik-cache)、入れ替えの少ない .apk 等を odex 化するメリットは少ないと思われる（改造時に編集が楽な程度）。
jar/apk の分解工作
apktoolまたはAPK Managerなどがおすすめ
- http://code.google.com/p/android-apktool/ (apktool)
- http://apkmultitool.com/node/2 (APK Manager 本家)
- http://bicthink.blog.fc2.com/blog-entry-89.html (APK Manager 日本語版)
今回これも使った。
何がやりたかったの？
acro たんにリブートオプションを追加したかった。それだけ。
- リブートオプション | 楽しみのない猫(旧家)
- http://www5216u.sakura.ne.jp/so02c/framework-res_acro-reboot_4.0.1.C.1.21.zip (成果物)
http://www5216u.sakura.ne.jp/so02c/systemui_acro+r_pctrl_unsigned.zip (SystemUI入りCWM用update.zip)
update.zip の作り方
ハマりポイントのみメモ。
http://forum.xda-developers.com/archive/index.php/t-1551884.html にerror statusの説明とか。
書式がおかしいとかstatus 4とか出た時はupdate(r)-scriptの名前がおかしいとか、7zip使ってないとか疑う。
status 0は本体のNANDの種類に応じたupdate-binaryを探してくる（機種に応じて切り替える必要がある）。
