デコンする際にapk->dex->うにょにょて具合でしたので、dexの存在自体は把握していましたが改めて調べてみた。
dalvik vm前提なので、ある種、泥固有に近い。
dexはdalvik executableということで、dalvik vmで実行出来る形式。
java vmで言うところのclassファイルと同じて考えている。
それで、odexはというと、optimized dalvik excutableということで、最適化されたdexを意味する。
どう最適化されているのかはスルー。
さて。
プリインアプリ群は、/system/app内にapkとodexが対となって配置してあるパターンが多かった。
そうではないパターンは、apkだけが/system/appに存在し、/data/dalvik-cacheにdexが配置してあるパターンだった。
ストアなどからの外界からインストールするアプリ群は(sd moveしていない限り)、/data/appにapk、/data/dalvik-cacheにdexというパターン。
それで、odexがあるパターンのプリインは、apkにdexが内包されていない(する必要もない)ので、それをそのまま別機種に持って行きインストールちゅうのは実行ファイルがないので意味がない。
odexがないパターンのプリインは、持って行くことが理論的には可能。
ということなんだと思う。
しかし。
プリインで他機種にまで持ち込みたいアプリなんて皆無だからどうでも良いこと。
あと、時々耳にする、smali/baksmaliは、odex->smaliというbaksmaliコマンドとsmali->dexというsmaliコマンドのこと。合わせると、odex->dexになるので、プリインアプリのdex内包apkを作成することが事実上可能という。
心底どうでも良いわと思うのだが。
どうも、/system/framework配下を弄る場合、odexはframeworkに依存しているため(最適化に絡む何かだと思うけど)、改変した場合に狂ってしまうらしい。弄る前に作っておいたdexからodexに作り直す必要が出てくるのだろうかね。そんな煩わしいのならば、一様にdex内包しておいた方が良いと思うけどね。dataパテ圧迫ちゅうたって微々たるもんだろうし。アプリいっぱいな人は知らないけど。
という、物凄い軽薄な推論。
物は試しで、framework系を弄るという愚行に走りたいと思います。
視察
/system/framework
ext.jar
ext.odex
qcrilhook.jar
qcrilhook.odex
ime.jar
ime.odex
javax.obex.jar
javax.obex.odex
android.policy.jar
android.policy.odex
framework.jar
framework.odex
services.jar
services.odex
bmgr.jar
bmgr.odex
monkey.jar
monkey.odex
svc.jar
svc.odex
qcnvitems.jar
qcnvitems.odex
core.jar
core.odex
pm.jar
pm.odex
framework-tests.jar
framework-tests.odex
com.qualcomm.location.vzw_library.jar
com.qualcomm.location.vzw_library.odex
com.google.android.maps.jar
com.google.android.maps.odex
android.test.runner.jar
android.test.runner.odex
am.jar
am.odex
com.toshiba.extention.jar
com.toshiba.extention.odex
input.jar
input.odex
framework-res.apk
糞芝エクステンションとか。
抹殺してやりたい。
おぉ？そいや、根くさすにすることを忘れていた。
