← Docs hub

TaskManager 사양 5 · 외부 연동과 기존 시스템 호환

AAR, IoT/MQTT, 선택적 Planner와 기존 direct 실행 경로의 점진 전환 방식을 정의한다.

이 장의 결론: 기존 채널과 응답 계약은 유지하고, 관리가 필요한 요청만 명시적으로 Task 또는 Workflow 경로에 올린다.

18. TaskManagerClient AAR

TaskManager Core는 호출 채널에 종속되지 않는다. 시스템 앱은 typed AAR, IoT는 MQTT, Cloud·On-device bridge는 Bundle/JSON 변환을 사용하지만, 최종 요청은 같은 submitTask 또는 submitWorkflow 계약으로 수렴해야 한다.

AAR은 시스템 앱이 문자열과 Bundle을 직접 조립하지 않도록 제공하는 product-level facade다. 다음 원칙을 지킨다.

• TaskSubmitRequest와 TaskWorkflowRequest builder가 필수 필드를 검증한다.
• TaskManagerClientCallback.onTaskEvent가 공통 event envelope를 전달한다.
• AAR은 TaskManager runtime을 포함하지 않고 DeviceAgent Binder 경계만 감싼다.
• 필드, 기본값과 callback 의미는 Core 계약과 동일해야 한다.

typed API, builder 예시와 배포 산출물은 TaskManagerClient AAR API Specification을 기준으로 한다.

19. IoT/MQTT와 Task Monitor 계약

IoT 요청은 transport metadata와 Task metadata를 분리한다. deviceId, topic, command ack는 MQTT 계층이 소유하고, requestId, traceId, taskMethod, queue, policy와 payload는 Task 계약으로 전달한다.

• 모의 실행과 실제 dispatch를 UI에서 구분한다.
• HTTP·MQTT 인증을 우회하는 payload 필드를 허용하지 않는다.
• 명령 ack와 물리 완료 event를 같은 상태로 취급하지 않는다.
• source가 달라도 validator, admission, executor와 completion gate를 우회하지 않는다.

전체 payload와 운영 속성은 MQTT Task Contract을 기준으로 한다.

20. 선택 연동: Cloud Planner와 A2A

20.0 선택적 상위 연동의 경계

기본 경로에는 Planner가 필요하지 않다. 앱·PUI·IoT·예약과 사전 정의 Workflow는 상위 의미 추론 없이 같은 Core를 사용한다. Planner가 연결되더라도 실행 허용, 자원 정책, 물리 완료 증거와 최종 상태 판정은 DeviceAgent TaskManager와 각 기기 도메인이 소유한다. 상위 Planner가 없어도 기기 내부에서 안전한 생명주기를 유지한다.

상위 Planner는 목표를 해석하고 capability와 단계 의존성을 구성한다. DeviceAgent는 계획을 다시 해석하지 않고 실행 가능성, 현재 상태, 안전 정책과 실제 완료 증거를 판정한다.

goal or product scenario
-> structured task/workflow
-> DeviceAgent admission and execution
-> progress/terminal evidence
-> continue locally or request bounded replanning

정상 진행마다 Planner를 호출하지 않는다. BLOCKED, FAILED, TIMEOUT 또는 명시적 사용자 변경처럼 상위 판단이 필요한 terminal event만 재계획 후보가 된다. requestId, traceId, cloudWorkflowId, cloudStepId는 왕복 동안 보존한다.

Cloud·On-device·DeviceAgent 폐루프와 callback 계약은 Voice TaskManager Closed Loop, 기기 상태 입력은 Device Context Planning Spec을 기준으로 한다.

제5부 · 운영·보안·검증 — 21~28장은 관측성, 영속성, 보안, 실패 UX, 시험, 변경과 참조 규격을 정리한다.

30. 기존 시스템 호환성과 점진적 전환 사양

TaskManager 도입은 기존 DeviceAgent 기능을 다른 구현으로 교체하는 작업이 아니다. 기존 PUI, IoT, 시스템 앱, Schedule과 Voice/LLM 호출이 사용하던 MainApi와 기기 도메인 구현을 유지하고, 관리가 필요한 요청만 TaskManager 생명주기에 편입하는 점진적 확장이다.

