TRAE + Doubao-Seed-Evolving + Android Studio：如何跑通一个旧 App项目

目录

前言

一、拿什么项目来试 Seed Evolving

二、第1轮：先把 22 个构建错误理清楚

三、第二轮：先修核心问题，再处理连锁问题

3.1 Facebook SDK：从 latest.release 改成固定版本

3.2 network_security_config：不用 resValue 绕了，改成 source set

3.3 APNetReceiver：Android 12+ 的 exported 要求

四、继续 Rebuild：后面几类问题才露出来

4.1 native so 重复

4.2 allowBackup 清单冲突

4.3 Guava ListenableFuture 重复

五、Gradle 问题修完，又遇到 Kotlin 编译错误

六、编译通过后，Run 按钮又灰了

七、终于装到手机，但开屏后闪退

八、整个流程回顾

九、个人感受

十、总结

前言

最近看到豆包 Seed Evolving 上线，我对它的理解是：它不是一个固定版本的模型，而是一个会持续迭代的 latest 分支，尤其偏向 Coding 和 Agent 这类需要多轮上下文、工具调用和长期任务推进的场景。这下子又有新玩意可以倒腾了，我在官网开通了Agent Plan 个人版，当然只使用它的语言模型 Doubao-Seed-Evolving 来试试水，看看能力如何。

我选择在TRAE 软件上添加模型进行使用 Doubao-Seed-Evolving，毕竟都是一家的产品，适配度更高。

一、拿什么项目来试 Seed Evolving

刚好手里有一个很适合测试的真实问题：一个很久没维护的视频剪辑 App 项目。这个项目不是 Demo，也不是新建工程，而是一个多模块、依赖复杂、接了广告、登录、支付、视频编辑 SDK、上传模块的老项目。

我在 Android Studio 里拉完代码后直接 Build，结果迎面就是：

BUILD FAILED with 22 failures。

错误日志文件有 140KB+，里面混着依赖冲突、Manifest 合并失败、AndroidTest 资源失败、native so 重复、Kotlin 编译错误等问题。平时遇到这种项目，我一般会先深呼吸一下，因为它不是改一行代码能解决的，而是要一点点剥洋葱。

这次我就把它作为 Seed Evolving 的测试任务：让它陪我从 Build、安装、运行到真机闪退排查，完整走一遍。

二、第1轮：先把 22 个构建错误理清楚

一开始比较棘手的问题不是“怎么改”，而是“到底先看哪个错误”。Android Studio 一次性抛出 22 个 failure，很多错误还会互相影响：前面的依赖冲突不解决，后面可能继续连锁报错。

我把构建日志文件交给 AI，让它先不要急着改代码，而是帮我做错误归类。它先从日志中搜索FAILED、error、exception这些关键字，再按模块和错误类型梳理。

第一轮它先抓出了三类核心问题：

这里我觉得比较有价值的是，它没有只盯着某一条报错，而是把错误背后的关系串起来了。比如 Facebook SDK 的重复类，不是简单“删一个包”就能解决，它追到了login_base/build.gradle里用了：

api "com.facebook.android:facebook-login:latest.release"

latest.release在老项目里很危险，因为它会随着远端仓库变化，导致本来能构建的项目过一段时间突然不稳定。

三、第二轮：先修核心问题，再处理连锁问题

3.1 Facebook SDK：从 latest.release 改成固定版本

AI 先建议把 Facebook SDK 固定到明确版本，避免动态拉取。这里中间还有一个小插曲：第一次它先改到了16.0.0，但后面 Rebuild 时发现 Facebook SDK 16.x 又引入了 Kotlin 1.8.x 的 stdlib，和项目当前 Kotlin 1.7.x 体系冲突。

于是又调整成更贴合当前工程的15.2.0，并排除它传递进来的 kotlin-stdlib：

