Android가 SKIX를 시작하고 복구하는 구조
- 이 그림이 답하는 질문: Android 부팅 때 누가 SKIX를 시작하고, Runtime 장애가 나면 어떻게 다시 연결하는가?
- 읽는 순서: 위쪽 1번 부팅부터 5번 Manager 공개까지 읽고, 아래의 6번 장애 감시·재연결 화살표를 따라간다.
- 현재 검증 범위: lifecycle 골격과 JVM 계약 기준이다. 실제 product 등록·권한·SELinux·실기기 자동 복구는 미검증이다.
전체 시퀀스
init -> zygote -> system_server -> SkixFrameworkSystemService -> publish(root Binder) -> bind(system_ext Runtime)다.
SystemServer bridge는 Android 신뢰 경계만 소유하고 무거운 로보틱스 실행은 Runtime에 둔다.
부팅 시 목표 동작은 onStart()의 시스템 서비스 등록과 Binder publish, phase 500의 Runtime bind, phase 600의 client
admission 개방이다. Runtime Binder death가 발생하면 generation을 올리고 재bind하며, 재조립 전
요청은 fail-closed로 거부한다. 현재 Root AIDL/admission/caller resolver/Stub은 구현·compile 검증됐지만
permission/signature policy, SystemService publish와 death 연결은 미구현이다.
파티션
| 위치 | 책임 |
|---|---|
system_server |
UID/package/permission/signature, publish, supervision |
system_ext |
ManagerService lifecycle, State/Task/Policy/Evidence |
| app/legacy | typed client와 DeviceAgent compatibility |
vendor |
Agent/ROS 2/native/HAL/MCU 실행 |
근거: ISkixFrameworkService.aidl, FrameworkAdmissionController.java,
FrameworkServiceRegistry.java, SkixFrameworkCompositionRoot.java, AOSP SystemService.java.