本 : Android を支える技術 Ⅱ

kawasin73 / knowledge

気になったツールやサイト、勉強した内容をまとめます。

8 stars 0 forks source link

本 : Android を支える技術 Ⅱ #35

Closed kawasin73 closed 3 years ago

kawasin73 commented 3 years ago

1 章 Android と Activity の基礎知識

1.1 : Activity が実現する世界

1.1.1 : スマホにおける画面遷移の標準を提供

スマホは１画面に1つの機能を実装するのが基本。画面遷移が多くなる。

1.1.2 : たくさんのアプリが共同でタスクをこなす

スワップアウトが無効になっているから、マルチタスクの状況はサーバーとは異なる。その代わり、Activity は半手動でスワップアウトのような機構を実現している。たくさんのアプリが連携する。その分同時に複数のアプリが動く。

1.2 : 入門 Activity プログラミング

1.2.1 : まずは HelloActivity から

1.2.2 : ある A という Activity から HelloActivity を起動してみる

明示的インテント

1.2.3 : テキストファイルを別のアプリで開いてみる

ACTION_VIEW インテント、暗黙的インテント FLAG_ACTIVITY_NEW_TASK フラグをつけると、新しいスタックが作られる。

1.2.4 : ギャラリーアプリなどで画像を選ぶ

ACTION_PICK インテントと onActivityResult()

1.2.5 : Activity が再生成された時の対応

onSaveInstanceState()
- 裏に行く時に毎回呼ばれる
onRestoreInstanceState()
- 再生成された時のみ呼ばれる
  1.2.6 : Activity のライフサイクルとは何か？
  
  1.3 : Activity はどう実現されているのか？
  
  この後の章の概要なので割愛
  
  1.4 : 本書で登場する Android の構成要素のうち本書の主役ではない部分
  
  1.4.1 : Looper と UI スレッド
  
  1.4.2 : Handler と handleMessage()
  
  1.4.3 : Binder とシステムサービス
  
  Binder は Android の中の分散オブジェクトの仕組み。プロセスや言語を気にせず呼び出せる。システムサービスは Binder を利用して機能を提供するシステムサービスは1つのプロセスに複数存在できる。1つのプロセスにまとめることで効率的になる
Binder を使う時には各プロセスでドライバの初期化とスレッドプールの初期化が必要
Binder 越しに呼び出される側は Binder 独自のスレッドプールのスレッドで動く
1.5 : Activity の仕組みを支えるデーモンとシステムサービス達

init.rc から起動される

1.5.1 : init.rc ファイルの今と昔

init.rc ファイルは複数のディレクトリに置かれている。

1.5.2 : service セクション

init.rc でソケットを作成するオプションがある。

1.5.3 : 本書で登場する init から起動されるサービスとデーモンたち
Zygote サービス
- Java で書かれたもののプロセスの親になる
installd サービス
- PackageManagerService と協力してアプリのインストールをする時に使われるサービス。インストールは各ユーザーだけが触れるディレクトリを作るなどの特権的な処理が必要だが、汎用的なライブラリを含むプロセスが特権を持つのは危ないので専用の installd が用意されている。installd はインストール処理のうち、mkdir と chown と chmod する部分だけを抜き出したような形になっている。
lmkd サービス
- oom_score_adj を変更するだけの機能を持ったサービス。Low Memory Killer
- lmkd へのソケット権限は 0660 で system ユーザーしかアクセスできない
  1.6 : まとめ

kawasin73 commented 3 years ago

2 章アプリのインストールとその情報

2.1 : Google Play の衝撃

2.1.1 : Google Play を実現するために必要な2つの前提

できの悪いアプリがクラッシュしても他のアプリやシステムに影響を与えない
アプリに必要な権限だけを使わせてそれ以外にはアクセスさせない仕組み
2.1.2 : かつての携帯電話の OS にはプロセスがなかった

かつてはプロセスという概念がなかった。プロセスの実現には MMU が必須。

2.1.3 : アプリの権限を制限する仕組み

PC の場合はユーザーがインストールしたソフトウェアは信頼できるものという前提がある。管理者がいるから？スマホのユーザーは知識がないので信頼できるかわからない。

2.1.4 : Android は、Linux のセキュリティ機構を応用したセキュリティモデル

