FVP 부팅중 에러 처리 과정

 

 초반에는 case-by-case처럼 보이지만, 계속 그렇게 가면 끝이 없습니다. 핵심은 개별 에러를 “패턴”으로 묶어서 FVP용 보드 포팅 체크리스트로 바꾸는 것입니다.

네. FVP 부팅 초반에는 어느 정도 case-by-case로 해결하는 게 맞습니다.

다만 계속 “에러 하나 → 패치 하나” 방식으로 가면 끝이 없습니다. 초기에는 case-by-case, 중반부터는 category-by-category로 전환해야 합니다.

즉 이렇게 가야 합니다.

나쁜 방식:
libicu.so 없음 → linkerconfig 패치
다음 so 없음 → 또 패치
다음 HAL 없음 → 또 패치
다음 SELinux denial → 또 패치

좋은 방식:
APEX/linker namespace 전체 검증
VINTF/HAL 전체 검증
SELinux 전체 permissive 비교
init service 전체 상태 검증
graphics stack 별도 분리

 

---

1. 왜 초반에는 case-by-case가 unavoidable인가?

FVP는 “완성된 Android 제품 보드”가 아니라 가상 Arm platform을 Android device처럼 보이게 만드는 bring-up 대상입니다.

AOSP에도 fvp_mini-eng 타깃이 있긴 하지만, 문서상 이 타깃은 GUI가 필요 없는 ART test 목적이라고 설명되어 있습니다. 즉 full Android UI 디바이스라기보다 headless/ART 검증용 FVP 이미지에 가깝습니다.

그래서 full framework, system_server, graphics, HAL까지 올리려면 다음이 계속 맞아야 합니다.

kernel
DTB
init.rc
fstab
APEX
linkerconfig
VINTF manifest
HAL service
SELinux
graphics
SurfaceFlinger
PackageManager
ActivityManager

 

하나라도 어긋나면 지금처럼 에러가 나옵니다.

---

2. 하지만 지금 libicu.so 같은 문제는 “한 건”이 아니라 “한 범주”다

이번 에러는 단순히 libicu.so 하나의 문제가 아닙니다.

정확히는 이 범주입니다.

APEX modularization
+ linker namespace
+ generated linkerconfig
+ system library dependency

 

Android의 linker namespace는 프로세스 시작 시 ld.config.txt 기반으로 만들어지고, namespace 간 link는 허용된 shared library만 통과시킵니다. 공식 문서도 ld.config.txt가 dynamic linker에 의해 로드되고 프로그램 시작 시 namespace가 생성된다고 설명합니다.

따라서 이번 문제를 이렇게만 고치면 위험합니다.

libicu.so만 통과시킴

 

더 좋은 방식은 이겁니다.

FVP target의 generated linkerconfig가
APEX namespace link를 정상 생성하는지 전체 점검

 

확인 대상:

 

adb shell grep -n "namespace.default.links" /linkerconfig/ld.config.txt
adb shell grep -n "com_android_i18n" /linkerconfig/ld.config.txt
adb shell grep -n "com_android_art" /linkerconfig/ld.config.txt
adb shell grep -n "com_android_runtime" /linkerconfig/ld.config.txt
adb shell ls /apex
adb shell cat /apex/apex-info-list.xml | grep -E "art|runtime|i18n|tzdata"

 

즉 libicu.so만 보는 게 아니라:

default → com_android_i18n
default → com_android_art
default → com_android_runtime
system → apex namespaces
vendor → vndk/sphal namespaces

 

이 전체가 맞는지 봐야 합니다.

---

3. FVP bring-up은 보통 이런 단계로 정리해야 한다

제가 추천하는 단계는 이겁니다.

0단계: kernel/init까지
1단계: apexd + linkerconfig
2단계: zygote/app_process64
3단계: system_server main
4단계: startBootstrapServices
5단계: startCoreServices
6단계: startOtherServices
7단계: PackageManager/ActivityManager 안정화
8단계: surfaceflinger/headless boot_completed
9단계: graphics/HWC/UI

 

