← Docs hub

SKIX Runtime Composition 구현 현황

이 문서의 작은 기본 구성과 후속 목록은 9월 5일 단계 기록이다. 현재 실제 7개 서비스 구성은 Resource·Capability·Task Runtime을 기준으로 본다.

결론

SKIX Runtime은 도메인별 Android Service를 여러 개 만드는 구조가 아니라, 하나의 격리된 privileged process 안에서 서로 독립된 다수 ManagerService를 생명주기와 의존성 순서에 따라 운영하는 구조로 고정한다. 얇은 system_server bridge는 이후 root Binder 공개와 Runtime 감시만 담당하고, 기존 Agent·ROS 2·MCU·HAL은 물리 실행 provider로 남는다.

2026-09-05 기준 Runtime 구성 기반은 91a5017, 첫 concrete Control owner인 StateManagerService와 Runtime+State 기본 조립은 b77c2c5에 반영됐다. 이후 다섯 typed observation adapter와 독립 Power domain은 b579a36부터 5fbf2e4까지 반영됐다. 이는 전송 계층 없는 Runtime/State seam의 JVM 검증이며 Binder 공개, SystemServer 등록, 제품 makefile·SELinux, 실제 observation producer 연결 또는 실기기 부팅 완료를 의미하지 않는다.

원본 SVG 열기

AOSP 골격을 적용한 방식

프로세스와 책임 경계

System app / Launcher / 상위 지능 서비스 Planner
  -> public Skix*Manager
  -> root ISkixFrameworkService                    [후속]
  -> SkixFrameworkSystemService in system_server  [후속]
  -> isolated SkixFrameworkService process
  -> SkixFrameworkCompositionRoot                 [구현]
  -> FrameworkServiceRegistry                     [구현]
  -> Control / Execution / Product ManagerService
  -> typed provider port                          [후속]
  -> Agent / ROS 2 / MCU / HAL                    [기존 owner 유지]

CleaningManagerService, AirQualityManagerService, PowerManagerService, UiManagerService는 같은 process를 공유해도 각각 별도 component ID, lifecycle, domain state와 정책 책임을 가진다. AMR, IoT, LLM, Vision, MCU, Update, Pairing, EventAsset, System, Diagnostics, Security도 같은 원칙을 따른다.

현재 구현 계약

FrameworkManagedService

• ManagerService의 FrameworkComponent identity를 강제한다.
• onStart, onBootPhase, onStop callback을 제공한다.
• supervisor 참조를 보유한 서비스가 registry와 같은 lifecycle owner인지 등록 전에 검증한다.
• Android, Binder, Agent, 하드웨어 타입을 참조하지 않는다.

FrameworkServiceRegistry

• 등록 누락 dependency와 component 중복을 안정적인 error code로 거부한다.
• 입력 목록 순서가 아니라 Blueprint dependency graph 순서로 시작한다.
• 서비스 callback 중에는 health가 STARTING, 완료 뒤에는 READY가 된다.
• boot phase는 증가 방향으로만 한 번씩 전달하며 callback 재진입을 거부한다.
• 시작 실패 시 실패 서비스를 정리하고 이미 시작된 서비스를 역순 rollback한다.
• 정상 종료도 역순으로 수행하며 registry는 one-shot terminal lifecycle을 갖는다.
• 등록 서비스와 전달 phase 목록은 분리된 immutable snapshot으로 노출한다.

SkixFrameworkCompositionRoot

생산 Runtime에서 ManagerService를 생성·연결할 유일한 진입점이다. createBaseRuntime()는 하나의 ServiceLifecycleSupervisor로 Runtime과 StateManagerService를 명시 조립한다. 일반 생성 경로도 lifecycle affinity가 다르면 lifecycle_mismatch로 등록 전에 원자적으로 거부한다. 아직 Evidence·Policy·Resource·Capability·Task·Workflow와 제품 도메인을 가짜 구현으로 채우지 않으므로, 구성 root 존재와 전체 제품 연결 완료를 혼동하지 않는다.

StateManagerService

• StateKey<T>와 StateRecord<T>로 value·source·관측 시각·freshness를 함께 저장한다.
• READY에서만 publish, current, fresh, snapshot을 허용한다.
• 타입 불일치는 type_mismatch, 동일/과거 관측 시각은 out_of_order로 거부한다.
• stale record는 진단 가능한 최신값으로 보존하되 fresh()에서는 제외한다.
• 물리 상태 owner, 정책 판정자, Task executor가 아니라 읽기 전용 latest projection owner다.

StateManager 구현·이식 경계 상세 · StateManager 원본 SVG

현재 StateManager에 넣을 typed 변환 계층은 IoT Connectivity, AMR StationLocation, LLM Pipeline, AirQuality, Power/Battery 다섯 종류가 구현·JVM 검증됐다. 이것은 adapter 준비 완료이며 DeviceAgent producer가 실제로 이 경로를 호출한다는 뜻은 아니다.

시작 순서

1. Runtime·Health
2. State·Evidence
3. Policy·Resource·Capability
4. Task·Workflow·TaskScheduler
5. AMR·IoT·LLM·Vision·MCU·Update·Pairing·EventAsset
6. Cleaning·AirQuality·Power·UI·System·Diagnostics·Security
7. Agent·ROS 2·MCU·HAL provider reconciliation
8. 외부 호출 준비 완료

이 순서는 lifecycle 순서다. 각 도메인의 MOVING, CLEANING, STREAMING, UPDATING 같은 operation state는 해당 ManagerService가 별도로 소유한다. lifecycle READY와 물리 동작 완료는 서로 다른 증거다.

검증 원장

검증 환경은 ANDROID_HOME과 ANDROID_SDK_ROOT를 /home/silogood/Android/Sdk로 지정한 로컬 JVM/Gradle 환경이다.

후속 구현 순서

1. 구현된 root AIDL과 admission core 사이에 UID·package·user·permission·signature evidence adapter 연결
2. 명시적 Manager Binder registry와 system_server bridge/runtime bind·death 복구 연결
3. MR6 다섯 observation producer에 구현된 typed adapter를 연결하고 State dual-publish 동등성 검증
4. Evidence·Capability·Resource ManagerService의 실제 managed lifecycle 연결
5. Workflow·TaskScheduler와 MR6 TaskManager persistence/compatibility 이식
6. AMR·Cleaning vertical slice에서 command owner를 하나로 고정하고 evidence를 Task에 환류
7. IoT·LLM·Vision 등 나머지 도메인과 provider adapter 연결
8. product makefile, permission XML, SELinux과 동일 서명 APK·AOSP boot·실기기 Gate

Connections

• SKIX 리팩터링 프레임워크 설계안
• SKIX StateManager 읽기 전용 투영 구현
• SKIX Root Binder Admission Core
• SKIX 제품 프레임워크 리팩터링 진행 현황
• SKIX 하이브리드 SystemService와 Runtime 구조
• 서비스 라이프사이클과 도메인 상태 감사
• 전체 Manager / ManagerService / Agent 맵