新しいセキュリティモデルを作るのは長い道のり。バグをあぶり出すための時間が必要。Linux のマルチユーザーのセキュリティモデルは長い実績がある。Android ではアプリ同士は信頼しない。

2.2 : アプリのインストール

2.2.1 : アプリのインストールの概要

PackageManagerService がインストール処理を行う。
空いている uid をアプリに割り振る
/data/data/<パッケージ名> というディレクトリを作成し、割り振られた uid に chown する
package.xml に uid とパッケージ名や apk の置かれているパスなどのアプリの情報を書き込むアプリの起動には package.xml に書かれた情報が使われる。
2.2.2 : uid の割り振り

uid の範囲は frameworks/base/core/java/android/os/Process.java で定義されていて、10000 ~ 19999。使われている uid は frameworks/base/services/core/java/com/android/server/pm/Settings.java の mUserIds の ArrayList に保持されている。複数のアプリで権限を共有したいときは AndroidManifest.xml の sharedUserId を指定して署名すると、アプリの uid は同じものが割り当てられる。

2.3 : installd による data ディレクトリの作成

2.3.1 : data ディレクトリ

chown などだけをする installd プロセス。

2.3.2 : installd プロセスの起動

init プロセスから直接 fork される

2.3.3 : installd の権限

Linux の capability の仕組み。

2.3.4 : data ディレクトリの作成と権限設定

installd はソケットから受け取った情報をもとに mkdir と chown をする。

2.3.5 : data ディレクトリに置かれるファイル達

SharePreferences や SQLite の実ファイル。独自のファイルは、/data/data/<パッケージ名>/files の下に置くことになっている。Context#getFilesDir() で取れる。

2.3.6 : dexopt コマンドによるバイトコードのインストール時処理

installd は dexopt コマンドも受け取る。コンパイル方式の変更によって installd でやることも変わってきている。

2.4 : packages.xml によるアプリの管理

2.4.1 : packages.xml の役割

全てのアプリの情報を持つ。
uid
apk のパス
署名
2.4.2 : 実際の packages.xml の中身

/data/system/packages.xmlにある。壊れている場合は /data/system/packages-backup.xmlが使われる。 package 要素の他にも、permissions や shared-user もある。 Android アプリは NDK を使って一部をネイティブで開発して Java からそれを呼ぶことができる。該当するアーキテクチャのバイナリを FAT バイナリから取り出して lib ディレクトリにコピーする

2.4.3 : 起動時の packages.xml 読み込み

2.4.4 : packages.xml の権限と重要性

system ユーザーのみが読み書きできる。

2.5 : インテントとインテントの解決

2.5.1 : インテントを送る側

アクション指定して暗黙的インテントでどのアプリとも連携できる

2.5.2 : インテントを受け取る側

アプリは拡張子が apk の zip アーカイブ。インテントの解決は、PackageManagerService の resolveIntent() メソッドで行われる。

2.5.3 : インテントの解決

PackageManagerService は起動時に packages.xml を読み込み、全ての apk ファイルの AndroidManifest.xml から intent-filter をリストに登録する。アプリがインストールした時も。

2.5.4 : intent-filter を持つその他の要素達
activity
service
- SDK の Service
receiver
- BroadCastReceiver
  2.6 まとめ

kawasin73 commented 3 years ago

3 章カーネル側から見たメモリ不足

3.1 : メモリ不足時のカーネル側の振る舞い

全体像の説明

3.1.1 : メモリ不足時のカーネル側の振る舞い、全体像

lmkd にメッセージを送ることで oom_score_adj を更新し、そしてこのスコアに応じて、メモリ不足の時には lowmemorykiller ドライバや OOM Killer がスコアの高いプロセスを kill することでメモリを解放する。 Linux のメモリ不足の仕組みだけだと運任せになるので２段構えになっている。

