← Docs hub

QCS6490 Platform Vendor Brief

이 문서는 기존 플랫폼 벤더 역할을 이어받아 개발을 수행할 협력업체와 회의할 때 사용할 AOSP/SoC 업무 범위 설명 자료다.

목표는 “A1 현재 코드만 유지보수할 사람”이 아니라, A2 이후 모델에서도 시스템 미들웨어 + 서비스 레이어 + vendor HAL + driver/DTS 포팅 일부까지 이어서 맡을 수 있는 업체인지 판단하는 것이다.

이 문서는 이제 SK-Intellix Framework and SDK Hub의 Platform Enablement 하위 자료로도 읽는다. 즉 플랫폼 벤더 범위는 단순 AOSP 외주가 아니라, A1 DeviceAgent API/runtime과 후보 SDK surface가 실제 보드, HAL, driver, DTS 위에서 동작하게 만드는 platform package다.

위 overview는 Android 공식 문서의 일반 platform architecture와 AOSP architecture overview를 기준으로 App, Framework, Runtime/Native, HAL, Kernel 레이어를 잡고, 그 위에 QCS6490의 QSSI/UM split build와 A1 DeviceAgent/product service hub 위치를 겹쳐 본 그림이다. VINTF/Treble 경계는 framework side와 vendor side가 Binder/AIDL/HIDL/VINTF 계약으로 만나는 지점으로 표시한다.

1. 회의에서 먼저 맞출 결론

2. AOSP 풀 구조와 Platform Vendor 반영 방식

현재 workspace에는 Qualcomm split 구조가 존재한다.

SoC/
  g13qcs6490/
    LA.QSSI.13.0.R1/   # QSSI, system/system_ext 중심
    LA.UM.9.14.1.R1/   # UM/target, vendor/kernel/device 중심
  <qssi-vendor-overlay>/       # QSSI 쪽 platform vendor overlay
  <um-vendor-overlay>/         # UM 쪽 platform vendor overlay

platform vendor overlay는 단순히 폴더가 존재한다고 제품에 반영되지 않는다. QSSI/UM 각각의 AOSP tree 아래 vendor/<platform-vendor>로 배치되어야 product makefile에서 포함된다.

운영 스크립트는 sync_vendor_overlay.sh다. 회의에서 업체에게는 “overlay 수정 -> vendor/<platform-vendor> 반영 -> QSSI/UM 분리 빌드 -> merge/package 검증” 흐름을 기준으로 설명하면 된다.

3. 레이어별 책임 범위

4. DeviceAgent, 서비스 Agent, HAL 실행 흐름

현재 DeviceAgent source는 a1-packages/apps/DeviceAgent에 있고, 제품 이미지에는 QSSI/system 쪽 source package 또는 prebuilt privileged APK 흐름으로 반영될 수 있다. 제품 관점에서는 단순 앱이 아니라 외부 client API, peer agent binding, 상태/정책/event, HAL bridge를 묶는 product-level SystemServer/service hub다.

Client / DeviceControlAPI
  -> DeviceAgent IDeviceControl.sendModuleCommand(Bundle)
  -> MainApi / framework command / TaskManager / domain managers
  -> AMRAgent / IotAgent / UpdateAgent / PairingAgent / VisionAgent
  -> vendor.<platform-vendor>.hardware.device_manager@1.0 or soundflowservice@1.0
  -> vendor HAL service in /vendor/bin/hw
  -> MCU / SoundFlow / sysfs / DTS-backed device nodes

회의에서 확인해야 할 핵심은 업체가 Android app만 보거나 HAL만 보는 것이 아니라, 위 전체 경로를 장애 원인별로 추적할 수 있는지다.

5. 업무 흐름

권장 업무 흐름은 아래 순서다.

6. A1에서 A2/next model로 넘어갈 때의 기대 역할

A2 이후 모델에서 플랫폼 벤더의 역할은 단순히 A1 파일을 다음 보드에 복사하는 것이 아니다. 제품 기능 확장, 기존 미들웨어/서비스 레이어 정리, SK-Intellix framework화, 장기 SDK화까지 이어지는 platform enablement 영역으로 본다.

이 네 영역은 서로 분리된 프로젝트가 아니라 같은 전환 축이다. 신규 기능은 먼저 미들웨어/서비스 레이어에 들어오고, 반복되는 호출/상태/정책 패턴은 SK-Intellix Framework 계약으로 올라가며, 장기적으로는 협력업체와 앱 개발자가 쓰는 SDK surface로 정리된다.

