[Android] apkの中身を見てみる

今日はapkの中身を見てみようと言うお話です。

まずは題材を選びますが、多分みんな入れているであろうと言うことでRom managerにしますよ。
/data/appからcom.koushikdutta.rommanager-1.apkをPC上に引っこ抜いてきます。
余談ですがアプリには一意のIDが付いていると以前書きました。
Rom Managerの場合にはcom.koushikdutta.rommanagerとなります。
このIDは作者が勝手に付けるもので、多分かぶらないだろうなと言う考えのもと作ります。
普通はプログラムのjavaメインクラス名と同じものになります。

では中身を見てみますが実はapkはzipファイルです。まずは普通に解凍してみます。
AndroidManifest.xmlをテキストエディタ見てみると辛うじて読めそうだけど文字化けしていますねぇ。
中身を弄ろうとすると、ただ解凍しただけでは余り意味がありません。
でも、この状態も大切なのでどんなファイルがあるかを何となく覚えておいて下さいね。
次はapktoolを使ってファイルの中身を見ていきましょう。

[ダークソウル] 二周目も佳境

二周目もあとラスボスを残す所まで来ました。

一周目で行っていなかった所を回っていたのでことのほか時間が掛かりました。
あとは途中から路線変更して白を呼ばず一人でまわる事にしたんです。
やっぱり自力で全てのボスを倒せる様にしておかないと後々詰まりますからね。
オーンスタイン&スモウ以外はそんなに苦労していません。
ちなみにステ振りはオールマイティー型で回っています。

暫く白で遊んでアイテム稼ぎして、いくつかの誓約をこなしてから三周目に入ります。

嫌な場所も度々行っていると慣れるらしい

昨日、一昨日は他の現場に手伝いに行っていました。
バグ探しの仕事です。

俺は昔からテストの工程が大嫌いです。だってやっていて面白くないからw
特にチェックリストを書くのと結果を取って纏める作業が嫌い。
こんなもの本当は無くても良いような気がするんですけどね。
でも、10やってくれる人
もいれば1しか出来ない人もいるわけで
管理者の立場からはレベルを平準化するためにちゃんとやらせないといかんですよ。
あと、後々バグが出た時に「そこはテストしました」とか嘘をつく輩がいるので結果もちゃんとないとダメです。

今回はオペレーションだけしていれば良かったので楽でした。
いつもまた呼ばれるんだろうなと思う状況なので「また今度来たときね」と言って去ってくるのですが
期待を裏切らず呼ばれます。次は11月中ぐらいと予想。

[Android] systemディレクトリの構成

今日はsystemディレクトリの構成についてのお話です。

スマフォのsystem下は大体こんな感じになっていると思います。

system ┳ app
　　　 ┣ bin
　　　 ┣ etc
　　　 ┣ fonts
　　　 ┣ framework
　　　 ┣ lib
　　　 ┣ media
　　　 ┣ usr
　　　 ┗ xbin

この構成はLinuxを踏襲していて、内容物には暗黙のルールがあります。

・app

プリインストアプリが入っている場所です。
ここのアプリは「アプリケーションの管理」からアンインスト出来ません。
apkを消してやれば可。

・bin

C言語で作られた実行モジュールが入っている場所です。
ここに物を突っ込んだり書き換える場合は
パーミッションを755にしないと不具合がでます。

・etc

設定ファイルが入っている場所です。

・fonts

フォントが入っている場所です。

・framework

OSの核となるjavaプログラムが入っている場所です。

・lib

C言語で作られたライブラリが入っている場所です。
ここのリソースはbin,frameworkのプログラムが参照を行っています。

・media

OSで使用する動画、音声ファイル等が入っている場所です。

・usr

ここのディレクトリはLinuxでも明確な定義はなくて何でもありって感じです。
本来はOSに絡まないユーザー寄りのリソースを入れる所なのかな？
でもHP-UXだとほとんどのライブラリは/usr/libにあったりするし…
良く分かりませんな。
Androidだとハードキーのマッピング定義等が入っています。

・xbin

ここはextra binなのかな？
独自の実行プログラムを入れる場所なんだろうと思う。
なので自分で何か突っ込む時はいつもここにしています。
bin同様、パーミッションを755にします。


何か思ったより面白く無かったね。うん。

[Android] systemディレクトリの構成

今日はsystemディレクトリの構成についてのお話です。

スマフォのsystem下は大体こんな感じになっていると思います。

system ┳ app
　　　 ┣ bin
　　　 ┣ etc
　　　 ┣ fonts
　　　 ┣ framework
　　　 ┣ lib
　　　 ┣ media
　　　 ┣ usr
　　　 ┗ xbin