カーネルがファイルシステムにキャッシュの解放を依頼するフェーズ
- lowmemorykiller ドライバが不要なアプリのプロセスを kill
Linux カーネルがプロセスを kill するフェーズ
- Android が oom_score_adj のスコアを通知する
  3.1.2 : Linux カーネルのメモリ回収と oom_score_adj
  
  Linux カーネルは oom_score を使う。経験則によって重要そうでなくてメモリをたくさん持っているプロセスを殺す。ユーザーランドから指定するための仕組みが oom_score_adj
  
  3.1.3 : lmkd デーモンとスコア更新
  
  oom_score_adj は特権のあるユーザーのみ設定可能。そのプロセスが lmkd
  
  3.1.4 : lowmemorykiller ドライバ
  
  デバイスドライバとして実装。Linux がプロセスを kill する前に不要なプロセスを殺す Android の機能このドライバも oom_score_adj を参照して殺すプロセスを決める。
  
  3.2 : Linux カーネルのメモリ回収
  
  3.2.1 : Linux のページフレーム回収の難しさ
  
  demand paging ユーザプロセスがメモリを確保・解放しても実際に割り当てられたり解放されているとは限らない。 Linux のメモリアロケータは大きく2つに分けられる。
ゾーンアロケータ
- ユーザプロセスやデバイスドライバなどが使う
slab アロケータ
- カーネル内のオブジェクトに使われる。 Linux ではメモリの回収は回収できそうなページを勝手に回収する。
  3.2.2 : Linux のページフレーム回収の概要
  
  解放のタイミング
メモリ確保時
定期的に
- kswapd ページフレームの分類
同期可能ページ
- 2次記憶にあるファイルの中身と同じ内容のメモリ
破棄可能ページ
- 現在使用していないがキャッシュとして存在しているメモリ
回収不能ページ
- ファイルの中身と違うメモリ内にしか保持されていない内容を含むメモリ
- すでに回収ずみで回収の必要のないメモリ
スワップ可能ページ
- スワップすることで解放できるメモリ
- Android ではスワップがないので回収できないメモリがファイルにマップされているかは Android では PC よりも重要になる。

slab アロケータのメモリもゾーンアロケータと同じタイミングで回収が試みられる。メモリを回収した後もメモリが不足した場合、緊急事態として OOM Killer が発動

3.2.3 : OOM Killer と oom_score

/proc/<process id>/oom_score で確認できる。SIGKILL で kill する。Linux の OOM Killer に頼るには Android のアプリの kill は頻度が高すぎる。

3.2.4 : oom_score_adj と OOM Killer の挙動のカスタマイズ

/proc/<process id>/oom_score_adj には -1000 から 1000 までの値を設定可能。 root 権限が必要。小さいほど kill されなくなる。

3.3 : Android の Low Memory Killer

3.3.1 : フラッシュメモリの仕組みと Android のスワップ事情

3.3.2 : Low Memory Killer の基礎知識

Low Memory Killer は、Android 上で OOM Killer をカスタマイズしている仕組みや、もっと前の段階でメモリを空ける仕組み

3.3.3 : lowmemorykiller モジュールと shrinker

Linux ではカーネルはファイルシステムの知識を持たず、キャッシュの解放はファイルシステム自身がコールバックを呼び出すようになっている。これが shrinker このコールバックを使って裏に回った Activity のプロセスを kill するのに活用メモリ逼迫でカーネルが shrink_slab() を呼び出す。これがディスクキャッシュを削減するタイミング。このタイミングのコールバックを登録するのが register_shinker() というインカーネル API。登録されるコールバックを shinker と呼ぶ。 Android 独自の lowmemorykiller というカーネルモジュールが shrinker を使って裏の Activity を kill する。 oom_score_adj を元に kill する Activity を選ぶ。その時のメモリの切迫具合に応じて段階的に kill される。

/sys/module/lowmemorykiller/parameters/minfree
- 残りメモリの閾値をカンマ区切りで列挙
/sys/module/lowmemorykiller/parameters/adj
- minfree に対応する oom_adj の値をカンマ区切りで列挙の2つのパラメーターでその挙動を制御。パラメータは lmkd が設定する。
  3.3.4 : lmkd デーモンと oom_score_adj 更新
  
  lmkd が adj と minfree のパラメータ変更、oom_score_adj の変更を行う。root 権限。 /dev/socket/lmkd というソケットに読み書きするのは ActivityManagerService だけ。 lmkd へのコマンドは、2つだけ。プロトコルは４バイト区切りで、最初の 4 バイトがコマンドで、続くブロックがその引数。
LMK_TARGET = 0
- adj と minfree を設定するコマンド
- 引数には adj と minfree の値が交互に並ぶ
LMK_PROCPRIO = 1
- oom_adj を設定
  3.4 : まとめ

kawasin73 commented 3 years ago

