Kernel بالا آمده، partitionها mount شدهاند و Android init serviceها را راه میاندازد. اما هنوز Home Screen نداریم. آخرین بخش مسیر، ساختن Android Runtime و Framework است.
Native services
init بر اساس rc fileها سرویسهای پایه مثل logd، vold، servicemanager، SurfaceFlinger و daemonهای دیگر را در زمان مناسب Start میکند. ترتیب دقیق دستگاهوابسته است.
Binder
Binder IPC اصلی Android است. Kernel Binder driver پیامها را بین Processها منتقل میکند و ServiceManager registry سرویسهای Binder را فراهم میکند.
ServiceManager
Processها سرویس خود را register میکنند و Clientها handle آن را میگیرند. بخش بزرگی از Android Framework روی همین الگوی Binder service ساخته شده است.
Zygote
Zygote Process ویژه Android Runtime است که init آن را Start میکند. Zygote classها و منابع مشترک را preload میکند و به جای راهاندازی Runtime از صفر برای هر App، Processهای جدید را fork میکند. AOSP آن را ریشه Processهای System و App با ABI مربوطه توصیف میکند.
init → Zygote
├─ preload ART/classes/resources
├─ fork system_server
└─ fork app processesART
Android Runtime اجرای Dex/bytecode، JIT/AOT و runtime services را مدیریت میکند. Preload در Zygote باعث startup سریعتر و Memory sharing بیشتر میشود.
system_server
system_server یکی از مهمترین Processهای Android است و تعداد زیادی Java Framework Service را میزبانی میکند. Zygote آن را fork میکند و Serviceها مرحلهبهمرحله Start میشوند.
- ActivityManagerService
- PackageManagerService
- WindowManagerService
- PowerManagerService
- Display/Input services
- Connectivity services و دهها System Service دیگر
Package Manager
PackageManager state Packageها، Permissionها، Componentها و Installها را میخواند تا Framework بداند چه Appهایی وجود دارند و چه چیزی میتواند اجرا شود.
Activity Manager
AMS lifecycle Processها و Componentهای App را هماهنگ میکند و برای ساخت Process جدید از Zygote استفاده میکند.
WindowManager و SurfaceFlinger
WindowManagerService policy و state Windowها را در Framework مدیریت میکند. SurfaceFlinger compositor native است و Surfaceها را برای نمایش Compose میکند. دیدن Boot Animation یعنی graphics stack تا حد خوبی بالا آمده، نه اینکه تمام Framework آماده شده باشد.
Launcher
وقتی Framework به Boot phase مناسب رسید، HOME Activity resolve و Start میشود. Launcher خودش یک App است؛ Process آن از طریق Zygote ساخته میشود و Activity اصلی Home را نمایش میدهد.
system_server ready
↓
resolve HOME activity
↓
Zygote forks Launcher process
↓
Launcher Activity
↓
HOME SCREENBOOT_COMPLETED و Direct Boot
Android بعد از رسیدن به مرحله مناسب Boot، BOOT_COMPLETED را برای Appهای مجاز ارسال میکند. با File-Based Encryption، بعضی Appها قبل از Unlock کاربر به Device Encrypted storage دسترسی دارند و بعد از Unlock، Credential Encrypted data باز میشود.
کل زنجیره
Power
↓
SoC ROM (PBL/BROM)
↓
Early boot stages
↓
Android bootloader
↓
Secure Boot / AVB
↓
Kernel + ramdisk
↓
Linux Kernel
↓
/init PID 1
↓
first/second-stage init
↓
Binder / native services
↓
Zygote
↓
system_server
↓
Framework
↓
Launcher
↓
HOME SCREENBoot failure چه سرنخی میدهد؟
EDL/BROM only → ROM-level path alive
Fastboot works → bootloader level alive
Kernel starts but no Android → kernel/init/mount issue possible
Boot animation loops → large parts of userspace alive
Home appears but apps fail → later framework/data/package issue possibleاین جدول ابزار تشخیص قطعی نیست، اما نشان میدهد شناخت Boot chain چطور در Debug و Repair به محدود کردن محل مشکل کمک میکند.
Qualcomm و MediaTek بعد از Kernel
بعد از ورود به Linux و Android userspace، معماری AOSP مشترکتر میشود. تفاوت Vendorها همچنان در Driverها، HALها، TEE، firmware و vendor services مهم است، اما init، Binder، Zygote و system_server مفاهیم مشترک Android هستند.
جمعبندی مجموعه
- Boot از Android شروع نمیشود؛ از ROM داخل SoC شروع میشود.
- Qualcomm و MediaTek Recovery path و نام Stageهای متفاوت دارند.
- Bootloader Mode، Slot و Image را انتخاب میکند.
- Secure Boot و AVB زنجیره اعتماد را میسازند.
- boot/init_boot/vendor_boot نقشهای متفاوت و نسخهوابسته دارند.
- Kernel فقط Linux را شروع میکند؛ init باید Android filesystem و policy را آماده کند.
- Zygote و system_server Android Framework و App world را زنده میکنند.