구조도의 두 실행 경로는 모두 같은 기존 기기 도메인에 도달한다. 차이는 기존 호출이 MainApi.executeMethod()와 executeMethodInternal()을 유지하는 반면, 관리 호출은 명시적 Task API 또는 forceTaskManager=true를 통해 실행 허용, 대기열과 생명주기 관리를 먼저 거친다는 점이다.

두 경로는 마지막에 같은 Movement, Cleaning, Schedule, Security, LLM/TTS와 Update 구현으로 합류한다. TaskManager는 기존 기능 로직을 복제하지 않고 실행 순서, 상태, 완료 증거와 취소 관리를 덧붙인다.

30.1 호환성 목표와 비목표

요약: 기존 기능을 유지하면서 필요한 경로부터 TaskManager 관리 대상으로 전환한다.

호환성은 “컴파일된다”가 아니라 다음 네 수준으로 판정한다.

1. 호출 호환성: 기존 메서드와 필드를 계속 보낼 수 있다.
2. 동작 호환성: 같은 기기 도메인이 같은 물리 동작과 안전 정책을 수행한다.
3. 관찰 호환성: 기존 콜백과 UI·IoT 상태 갱신이 유지된다.
4. 운영 호환성: 배포, 재부팅 복원, 모니터링과 원복이 가능하다.

30.2 이중 실행 경로

요약: 기존 요청은 종전 경로로, 관리 대상 요청은 TaskManager 경로로 보내며 실제 기능은 같은 기기 도메인이 수행한다.

MainApi.executeMethod()의 호환 분기는 다음 순서를 따른다.

구조도의 분기 순서는 명시적 제어 API, forceTaskManager=true인 기존 메서드, 그 밖의 기존 메서드 순이다. 각 요청은 각각 TaskManager.handleControlMethod(), TaskManager.executeLegacy(), executeMethodInternal()로 전달된다.

소스 표현 빠른 해석

소스 심볼은 현재 구현 위치를 설명하기 위한 근거다. 외부 호출자가 의존해야 하는 공개 계약은 제어 API, AAR 스키마와 콜백 계약이다. 내부 클래스 이름은 리팩터링 과정에서 바뀔 수 있다.

30.2.1 외부 MainApi 기존 경로

• forceTaskManager가 없으면 기존 executeMethodInternal()을 그대로 사용한다.
• 기존 호출자의 즉시 반환, 오류 전달과 콜백 계약은 TaskManager 대기열 때문에 바뀌지 않는다.
• TaskManager 전체 활성화 상태와 무관하게 기존 원시 경로는 유지한다.

30.2.2 외부 MainApi 관리 경로

• 명시적 submitTask/submitWorkflow 또는 forceTaskManager=true 요청만 관리 경로로 들어간다.
• TaskPolicy가 DIRECT이면 기존 함수를 직접 호출하되 Task 결과를 기록한다.
• ASYNC와 QUEUED_WAIT이면 TaskRecord와 대기열을 만들고 기존 도메인 실행기를 호출한다.
• 실행기가 다시 MainApi를 사용할 때 runningManagedTask 재진입 보호 장치가 대기열 중복 등록을 막는다.

30.2.3 내부 AppCmd 모듈 경로

DeviceAgent 내부 AppCmd에는 외부 MainApi와 다른 호환 분기가 있다.

이 경로에서는 persist.sys.deviceagent.taskmanager.legacy_queue 기본값이 true이므로 조건을 만족하는 내부 명령이 자동으로 대기열에 들어갈 수 있다. 반면 외부 MainApi 원시 호출은 이 속성만으로 관리 경로에 들어가지 않으며 forceTaskManager=true가 필요하다.

30.2.4 TaskManagerClient AAR 경로

AAR은 모든 기존 호출을 자동 변환하는 프록시가 아니다. 타입 기반 요청 생성기는 관리 계약을 만들고, sendRaw()는 점진적 전환 중 아직 타입 기반 API가 없는 기존 계약을 보존한다.

