尧图网页设计 
如何搭建 Titanium Browser CI 流水线GitHub Actions 签名构建与 gh attestation 构建认证完整指南【免费下载链接】android-titanium-browserSecure open-source Android browser with support for extensions项目地址: https://gitcode.com/gh_mirrors/an/android-titanium-browserTitanium Browser 是一款基于 Chromium 的开源安全 Android 浏览器支持扩展安装与签名发布。本文将手把手带你搭建它的 CI 流水线使用 GitHub Actions 完成 Chromium 编译、APK/AAB 签名构建并讲解如何用 gh attestation 验证构建产物的真实性。即使你是 CI 新手也能照做完成第一次自托管构建。为什么值得自己搭建 Titanium Browser 构建流水线很多用户只会在 Releases 页面下载 APK但自己搭建 CI 流水线有三个实际好处好处说明 签名可控用自己的 keystore 签名产物只来自你的构建环境⏰ 版本可控定时触发 手动触发随时锁定最新 Chromium 快照构建✅ 可验证配合 gh attestation任何人都能校验这个 APK 确实由该仓库的 CI 产出Titanium Browser 的每次官方发布都由 Actions 构建并支持用 GitHub CLI 做构建认证见 README.md。你在自己的 Fork 里复刻这套流程即可。一分钟看懂现有流水线结构整个 CI 定义只有一个文件build.yml先读懂它你改造时就不会迷路。触发方式手动 定时双保险在 build.yml 中workflow_dispatch手动触发并暴露一个runner输入项可填ubuntu-latestGitHub 托管或self-hosted自托管schedulecron: 0 0 */16 * *即每 16 天自动跑一次。权限声明attestations 是认证的关键build.yml 声明了三项权限permissions: contents: write # 允许发布 Release id-token: write # 允许 OIDC 身份令牌 attestations: write # 允许写入构建证明attestation缺少attestations: write最后一步的构建认证会直接失败——这是新手最常踩的坑。六步流水线从源码到认证产物步骤位置作用CheckoutL23-L25拉取代码并初始化子模块含 vanadiumUpdateL27-L39将 vanadium 子模块升级到最新 tag 并回推BuildL46-L52执行 build.sh完成编译与签名SetL54-L60提取版本号重命名产物为版本号-时间戳-架构.apk/aabPublishL62-L71用 action-gh-release 发布到 ReleasesAttestL73-L79对三个产物写入构建证明签名构建配置两个 Secrets 搞定 APK 签名CI 里不直接放密钥文件而是把 keystore 和属性文件做 base64 编码后存入 Secrets。准备本地密钥用keytool生成keystore.jks记下keyAlias、keyPassword、storePassword写一个local.properties文件保存这三个值分别编码base64 -w 0 keystore.jks和base64 -w 0 local.properties。配置 Repository Secrets在仓库的Settings → Secrets and variables → Actions中添加两个密钥对应 build.yml 中的引用Secret 名称内容LOCAL_TEST_JKSbase64 编码的local.propertiesSTORE_TEST_JKSbase64 编码的keystore.jks流水线运行时common.sh 中的set_keys会把这两个 Secret 解码还原到keys/目录随后 build.sh 调用签名函数sign_apk用 Android SDK 的apksigner对 APK 签名common.shsign_aab用jarsigner对 AAB 签名common.sh。构建结束后 build.sh 会立即删除本地keys/目录避免密钥残留在 Runner 磁盘上。⚠️ 注意keystore 一旦泄露攻击者可继续用同一签名发版。请只在私有 Fork 的 Secrets 中存放切勿提交进仓库。Runner 选择GitHub 托管还是自托管build.yml 通过一行表达式决定 Runnerruns-on: ${{ github.event_name workflow_dispatch inputs.runner || self-hosted }}ubuntu-latestGitHub 托管零配置但 Chromium 全量编译对 CPU/内存/磁盘要求很高免费额度与磁盘容易不够self-hosted自托管官方默认推荐。建议一台干净的 Linux 机器官方脚本基于最新 Ubuntu见 build.sh 的依赖安装逻辑注册为 Actions Runner 后即可复用。手动触发时在Actions → Build → Run workflow里填入 Runner 值即可切换。发布产物并用 gh attestation 验证构建认证产物长什么样流水线会发布三个文件build.yml版本号-时间戳-arm64-v8a.apk— 64 位设备安装包版本号-时间戳-arm64-v8a.aab— Google Play 包版本号-时间戳-armeabi-v7a.apk— 32 位设备安装包用 GitHub CLI 验证真实性下载产物后一条命令即可验证它是否由你的仓库 CI 构建原理见 README.mdgh attestation verify 版本号-时间戳-arm64-v8a.apk -R 你的账号/仓库名验证通过会输出构建时间、Runner 信息和 commit形成代码 → 构建 → 产物的完整证据链。这正是permissions中id-token: write与attestations: write的意义所在。常见问题与排错清单现象原因与解决Attest 步骤失败检查 build.yml 是否声明了attestations: write与id-token: write签名失败 / 找不到 keyAlias确认两个 Secret 的 base64 编码正确local.properties中三个字段齐全构建中途磁盘写满改用自托管 Runner或清理磁盘Chromium 源码与中间产物体积极大版本号异常版本来自 vanadium 子模块的 args.gn 版本号提取逻辑build.shUpdate 步骤会先升级到最新 tag总结搭建 Titanium Browser 的 CI 流水线只需三步读懂 build.yml 的六步结构 → 配置LOCAL_TEST_JKS与STORE_TEST_JKS两个签名 Secrets → 选择合适 Runner 并运行。再用gh attestation verify给每个产物盖上构建认证的印章你就拥有了一条可复现、可验证、签名可信的完整发布流水线 。相关核心文件build.sh · patch.sh · args.gn · common.sh【免费下载链接】android-titanium-browserSecure open-source Android browser with support for extensions项目地址: https://gitcode.com/gh_mirrors/an/android-titanium-browser创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何搭建 Titanium Browser CI 流水线？GitHub Actions 签名构建与 gh attestation 构建认证完整指南
如何搭建 Titanium Browser CI 流水线GitHub Actions 签名构建与 gh attestation 构建认证完整指南【免费下载链接】android-titanium-browserSecure open-source Android browser with support for extensions项目地址: https://gitcode.com/gh_mirrors/an/android-titanium-browserTitanium Browser 是一款基于 Chromium 的开源安全 Android 浏览器支持扩展安装与签名发布。本文将手把手带你搭建它的 CI 流水线使用 GitHub Actions 完成 Chromium 编译、APK/AAB 签名构建并讲解如何用 gh attestation 验证构建产物的真实性。即使你是 CI 新手也能照做完成第一次自托管构建。为什么值得自己搭建 Titanium Browser 构建流水线很多用户只会在 Releases 页面下载 APK但自己搭建 CI 流水线有三个实际好处好处说明 签名可控用自己的 keystore 签名产物只来自你的构建环境⏰ 版本可控定时触发 手动触发随时锁定最新 Chromium 快照构建✅ 可验证配合 gh attestation任何人都能校验这个 APK 确实由该仓库的 CI 产出Titanium Browser 的每次官方发布都由 Actions 构建并支持用 GitHub CLI 做构建认证见 README.md。你在自己的 Fork 里复刻这套流程即可。一分钟看懂现有流水线结构整个 CI 定义只有一个文件build.yml先读懂它你改造时就不会迷路。触发方式手动 定时双保险在 build.yml 中workflow_dispatch手动触发并暴露一个runner输入项可填ubuntu-latestGitHub 托管或self-hosted自托管schedulecron: 0 0 */16 * *即每 16 天自动跑一次。权限声明attestations 是认证的关键build.yml 声明了三项权限permissions: contents: write # 允许发布 Release id-token: write # 允许 OIDC 身份令牌 attestations: write # 允许写入构建证明attestation缺少attestations: write最后一步的构建认证会直接失败——这是新手最常踩的坑。六步流水线从源码到认证产物步骤位置作用CheckoutL23-L25拉取代码并初始化子模块含 vanadiumUpdateL27-L39将 vanadium 子模块升级到最新 tag 并回推BuildL46-L52执行 build.sh完成编译与签名SetL54-L60提取版本号重命名产物为版本号-时间戳-架构.apk/aabPublishL62-L71用 action-gh-release 发布到 ReleasesAttestL73-L79对三个产物写入构建证明签名构建配置两个 Secrets 搞定 APK 签名CI 里不直接放密钥文件而是把 keystore 和属性文件做 base64 编码后存入 Secrets。准备本地密钥用keytool生成keystore.jks记下keyAlias、keyPassword、storePassword写一个local.properties文件保存这三个值分别编码base64 -w 0 keystore.jks和base64 -w 0 local.properties。配置 Repository Secrets在仓库的Settings → Secrets and variables → Actions中添加两个密钥对应 build.yml 中的引用Secret 名称内容LOCAL_TEST_JKSbase64 编码的local.propertiesSTORE_TEST_JKSbase64 编码的keystore.jks流水线运行时common.sh 中的set_keys会把这两个 Secret 解码还原到keys/目录随后 build.sh 调用签名函数sign_apk用 Android SDK 的apksigner对 APK 签名common.shsign_aab用jarsigner对 AAB 签名common.sh。构建结束后 build.sh 会立即删除本地keys/目录避免密钥残留在 Runner 磁盘上。⚠️ 注意keystore 一旦泄露攻击者可继续用同一签名发版。请只在私有 Fork 的 Secrets 中存放切勿提交进仓库。Runner 选择GitHub 托管还是自托管build.yml 通过一行表达式决定 Runnerruns-on: ${{ github.event_name workflow_dispatch inputs.runner || self-hosted }}ubuntu-latestGitHub 托管零配置但 Chromium 全量编译对 CPU/内存/磁盘要求很高免费额度与磁盘容易不够self-hosted自托管官方默认推荐。建议一台干净的 Linux 机器官方脚本基于最新 Ubuntu见 build.sh 的依赖安装逻辑注册为 Actions Runner 后即可复用。手动触发时在Actions → Build → Run workflow里填入 Runner 值即可切换。发布产物并用 gh attestation 验证构建认证产物长什么样流水线会发布三个文件build.yml版本号-时间戳-arm64-v8a.apk— 64 位设备安装包版本号-时间戳-arm64-v8a.aab— Google Play 包版本号-时间戳-armeabi-v7a.apk— 32 位设备安装包用 GitHub CLI 验证真实性下载产物后一条命令即可验证它是否由你的仓库 CI 构建原理见 README.mdgh attestation verify 版本号-时间戳-arm64-v8a.apk -R 你的账号/仓库名验证通过会输出构建时间、Runner 信息和 commit形成代码 → 构建 → 产物的完整证据链。这正是permissions中id-token: write与attestations: write的意义所在。常见问题与排错清单现象原因与解决Attest 步骤失败检查 build.yml 是否声明了attestations: write与id-token: write签名失败 / 找不到 keyAlias确认两个 Secret 的 base64 编码正确local.properties中三个字段齐全构建中途磁盘写满改用自托管 Runner或清理磁盘Chromium 源码与中间产物体积极大版本号异常版本来自 vanadium 子模块的 args.gn 版本号提取逻辑build.shUpdate 步骤会先升级到最新 tag总结搭建 Titanium Browser 的 CI 流水线只需三步读懂 build.yml 的六步结构 → 配置LOCAL_TEST_JKS与STORE_TEST_JKS两个签名 Secrets → 选择合适 Runner 并运行。再用gh attestation verify给每个产物盖上构建认证的印章你就拥有了一条可复现、可验证、签名可信的完整发布流水线 。相关核心文件build.sh · patch.sh · args.gn · common.sh【免费下载链接】android-titanium-browserSecure open-source Android browser with support for extensions项目地址: https://gitcode.com/gh_mirrors/an/android-titanium-browser创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考