今日はapkとodexの関連性についてのお話です。
スマフォの/system/appや/system/frameworkを覗くとapkとodexが対になっていると思います。
また、機種によってはodexが無くてapkだけの物もあるかな?
カスタムROMに入れ換えている人も多分apkしかありませんよね。
ここでは昨日のdalvik-cacheの話が出てきます。
apkの中にはclass.dexがあってそれを最適化したものがdalvik-cacheに生成されると話しましたが
よく考えると保存されるのはどちらもnand(内蔵フラッシュメモリ)ですよね。
限りあるnand領域に同じような物がある事は非常に無駄です。
そこでdalvik-cacheに生成されるデーターを事前作成してodexとし
apkの中からclass.dexを取り除いてあるのがこの、apkとodexのセットです。
このセットは完全機種依存のプログラムになりますので
もし、引っこ抜いて他機種に入れたとしても動きません。
移植する場合にはodexをclass.dexに変換し、apkに突っ込んで再署名する作業が必要になります。
と言う事でodex化する利点は以下の様な物になります。
・nand領域の節約になる
・初回起動時間の短縮(system配下のapk分、dalvik-cache作成が必要なくなるため)
・システムアプリを他機種に移植しにくくする
ここでsystem配下にあるapkのodex化について軽く触れておきます。
OSがclass.dexからdalvik-cacheの最適化プログラムを生成するに当り
他のapk内のclass.dexを参照している構造になっている物があります。
例えば中途半端に/system/frameworkだけodex化した場合には、
この依存関係が解決出来ず起動しなくなってしまいます。
これを回避する為には/system/appと/system/frameworkを同時に
且つ、依存関係が解決できる順番でodex化していく必要があります。
この順番はdalvik-cacheをwipeし再起動直後をlogcatで監視し
installdが処理していく順にすればOKです。
スマフォの/system/appや/system/frameworkを覗くとapkとodexが対になっていると思います。
また、機種によってはodexが無くてapkだけの物もあるかな?
カスタムROMに入れ換えている人も多分apkしかありませんよね。
ここでは昨日のdalvik-cacheの話が出てきます。
apkの中にはclass.dexがあってそれを最適化したものがdalvik-cacheに生成されると話しましたが
よく考えると保存されるのはどちらもnand(内蔵フラッシュメモリ)ですよね。
限りあるnand領域に同じような物がある事は非常に無駄です。
そこでdalvik-cacheに生成されるデーターを事前作成してodexとし
apkの中からclass.dexを取り除いてあるのがこの、apkとodexのセットです。
このセットは完全機種依存のプログラムになりますので
もし、引っこ抜いて他機種に入れたとしても動きません。
移植する場合にはodexをclass.dexに変換し、apkに突っ込んで再署名する作業が必要になります。
と言う事でodex化する利点は以下の様な物になります。
・nand領域の節約になる
・初回起動時間の短縮(system配下のapk分、dalvik-cache作成が必要なくなるため)
・システムアプリを他機種に移植しにくくする
ここでsystem配下にあるapkのodex化について軽く触れておきます。
OSがclass.dexからdalvik-cacheの最適化プログラムを生成するに当り
他のapk内のclass.dexを参照している構造になっている物があります。
例えば中途半端に/system/frameworkだけodex化した場合には、
この依存関係が解決出来ず起動しなくなってしまいます。
これを回避する為には/system/appと/system/frameworkを同時に
且つ、依存関係が解決できる順番でodex化していく必要があります。
この順番はdalvik-cacheをwipeし再起動直後をlogcatで監視し
installdが処理していく順にすればOKです。
※コメント投稿者のブログIDはブログ作成者のみに通知されます