forceTaskManager는 단순 로그 표시가 아니다. 요청을 Task 생명주기에 편입하고 반환 시점과 결과 구조를 바꿀 수 있는 호환성 경계 플래그다.

30.2.5 IoT·App·LLM Agent의 채널별 적용 방식

결론: MQTT 연결과 기존 명령을 일괄 교체하지 않는다. 기존 단일 명령은 그대로 두고, Task 생명주기가 필요한 요청만 선택적 관리 계약으로 확장한다.

TaskManager 도입으로 바뀌는 범위는 MQTT broker, topic, 인증, QoS와 재연결 같은 전송 계층 전체가 아니다. 바뀌는 부분은 명령 payload가 직접 실행인지 관리 대상 Task·Workflow인지 표현하는 응용 계약과, 관리 요청의 진행·완료를 돌려주는 결과 계약이다.

MQTT를 전부 바꾸지 않는 이유

MQTT의 기존 기능 payload는 이미 DeviceAgent 도메인 입력과 연결되어 있다. 이를 새 스키마로 일괄 치환하면 Topic parser, 응답 앱, 서버와 구버전 기기의 동시 배포 문제가 커진다. 현재 IotTaskManagerBridge는 다음 방식으로 호환성을 유지한다.

request.task 없음
  -> 기존 parser가 만든 method와 payload 유지
  -> 기존 MainApi 직접 실행

request.task 있음, managed 생략 또는 true
  -> 기존 method를 taskMethod로 보존
  -> method=submitTask, source=iot로 감쌈
  -> payload는 그대로 두고 Task metadata만 추가

request.task.managed=false
  -> 기존 직접 실행 유지

따라서 기존 MQTT 명령은 수정하지 않아도 계속 동작한다. TaskManager가 필요한 명령만 아래처럼 task 객체를 추가한다.

{
  "correlationId": "move-bedroom-001",
  "request": {
    "method": "setMoveTo",
    "payload": {
      "positionId": "5"
    },
    "task": {
      "managed": true,
      "executionMode": "async",
      "completionTarget": "movement.arrived"
    }
  }
}

priority, queueKey, timeoutMs, preemptPolicy까지 모든 값을 외부가 채울 필요는 없다. 생략된 값은 TaskPolicyRegistry의 메서드별 기본 정책으로 보강한다. 외부 입력값은 호출자 정책과 허용 범위로 다시 검증하며, 특히 EMERGENCY, 전체 대기열 교체와 임의 취소·보상 메서드는 그대로 신뢰하지 않는다.

복합 Workflow는 별도 계약으로 추가한다

여러 단계를 기존 단일 명령 Topic에 억지로 분산하면 서버 또는 App이 각 단계의 완료를 추측하고 다음 명령을 보내야 한다. 이 경우 TaskManager의 순서·취소·실패 전파 이점을 잃는다. 복합 실행은 하나의 submitWorkflow 요청으로 제출한다.

{
  "correlationId": "clean-return-001",
  "request": {
    "method": "submitWorkflow",
    "payload": {
      "workflowName": "bedroom_clean_return",
      "subTasks": [
        {"taskMethod": "setMoveTo", "positionId": "5"},
        {"taskMethod": "setAirCleanerOperation", "action": "1", "mode": "1"},
        {"taskMethod": "returnToStation"}
      ]
    }
  }
}

이 형식은 기존 모든 MQTT Topic을 변경한다는 뜻이 아니다. submitWorkflow를 처리하는 공통 command parser 또는 전용 관리 Topic 하나를 추가하고, 기존 단일 명령 Topic은 유지하는 방식이 안전하다. 현재 MR6의 IotTaskManagerBridge는 단일 명령의 request.task 변환까지 구현되어 있으며, payload.subTasks[]를 ArrayList<Bundle>로 만드는 MQTT Workflow parser는 아직 구현 완료로 보면 안 된다.

응답과 이벤트의 호환 원칙

기존 callback을 즉시 제거하면 구버전 App과 IoT 서버가 상태를 잃는다. 전환 기간에는 기존 callback과 Task event를 함께 발행하되, requestId, traceId, correlationId로 같은 실행을 묶고 수신자는 중복 반영하지 않아야 한다.

