Files

T

History

SkyJourney d90d2ecd03 初始化：私有维护版 Gemini-in-Chrome 安装脚本

从 appsail/Gemini-in-Chrome (MIT) fork 并重写 install.sh / install.ps1：
- 原脚本用正则/sed 做“仅替换已存在字段”，字段本不存在时静默不生效
- 改为 JSON 感知读写（jq 优先，探测/自动装失败时降级为 sed+awk 零依赖兜底）
- 修复过程中实测发现并修掉的坑：BSD sed 不支持 GNU 的 0,/re/ 插入语法、
  正则不容忍冒号后空格导致插入重复 key、macOS 系统自带 bash 3.2 在脚本文件模式下
  中文紧跟未加花括号的 $VAR 会解析错位丢字节
- 新增 test-fixtures/ 下完全人工构造（非真实数据脱敏）的多 profile 测试样本
- README 改为中文，下载链接指向本仓库，补充 MIT LICENSE 及上游致谢

2026-08-16 13:30:42 +08:00

Local State.sample.json

初始化：私有维护版 Gemini-in-Chrome 安装脚本

2026-08-16 13:30:42 +08:00

README.md

初始化：私有维护版 Gemini-in-Chrome 安装脚本

2026-08-16 13:30:42 +08:00

README.md

测试用 Local State fixture

Local State.sample.json 是完全人工构造的样本文件，不是从任何真实 Chrome 安装脱敏而来—— 所有 gaia_id、姓名、邮箱、头像 URL 等字段都是占位符（test.user.one@example.com 之类），不包含任何真实账号信息，可以放心提交到仓库、拿去别的机器测试。

结构上覆盖了 profile.info_cache 的三种场景，用来验证 install.sh / install.ps1 对每个 profile 的处理是否正确：

profile	初始状态	用来验证什么
`Default`	完全没有 `is_glic_eligible` 字段	插入逻辑
`Profile 1`	`is_glic_eligible: false`	翻转逻辑
`Profile 2`	`is_glic_eligible: true`	已生效时保持不变、不产生重复 key

顶层也没有 variations_country / variations_permanent_consistency_country，用来验证插入逻辑。

在 Windows 上测试 install.ps1

先备份你自己真实的 Local State（如果要在真实 Chrome 目录下测）：

Copy-Item "$env:LOCALAPPDATA\Google\Chrome\User Data\Local State" "$env:LOCALAPPDATA\Google\Chrome\User Data\Local State.real.bak"

把这份 fixture 拷贝过去顶替（记得测完要恢复）：

Copy-Item ".\test-fixtures\Local State.sample.json" "$env:LOCALAPPDATA\Google\Chrome\User Data\Local State"

运行 ..\install.ps1，检查输出里三个 profile 是否都提示 is_glic_eligible 已启用。

测完恢复真实文件：

Copy-Item "$env:LOCALAPPDATA\Google\Chrome\User Data\Local State.real.bak" "$env:LOCALAPPDATA\Google\Chrome\User Data\Local State" -Force

也可以不碰真实路径，直接改一份 install.ps1 的副本把 $chromeStatePath 硬编码指向这份 fixture，跑完直接看输出文件内容，更安全、不依赖"记得恢复"这一步。