andorid service 실행 단계

10. services.jar / system_server classpath 로딩 단계

system_server가 Java framework service들을 실행하려면 SYSTEMSERVERCLASSPATH에 포함된 jar들을 로딩해야 한다.

대표 jar는 다음과 같다.

/system/framework/services.jar
/system/framework/ethernet-service.jar
/system/framework/wifi-service.jar
/system/framework/com.android.location.provider.jar
...

 

이 단계에서 ART는 각 jar에 대해 다음을 수행한다.

DexFile.openDexFile()
  ↓
DexFile_openDexFileNative()
  ↓
OatFileManager::OpenDexFilesFromOat()
  ↓
OAT/VDEX/DEX 선택
  ↓
app image 존재 시 OpenImageSpace()
  ↓
LoadDexFiles()
  ↓
JIT / NotifyDexFileLoaded

 

현재 로그에서는 com.android.location.provider.jar는 app image가 없어서 LoadDexFiles() 경로로 정상 진행했다. 반면 services.jar는 services.odex 선택 후 OpenImageSpace()에서 non-null app image를 얻은 상태까지 진행한다.

따라서 현재 로그의 실제 진행 위치는 아래와 같다.

U-Boot
  ↓
kernel
  ↓
init first/second stage
  ↓
APEX / linkerconfig
  ↓
zygote
  ↓
system_server fork
  ↓
services.jar OAT/app image 로딩  ← 현재 주요 정체 지점

 

---

11. SystemServer.main() 단계

services.jar 로딩이 완료되면 com.android.server.SystemServer class가 로딩되고 SystemServer.main()이 실행된다.

이 시점부터 Android framework service 초기화가 시작된다.

SystemServer.main()
  ↓
new SystemServer().run()
  ↓
Looper.prepareMainLooper()
  ↓
System.loadLibrary("android_servers")
  ↓
createSystemContext()
  ↓
startBootstrapServices()
  ↓
startCoreServices()
  ↓
startOtherServices()

 

SystemServer.main() 진입은 Android framework로 들어갔다는 매우 중요한 기준점이다. 하지만 아직 부팅 완료는 아니다. 이 단계에서는 단지 framework service들을 시작할 준비가 된 것이다.

---

12. startBootstrapServices 단계

startBootstrapServices()는 system_server 안에서 가장 먼저 필요한 핵심 서비스를 올린다.

대표 서비스는 다음과 같다.

서비스역할

Installer / installd 연결	앱 설치/패키지 dexopt 등에 필요
ActivityTaskManagerService	Activity/task/window 관리의 기반
ActivityManagerService	process/activity lifecycle 관리
PowerManagerService	suspend/wakeup/power 상태 관리
DisplayManagerService	display device 관리
PackageManagerService	APK/framework package scan
UserManagerService	user/profile 관리
SensorService 일부	sensor framework 연동

이 단계의 특징은 Android framework가 실제 device contract를 강하게 요구하기 시작한다는 점이다.

예를 들어 FVP bring-up에서는 다음 문제가 발생하기 쉽다.

PackageManagerService scan 실패
/data 권한 문제
installd 연결 실패
Power HAL 없음
Display HAL 없음
SELinux denial
VINTF/HAL mismatch

 

---

13. startCoreServices 단계

startCoreServices()에서는 system_server의 core service들이 올라간다.

대표적으로 다음 서비스가 포함된다.

BatteryService
UsageStatsService
WebViewUpdateService
CachedDeviceStateService
BinderCallsStatsService
BugreportManagerService

 

이 단계는 device 상태와 framework 정책을 연결하는 구간이다. battery, usage, webview, stats 등 Android 운영에 필요한 core service가 준비된다.

FVP에서는 실제 배터리 장치가 없을 수 있으므로 healthd: No battery devices found 같은 로그가 보일 수 있다. 현재 로그에서도 battery device가 없다는 메시지가 확인된다.

---

14. startOtherServices 단계

startOtherServices()는 가장 많은 서비스가 시작되는 구간이다.

대표적으로 다음이 올라간다.

서비스역할

WindowManagerService	window, display layout, focus, input dispatch 연결
InputManagerService	keyboard/mouse/touch input 처리
NetworkManagement / Connectivity	network stack
AudioService	audio routing/policy
UsbService	USB 관리
LocationManagerService	location provider
TelephonyRegistry	통신 관련 상태
NotificationManagerService	notification
StatusBarManagerService	system UI 연동
DevicePolicyManagerService	device policy
StorageManagerService	volume/storage 관리