채널 전환 순서

1. 기존 MQTT·App 명령과 응답을 기준선으로 고정한다.
2. 취소·진행률·물리 완료 추적이 필요한 메서드 하나를 선택한다.
3. IoT는 request.task, System App은 AAR, LLM은 구조화된 device request로 같은 Task 의미를 만든다.
4. 기존 callback과 Task event가 같은 물리 실행을 가리키는지 확인한다.
5. 단일 Task가 안정화된 뒤 공통 submitWorkflow ingress를 추가한다.
6. 호출자×메서드 단위로 확대하며 기존 direct 경로는 원복 수단으로 유지한다.

이 구조에서 호출 채널은 서로 달라도 TaskManager가 받는 최종 계약은 동일하다. 반대로 센서 update, heartbeat, 조회 결과와 단순 상태 동기화는 실행 생명주기가 아니므로 기존 메시지 경로에 남긴다.

30.2.6 기존 direct 명령과 관리 Task의 동시성

현재는 관리 Task끼리의 순서는 TaskManager가 통제하지만, 비관리 direct 명령은 대기열 밖에서 실행된다. 두 경로는 기존 DeviceAgent 도메인 정책에서 다시 만나므로 물리 안전 제한은 공유하지만, 실행 순서와 Task 상태까지 자동으로 정합되는 것은 아니다.

현재 구현에서 보장되는 범위

예를 들어 관리 Task가 이동 중일 때 기존 App이 direct setMoveTo를 보내면, 후속 명령은 기존 CmdPolicyManager.setMoveTo()의 is_moving 검사에서 거절될 수 있다. 이는 물리적으로 두 이동을 동시에 실행하지 않게 하지만, 거절된 direct 요청을 TaskManager가 대기시키거나 원래 이동 Task의 선점 사유로 기록한 것은 아니다.

반대로 PUI 정지나 복귀가 기존 경로에서 현재 동작을 중단할 수 있다. 해당 도메인의 중단 callback이 TaskCompletionStateStore와 연결된 기능은 관리 Task가 취소·실패로 닫힐 수 있지만, 모든 도메인에서 원인과 Task ID가 연결된다고 가정하면 안 된다. 연결이 없는 기능은 관리 Task가 물리 중단을 모르고 시간 초과까지 남을 수 있다.

호환성을 유지하는 공통 동시성 경계

기존 direct 호출을 모두 공개 단일 Task로 바꾸지 않고도 동시성을 맞추려면, TaskManager와 기존 경로 아래에 공통 실행권 조정 경계가 필요하다.

기존 direct 요청 ─┐
                  ├─ 실행 분류 ─ 공통 도메인 실행권/자원 점유 ─ 기존 DeviceAgent 정책 ─ 실제 동작
관리 Task 요청 ───┘                   │
                                      └─ 시작·중단·완료 증거를 원 요청에 귀속

이 경계는 자연어 의미를 추론하는 규칙이 아니다. TaskPolicyRegistry, 기능 계약과 requiredResources에 선언된 실행 특성을 사용해 결정적으로 동작한다.

장기 direct 동작의 실행권을 물리 완료까지 유지하려면 결국 시작·중단·완료 callback과 연결된 내부 기록이 필요하다. 따라서 이동·청정 같은 메서드는 검증이 끝난 순서대로 외부 응답 형식은 유지하면서 내부적으로 단일 Task로 승격하는 편이 단순한 잠금보다 안정적이다. 반면 조회와 상태 update까지 Task로 승격하면 대기열과 이벤트만 오염되므로 그대로 direct로 둔다.

충돌 결과의 일관된 귀속

동시성 조정 결과는 물리 동작과 관리 상태가 함께 바뀌어야 한다.

단순히 CmdPolicyManager가 POLICY_NOT_ALLOWED를 반환하는 것으로 끝내면 호출자는 “왜 안 됐는지”, TaskManager는 “기존 작업이 계속 유효한지”를 알 수 없다. 도메인 정책 결과를 errorCode, reason, 점유 자원과 관련 taskId로 연결해야 동시성 호환이 완성된다.