지금은 대략:

1~3단계 경계 또는 3~4단계 초입

 

입니다.

libicu.so not found는 zygote/app_process64 실행 시 native linker가 실패하는 단계라서, 아직 SystemServer 내부 문제라기보다는 runtime/linker/APEX device config 문제입니다.

---

4. case-by-case를 언제 멈춰야 하나?

같은 범주의 에러가 2번 이상 나오면, 개별 패치를 멈추고 범주 검증으로 넘어가야 합니다.

예를 들어:

so missing이 반복된다

libicu.so not found
libandroidicu.so not found
libnativehelper.so not found
libart.so not found

 

이때는 더 이상 개별 so를 하나씩 추가하면 안 됩니다.

봐야 할 것:

APEX mount 상태
linkerconfig 생성 input
namespace.default.links
shared_libs allowlist
system/apex 버전 mismatch

 

---

HAL wait가 반복된다

Waited one second for android.hardware.power.IPower/default
Cannot find android.hardware.graphics.composer
hwservicemanager cannot find entry

 

이때는 개별 HAL을 하나씩 끄는 게 아니라 VINTF를 봐야 합니다.

Android의 Framework Compatibility Matrix는 framework가 device에 요구하는 HAL 조건을 설명하고, 이 요구사항은 device manifest가 만족해야 합니다. 공식 문서도 FCM 요구사항은 build time, runtime, VTS에서 device manifest로 만족되어야 한다고 설명합니다.
또 HAL match rule에서는 manifest와 matrix의 HAL version/interface/instance가 어떻게 매칭되는지 정의합니다.

확인:

 

adb shell lshal
adb shell service list
adb shell dumpsys -l
adb shell cat /vendor/etc/vintf/manifest.xml
adb shell cat /system/etc/vintf/compatibility_matrix.xml

 

---

SELinux denial이 반복된다

avc: denied { read }
avc: denied { find }
avc: denied { call }

 

이때는 개별 allow rule만 계속 추가하지 말고:

permissive에서 부팅 차이 확인
도메인 전환 확인
file_contexts 확인
service_contexts 확인
binder/service_manager 접근 확인

 

으로 봐야 합니다.

---

graphics 문제가 반복된다

surfaceflinger crash
composer HAL missing
gralloc allocation fail
DRM node fail
SMMU stream fault

 

이때는 Android framework 문제가 아니라 별도 graphics bring-up phase로 분리해야 합니다.

headless boot_completed 먼저 달성
그 다음 SurfaceFlinger/HWC/DRM/GPU

 

---

5. 지금 작업 방식은 이렇게 바꾸는 게 좋다

현재처럼 libicu.so가 나오면 바로 고치는 것은 맞습니다.
하지만 고친 뒤에는 반드시 “같은 계층 전체 검사”를 해야 합니다.

이번 케이스라면 다음 순서입니다.

1. libicu.so 에러 수정
2. default → com_android_i18n link만 추가했는지 확인
3. 같은 방식으로 빠질 수 있는 APEX link 전체 확인
4. system image / apex image / linkerconfig 생성 branch 일치 확인
5. app_process64가 어떤 linkerconfig section을 타는지 확인
6. 다음 so missing이 나오면 개별 대응 대신 linkerconfig generator 쪽 수정

 

실제 명령:

 

adb shell grep -n "namespace.default.links" /linkerconfig/ld.config.txt
adb shell grep -n "namespace.default.link.com_android_i18n" /linkerconfig/ld.config.txt
adb shell grep -n "shared_libs" /linkerconfig/ld.config.txt | grep -E "icu|art|runtime|i18n"
adb shell readelf -d /system/lib64/libharfbuzz_ng.so | grep NEEDED
adb shell ls -l /apex/com.android.i18n/lib64