Revanced-And-Revanced-Extended-Non-Root：把补丁构建变成下载链接的仓库
该项目围绕「FiorenMas/Revanced-And-Revanced-Extended-Non-Root」构建，面向真实业务场景提供可复用的开源实践方案，支持稳定落地与可扩展的项目实践。
秒懂
- 它是什么？
- 这个仓库用 GitHub Actions 自动构建 ReVanced、ReVanced Extended 和 Morphe 补丁版 APK，按 CPU 架构分发。它的价值是省去命令行操作，代价是你必须信任自动构建的产物。
- 适合谁用？
- 这个仓库适合不想碰命令行、只想下载现成补丁 APK 的普通用户，尤其是那些分不清 arm64-v8a 和 x86 的人，因为 All Architectures 选项降低了门槛。不适合对供应链安全敏感的用户，因为你无法验证构建脚本之外的产物完整性，也没有签名校验。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Shell（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是补丁分发难题
ReVanced 系列的补丁脚本本身是开源的，但对普通用户来说，要自己安装 Java、配置 ADB、运行命令行工具，门槛太高。这个仓库的定位很直接：把构建过程从用户手里拿走，变成预编译的 APK 下载。README 里明确说，这些脚本对大多数用户太难用，所以作者创建了这个仓库来提供更简单的方式。它面向的是不想折腾工具链、只想要一个能用 APK 的人。仓库覆盖了 YouTube、YouTube Music、Facebook、Twitter、Instagram 等几十个应用，但核心场景还是 YouTube 系列。它不是一个补丁项目，而是一个构建分发项目，这一点从它只发布文件、不创建新 release 就能看出来。
构建流程藏在 Actions 里
README 没有给出构建脚本的细节，但仓库结构暗示了工作方式。它依赖 GitHub Actions 自动运行，README 顶部有指向 Actions 页面的徽章链接。作者声称仓库会在补丁发布后约 10 分钟开始实时构建，这对应 Actions 的触发器，大概率是监听上游补丁仓库的 release 事件。构建产物直接附加到名为 all 的 release 下载里，而不是为每个版本创建新 release。这种设计让下载链接保持不变，用户不需要跟着版本号走。但这也意味着你无法从 release 页面看到版本历史，只能靠文件名里的 stable 或 beta 区分。如果你想知道某个 APK 具体用了哪个补丁版本，必须去翻 Actions 日志，README 没有提供这个信息。
下载选项的粒度：架构与版本
下载页按应用分组，每个应用下先分 Morphe、Revanced Extended（anddea fork）、Revanced（已过时）三个补丁源，再分 Stable 和 Beta，最后按 CPU 架构列出文件。架构选项包括 arm64-v8a、armeabi-v7a、x86、x86_64，以及一个 All Architectures 的通用包。README 的建议是，不知道架构就选 All Architectures。这个选项实际上是一个 fat APK，包含多种架构的代码，体积更大但兼容性最好。Lite 版本则相反，它去掉多余资源，比如只保留英文界面、移除不常用的屏幕 DPI，文件更小但功能可能受限。Beta 版本用的是开发版补丁，不是 beta 版 APK 文件，这一点 README 专门强调过，而且 Beta 与 Stable 的包名相同，安装会覆盖 Stable 版本。
MicroG 是绕不开的前置条件
对于 YouTube、YouTube Music 和 Google Photos 这几个应用，README 明确要求先安装 MicroG RE。这是 ReVanced 系列的标准做法，因为补丁后的应用去掉了 Google 服务依赖，需要 MicroG 来模拟 Google 框架。MicroG RE 来自 MorpheApp 的独立仓库，不是这个项目维护的。这意味着你要装两个 APK，一个是 MicroG，一个是补丁后的主应用。如果只装主应用，大概率会闪退或无法登录。这个依赖关系在 README 里用注意块标出，但没有提供安装顺序的详细说明。对于不熟悉 Android 侧载的用户，这可能是一个隐藏的坑。
信任模型：自动构建的安全边界
仓库声称所有代码开源，APK 文件从可信站点下载，所以安全。这个说法只覆盖了构建脚本本身。你下载的 APK 是 Actions 自动构建的，构建环境由 GitHub 托管，但补丁源和基础 APK 的完整性取决于上游仓库。作者没有提供 APK 的校验和，也没有签名指纹。这意味着你无法验证下载的文件是否真的由这个仓库的脚本产出，也无法确认它没有被篡改。对于普通用户，这个风险可能可以接受，因为 Actions 日志是公开的，你可以手动核对构建步骤。但如果你对供应链攻击敏感，这个仓库就不适合你。它没有提供任何形式的产物验证机制，这是它的一个真实短板。
维护状态与替代方案
仓库最后推送停在 2023 年 6 月 1 日，之后没有更新。这意味着所有下载链接指向的 APK 都基于当时的补丁版本。ReVanced 和 ReVanced Extended 的补丁持续更新，旧补丁可能在新版 YouTube 上失效。如果你现在使用这个仓库，很可能拿到过时的构建。替代方案有两个方向。一是自己运行 ReVanced CLI，从 revanced-patches 官方仓库获取最新补丁，手动执行构建命令，这需要安装 Java 和下载基础 APK，但你能完全控制版本。二是使用 ReVanced Manager，这是一个图形化工具，自动下载补丁并应用，不需要命令行，但需要你手动选择 APK 文件。两者的共同点是你直接面对上游补丁，而不是依赖第三方构建。这个仓库的停止更新恰恰说明了它的模式不可持续，维护者一旦离开，所有产物就冻结了。
许可证与使用边界
仓库采用 GPL-3.0 许可证，这意味着构建脚本本身是开源的，你可以 fork 并修改。但要注意，补丁后的 APK 包含原始应用的代码，这些代码的版权属于各自作者，GPL 不覆盖它们。README 里也提到，许可证归创建者所有，如果你喜欢某个修改版应用，请支持原作者。这是一个法律上的灰色地带，ReVanced 项目本身也面临类似问题。对于企业用户，使用这些 APK 可能违反 Google Play 的服务条款，虽然 README 没有明说。个人使用通常风险较低，但你不应该假设它有法律保障。这个仓库的脚本可以 fork 后自己跑 Actions，这是 GPL 赋予你的权利，但你需要自行承担构建和分发的责任。
编辑结论
这个仓库适合不想碰命令行、只想下载现成补丁 APK 的普通用户，尤其是那些分不清 arm64-v8a 和 x86 的人，因为 All Architectures 选项降低了门槛。不适合对供应链安全敏感的用户，因为你无法验证构建脚本之外的产物完整性，也没有签名校验。也不适合需要最新补丁的人，仓库最后推送停在 2023 年 6 月，后续补丁更新只能靠 fork 或自己构建。采用前先检查 Actions 日志是否对应当前补丁版本，再确认下载的 APK 包名是否与官方一致，避免误装覆盖稳定版。这个仓库的价值在于它证明了自动化构建可以做到多简单，但它的停止更新也提醒你，依赖第三方构建始终是临时方案。
社区笔记