4 章スタックから見た！Activity のライフサイクル

4.1 : ActivityStack とタスク

4.1.1 : なぜ Activity をスタック構造で管理するのか

画面が小さいので一つの画面に一つの役割を持たせるのが一般的。そのため、画面遷移が必然的に頻繁に起こる。ある画面を再利用したくなる。前後の遷移と画面を切り離すことが重要。C などの関数がコールスタックで実現されるのに似ている。

4.1.2 : タスク

タスクとは複数の Activity が連携して１つの仕事をこなす単位。バックキーを押して辿ることのできる Activity を含む

4.1.3 : タスク作成を意識する難しさ

基本的には新しい Activity が別のタスクになるのかは system がよしなに判断してくれる。launchMode で制御もできる

4.1.4 : Activity を管理するスタック

ActivityStack

4.1.5 : ActivityStack とタスクの戻り先フラグ

ActivityStack にはホーム画面用とそれ以外用(アプリの)の2つの ActivityStack インスタンスがある。一般的なタスクは作成される都度アプリの ActivityStack に載せられる。タスク内の Acitivity の順序は変えられない。タスクの順番はアクセスするたびに ActivityStack の一番上に移動する ActivityStack はタスクのリストを保持している。一旦ホーム画面に行った後に別のタスクにアクセスすると戻り先が Home であるというフラグが立つ。

4.1.6 : launchMode とインテントフラグ

launchMode は AndroidManifest.xml の要素に設定する。

standard
singleTop
singleTask
singleInstance インテントフラグは、Intent#addFrags() で設定。
4.1.7 : タスクと ActivityStack の具体例 - 通常の Activity 起動のケース

何も設定していない場合。

4.1.8 : タスクと ActivityStack の具体例 - launchMode が singleTask のケース

例えば Chrome 一度ホーム画面を見ると戻り先のフラグが home に上書きされる。別のタスクからその Activity を起動してもすでに作られている Activity に飛ばされ、戻り先のフラグもクリアされる。難しいので非推奨

4.1.9 : タスクと ActivityStack の具体例 - インテントフラグ

FLAG_ACTIVITY_CLEAR_TOP はよく使う。 A-B-C-D と Activity が積まれている状態で A-B と遷移したい時。C-D を同時に消す。

4.1.10 : タスクと ActivityStack についての考え方

4.2 : アプリ側から見たメモリ不足

4.2.1 : Android における重要なプロセス
システムの維持に必要なサービスは重要
- init プロセス、SystemServer プロセス、lmkd プロセス
- 起動時から変わらないので難しくない
画面を占有してユーザとやりとりしているアプリは他のアプリより重要
- ActivityManagerService が ActivityStack を操作するときに設定
SDK の Service や ContentProvider などを提供するプロセスは他のアプリプロセスよりも重要
- ActivityManagerService が各プロセスをチェックして対応するものが存在するかを判断このルールに基づいて oom_score_adj を指定する
  4.2.2 : ActivityStack と oom_score_adj
  
  -17 から +16 の間で指定。大きいほど削除していい。キャッシュされているアプリは 9 ~ 15 で時間に応じて大きくなる。見えているアプリには 0 と 1
  
  4.3 : Activity の生成
  
  ActivityStack には Activity ではなく、ActivityRecord が積まれる。
  
  4.3.1 : ActivityStack と ActivityRecord
  
  Activity を再開するのに必要な情報をアプリプロセスとは別に保存する。ActivityRecord は ActivityManagerService のプロセスに保持される。 Activity#attach() で Activity と ActivityRecord が対応づけされる。
  
  4.3.2 : Bundle はどこにあるのか？
  
  onSaveInstanceState() と onRestoreInstanceState() Bundle は Activity のあるプロセスで作成されて、Binder で ActivityManagerService に送られて ActivityRecord に保存される。
  
  4.3.3 : Bundle はどのくらい kill されないか？
  
  SystemServer のプロセスは -16 に設定される。これが kill されるのは相当な異常事態
  
  4.3.4 : ActivityRecord からの Activity 生成
  
  パッケージ名から ProcessRecord を調べて、対象となるプロセスがあるかを確かめる。