この構成はLinuxを踏襲していて、内容物には暗黙のルールがあります。

・app

プリインストアプリが入っている場所です。
ここのアプリは「アプリケーションの管理」からアンインスト出来ません。
apkを消してやれば可。

・bin

C言語で作られた実行モジュールが入っている場所です。
ここに物を突っ込んだり書き換える場合は
パーミッションを755にしないと不具合がでます。

・etc

設定ファイルが入っている場所です。

・fonts

フォントが入っている場所です。

・framework

OSの核となるjavaプログラムが入っている場所です。

・lib

C言語で作られたライブラリが入っている場所です。
ここのリソースはbin,frameworkのプログラムが参照を行っています。

・media

OSで使用する動画、音声ファイル等が入っている場所です。

・usr

ここのディレクトリはLinuxでも明確な定義はなくて何でもありって感じです。
本来はOSに絡まないユーザー寄りのリソースを入れる所なのかな？
でもHP-UXだとほとんどのライブラリは/usr/libにあったりするし…
良く分かりませんな。
Androidだとハードキーのマッピング定義等が入っています。

・xbin

ここはextra binなのかな？
独自の実行プログラムを入れる場所なんだろうと思う。
なので自分で何か突っ込む時はいつもここにしています。
bin同様、パーミッションを755にします。


何か思ったより面白く無かったね。うん。

Androidのgitが復活した

この週末からAndroidのgitが復活しています。
URLはhttps://android.googlesource.com/
今回からgmailによるログイン認証が必要になりました。
Android使いの人ならgmailアカウントは絶対持っているでしょうから、良いんじゃないですかね。
この認証コードはhttps://android.googlesource.com/から取得してくるんですが
どうも端末もチェックしているようで、git接続するPCでコードを取得する必要があるようです。
試していませんが新たな認証コードを取得すると以前のは無効になるんじゃないかな。

あとはWeb上からgitの中身が覗けなくなりました。
ここが一番セキュリティホールになる所なので仕方ないことかな？
でも新しいブランチのチェックとかちょっと面倒ですね。
取り敢えずはmanifestをcloneして「git branch -a」を叩くのかな？

以下、需要あるか知らんけど新gitの設定

・repoの更新

上記の認証対応とgitのURLが埋め込まれているのでrepoを更新します。

curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo

置き先は適宜変えてください。

・認証コードを取得する

gmailアカウントにログインした状態でhttps://android.googlesource.com/にアクセスし
「Generate New Password」→「Allow Access」
画面下に表示された文字列をコピーして~/.netrcとして設置します。

あとは普通に

repo init -u https://android.googlesource.com/platform/manifest -b android -2.3.7_r1

とかやってやればOK。

なんとなく調子悪い

今日はあまり書き物をする気が起こりません。

ちょっと調子悪い気もするんですが
最近は夜更かしの眠気が翌々日に来たりするので
理由が良くわからない。
昨日寝過ぎたのが原因のような気もしますが
どちにしても不摂生な生活が原因ですな。

[ダークソウル] 二周目も順調

一周目でスルーしてしまったイベントをこなしつつ、順調に進んでいます。

ただ、デブガリの所はことのほか苦労して20時間位かかってしまいました。
白呼んでも皆死んでしまうし、人間性も尽きてしまってね。
結局は一人で倒せましたけど。
一周目は白呼んで倒してしまったので動きを見切る所までは行っていなかったんですね。
これで次の周回に進んでも多分大丈夫。

現在のSLは87位だったかな？
これ以上余り上げるつもりはありません。
行ける所まで行ってみようと思います。

Android 4.0

昨日、Galaxy Prime(Galaxy Nexus)と一緒にAndroid 4.0が発表されましたね。

4.0はスマートフォン用の2.3.Xとタブレット用の3.Xが統合された物ですが
UIの雰囲気は3.Xっぽいですね。
4.0のソース公開はGalaxy Prime発売の二週間後位になるそうですが
是非ともそこでgitを復活させて貰いたいものです。
また、GPL部分のみの公開だったら嫌だな。

発表にあわせてAndroid SDKのエミュに4.0が追加されています。
興味のある人は触ってみてください。
SDKもr14にバージョンアップしてAVD Manegerが分離したりUIが刷新されたりしていますが
今回からパッケージにfastbootが含まれなくなったようです。
バックアップをとっておくか、アップデートせず別ディレクトリに入れるとかした方が良いかも。

[Android] apkとodex

今日は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です。