FVP 환경에서 부팅 까지 동작을 위해 계속 맞춰 나가는것

어느 정도는 try-error처럼 진행될 수밖에 있습니다.

하지만 정확히 말하면 무작정 try-error가 아니라, 단계별 contract를 맞춰가는 FVP board bring-up 작업입니다.

즉 지금 하고 있는 일은:

AOSP 코드를 임의로 고치는 작업

 

이라기보다,

FVP를 Android가 기대하는 “정상 디바이스”처럼 보이게 만들기 위해
kernel / init / APEX / ART / HAL / service / sepolicy / graphics 조건을 하나씩 맞추는 작업

 

현재 위치는 이미 꽤 깊은 곳이다

처음에는 이런 문제를 넘겼습니다.

U-Boot
 ↓
kernel
 ↓
init
 ↓
apexd / linkerconfig
 ↓
zygote
 ↓
system_server fork
 ↓
services.jar 로딩

 

이 단계에서 나온 문제들은 주로:

APEX namespace
linkerconfig
libicu.so visibility
app_process64 native link
ART Runtime 생성
services.jar OAT/VDEX/app image
ScopedSuspendAll("Add image space")

 

같은 런타임/ART 계층 문제였습니다.

그 다음에는:

SystemServer.main()
 ↓
SystemServer.run()
 ↓
System.loadLibrary("android_servers")
 ↓
JNI registration
 ↓
FaceService 등 native registration

 

이 구간으로 넘어왔습니다.

그리고 지금은:

createSystemContext()
 ↓
SystemServiceManager 생성
 ↓
startBootstrapServices()
 ↓
FileIntegrityService

 

근처까지 왔다는 뜻입니다. 즉 이제부터는 system_server service bring-up 본게임입니다.

---

앞으로도 계속 case-by-case로 해야 하나?

답은 초반에는 yes, 하지만 계속 그렇게 하면 안 됩니다.

처음에는 어쩔 수 없이 이렇게 됩니다.

lib missing 발생
→ linkerconfig 확인
→ APEX link 추가

services.jar hang
→ marker 추가
→ app image attach skip

FaceService hang
→ optional JNI registration skip

FileIntegrityService hang
→ fs-verity/keystore/sepolicy 확인

 

하지만 같은 종류의 문제가 반복되면 개별 패치를 멈추고 범주별로 정리해야 합니다.

.so missing 반복
→ APEX/linker namespace 전체 점검

service start 실패 반복
→ VINTF/HAL/service manifest 전체 점검

avc denied 반복
→ sepolicy/file_contexts/service_contexts 전체 점검

display 관련 실패 반복
→ SurfaceFlinger/HWC/gralloc/DRM을 별도 phase로 분리

optional service hang 반복
→ FVP용 minimal product profile 구성

 

즉 목표는 이것입니다.

try-error 패치 모음
  ↓
FVP용 board support patch set