Repository navigation
docs(release): state exactly how the 0.2.0 release packages were verified - #4
Merged
Merged
Conversation
…fied The first version of the 0.2.0 notes said the upgrade over the 0.1.0 release package would be checked after publishing with the downloaded files on the test phone. That cannot be done on that phone: it carries builds signed with the debug certificate, so switching to the release certificate means uninstalling first and losing its data and model configuration. The release packages were checked on a clean API 36 emulator instead, and this commit writes down what was done there and what was not: - downloaded 0.1.0 Messages APK (checksum equals its own SHA256SUMS), one setting changed, then the 0.2.0 release APK installed over it: success, setting kept, the first-run dialog is not shown again; - the AgentOS app and the five sample APKs of this release install at 0.2.0, and the release Messages app reaches the AgentOS authorization wait after Start; - every APK has the same certificate fingerprint as 0.1.0. Not done, and said so: release-certificate packages on the Pixel 8, re-flashing the module on a real phone, the AgentOS app 0.1.0 to 0.2.0, authorization records surviving the upgrade.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
做了什么、为什么
0.2.0 的发布说明原来写的是“覆盖安装在发布后用从 GitHub 下载的文件在测试机上验证”。这件事在那台 Pixel 8 上做不了：它装的是 debug 证书的构建，换成发布证书要先卸载，数据和模型配置会一起丢，用户录屏就没法用了。所以改在干净的 API 36 模拟器上验证发布包，并把实际做过的和没做的如实写进发布说明和验收记录。只改文档，不改代码和版本号。
验证
python3 tools/check-i18n.py、tools/tests137 项通过；check_release_notes对新文件没有问题真机测试
docs/release-notes/0.2.0.md和docs/m1-acceptance.md，不改任何运行行为。文中描述的验证本身在模拟器上做了（Pixel_8a，API 36，只读无快照）：已发布的 0.1.0 短信 APK → 改一项设置 →install -r0.2.0 发布 APK，成功、设置保留、不再弹第一次的对话框；AgentOS App 和五个示例的发布 APK 装上、版本 0.2.0；发布版短信 App 的按钮 → 预览 → 开始 → “等你在 AgentOS 里允许”。这是模拟器，不是真机，文档里也是这么写的。文档与契约
风险与回滚
git revert即可。合并后会基于合并后的 main 重新做签名构建，所以发布包里的RELEASE-NOTES.md和build-info.json的gitRevision与 tag 一致。