이 단계부터는 단순히 Java framework만 맞으면 되는 것이 아니라, HAL, native daemon, SELinux, device feature XML, vendor manifest, graphics stack이 모두 맞아야 한다.

---

15. DisplayManagerService / InputManagerService / DisplayViewport 단계

DisplayViewport는 system_server 이후 display/input 계층에서 만들어진다.

위치는 대략 다음이다.

SystemServer.main()
  ↓
startBootstrapServices()
  ↓
DisplayManagerService 생성
  ↓
InputManagerService 생성
  ↓
Display device scan
  ↓
LogicalDisplay 구성
  ↓
DisplayViewport 계산/갱신
  ↓
InputReaderConfiguration에 viewport 전달
  ↓
TouchInputMapper.mViewport 설정

 

DisplayViewport는 화면을 직접 그리는 구조체라기보다, 물리 display 좌표를 logical display 좌표로 변환하기 위한 input system용 정보다. AOSP 코드 주석도 DisplayViewport가 physical display coordinate를 logical display coordinate로 변환하기 위해 input system에서 사용된다고 설명한다.

Android input routing 문서에서도 viewport mapping은 InputReaderConfiguration에 저장되고, TouchInputMapper.mViewport가 display port에 맞는 viewport로 설정된다고 설명한다.

따라서 display viewport 관련 로그가 보인다면, 부팅 위치는 다음을 의미한다.

services.jar 로딩 완료
SystemServer.main() 진입 완료
DisplayManagerService / InputManagerService 초기화 진행 중

 

즉 현재 services.jar app image attach 정체 지점보다 뒤쪽 단계다.

---

16. SurfaceFlinger / HWC / gralloc / DRM 단계

화면을 실제로 표시하려면 system_server만으로는 부족하다.

Android UI 출력은 다음 체인을 필요로 한다.

Application / SystemUI / Launcher
  ↓
WindowManager
  ↓
SurfaceControl / SurfaceComposerClient
  ↓
SurfaceFlinger
  ↓
Hardware Composer HAL
  ↓
gralloc / mapper
  ↓
DRM/KMS or framebuffer
  ↓
display controller / GPU

 

FVP에서는 이 구간이 특히 어렵다. 이유는 실제 모바일 디스플레이 파이프라인이 아니라 FVP의 가상 display/GPU/DRM/HWC 구성을 Android가 기대하는 형태로 맞춰야 하기 때문이다.

현재 kernel 로그에서는 Komeda display controller가 DRM minor 0으로 초기화되었지만, fbdev generic emulation setup은 ret=-12로 실패했다.

이 메시지는 즉시 zygote/system_server를 막는 blocker는 아니지만, 나중에 SurfaceFlinger/HWC/UI 단계에서 문제가 될 가능성이 있다.

---

17. PackageManager / ActivityManager / Launcher 단계

부팅 후반부에서는 PackageManagerService가 system package와 app package를 scan하고, ActivityManagerService가 persistent process와 launcher start를 준비한다.

일반 흐름은 다음이다.

PackageManagerService package scan 완료
  ↓
ActivityManagerService systemReady()
  ↓
WindowManagerService systemReady()
  ↓
DisplayManagerService systemReady()
  ↓
SystemUI start
  ↓
Launcher resolve
  ↓
Launcher process fork
  ↓
Home Activity 표시

 

이 단계에서 문제가 있으면 다음 증상이 나온다.

launcher not found
PackageManager scan hang
system_server Watchdog
ActivityManager systemReady 미진입
SystemUI crash
SurfaceFlinger 연결 실패

 

---

18. boot_completed 단계

Android에서 부팅 완료의 대표적인 기준은 다음 property다.

 

getprop sys.boot_completed
getprop dev.bootcomplete

 

일반적으로 정상 부팅 완료 시:

sys.boot_completed=1
dev.bootcomplete=1

 

이 된다.

BOOT_COMPLETED broadcast는 framework가 충분히 준비되고 user unlock/boot phase가 진행된 이후 앱들에게 전달된다.

부팅 완료 직전의 일반 흐름은 다음과 같다.

SystemServer boot phases 진행
  ↓
ActivityManagerService.systemReady()
  ↓
PackageManager ready
  ↓
WindowManager ready
  ↓
Display ready
  ↓
SystemUI / Launcher start
  ↓
boot animation 종료
  ↓
sys.boot_completed=1
  ↓
BOOT_COMPLETED broadcast