단계적 적용

1. 기존·관리 경로의 동시 실행 조합을 로그로만 관찰한다.
2. 이동·청정·보안·화면/카메라 세션의 자원 소유권과 사용자 취소 결과를 표준화한다.
3. 충돌 가능 direct 명령에 공통 실행권 검사를 적용하되 기존 응답 형식은 유지한다.
4. 검증된 장기 메서드만 내부 단일 Task 승격 대상으로 확대한다.
5. PUI·오류·저전력 선점이 기존 관리 Task를 올바른 terminal 상태로 닫는지 실기기에서 검증한다.
6. 호출자×메서드 단위 회귀가 끝날 때까지 기존 direct 원복 경로를 유지한다.

30.3 호환성 표면

요약: API 이름뿐 아니라 입력값, 응답 시점, 콜백, 저장소, SDK와 배포 방식도 호환성 검토 대상이다.

30.4 그대로 보존해야 하는 동작

요약: TaskManager를 사용해도 실제 기능 주체, 안전 정책, 기존 콜백과 제품 스케줄의 의미는 유지해야 한다.

다음은 TaskManager 도입 전후에 바뀌면 안 되는 호환 불변 조건이다.

1. 같은 요청은 Movement, Cleaning, Schedule, Security 등 기존 수행 주체가 처리한다.
2. 기존 PUI, IoT와 시스템 앱의 원시 메서드는 선택 적용 전까지 기존 경로를 사용한다.
3. 기존 기기 도메인 콜백과 상태 갱신은 계속 발행된다.
4. LLM, 배터리, AMR, 개인정보 보호, 오류와 주 상태 제한은 기존 기기 도메인이 최종 판정한다.
5. 같은 기기 동작이 기존 경로와 관리 경로에서 중복 실행되지 않는다.
6. TaskManager가 비활성화돼도 기존 핵심 기능은 원시 경로로 수행할 수 있어야 한다.
7. 기존 제품 스케줄의 등록, 조회, 실행 의미와 DB 소유권은 유지한다.
8. 시스템 앱 패키지, UID, 서명 권한과 플랫폼 인증서 관계를 유지한다.

30.5 선택 적용 후 달라질 수 있는 동작

요약: 같은 기능도 TaskManager를 거치면 “접수”와 “실제 완료”의 응답 시점과 결과 형식이 달라질 수 있다.

TaskManager 경로는 실행 기능은 같지만 호출 의미까지 완전히 투명하지는 않다.

같은 이동 명령의 호출 차이

아래 예시는 반환 의미를 설명하기 위한 개념 예시다. 실제 필드는 호출자 계약과 출시 스키마를 따른다.

기존 호출

{
  "method": "setMoveTo",
  "positionId": "5",
  "positionName": "안방"
}

기존 이동 경로는 MainApi가 이동 도메인에 명령을 전달하고 기존 메서드 결과를 반환한 뒤, 기존 이동 콜백으로 도착 상태를 알리는 계약을 그대로 유지한다.

TaskManager 선택 호출

{
  "method": "submitTask",
  "forceTaskManager": true,
  "taskMethod": "setMoveTo",
  "source": "APP",
  "requestId": "move-bedroom-001",
  "positionId": "5",
  "positionName": "안방",
  "executionMode": "async",
  "completionTarget": "movement.arrived"
}

{
  "accepted": true,
  "taskId": "task-...",
  "taskState": "PENDING",
  "message": "작업이 접수됨"
}

이 응답의 accepted=true는 안방 도착을 뜻하지 않는다. 이동 콜백이 movement.arrived 증거로 연결되고 Task가 COMPLETED가 돼야 실제 완료다. 기존 호출자는 종전 콜백을 계속 받을 수 있고, 관리 경로 호출자는 Task 이벤트 또는 getTaskStatus를 추가로 사용할 수 있다.

따라서 호출자별 전환 전에 다음을 명시한다.

• 기존 호출자가 접수 응답을 기다리는지 실제 완료를 기다리는지
• 동기 호출 시간 제한과 UI 스레드 사용 여부
• 기존 outdata에서 반드시 읽는 키
• 콜백을 별도로 기다리는지
• 중복 재시도가 기기 동작을 다시 일으킬 가능성