api("com.facebook.android:facebook-login:15.2.0") { exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib' }

同时在根build.gradle里补了一层版本约束，统一 Kotlin stdlib：

allprojects { configurations.all { resolutionStrategy { force "org.jetbrains.kotlin:kotlin-stdlib:${kotlin_version}" force "org.jetbrains.kotlin:kotlin-stdlib-jdk7:${kotlin_version}" force "org.jetbrains.kotlin:kotlin-stdlib-jdk8:${kotlin_version}" } } }

这个过程很像真实开发：不是一次就选到完美版本，而是根据后续报错再收敛方案。

3.2 network_security_config：不用 resValue 绕了，改成 source set

原项目在app和app_*模块里，通过resValue动态指定网络安全配置：

resValue 'xml', "network_security_config", "@xml/network_security_config_debug"

普通 Debug 包可能没问题，但 AndroidTest 构建时测试 APK 找不到被引用的network_security_config_debug，于是资源链接失败。

AI 的处理方式不是简单复制一个同名文件到 androidTest，而是把方案改得更清晰：不同 build type 直接放各自的network_security_config.xml。

app/src/debug/res/xml/network_security_config.xml app/src/release/res/xml/network_security_config.xml app/src/betaTest/res/xml/network_security_config.xml app/src/huaweiBetaTest/res/xml/network_security_config.xml app/src/huawei/res/xml/network_security_config.xml app/src/google/res/xml/network_security_config.xml

app_*也做同样处理。这样 Manifest 里始终引用@xml/network_security_config，具体用哪份资源交给 Android 的 source set 合并机制来决定，逻辑更直观。

3.3 APNetReceiver：Android 12+ 的 exported 要求

另一个批量报错来自com.aipai.netmonitorsdk.receiver.APNetReceiver。它在第三方 SDK 的 Manifest 中声明了intent-filter，但没有写android:exported。Android 12 之后这类组件必须显式指定 exported，否则 Manifest merger 会失败。

AI 先在common模块里加了覆盖声明：

<receiver android:name="com.aipai.netmonitorsdk.receiver.APNetReceiver" android:exported="true" tools:replace="android:exported"> <intent-filter> <action android:name="android.net.conn.CONNECTIVITY_CHANGE" /> </intent-filter> </receiver>

但它也继续检查了依赖关系，发现有些模块不一定通过 common 传递到这个 Manifest，所以又在router、upload、base_app、ipay-exposed、webview、downloadImpl等模块补了对应声明。

这一步如果手工做，比较容易漏模块；AI 的优势在于它能顺着错误日志和模块结构继续扫。

四、继续 Rebuild：后面几类问题才露出来

前面三类问题处理完后，我本来以为差不多了。但继续读日志后面的What went wrong，又发现了几类隐藏问题。

4.1 native so 重复

main模块报了：

2 files found with path 'lib/arm64-v8a/libc++_shared.so' - jetified-mmkv-1.2.7 - jetified-video-editor-ai-common-1.9.0.300

这是多个 AAR 都带了libc++_shared.so。处理方式是在main/build.gradle里添加：

packagingOptions { pickFirst 'lib/*/libc++_shared.so' }

4.2 allowBackup 清单冲突

pay-huaweipay模块里，aiPai http 库和华为 IAP SDK 对android:allowBackup的声明不一致，一个是 true，一个是 false。Manifest merger 需要明确取哪个值。

于是 Manifest 里加了：

<application android:allowBackup="true" tools:replace="android:allowBackup">

4.3 Guava ListenableFuture 重复

upload模块中 AWS SDK 传递依赖带来了guava:18.0，同时又有listenablefuture:1.0，产生重复类。AI 对 AWS 依赖加了 exclude：

implementation(rootProject.ext.dependencies.aws_s3) { exclude group: 'com.google.guava', module: 'listenablefuture' } implementation(rootProject.ext.dependencies.aws_auth) { exclude group: 'com.google.guava', module: 'listenablefuture' }

这几类问题都不大，但散落在不同模块里。对人来说比较消耗注意力，对 Agent 来说，只要上下文不断，它可以一直往下推进。

五、Gradle 问题修完，又遇到 Kotlin 编译错误

Gradle 配置、Manifest、资源问题修完后，再 Rebuild，upload 模块又冒出一个 Kotlin 编译错误：

e: CreateThumbManager.kt: (74, 42): Smart cast to 'FileOutputStream' is impossible, because 'out' is a local variable that is captured by a changing closure

出问题的代码大概是这样：

var out: FileOutputStream? = null runCatching { out = FileOutputStream(saveFile) bitmap.compress(format, 100, out) out?.flush() out?.close() }.onFailure { out?.close() if (saveFile.exists()) saveFile.delete() }

Kotlin 不允许对被闭包捕获、且会变化的局部变量做 Smart Cast。AI 把它改成.use {}：

runCatching { FileOutputStream(saveFile).use { out -> bitmap.compress(format, 100, out) out.flush() } }.onFailure { if (saveFile.exists()) saveFile.delete() }

这个改法比原代码更符合 Kotlin 写法，也避免了异常情况下漏关流的问题。

六、编译通过后，Run 按钮又灰了

Make Project 成功后，我准备直接装手机，结果 Android Studio 顶部的 Run 按钮是灰色的。

这个问题其实和代码无关，是因为前面改了多个build.gradle文件，Android Studio 需要重新 Gradle Sync。同步完成后，设备能正常识别，Run 按钮也恢复了。

这个小插曲也挺真实：工程跑起来不是只有“代码正确”就够了，IDE 状态、Gradle Sync、设备连接都会影响最后一步。

七、终于装到手机，但开屏后闪退

Run 成功安装到小米手机（Android 10 / MIUI 12）后，App 能进入开屏页，但很快闪退。再次打开会弹各种权限，授权后还是闪退。

一开始我怀疑是不是 Android 10 系统版本不兼容。但看项目的 minSdk 是 24，Android 10 理论上没问题。

我先尝试用 adb 抓日志，但终端里 adb daemon 没连上。后来用 Android Studio Logcat 看了一段，只看到进程启动后几秒结束，前面全是 MIUI、Google Play services、PowerKeeper 这类系统日志，没有明显的 Java 崩溃栈。

AI 建议我导出更完整的日志文件。我把完整 Logcat 保存成日志报错.md再给它分析，这次终于抓到了关键堆栈：

FATAL EXCEPTION: main java.lang.IllegalArgumentException: Linear gradient requires 'angle' attribute to be a multiple of 45 at android.graphics.drawable.GradientDrawable$GradientState .updateGradientStateOrientation(GradientDrawable.java:2208) ... at androidx.viewpager.widget.ViewPager.onMeasure(ViewPager.java:1622)

这不是系统版本不匹配，而是 drawable 资源兼容性问题。

Android 的GradientDrawable要求线性渐变的android:angle必须是 45 的倍数，比如 0、45、90、135、180、225、270、315。项目里有几个资源写得不规范：

其中332肯定不合法；360虽然数学上等于 0，但在部分系统实现里也会抛异常。修改后重新 Make Project，再 Run，App 终于能正常进入首页。

八、整个流程回顾

这次不是一次性修完，而是一步一步推进：

Build失败（22个错误） → 分析日志，先定位3类核心问题 → 修复Facebook / network_security_config / APNetReceiver → Rebuild后发现Facebook版本引入Kotlin冲突 → 调整Facebook版本并统一Kotlin stdlib → 继续读日志，处理native so / allowBackup / Guava问题 → Rebuild后出现Kotlin Smart Cast错误 → 重构FileOutputStream写法 → Make Project成功，但Run按钮灰色 → Gradle Sync后恢复Run → 安装到手机，开屏后闪退 → 日志不完整，导出完整Logcat → 定位GradientDrawable angle问题 → 修改drawable资源，重新运行成功

我没有刻意统计精确耗时，但对比自己以前处理类似项目的经验，这类问题通常会被拆散在半天甚至更久的碎片时间里。用 Seed Evolving 的感受是：它能把长上下文里的错误、文件、修改历史串起来，不会只盯着当前这一条报错看。

比较打动我的是，它不是只回答“这一行怎么改”，而是能陪着任务往后走。前面修完构建，后面又遇到 IDE 状态、真机安装、运行时闪退，它都能接着上下文继续分析。

九、个人感受

如果只是新建一个 Demo，让 AI 写几个页面，其实不太能看出差距。真实项目麻烦的地方在于：问题不是按教材顺序出现的，而是混在一起；你修完一个，另一个才会冒出来。

这次 app项目 的修复过程，比较能体现 Seed Evolving 适合的场景：

• 上下文长：要读构建日志、多个 build.gradle、Manifest、drawable、Kotlin 文件；
• 任务链长：Build → Rebuild → Make → Sync → Run → Logcat → 再修复；
• 问题跨度大：Gradle、Android资源、Manifest合并、Kotlin语法、Android版本兼容性都碰到了；
• 多轮对话不能断：每一步都依赖前面的修改结果。

解决问题过程中的 token / 工具调用消耗也不低，但这个场景里我觉得是合理的。它花的不是“闲聊成本”，而是在持续读文件、定位问题、修改代码、根据新错误调整方案。

这次体验之后，我对这类 Coding Agent 的期待也更明确了：不是替我写几段代码，而是在我面对复杂老项目时，能帮我稳定地把上下文接住，一步步把项目跑起来。

十、总结

这次用 TRAE + 豆包 Seed Evolving 修复 app 项目的过程，从一开始的 22 个构建错误，到后来真机运行成功，基本覆盖了一次旧 Android 项目接手时会遇到的典型坑。

它让我感觉比较明显的一点是：AI 编程助手已经不只是“代码补全工具”，更像一个能一起排查问题的工程搭子。它可能中间也会试错，比如 Facebook SDK 版本一开始选高了，但它能根据后续错误继续调整，不会卡在一个点上。

对于开发者来说，这种能力挺实用：你不需要一开始就把所有问题都说清楚，只要把真实日志、真实代码、真实现象给它，它就能陪你把 Build、安装、运行这条链路逐步跑通。