Um künftig Änderungen am System durchzuführen wie bspw. die Implementierung von Diensten wie init.d oder cron ist es notwendig, die Startprozedur genauer anzusehen und eine Möglichkeit des Scriptaufrufs möglichst nah am /init zu finden.

Hauptkomponenten des Bootvorganges

Bootloader

Der Bootloader ist grundsätzlich das erste Programm, welches beim Starten des Systems gestartet wird. Technisch gesehen ist er nicht Teil von Android und seine Aufgabe ist es, grundliegende Initialisierungen des Systems durchzuführen um später z.b. den Kernel laden zu können. Dieser initialisiert dann erst die spezifische restliche Hardware befor das eigentliche Betriebsystem gestartet werden kann. Dieser Bootloader („Firmware“) besteht meist aus MBR (Masterboot Record – meist zu finden im ersten Speicherblock), Bootloader Stage 1 und Stage 2.

Je nach Verwendung unterschiedlicher Bootloader (und deren Konfiguration) unterstützen diese mal mehr oder weniger Funktionen und Hardware… beispielsweise die Erkennung von Tasteneingaben um zwischen dem normalen Bootvorgang und eines Recoverymodus oder eines Fastbootmodus zu unterscheiden.

Init

Eine weitere Schlüsselkomponente ist das Progrämmchen „init“ – dessen Aufgabe ist es verschiedene Elemente von Android zu initialisieren. Android verwendet hierbei nicht die Linuxversion von init sondern ein eigenes Programm. Hin und wieder verwenden besser ausgestattete embedded Linux Systeme eine „abgespeckte“ Version vom Linux init in Form der bekannten Busybox.

Das Android init – Programm ruft 2 Files auf: init.rc mit allgemeinen Initialisierungsanweisungen und init.<systemcode>.rc mit hardware-spezfischischen Anweisungen (wobei Goldfish für den Emulator steht. Bei unserem AV7 ist dies noch etwas unklar, da es neben dem init.rc nur das Configfile für den Emu (Goldfish) gibt plus eines für trace und für usb welche beide aus dem init.rc heraus referenziert werden. Da sonst kein init.rc mit Bezug zur Hardwarekennung vorhanden ist, gehe ich davon aus, dass die Hersteller vom AV7 das Teil wirklich im „Emu“ – Modus laufen lassen.

Bootabfolge

Firmware

Stage 1 Bootloader
- Kontrolle auf Tasteneingaben wegen Entscheidung „Recovery or not“. Tastenkombis scheinen beim AV7 nicht zu vorhanden zu sein!
Stage 2 Bootloader
- initialisiert weitere Hardware und ladet den Kernel
Kernel wird in den Speicher geladen – aus der Partition /dev/block/mmcblk0p4 welche mutmaßlich beim Flashen mit dem Image boot.img beschrieben wird.

Kernel

der Kernel startet
- Kernel core Initialisierung
  - Speicher und I/O Bereiche werden initialisiert
  - interrupts starten, Prozesstabelle wird angelegt
- Treiber werden initialisiert
- Threads / Daemons des Kernels werden gestartet
- root Filesystem wird gemountet -> ebenfalls höchstwahrscheinlich blk0p4 / boot.img
- der erste Userland Prozess wird gestartet
  - normalerweise /init (nicht wie auf normalem Linux /sbin/init)

Userland

Der Kernel ruft /init auf
- init läuft über /init.rc und init.<??>.rc
- Dalvik wird von Zygote ( /system/bin/app_process) gestartet (haben ja kein Android 5 *g*) – ca. Zeile 560 in /rc.init
- verschiedene Dienste werden gestartet
  - rild (Radio Interface Daemon)
  - vold (Volume Daemon für die Dateisysteme)
der system server startet und startet weitere core services
- Details nicht so wichtig – siehe http://www.androidenea.com/2009/07/system-server-in-android.html
- init in 2 Schritten
  - eine library wird geladen, um eine Schnittstelle zu einem spezifischen Dienst zu erstellen und danach
  - werden im ServerThread::run() innerhalb des Systemservers javabasierende core Services gestartet
der activity manager startet die core Applikationen (eigentlich Dalvik Applikationen)
- com.android.phone
- com.cardroid.carhome – Launcher
etliche weitere Prozesse werden von /init gestartet
- adbd – ja tatsächlich!
- /system/bin/mediaserver
- /system/bin/dbus-daemon
- etc.

weitere Infos

logcat -d -b events | grep „boot“

I/boot_progress_start(  950): 6041
I/boot_progress_preload_start(  950): 8183
I/boot_progress_preload_end(  950): 11798
I/boot_progress_system_run( 1413): 12019
I/boot_progress_pms_start( 1413): 12182
I/boot_progress_pms_system_scan_start( 1413): 12486
I/boot_progress_pms_data_scan_start( 1413): 15263
I/boot_progress_pms_scan_end( 1413): 17491
I/boot_progress_pms_ready( 1413): 17679
I/boot_progress_ams_ready( 1413): 19508
I/boot_progress_enable_screen( 1413): 25816
I/am_create_service( 1413): [1105891816,eu.chainfire.supersu/.SuperUserIntentService,act=boot_complete,2401]

Gretchenfrage: Wo kommt rc.init her und wie bekommen wir einen Hook?

Muss per Definition zu finden sein im Root Filesystem /
Manuelle Änderungen in /init.rc überleben keinen Neustart. -> wird also beim Hochfahren jeweils neu entpackt, „normalerweise“ aus der Ramdisk / uramdisk.img
es liegt unterhalb von /system -> also ist system.img.lzo auszuschliessen
mögliche Kandidaten für das richtige Root – Filessystem
- boot.img (genauer: das 2. Image im Multi uImage)
  - käme mit 812 Zeilen in etwa hin – aber Änderungen im Image finden sich nach dem Update NICHT am System wieder!
  - komischerweise trifft das auch auf z.b. das default.prop zu – dennoch wurde der Kernel insecure geladen.
- uramdisk.img (ebenfalls 2. Image)
  - rund 200 Configzeilen weniger als boot.img – auch hier scheinen keine Änderungen nach dem Update auf
- recovery.img (2. Image)
  - auszuschliessen – nur 70 Zeilen
- die derzeit noch unbekannten „Data“ Images jeweils am Anfang der oberen 3 Files. Eher auszuschließen da dort wohl der jeweilige Kernel sitzen wird.

AV7 Bootprozess