VirtualApp 贡献指南：5 步完成你的第一个 PR-平芜编程栈

VirtualApp 贡献指南：5 步完成你的第一个 PR

【免费下载链接】VirtualAppVirtual Engine for Android(Support 14.0 in business version)项目地址: https://gitcode.com/GitHub_Trending/vi/VirtualApp

VirtualApp 是一款运行在 Android 上的沙盒 SDK，能把外部 App 装进宿主内部的隔离空间里运行，实现多开、插件化和应用隔离。这篇文章写给准备提交第一个 PR 的开发者：读完你会知道怎么把 Demo 在本地跑起来、从哪个包读起、怎么挑一个能完成的 issue。

① 先判断这个项目适不适合你

技术栈门槛：主体是 Android Framework 层的 Java 代码，涉及大量系统服务拦截、反射和 AIDL；Native 层（IO 重定向、jni hook）在VirtualApp/lib/src/main/jni/下，不深入可以不看。另外要留意一点：开源仓库的构建链较老——VirtualApp/build.gradle 用的是 AGP 3.0.1，gradle-wrapper.properties 锁的是 Gradle 4.1，compileSdkVersion 26，需要匹配旧版 Android Studio。

主要难点：理解"VA Framework 代理"这条主线——App 的每个系统请求都被拦截、改参、还原，逻辑分散在 client 的 stub 和 server 的实现两侧，读起来需要来回对照。

时间投入：环境跑通约 1～2 天，看懂 doc/VADev.md 的源码结构部分约半天，第一个小修复 PR 通常 3～5 天可以完成。

② 先在本地把项目跑起来

先克隆仓库：

git clone https://gitcode.com/GitHub_Trending/vi/VirtualApp

用旧版 Android Studio（或命令行）构建。VirtualApp/settings.gradle 只注册了两个模块：

include ':lib', ':app'

其中lib是核心库，app是可运行的 Demo。执行./gradlew :app:assembleDebug打出 Demo APK，装到 Android 5.0+ 的实机或模拟器上，能看到应用列表界面即算跑通。

关于配置：doc/VADev.md 中描述的VAConfig.gradle属于商业版工程，开源仓库里没有这个文件；开源版的包名直接写在 VirtualApp/app/build.gradle 里（applicationId "io.virtualapp"）。文档列出的配置项（PACKAGE_NAME、EXT_PACKAGE_NAME、VA_MAIN_PACKAGE_32BIT、VA_ACCESS_PERMISSION_NAME）在集成到自己宿主时依然要逐项落实：

ext { VA_MAIN_PACKAGE_32BIT = true // 主包为32位 VA_ACCESS_PERMISSION_NAME = "io.busniess.va.permission.SAFE_ACCESS" }

③ 看代码从哪里下手

先看运行时进程模型，VA 有 5 类进程（VAPP Client、VA Server、VA Host Main/Plugin、CHILD），很多代码"为什么长这样"的答案都在进程边界上：

读源码建议从这三个真实入口包开始，都在 VirtualApp/lib/src/main/java/ 下：

com/lody/virtual/client/：运行在 VAPP Client 进程，负责对各系统服务的 Hook，其中hook/目录有 90 多个 stub 文件，是改动最频繁的区域之一。
com/lody/virtual/server/：运行在 VA Server 进程，处理 App 安装、包管理等不交给 Android 系统处理的请求。
mirror/：对系统隐藏类的反射引用封装，工具性质，适合当"查字典"用，理解它之后看 client 代码会顺很多。

Demo 侧的入口在 VirtualApp/app/src/main/java/io/virtualapp/，VApp.java是宿主 Application，能看到VirtualCore.get().startup()的初始化方式。

④ 挑一个新手友好的 issue

去仓库页面顶部的 Issues 标签页筛选未关闭的问题。判断能不能接，看三点：

能不能本地复现：先在自己跑通的 Demo 上复现，复现不了的先不碰。
改动范围是否收敛：优先挑"某系统 API 适配""某 App 打不开"这类问题，往往对应 client 下某个单一 stub 或 server 下某个服务方法；涉及 IO 重定向、进程模型的大问题留给熟悉 Native 层的人。
是否在维护范围内：README 说明 GitHub 上的开源代码已于 2017 年 12 月停止更新，部分 issue 可能长期无人响应。挑问题时顺手看一下该 issue 是否和现有代码对得上，避免对着已删除的逻辑提 PR。

⑤ 从写代码到提交 PR

仓库没有 CONTRIBUTING 文件，也没有现成的分支规范，实操建议照 README 商业版更新日志的风格写提交信息，一句话说清改了什么，例如：

git checkout -b fix-xxx git commit -m "fix: 修复某应用在Android 14.0上无法启动的问题"

测试方面，仓库内没有单元测试基础设施，验证靠真机：重新安装 Demo，在沙盒内装一个会被影响的小 App，确认功能正常且 Demo 自身启动、应用列表、安装流程不回归；配合VLog输出看 logcat 定位。提交前自查：32 位和 64 位 App 各测一遍；在你手上设备之外的 Android 版本上至少确认 Demo 能启动；确认没有改动 VirtualApp/app/build.gradle 中与你 PR 无关的版本号、依赖。

⑥ 容易踩的坑

包名没换：Demo 的applicationId是写死的io.virtualapp，集成到自己宿主时不改包名，且SettingConfig.getMainPackageName()与实际包名不一致，会导致组件权限校验失败。
权限名不一致：VA_ACCESS_PERMISSION_NAME必须与 AndroidManifest 中<uses-permission>完全一致，doc/VADev.md 建议用manifestPlaceholders注入，手写字符串极易漏改。
依赖源已失效：VirtualApp/build.gradle 里同时使用了jcenter()，该仓库已停止服务，首次构建很可能卡在依赖解析，需要自行调整仓库源。
构建环境过新：Gradle 4.1 + AGP 3.0.1 的组合在最新版 Android Studio 上可能打不开或编译报错，别升级 wrapper，优先降级 IDE。