skills/android-to-harmonyos-migration-workflow/SKILL.md
多 agent 协作的 Android 到 HarmonyOS 代码迁移工作流(迭代式)。当用户需要将 Android 项目迁移到 HarmonyOS 时触发,提供:1) Analyzer Agent 扫描代码结构 2) Planner Agent 制定迁移计划 3) Translator Agent 执行代码转换 4) **Validator Agent(验证代理)** 使用 **ohos-app-build-debug** skill 进行编译验证、应用打包和上板验证首界面 5) Tester Agent 验证功能(每个模块迁移完成后执行) 6) 所有模块迁移完成后,执行 Feature Comparator Agent 检查遗漏功能 7) UI Comparator Agent 验证界面一致性 8) 将未完成部分反馈给 Planner Agent 继续迭代。包含代码分析脚本、API映射表、组件转换模式和自动化验证工具。触发关键词:迁移Android到鸿蒙、Android迁移、HarmonyOS迁移、Java/Kotlin转ArkTS、Activity转Page、功能比对、UI比对。
npx skillsauth add openharmonyinsight/openharmony-skills android-to-harmonyos-migration-workflowInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
本技能提供系统化的 Android 到 HarmonyOS 代码迁移流程,使用 7 个专业 agent协作完成迁移任务。
用户提供源码和目标路径后,启动 Analyzer Agent
Planner Agent 制定初始迁移计划
模块迁移循环(逐个模块执行):
重复步骤 3,直到所有计划模块完成迁移
全局比对阶段(所有模块完成后):
┌─────────────────────────────────────────────────────────────────┐
│ Android 到 HarmonyOS 迁移工作流(迭代式) │
└─────────────────────────────────────────────────────────────────┘
┌──────────┐
│ Analyzer │ 扫描源码,生成结构报告
│ Agent │
└────┬─────┘
│
▼
┌──────────┐
│ Planner │ 制定初始迁移计划(模块清单、优先级)
│ Agent │
└────┬─────┘
│
▼
╔═══════════════════════════════════════════════════════════════╗
║ 模块迁移循环 ║
╠═══════════════════════════════════════════════════════════════╣
║ ║
║ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ║
║ │ Translator │───▶│ Validator │───▶│ Tester │ ║
║ │ Agent │ │ Agent │ │ Agent │ ║
║ │ 代码转换 │ │ 质量验证 │ │ 功能测试 │ ║
║ └──────────────┘ └──────────────┘ └──────┬───────┘ ║
║ │ ║
║ ▼ ║
║ ┌──────────────┐ ║
║ │ 模块完成 │ ║
║ │ 标记状态 │ ║
║ └──────┬───────┘ ║
║ │ ║
║ ┌────────┴────────┐ ║
║ │ │ ║
║ ▼ ▼ ║
║ 有更多模块? 所有模块完成 ║
║ │ │ ║
║ ▼ │ ║
║ ┌──────────────────┐ │ ║
║ │ 下一模块 N+1 │────────┘ ║
║ └────────┬─────────┘ ║
║ │ ║
╚═══════════════════════════════════════╪═══════════════════════╝
│ 所有模块完成
▼
╔═══════════════════════════════════════════════════════════════╗
║ 全局比对阶段 ║
╠═══════════════════════════════════════════════════════════════╣
║ ║
║ ┌─────────────────────────────────────────────────┐ ║
║ │ 比对阶段(并行执行) │ ║
║ ├────────────────────────────┬─────────────────────┤ ║
║ │ Feature Comparator │ UI Comparator │ ║
║ │ Agent │ Agent │ ║
║ │ 功能比对 │ UI 比对 │ ║
║ └─────────┬──────────────────┴────────────┬────────┘ ║
║ │ │ ║
║ └──────────┬────────────────────┘ ║
║ ▼ ║
║ ┌──────────────────┐ ║
║ │ 遗漏项收集 │ ║
║ │ (未完成功能/UI) │ ║
║ └────────┬─────────┘ ║
║ │ ║
╚════════════════════════╪═════════════════════════════════════╝
│
▼
┌──────────────────┐
│ Planner │◀────────┐
│ Agent │ │
│ 制定补充计划 │ │
└────────┬─────────┘ │
│ │
┌────────────────┴───────────────────┤
│ │
▼ ▼
有遗漏项? 无遗漏项
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ 迭代下一轮 │ │ 迁移完成 │
│ (回到模块循环) │ └──────────────┘
└──────────────┘
任务:扫描 Android 源码,生成代码结构报告
执行步骤:
# 运行分析脚本
python scripts/analyze.py <source-path>
输出:
任务:制定和更新模块化迁移计划(初始 + 迭代)
规划原则:
初始规划:模块清单和迁移检查清单
迭代规划(全局比对后触发):
详细规划方法:见 PLANNING.md
状态追踪:
migration_state:
iteration: 1 # 迭代轮次
completed_modules: []
in_progress: null
pending_modules:
- name: "数据层模块"
priority: 1
status: "pending"
missing_features: [] # 全局比对后填充
ui_differences: [] # 全局比对后填充
任务:执行代码转换
输入:来自 Planner Agent 的待迁移模块
转换映射:见 API_MAPPING.md
核心转换规则:
@Entry @Component Page@ComponentLazyForEach@Observed + @ObjectLink执行转换:
python scripts/migrate.py <source-file> <target-file> --mode <component-type>
输出:
任务:验证迁移质量
输入:来自 Translator Agent 的转换后代码
检查项:
执行验证:
使用 ohos-app-build-debug skill 进行编译验证、应用打包和上板验证首界面:
# 切换到项目目录
cd <project-path>
# 1. 编译验证(构建 HarmonyOS 应用)
python $SKILL_DIR/scripts/build.py
# 2. 应用打包(生成 HAP 安装包)
python $SKILL_DIR/scripts/install.py -f entry/build/default/outputs/default/entry-default-signed.hap
# 3. 上板验证首界面
python $SKILL_DIR/scripts/launch.py
# 4. 验证应用已启动
python $SKILL_DIR/scripts/screenshot.py -o ./screenshots/launched.png
如果需要更详细的调试或使用 DevEco Studio 内置工具:
# 设置 DevEco Studio 环境变量
set "HUAWEI_DEV_HOME=C:\Program Files\Huawei\DevEcoStudio"
set "PATH=%HUAWEI_DEV_HOME%\tools\hvigor\bin;%PATH%"
# 使用 hvigorw 编译
cd <project-path> && hvigorw assembleApp
# 安装 HAP
hdc install entry/build/default/outputs/default/entry-default-signed.hap
# 启动应用
hdc shell aa start -b <bundle-name> -a <ability-name>
输出:
任务:功能验证
输入:来自 Validator Agent 的已验证代码
测试清单:见 TESTING.md
输出:
任务:对比 Android 源码与迁移后的 HarmonyOS 代码,找出遗漏的功能
执行时机:所有模块迁移完成后执行(非每个模块后执行)
执行步骤:
# 运行功能比对脚本
python scripts/compare_features.py <android-source> <harmonyos-target>
比对维度:
输出:
详细比对方法:见 FEATURE_COMPARE.md
任务:比对 Android 和 HarmonyOS 应用的 UI 界面,确保视觉和交互一致性
执行时机:所有模块迁移完成后执行(非每个模块后执行)
执行步骤:
使用 Hypium 自动化框架启动应用并进行 UI 截图比对:
# 运行自动化 UI 比对脚本
迁移前Android 应用:
应用包名:com.simplemobiletools.gallery.pro
启动 Activity:com.simplemobiletools.gallery.pro.activities.SplashActivity.Orange
迁移后鸿蒙 应用:
应用包名:com.example.myapplication
启动 Activity:EntryAbility
python scripts/compare_ui_auto.py --android <android-package> --harmonyos <harmonyos-package>
# 运行 UI 比对脚本
python scripts/compare_ui.py <android-screenshots-dir> <harmonyos-screenshots-dir>
# 或比对布局文件
python scripts/compare_ui.py --layout <android-xml-dir> <harmonyos-ets-dir>
比对维度:
输入要求: | 输入类型 | Android | HarmonyOS | |----------|---------|-----------| | 应用包名 | com.simplemobiletools.gallery.pro | com.example.myapplication | | 启动 Activity | com.simplemobiletools.gallery.pro.activities.SplashActivity.Orange | EntryAbility | | 截图 | PNG/JPG 文件 | PNG/JPG 文件 | | 布局文件 | XML (res/layout/) | ETS (@Component) | | 样式文件 | styles.xml | 主题配置 |
比对维度:
输出:
详细比对方法:见 UI_COMPARE.md
| 文档 | 用途 | 何时读取 | |------|------|----------| | API_MAPPING.md | Android/HarmonyOS API 对照表 | 执行转换时 | | COMPONENT_MAPPING.md | 组件转换模式 | 转换 UI 组件时 | | COMMON_PATTERNS.md | 常见代码模式转换 | 遇到特定模式时 | | TROUBLESHOOTING.md | 问题排查指南 | 出现错误时 | | FEATURE_COMPARE.md | 功能比对方法和检查项 | 功能比对时 | | UI_COMPARE.md | UI比对方法和检查项 | UI比对时 |
C:\xxj\code\Simple-Gallery-masterC:\workspace\0210C:\xxj\code\docsC:\xxj\code\zh-cn\application-dev┌─────────────────────────────────────────────────────────────────┐
│ 模块迁移循环 │
│ (逐个处理所有计划模块) │
└─────────────────────────────────────────────────────────────────┘
模块N ──▶ Translator ──▶ Validator ──▶ Tester ──▶ 模块完成 ✓
Agent Agent Agent
(代码转换) (质量验证) (功能测试)
│
┌─────────┴─────────┐
▼ ▼
有更多模块? 所有模块完成
│ │
▼ │
┌──────────┐ │
│ 模块N+1 │ │
└──────────┘ │
│ │
└───────────────────┘
│ 所有模块完成
▼
┌──────────────────────────┐
│ 进入全局比对阶段 │
└──────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 全局比对阶段 │
│ (所有模块迁移完成后执行一次) │
└─────────────────────────────────────────────────────────────────┘
Feature Comparator ──┐
Agent │ 并行执行
├──▶ 遗漏项收集 ──▶ Planner Agent ──┬─▶ 有遗漏项?
UI Comparator ──────┘ (合并) (制定补充计划) │
Agent │
▼
┌──────────────────┐
│ 回到模块迁移循环 │
│ 处理遗漏项模块 │
└──────────────────┘
│
┌────────────────────────┴────────┐
▼ ▼
有遗漏项? 无遗漏项
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ 继续迭代 │ │ 迁移完成 │
│ (下一轮) │ └──────────────┘
└──────────────┘
迁移工作完成需满足以下所有条件:
| 检查项 | 标准 | 负责代理 | |--------|------|----------| | 代码转换率 | 100% 文件已转换 | Translator Agent | | 语法验证 | 0 错误,< 10 警告 | Validator Agent | | 编译状态 | 编译通过 | Validator Agent | | 功能测试 | 核心功能 100% 通过 | Tester Agent | | 功能覆盖率 | ≥ 95% | Feature Comparator Agent | | UI 一致性 | 核心页面 100% 匹配 | UI Comparator Agent | | 性能对比 | 响应时间差异 < 20% | Tester Agent |
每次迭代后,Planner Agent 更新 migration_status.yaml:
# migration_status.yaml
project:
name: "SimpleGallery"
source: "C:\\xxj\\code\\Simple-Gallery-master"
target: "C:\\workspace\\0210"
# 迭代信息
iteration:
current: 2 # 当前迭代轮次
phase: "module_migration" # 模块迁移阶段 | 全局比对阶段
overall_progress:
total_modules: 8
completed_modules: 3
in_progress: "数据模型模块"
completion_percentage: 37.5%
modules:
- name: "数据模型模块"
status: "completed"
files:
- "Photo.ets ✓"
- "Album.ets ✓"
issues: []
- name: "数据访问层模块"
status: "completed"
files:
- "PhotoRepository.ets ✓"
- "AlbumRepository.ets ✓"
issues: []
- name: "业务逻辑层模块"
status: "in_progress"
files:
- "MainViewModel.ets ⚠ (部分API未实现)"
- "SettingsViewModel.ets ✓"
issues:
- type: "missing_api"
description: "批量删除API未实现"
priority: "high"
- name: "UI层模块"
status: "pending"
files: []
# 全局比对结果(所有模块完成后填充)
global_comparison:
status: "pending" # pending | in_progress | completed
missing_features:
- feature: "照片批量删除"
module: "业务逻辑层模块"
priority: "high"
found_by: "Feature Comparator Agent"
status: "待实现"
- feature: "照片分享功能"
module: "业务逻辑层模块"
priority: "medium"
found_by: "Feature Comparator Agent"
status: "待实现"
ui_differences:
- page: "MainPage"
differences:
- type: "missing_component"
description: "缺少滑动删除手势"
priority: "medium"
found_by: "UI Comparator Agent"
status: "待修复"
last_update: "2026-02-07T17:15:00"
next_step: "继续迁移 业务逻辑层模块"
testing
--- name: ohos-req-value-decision description: Use after review meeting to record decision and route to next step. Triggers: 评审决策纪要, 评审结论回流, value decision, 评审接纳, 评审不接纳, 评审退回, 下次重新上会. Do NOT use for feature baseline (ohos-req-feature-baseline), review gate checks (ohos-req-review-gate), or IR generation (ohos-req-feature-to-ir). metadata: author: openharmony scope: common stage: requirements capability: value-decision version: 0.3.0 status: draft tags: - sdd - requirements
development
Use when converting an OpenHarmony requirement document, spec, or design proposal into an OpenHarmony review slide deck (需求评审 / 需求变更评审 / 设计评审 PPTX) — produces the fixed OpenHarmony-branded review-deck structure (OH logo on every page) with architecture/flow diagrams and field tables. Triggers on "需求评审PPT", "需求变更评审", "把需求文档转成评审PPT", "spec转评审PPT", "requirement/spec to review deck". NOT for arbitrary or generic slide decks unrelated to OpenHarmony requirement/design review.
testing
Use when performing the Phase 0 Step 0.5 Review Ready Gate on a 04-feature.md, especially when the user says "evaluate gate", "review readiness", "feature ready?", "should we generate IR", or when the ohos-req-intake-orchestration main session needs a structured Ready / Conditional Ready / Not Ready judgment instead of doing the check inline. Reads 01-04, runs seven fixed checks plus a conditional-items check, and returns a machine-readable JSON summary plus a human-readable table that the main session can route on. Do NOT use for feature baseline generation (ohos-req-feature-baseline), value decision recording (ohos-req-value-decision), or IR generation (ohos-req-feature-to-ir).
testing
--- name: ohos-req-requirement-intake description: Use when importing an OHOS requirement into Phase 0.1, especially for 01-requirement.md, requirement intake, background, user value, scenarios, scope, FR/NFR, affected modules, or priority. Triggers: 需求导入, 01-requirement, 需求基线, RR单号. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline). metadata: author: openharmony scope: common