30.6 메서드·필드 별칭 계약

요약: 메서드·필드 별칭은 등록된 항목에만 적용되며 모든 과거 입력을 자동으로 호환하지 않는다.

별칭 처리는 기존 요청 데이터를 모두 자동 수용하는 범용 기능이 아니다. TaskMethodAliasResolver, TaskFields와 실행기 어댑터에 등록된 범위만 계약이다.

현재 대표 호환 범위:

• 청정 시작·중지·일시정지·재개와 복귀 별칭을 표준 청정 메서드로 정규화한다.
• schedule 식별자는 scheduleId, scheduleid, schedule_id를 일부 경로에서 수용한다.
• 활성·대기열 필드는 isActive/is_active, taskQueue/queue를 일부 어댑터가 수용한다.
• 결과에는 Task, 실패 사유와 Cloud 상관관계의 camelCase·snake_case 별칭을 함께 기록하는 경로가 있다.

현재 알려진 정합 공백:

• TaskManagerClient 요청 생성기는 queue를 쓰는 반면 정책 변경값은 queueKey를 읽는 경로가 있다.
• setMoveTo의 엄격 검증 허용 키와 실행기가 읽는 areaId, targetRoom, roomName 범위가 완전히 같지 않다.
• 모든 기존 Bundle 키가 표준 스키마 별칭으로 등록된 것은 아니다.

따라서 엄격한 입력 검증을 기본 활성화하기 전에 메서드별 호출 필드 계약 확인과 기준 요청 회귀 시험을 수행해야 한다. 현재 기본값을 false로 유지하는 것은 기존의 유연한 요청이 갑자기 거절되는 상황을 막기 위한 호환 장치다.

30.7 콜백과 이벤트 호환

요약: 기존 콜백은 유지하고 TaskManager 이벤트로 진행률과 완료 상태를 추가한다.

관리 대상 Task는 기존 콜백을 대체하지 않고 완료 증거로 사용한다.

기존 PUI·IoT·시스템 콜백은 유지한다. 관리 대상 Task와 연결된 콜백만 CompletionBridge가 TaskCompletionStateStore와 Task 진행·최종 이벤트로 변환한다.

Task 이벤트 전달 범위

TaskManager 내부 이벤트와 시스템 앱이 받는 모듈 콜백의 범위는 같지 않다.

TaskManagerClientCallback.onTaskEvent()는 DeviceControlProxy의 모듈 콜백을 받는다. 따라서 내부 수신자가 본 모든 이벤트가 AAR 클라이언트에도 전달된다고 가정하면 안 된다. 호출자별 관찰 요구에 따라 모듈 콜백, getTaskStatus, 모니터 이벤트 중 어느 경로를 사용할지 계약해야 한다.

호환 규칙:

1. 기존 콜백 수신자를 유지한 상태에서 Task 이벤트를 추가 발행한다.
2. 콜백의 기능 의미를 TaskManager에서 다시 추정하지 않는다.
3. Task 이벤트에는 taskId, Workflow·단계 상관관계와 최신 시각을 추가한다.
4. 같은 콜백이 재전송돼도 최종 이벤트는 멱등하게 처리한다.
5. Task Monitor가 콜백을 받지 못해도 기존 기능 상태를 덮어쓰지 않는다.
6. 기존 콜백 제거는 모든 수신자의 전환과 원복 검증 이후 별도 출시에서 수행한다.

30.8 제품 스케줄과 저장소 호환

요약: 반복 제품 일정과 “30분 뒤 한 번 실행”하는 Task 예약은 서로 다른 기능과 저장소로 유지한다.

제품 반복 스케줄과 TaskManager 지연 실행은 저장 주체와 의미가 다르다.

기존 스케줄 기록을 TaskManager 기록으로 묵시 변환하거나, 제품 반복 일정을 단발 Task로 재해석하면 안 된다. 상위 Planner가 제품 스케줄을 만들더라도 기존 Schedule 도메인 메서드를 관리 대상 Task로 호출하며, 스케줄 데이터의 소유권은 그대로 유지한다.