プロセスが存在するとき
- ActivityThread のプロキシに対して scheduleLaunchActivity() を呼び出す
プロセスが存在しないとき
- プロセスを作る。
- プロセスから ActivityManagerService に非同期で attachApplication() が呼ばれる。
  4.4 : Activity のライフサイクル
  
  4.4.1 : Activity のライフサイクル概要
  
  4.4.2 : Activity のライフサイクルで実現したいこと
  
  ユーザーにアプリを起動しているかしていないかを意識させない。そのため、アプリには終了する方法は提供しない。アプリ開発者はライフサイクルに則っていれば、プロセスが kill されたかどうかを意識することなく実装できる
  
  4.4.3 : Activity のライフサイクル - ActivityStack の視点から
  
  Activity のライフサイクルの各コールバックは、ActivityStack 上に ActivityRecord を操作するときに呼ばれる。 ActivityManagerService が ActivityStack を操作する。
  
  4.4.4 : ActivityRecord の一時的な実体としての Activity
  
  ActivityRecord が Source of Truth になり、Activity がその写像になる。表にある Activity 以外は全てキャッシュのようなもの。
  
  4.4.5 : Activity のライフサイクル - Activity インスタンスの視点から
  
  裏に行ったらいつ削除されてもいいように覚悟する。
  
  4.4.6 : Activity のライフサイクル - ActivityManagerService の視点から
  
  ActivityMangerService から Activity のプロセスへ投げるメッセージは launch などの1つのメッセージだが、アプリのプロセスでは onCreate() や onStart() などの複数のライフサイクルメソッドが呼ばれる。バックキーで一つ下の Activity を再開するとき、ActivityRecord を調べてそのプロセスがまだ生きているかを確かめる。生きている場合は resume のメッセージを送る。死んでいる場合はプロセスを生成し、launch のメッセージを Bundle 付きで送る。
  
  4.4.7 : Activity のライフサイクル
  
  4.5 まとめ

kawasin73 commented 3 years ago

5 章アプリのプロセスから見る！Activity の生成と再生成

5.1 : アプリ側プロセスの Activity

5.1.1 : プロセスの生成からアプリのプロセスになるまで

Zygote からプロセスを fork。ソケットでエントリポイントとなるクラス名 (ActivityThread) や uid を受け取る。ActivityManagerService が Zygote に依頼する。 ActivityThread#main() の時点では apk の情報はわからないので ActivityManagerService に問い合わせる。これが ActivityThread#attach()。

5.1.2 : アプリのプロセスが、Activity を生成するまで

attach() が終わると ActivityManagerService が ActivityThread の scheduleLaunchActivity() を呼ぶ。このときに token が作られてアプリのプロセスに渡される。token が Activity の id になる。

5.2 : バイトコードを実行するプロセスとその始まり

5.2.1 : app_process とその main() 関数

app_process コマンドでバイトコードの実行環境を実行できる。2つのモードがある。

指定された特定のクラスをロードして実行するモード
- adb pm コマンドで
Zygote をロードして待機モードになるモード
- --zygote オプション
- init.rc の service で立ち上げられる。
  5.2.2 : ZygoteInit の main() メソッドの 3 つの処理

preload() で共有したいクラスを全てロード
SystemServer プロセスを起動
runSelectLoop() でソケットを待ち、やってきたメッセージに応じて処理
MethodAndArgsCaller が throw されたら catch して、引数のメソッドを呼ぶ

exception を使うのはコールスタックを一番上まで戻すため。

5.2.3 : preload() メソッドでロードされるクラス達

preloadClasses() では、/system/etc/preloaded-classes に書かれているクラスがロードされる。

5.2.4 : runSelectLoop() メソッド処理概要

selectReadable() で server ソケットと peer ソケットを待つ。

5.2.5 : Zygote の forkAndSpecialize() と Process.start() メソッド

ZygoteConnection#runOnce() Process.start() が Zygote にメッセージを書き込む。

5.2.6 : startSystemServer() メソッドと SystemServer のプロセス

SystemServer プロセスは他のプロセスよりも大きな権限が必要になるので事前に fork する。

5.3 : ActivityThread とは何か？

5.3.1 : ActivityThread の 3 つの重要なメソッド

main()
- 最初に呼ばれる関数
attach()
- 共通のコードから apk のアプリに切り替わる
handleMessage()
- Handler
  5.3.2 : ActivityThread の役割
