← Docs hub

SKIX 하이브리드 SystemService와 Runtime 구조

결론

SKIX는 얇은 system_server 브리지 + 분리된 system_ext Runtime 구조로 간다.

• SkixFrameworkSystemService는 Android 부팅 단계에 참여하고 전역 root Binder skix_framework를 게시한다.
• Task·Workflow·Policy·State·Evidence와 도메인 ManagerService들은 별도 privileged SkixFrameworkService process에서 실행한다.
• DeviceAgent와 AMR·IoT·LLM·Vision·MCU 등 기존 Agent는 실제 기기 동작을 수행하는 provider로 유지하면서 adapter 뒤로 옮긴다.
• Java framework/runtime을 init.rc의 app_process daemon으로 띄우지 않는다. init은 필요한 native ROS 2·MCU·HAL provider에만 사용한다.

이 결정은 Android의 부팅·Binder·Manager/Service 관념을 사용하면서, 무거운 로보틱스 실행부 장애가 system_server까지 전파되는 것을 막는다.

구현 상태를 먼저 구분

빌드 성공은 canonical 소스를 AAR/APK로 컴파일할 수 있다는 증거다. Android 부팅 등록, SELinux, 실제 Binder caller와 센서·모터 완료를 증명하지는 않는다.

전체 구조와 파일 소유권

그림 1. source owner, process, partition과 provider 경계
파란색은 이번 단계에서 소스 이동과 빌드가 검증된 영역, 청록색은 설계가 확정됐으나 제품 구현이 남은 영역, 주황색은 기존 provider와 실기기 검증 영역이다.
원본 SVG 열기

skix-framework/base/
├── Android.bp
├── core/
│   ├── java/com/sk/airbot/framework/       # 공개 Manager·Task·model
│   └── tests/src/com/sk/airbot/framework/ # 생산 package 미러링
├── services/
│   ├── core/java/com/sk/airbot/frameworkservice/server/
│   │   ├── control/                        # lifecycle·state·policy·resource
│   │   ├── execution/                      # Task·Workflow·Scheduler·Evidence
│   │   ├── domain/                         # AMR·Cleaning·Vision·IoT·LLM 등
│   │   ├── entrypoint/
│   │   ├── integration/
│   │   └── legacy/
│   ├── tests/src/                          # ManagerService test
│   ├── systemserver/                       # 얇은 SystemService 경계
│   └── runtime/                            # isolated Android Service 경계
├── adapters/                               # Agent·ROS 2·MCU·HAL adapter
├── compatibility/                          # legacy forwarding
├── data/etc/                               # permission·overlay·service_contexts
└── api/                                    # 검토된 API signature

apps/AirbotSdkProject/devicecontrolapi와 apps/SkixFrameworkService는 각각 AAR와 APK의 패키징 host로 남는다. 새 framework/server Java source를 다시 소유하지 않고 위 canonical directory를 Gradle source set으로 직접 컴파일한다.

Process와 partition

framework core, SystemService jar, Runtime APK, permission과 overlay는 system_ext가 기본 위치다. 하드웨어 종속 native daemon/HAL은 vendor에 둔다. 두 partition은 stable AIDL/HAL 계약으로 연결하고 Java 구현을 서로 import하지 않는다.

부팅과 lifecycle

그림 2. Android boot phase와 SKIX readiness 전이
root Binder가 보인다는 사실과 물리 명령을 받을 준비가 됐다는 사실을 분리한다.
원본 SVG 열기

1. init이 zygote를 시작하고 zygote가 system_server를 시작한다.
2. 제품 RRO가 config_deviceSpecificSystemServices에 SKIX bridge class를 추가한다.
3. onStart()는 skix_framework를 NOT_READY 상태로 먼저 게시한다.
4. phase 500에서 로컬 권한·연결 상태를 초기화한다.
5. phase 520에서는 discovery·version·health 조회만 제공한다.
6. phase 600에서 explicit component로 system_ext Runtime을 bind하고 의존 순서대로 ManagerService graph를 시작한다.
7. phase 1000에서 저장된 Task/Workflow와 provider 상태를 조정한 뒤 mandatory service gate가 모두 통과하면 명령 admission을 READY로 바꾼다.

각 주요 서비스는 별도 상태를 가진다.

NOT_READY → STARTING → READY → DEGRADED → RECOVERING → READY
                         └────────────────────────────→ STOPPED