현재 구조에서 특히 중요한 리팩토링 포인트는 DeviceAgent의 역할을 “모든 상태와 자원을 직접 소유하는 중앙 객체”가 아니라 “제품 기능의 service hub이자 command/callback broker”로 재정의하는 것이다. DeviceAgent는 외부 API 진입점, TaskManager, 정책/상태 snapshot, callback fan-out을 담당하되, 기기 상태의 source of truth와 자원 점유 판단은 AMR, IoT, vendor HAL/service, domain manager 등 실제 기기/도메인 owner가 책임지는 구조로 내려야 한다.

따라서 다음 모델로 넘어갈 때는 명령 실행 여부, busy/resource conflict, cancel/rollback, callback 완료 조건을 DeviceAgent 내부 ad-hoc 분기만으로 판단하지 않고, domain owner가 상태와 자원 lock을 보고 reason/event를 반환하는 계약으로 정리해야 한다. 이 정리가 되어야 SK-Intellix Framework화와 장기 SDK화가 단순 wrapper가 아니라 실제로 안정적인 platform API가 된다.

이 구조가 구현되면 DeviceAgent는 제품 레벨의 SystemServer 역할, 즉 service hub와 command/callback broker 역할을 유지한다. 다만 상태 source of truth, 자원 lock, 실행 가능 여부, busy/reason 판단, callback 완료 조건은 AMR/IoT/Vision/Update 같은 domain owner가 판단한다. DeviceAgent는 command를 정규화해 domain owner로 라우팅하고, domain owner가 반환한 reason/event/callback을 표준 envelope로 fan-out한다.

구조적으로는 Android Developers의 Platform Architecture가 설명하는 System Apps -> Java API Framework -> Runtime/Native -> HAL -> Linux Kernel 흐름을 따라간다. SK-Intellix Framework는 Android Java API Framework를 대체하거나 우회하는 계층이 아니라, 그 옆에 붙는 제품 미들웨어 Framework다. 즉 외부 앱/클라우드/음성 진입점에는 DeviceManager와 Task API facade, mobility/cleaning/perception 같은 domain facade를 제공하되, Android 자원은 Activity/Package/Resource/Notification/Connectivity/Media/Camera 등 Java API Framework와 Binder permission/lifecycle 규칙을 통해 사용해야 한다. callback은 독립된 상위 CallbackManager라기보다 EventBus와 task result contract가 담당하는 하위 결과/이벤트 전달 계약으로 보는 편이 자연스럽다.

DeviceAgentService는 Android의 system_server처럼 제품 레벨 서비스 허브 역할을 맡는다. 이 계층은 Binder 진입점, service registry, lifecycle, routing을 담당하되, 모든 실행을 직접 처리하지 않는다. 실행 중심은 TaskManager Core로 두고, goal-to-task decomposition, queue, priority, retry, timeout, cancellation, composite-command orchestration을 담당하게 한다. 그 아래 지원 계층에는 Safety/Policy, Resource, StateMirror, Event, CapabilityRegistry, Dispatcher를 두어 TaskManager가 domain owner로 내려가기 전에 안전성, 자원 충돌, 상태 mirror, 결과 이벤트, capability routing을 확인하게 한다. 단, StateMirror는 domain state의 semantic mirror/cache이지 실제 기기 상태의 source of truth가 아니다.

핵심은 Domain/Capability Manager 계층이다. 장기적으로 AI robotics 관점에서는 A2A/AI planner/voice가 raw command를 직접 HAL로 밀어 넣는 구조가 아니라, goal/command를 TaskManager에 제출하고 TaskManager가 mobility, cleaning, perception, system capability로 분해해 실행하는 구조가 되어야 한다. MobilityManager, CleaningManager, PerceptionManager, SystemManager 같은 domain manager가 실제 기기 상태의 owner가 되고, 각 manager가 canExecute(command, state, resourceLock), execute, cancel, rollback 계약을 가진다. DeviceAgentService와 TaskManager는 이 판단을 대신하지 않고, domain manager의 결과를 표준 reason/event/task-result로 정규화해 상위 API/SDK와 AI planner가 이해할 수 있는 evidence로 올린다.

따라서 리팩토링 산출물은 단순 클래스 분리가 아니라 state/resource ownership matrix, domain canExecute() 계약, reason/event/callback schema, HAL/service validation evidence까지 포함해야 한다. 이 기준이 있어야 다음 모델에서 신규 기능을 추가하더라도 DeviceAgent에 분기가 계속 누적되지 않고, framework/SDK surface로 올릴 수 있는 안정적인 플랫폼 계약이 된다.

7. 현재 확인된 리스크

8. 연결 문서

9. 회의용 한 문장

플랫폼 벤더에게 기대하는 역할은 QCS6490 AOSP/BSP/HAL 경계를 이해한 상태에서 신규 기능 개발, 기존 미들웨어/서비스 레이어 리팩토링, SK-Intellix Framework화, 장기 SDK화까지 이어지는 platform enablement를 책임지는 것이다.