アプリのプロセスのエントリポイント (main メソッド)
ActivityManagerService とアプリのプロセスとのインターフェース
Activity や SDK の Service のライフサイクル関連の処理を実際に行うクラス
UI スレッドを表すオブジェクト
アプリの apk のクラスをロードして実行するクラス
5.4 : ActivityThread の構成要素と main() メソッド

5.4.1 : ActivityThread の main() メソッド

main() を呼び出したスレッドがアプリのメインスレッドになる。

5.4.2 : ActivityThread の 2 つの内部クラス
H
- Handler のサブクラス
- main スレッドで初期化
ApplicationThread
- Binder のサブクラス
- 呼ばれるスレッドは main スレッドとは別。
- Binder からの通知を H にメッセージを投げるだけ。
  - メソッド名に schedule を使う convention がある
  - 実際の処理はせずにメッセージを投げるだけ。H が実際の処理を起動する。実際の処理は top クラスである ActivityThread に書かれている。
    5.5 : attach() メソッドと Application Context の誕生
    
    attach() は ActivityManagerService に自分のプロセスを登録する
    
    5.5.1 : attach() メソッドで行われること
ActivityManagerService#attachApplication() を呼び出す。
bindApplicatoin() と scheduleLaunchActivity() が呼ばれる。
5.5.2 : handleBindApplication() での Application Context と Application インスタンスの作成

bindApplication() で ActivityManagerService から apk の情報が渡ってくる。
apk の情報から Application Context を作成
apk からクラスをロード
カスタムの Application クラスが指定されていたらそれをインスタンス化
5.5.3 : attach() メソッドの呼び出しスタック

5.6 : ActivityThread の handleMessage()

5.6.1 : handleMessage() 周辺の構造

H で実装されている。

5.6.2 : Activity と Context の誕生

handleLaunchActivity()
ActivityClientRecord のデータから performLaunchActivity() で Activity や Context の作成、onCreate() の呼び出しを行う。
- 作った Context を作った Activity に attach() する。
handleResumeActivity()
5.6.3 : H のメッセージ概観

いろんなメッセージ ID がある。

5.7 : アプリの開始を見直す

5.7.1 : 本節で見ていく startActivity() の呼び出しコード例

startActivity(intent)

5.7.2 : 最初はインテントの解決

ActivityManagerService がインテントから Activity を解決する。PackageManagerService#resolveIntent()

5.7.3 : プロセスの開始と初期化

ActivityManagerService は ActivityRecord を作って ActivityStack に積む。 Process.start() で Zygote にプロセス作成を依頼。 fork されたプロセスで ActivityThread.main() が実行されて attach() を呼び出す。apk のクラスがロードされて Activity が作成される。このときに oom_score_adj を更新

5.7.4 : oom_score_adj によるプロセスの kill

lmkd で oom_score_adj のスコアを更新 Linux カーネルがメモリが足りなくなってきたときに shrink_slab() を呼び出す。このコールバックから lowmemorykiller ドライバの shrinker が起動される。それで間に合わないときは OOM Killer が発動。

5.7.5 : アプリの開始解説の結びに

5.8 まとめ

kawasin73 commented 3 years ago

6 章 Android の始まり

6.1 : ブートローダーとその周辺

6.1.1 : 電源を入れてから init を起動するまでの概要

ブートローダーの実行
カーネルのロードと実行
init を起動するのに必要な程度のカーネルの初期化
init プロセスの起動
カーネルの残った初期化と、init による初期化、ファイルシステムのマウントなど
6.1.2 : Android 端末のパーティション

端末ごとに違うがよくある構成はこれ
aboot
- ブートローダーが保存されている
boot
- boot.img が保存されている。ブートイメージ
- カスタム ROM でブートイメージを焼く時とか
cache
- バックアップなどで使われる
- /cache にマウント
recovery
- リカバリイメージが保存されている
system
- Android を構成するバイナリが格納されている
- /system にマウント
- 読み取り専用でマウントされる
userdata
- /data にマウント
- アプリごとのデータや apk が保存
  6.1.3 : ブートイメージとリカバリイメージ
  
  基本的なフォーマットは2つとも同じ。ヘッダ、カーネル、RAM ディスク RAM ディスクにはルートになるファイルシステムが入っているファクトリーイメージにはブートイメージの他のパーティションの初期イメージが含まれている。
  
  6.2 : Android のブートローダ
  
  6.2.1 : LK ブートローダとはなにか？
  
  Little Kernel Boot Loader 汎用的なブートローダ