전체 Runtime의 READY는 필수 lifecycle dependency로 계산한다. Vision 장애를 숨기고 전체가 READY라고 표시하거나, 선택 service 하나 때문에 무관한 모든 domain을 중단하지 않는다. Cleaning·AirQuality·Power·UI도 같은 Runtime process에 있지만 각각 다른 component ID, 의존 그래프와 상태 모델을 가진다. process 공유를 authority 공유로 해석하지 않는다.

Manager / Binder / ManagerService

앱은 Skix*Manager를 사용하고 Binder 세부사항을 직접 처리하지 않는다.

SkixVisionManager
  → ISkixFrameworkService.getManagerService(VISION)
  → ISkixVisionService
  → VisionManagerService
  → Vision provider adapter
  → VisionAgent

전역 ServiceManager 이름은 skix_framework 하나로 시작한다. root service는 고정된 manager identifier로 versioned typed Binder를 반환한다. 임의 class reflection이나 제한 없는 문자열 service 조회를 API로 만들지 않는다.

권한 검사는 두 겹이다.

• SystemService bridge: caller UID, signature permission, user와 service readiness 검사
• Runtime ManagerService: 동일 caller context를 다시 확인하고 domain policy, lifecycle, capability, resource와 상태 전이 검사

Runtime 장애와 복구

그림 3. runtime death를 system_server 생존과 Task 무결성으로 격리
재연결을 성공으로 간주하지 않고 generation·idempotency·provider reconciliation을 거친다.
원본 SVG 열기

Runtime Binder death가 발생하면 bridge는 다음 순서를 지킨다.

1. root health를 DEGRADED로 변경한다.
2. 상태·version 조회는 유지하고 새 변경 요청은 SERVICE_NOT_READY와 retry hint로 거절한다.
3. connection generation을 증가시켜 이전 process callback이 현재 Task를 완료시키지 못하게 한다.
4. 제한된 exponential backoff로 Runtime을 다시 bind한다.
5. 새 Runtime이 durable Task/Workflow와 provider 실제 상태를 조정한다.
6. mandatory lifecycle gate가 통과해야 READY로 복귀한다.

Binder 재연결만으로 물리 명령을 재전송하지 않는다. 명령별 idempotency key 또는 provider reconciliation 규칙이 있어야 한다. 결과를 알 수 없으면 자동 성공·재시도가 아니라 UNKNOWN_OUTCOME과 evidence gap으로 남겨야 중복 이동·청정·구동을 막을 수 있다.

TaskManager, ROS 2와 Experience 경계

Runtime Framework는 Task/Workflow 상태, 현재 기기·서비스 상태, policy/resource admission, progress, evidence와 안정적인 거절 이유를 제공한다. 구동부는 TaskManager와 goal·feedback·result· cancel 상태를 주고받고, 실제 완료 callback/evidence가 terminal state를 확정한다. 이 관념은 ROS 2 Action과 유사하지만 Android Binder lifecycle·권한·제품 정책을 함께 적용한다.

상위 지능 서비스는 Experience goal 추론, 사용자 질문, 계획 수정과 replanning을 담당한다. 상위 지능 서비스가 아직 실행되지 않은 Workflow step을 교체할 수는 있지만 이미 commit된 Task record를 변조하거나 hard safety, identity, lifecycle, capability와 resource policy를 우회할 수는 없다.

구현 순서

현재 검증 증거

• canonical tree verifier와 기존 layer-boundary verifier contract 통과
• 5 Control + 4 Execution + 15 Product Domain lifecycle ID 독립성과 Cleaning·AirQuality·Power·UI 의존 분리 JVM test 통과
• 15개 Product Domain 모두 별도 concrete *ManagerService lifecycle 골격 생성; 다섯 typed observation adapter 외 실제 producer/명령 기능 이식은 아직 미완료
• devicecontrolapi 전체 unit test와 release AAR build 통과
• SkixFrameworkService 전체 unit test와 release APK build 통과
• Gradle build tools 34 지정은 AGP가 35로 올려 사용하는 기존 warning이 남아 있음
• SystemServer boot, Binder 등록, permission/SELinux와 실기기 동작은 아직 검증하지 않음

연결 문서

• SKIX 리팩터링 프레임워크 설계안
• SKIX 제품 프레임워크 리팩터링 진행 현황
• 서비스 라이프사이클과 도메인 상태 감사
• Task / Execution 리팩터링
• 전체 Manager / ManagerService / Agent 맵