feat: 重构 Reminder Notification 系统并更新应用包名

docs/protocols/app/update-check.md

@@ -104,3 +104,62 @@ Android 安装包命名规范：
 
 - `versionName`（如 `0.1.0`）由开发者手动维护
 - `buildNumber`（如 `+2`）由打包脚本自动递增
+
+## 7. Android Production Signing And Upgrade Strategy
+
+为了保证 APK 升级是覆盖安装（保留应用数据和登录态），生产环境必须满足以下条件：
+
+1. `applicationId` 保持不变（当前为 `com.xunmee.xisocial`）
+2. 所有 `release` 包使用同一套正式签名证书（固定 keystore）
+3. `versionCode` 严格递增
+
+若证书变化，Android 通常无法覆盖安装，会要求先卸载旧包再安装新包，导致本地 token/缓存数据丢失。
+
+### 7.1 Signing Files
+
+- 签名配置文件：`apps/android/key.properties`（本地文件，不入库）
+- 模板文件：`apps/android/key.properties.example`
+- 证书文件建议：`apps/android/release.jks`（本地文件，不入库）
+
+`key.properties` 示例：
+
+```properties
+storeFile=release.jks
+storePassword=<store_password>
+keyAlias=<key_alias>
+keyPassword=<key_password>
+```
+
+### 7.2 Release Build Contract
+
+- `apps/android/app/build.gradle.kts` 的 `release` 构建必须使用 `signingConfigs.release`
+- 当 `apps/android/key.properties` 缺失时，构建必须失败（禁止回退到 debug 签名）
+
+### 7.3 Production Packaging Command
+
+```bash
+bash deploy/build-android-release.sh \
+  --backend-host <prod-domain-or-ip> \
+  --channel release \
+  --release-notes "<release notes>"
+```
+
+产物位置：
+
+- APK：`deploy/static/releases/social-app-android-v{versionName}+{versionCode}-release.apk`
+- 清单：`deploy/static/releases/manifest.json`
+
+### 7.4 First Migration To Stable Signing
+
+如果历史版本使用 debug 签名，而新版本改为正式签名：
+
+- 首次升级通常需要卸载旧包后安装新包（一次性迁移）
+- 迁移完成后，后续版本在同签名条件下可覆盖安装并保留登录态
+
+### 7.5 Operational Checklist (Mandatory)
+
+1. 确认 `applicationId` 未变
+2. 确认 `release` 签名证书与上个生产版本一致
+3. 确认 `versionCode` 大于上个生产版本
+4. 在测试机执行一次覆盖安装验证（旧版登录 -> 升级 -> 登录态保留）
+5. 上传新 APK 到 `deploy/static/releases/` 并校验 `manifest.json` 对应条目