署名されたイメージのロードをサポート
Device Tree をサポート
fastboot というモードをサポート
6.2.2 : 通常のブートローダの処理

通常 aboot パーティションは書き換えが困難になっているのが通例。ブートローダの処理
ハードウェアを初期化
- PC ではカーネルが行うようなことも Android ではある程度構成を知っているのでブートローダでできる
ブートイメージの署名を確認し、正しい秘密鍵で署名されているかを確認
- root を取る時に行うブートローダのアンロックはこの署名検査を外すこと
カーネル、Device Tree, RAM ディスクをメモリにロードして、そのロードしたアドレスを特定のレジスタに入れた上でカーネルに処理を移す

Device Tree はデバイスのパラメータを記述。デバイスドライバが読み取って利用する

6.2.3 : fastboot 概要

USB でホスト PC と通信できるモードが fastboot 大抵はボリュームダウンを押しながら電源を入れる。

6.2.4 : ブートローダの話、終わりに

6.3 : init プロセスとその始まり

6.3.1 : init プロセスとその処理概要

ファイルシステムなどのシステムの初期化を行う
必要となるシステムサービスやデーモンを立ち上げる
システムサービスやデーモンのプロセスとしてシグナルを処理し、必要に応じて restart 処理をする
プロパティの処理
- システムの設定などを保存する Android 特有の仕組み。
  6.3.2 : init プロセスの始まり
  
  init.cpp の main() 関数から始まる
ファイルシステムのマウント
プロパティの初期化
epoll_fd 関連の初期化
init.rc のパースと実行 /init.rc はハードコードされており、差し替える仕組みはない。
6.3.3 : init の main() 関数後半

無限ループの部分
ActionManager に積まれているコマンドの処理
restart 処理
epoll_wait() とその処理
6.3.4 : init のシグナル処理

シグナルハンドラ (SIGCHLD_handler()) でソケットペアにシグナルの内容を書き込む。そのソケットペアを epoll で監視する。ソケットのハンドラでは、ServiceManager の ReapAnyOutstandingChildren() を実行。子プロセスを restart したりする。
子プロセスの kill
保持しているソケットを削除
service の記述に応じて、restart など Reap の中では再起動は行わず、SVC_DISABLED フラグを立てる。再起動は init のループで行う。
6.4 : プロパティ

6.4.1 : プロパティの具体例

/system/bin の下の getprop と setprop で、adb shell から操作できる。

6.4.2 : 特殊なプロパティ

ro. のプレフィックスは read only ctl, のプレフィックスは設定すると副作用を発行するだけで値を持たない。(ctl.stop など)

6.4.3 : プロパティの listener

SDK にはないが、listener を登録することで監視できる。

6.4.4 : プロパティの実装

プロパティは基本的に init プロセスがオンメモリで保持する。値は /dev/__properties__ に mmap されて見ることができる。

6.5 : init.rc とその内容

6.5.1 : PC の rc スクリプトとの比較

Android の方がファイルシステムのマウントなど多くのことをやっている

6.5.2 : Android Init Language 概要
アクション
- コマンドをまとめたもの、トリガーによって実行される
トリガー
service
6.5.3 : アクションとトリガー

6.5.4 : 様々なトリガー
文字列のラベルとしてのトリガー
プロパティの値に応じたトリガー
6.5.5 : service によるサービス定義

6.6 まとめ

kawasin73 commented 3 years ago

Appendix

A.1 Activity の onSaveInstanceState() デフォルト実装

A.1.1 : 基本事項のおさらい

EditText の情報などは onSaveInstance で自動的に保存されている

A.1.2 : 実際の Activity の onSaveInstanceState() のコード

mWidnow.saveHierarchyState()

A.1.3 : PhoneWindow の saveHierarchyState()

フォーカスの当たっている View などを保存する

A.1.4 : Parcel と Parcelable

Binder のための配慮

A.1.5 : View の saveHierarchyState() より先の処理

ただ、dispatchSaveInstanceState() を呼ぶだけ。各 View の onSaveInstanceState() が発動される。

A.1.6 : dispatchSaveInstanceState() を眺める

フラグが SAVE_DISABLED になっていない View が対象

kawasin73 / knowledge