30.9 AAR, Binder와 시스템 앱 호환

요약: 기존 앱은 종전 호출을 유지할 수 있고 신규 앱은 AAR을 사용할 수 있지만, 기기 서명과 권한 조건은 동일하게 적용된다.

TaskManagerClient AAR은 기존 DeviceAgent 기능을 다른 프로세스로 옮기는 SDK가 아니다. 기존 AIDL·Binder 경계 위에 타입 기반 Task API를 제공하는 진입점이다.

• 기존 앱은 원시 Bundle 호출을 유지할 수 있다.
• 신규 앱은 타입 기반 요청 생성기로 Task·Workflow·예약·제어 API를 사용할 수 있다.
• sendRaw(Bundle)는 아직 타입 기반 API가 없는 메서드의 점진 전환 경로다.
• AAR 계약 버전과 지원 메서드 목록은 DeviceAgent 출시 형상과 함께 관리한다.
• 클라이언트 AAR과 DeviceAgent APK의 갱신 순서가 달라도 지원하지 않는 계약은 명시적으로 거절해야 한다.
• 플랫폼 서명 특권 앱의 패키지, UID와 서명 권한 조건은 TaskManager 도입으로 완화되지 않는다.
• 실기기 교체 시 apksigner verify --print-certs로 기존 APK와 신규 APK 인증서를 비교하고, 디버그 인증서 APK를 /system/priv-app에 배포하지 않는다.

30.10 단계적 전환

요약: 전체 기능을 한 번에 바꾸지 않고 호출자와 기능 단위로 전환하고 검증한 뒤 확대한다.

일괄 전환보다 호출자 x 메서드 x 실행 방식 단위 허용 목록이 안전하다. 예를 들어 Cloud Workflow의 setMoveTo만 먼저 관리 경로로 전환하고 PUI 단일 이동은 기존 경로를 유지할 수 있다.

30.11 원복 사양

요약: 문제가 생기면 전체 APK를 되돌리기 전에 해당 호출이나 관리 기능만 기존 경로로 원복할 수 있어야 한다.

현재 TaskManager.isEnabled()는 forceTaskManager=true이면 활성화 속성보다 강제 실행을 우선한다. TaskSubmitRequest와 TaskWorkflowRequest도 강제 실행 플래그를 자동으로 추가한다. 따라서 persist.sys.deviceagent.taskmanager.enable=false는 모든 요청을 차단하는 전역 중지 스위치가 아니다.

강제 요청까지 즉시 차단해야 한다면 신뢰된 호출자별 기능 플래그나 DeviceAgent의 별도 긴급 실행 차단 장치가 필요하다.

원복은 설정만 바꾸는 절차로 끝나지 않는다. 실행 중인 대기열과 Task의 취소 또는 종료 대기, 콜백 이중 발행 정리, 예약 영속성 처리와 재부팅 후 상태 정합까지 정의해야 한다.

30.12 호환성 인수 기준표

요약: 빌드뿐 아니라 기존 호출, 실기기 동작, 콜백, 재부팅과 원복의 전후 결과를 비교해야 호환 완료로 본다.

각 전환 메서드는 다음 항목을 기존 경로와 관리 경로에서 대조한다.

최소 회귀 세트는 PUI, IoT/MQTT, Launcher·시스템 앱, 제품 Schedule과 Voice/LLM을 모두 포함해야 한다. JVM 시험이나 APK 빌드 통과만으로 기존 시스템 호환을 확정하지 않는다.

30.13 현재 남은 호환성 위험

요약: 기본 이중 경로는 마련됐지만 필드 이름, 응답 해석, 이벤트 중복, 버전 조합과 실기기 원복 검증은 아직 완료되지 않았다.

30.14 소스 근거와 검증 상태

이 표에서 “자동 검증 존재”는 해당 분기 일부를 시험했다는 뜻이다. 실제 Binder 호출자, 스레드 실행 시점, 플랫폼 권한과 물리 기기 동작까지 동일하다는 의미는 아니다. L3 이상의 적합성은 실기기 증거로 별도 판정한다.