laoyang/SyncCalendar
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity
70 Commits 1 Branch 11 Tags
b7bc4b540338c736dd2ceaf4beb9dd10cd05a6cd
Commit Graph
18 Commits
Author SHA1 Message Date
laoyang 942f71bfdf 0.0.8 上架收尾：移除同步记录落盘 + 镜像空清单防护 + 前台默认间隔 15 分钟 
三处改动（均来自 2026-10-16 真机日志实测）：

1) 移除「同步记录」落盘
   · LogUtil 顶部新增 ENABLE_FILE_LOG=false（发行版只输出 console），
     真机排查时改 true 即可恢复落盘，所有调用点无需改动；
   · init() 里顺手 unlink 历史版本遗留的 sync.log / mirror_diag.txt，
     保证升级上来的设备沙箱也干净；
   · SystemCalendarMirror 删掉 dumpDiagnosis 整个方法（不再导出 mirror_diag.txt），
     连带去掉已无引用的 fs 依赖；
   · SettingsPage「清理残留镜像账户」提示语由"见同步日志"改为"见下方"（清单本就在页面上）。

2) 镜像防护：系统日历清单为 0 时跳过创建
   · 依据：2026-10-16 07:55:00 日志 `系统日历账户清单（共 0）` →
     `镜像完成：本=0 … 失败=12`，12 个 bookId 连续 `201 CreateCalendar failed!`。
   · 真因：设备重启后尚未解锁（direct boot），日历数据在加密存储里读不到，
     getAllCalendars() 返回空列表 ⇒ createCalendar 必然失败，还可能留下半创建账户。
   · 正常设备至少有一个本机日历，故"清单为 0"只可能是服务未就绪 ⇒ syncNow()
     在 plan/syncBook 之前直接跳过本轮，等解锁后的下一次同步自然恢复。

3) 前台自动同步默认间隔 1 分钟 → 15 分钟
   · 依据：2026-10-16 17:16–17:20 日志，5 分钟内连跑 5 轮
     "12 本全量比对 + 出站镜像 + 提醒刷新"，随后
     `17:20:43 短时任务超时（配额用尽），后台同步将被挂起`
     —— 前台把短时任务配额烧光，反而拖垮了真正的后台同步通道。
   · 设备 preferences 里并无 sync_interval_minutes 键 ⇒ 走的就是这个默认值。
   · AppSettings.getSyncIntervalMinutes 默认值 + Index.startAutoSync 的
     setOrCreate 与 ?? 兜底 + SettingsPage 的 @State 初值，四处一并改为 15。
   · 用户仍可在设置页选 1/5/15/30 分钟 或 1 小时。

验证：assembleHap 与 assembleApp 均 BUILD SUCCESSFUL。
 2026-10-16 19:38:21 +08:00
laoyang 24d8117ce7 v51c 卡片后台同步：修复"每轮全量重拉"，单账号 236 秒 → 10 秒 
真机实测根因：服务端 CalDav.php:253 用 preg_replace('/[^A-Za-z0-9._-]/','_',$uid)
派生资源文件名（UID movie-188@familybook → 资源 movie-188_familybook.ics），
而客户端 SyncEngine.syncAccountInner 拿 REPORT 给的**资源名当 uid** 去本地行里查
⇒ byUid 永远查不到 ⇒ 每轮判"变了" ⇒ 全量 GET。ETag 明明一样，比较压根执行不到。

改动：
· SyncEngine —— 加 byEtag 兜底（uid 查不到就用内容哈希认领本地行）+ 复用判定计数日志
  （uid 命中 / etag 兜底命中 / 需补拉）；抽 groupPush() 去重。
· EventDb.applyRemote —— existing.find() 的 O(n·m) → keyed.get() 的 O(n)。
· BackgroundSyncRunner —— runOnce 每阶段计时（+Xms）+ pid；预算可由 preferences
  card_budget_ms 覆盖（诊断开关，默认走内置 9 秒）。
· AppSettings —— getCardBudgetMs()。
· EntryFormAbility —— onUpdateForm 日志带 pid。
· MirrorInbound —— 顺带修一个已死的功能：getEvents(undefined, 字段) 在 7.0.0.109 上
  必抛 401 type error!，导致**入站对账 12/12 全失败**；改成"先无参、失败再带字段"
  （照抄 SystemCalendarMirror.queryEvents 的绕法）。

真机验证（DEL-AL20，卡片 onUpdateForm 触发，卡片进程 pid=27411）：
  [21:33:06] 卡片驱动同步：开始（可用窗口 9 秒）
  [21:33:09] 「观影」复用判定：uid 命中 0、etag 兜底命中 193、需补拉 0（共 193）
  [21:33:09] 「观影」落库完成：不变193，耗时 1 秒     ← 修复前 124 秒
  [21:33:17] 同步账号完成：拉取 2182 条，耗时 10 秒   ← 修复前 215~236 秒
  [21:33:22] 后台同步[cardTick] 完成：1/1 个账号，总耗时 16 秒
12 个日历本全部跑完 + 出站镜像，9 秒窗口不再"连第一个本都过不去"。

复算（真库快照 + 真服务器 PROPFIND，_tooling/_sc_etag_sim.py）：
  旧逻辑补拉 1384 个 → 新逻辑 80 个（降 94.2%）；观影 193→0、旅行 23→0、工作 362→5。
  另证服务端 ETag == md5(正文)、三次 PROPFIND 逐字节一致 ⇒ etag 兜底语义正确、非碰巧。
 2026-10-15 21:39:54 +08:00
laoyang 3025f92cb6 0.0.8：借服务卡片 30 分钟刷新驱动后台同步 
用户反馈"基本不会定期同步，每次都要手动点进去才同步"。
诊断发现主因是「后台自动同步」默认关闭（workScheduler 2 小时兜底根本没注册），
且系统对普通应用后台频率有硬管控（活跃分组下限 2 小时）。

本提交新增一条**免权限、约 30 分钟一次**的定期同步路径：
利用服务卡片已有的定时刷新（form_config.json 的 updateDuration=1，**单位 30 分钟**，
系统每 30 分钟调用一次 onUpdateForm），在该回调里顺带跑一次后台同步。

改动：
1. AppSettings 新增 `card_sync_at`（上次卡片驱动同步时间戳，用于节流）。
2. BackgroundSyncRunner 新增 `runOnceThrottledByCard(context)`：
   · 节流 CARD_MIN_GAP_MS = 25 分钟（略小于 30 分钟卡片周期，避免系统刷新漂移被误跳过）；
   · **先写时间戳再执行** → 防止同步期间卡片再次刷新导致并发重入；
   · 复用现有 `runOnce(context,'cardTick')`（完整同步：入站对账→推送→拉取→镜像→刷新卡片与提醒）；
   · **永不抛错**（后台路径没有 UI 承担异常）。
3. EntryFormAbility.onUpdateForm：
   · ① 先用**本地缓存**立刻刷卡片（毫秒级，不依赖网络）；
   · ② 再跑节流同步，完成后二次推卡片数据，让卡片显示刚同步回来的结果。

⚠️ 关键约束（官方 FormExtensionAbility 生命周期原文）：
  "FormExtensionAbility 进程不能常驻后台，生命周期回调中无法处理长时间的任务，
   生命周期调度完成后会继续存在 **10 秒**……可能需要 10 秒以上才能完成的业务逻辑，
   建议拉起主应用进行处理。"
  ⇒ 同步**可能被进程回收中断**，故：
    · 设 **9 秒软超时**主动收手（干净放弃而非被硬杀在半途）；
    · 语义明确为"**尽力而为地提高后台同步频率**"，不承诺 30 分钟必然成功；
    · 中断安全：同步幂等（etag 增量比对 + dirty 标记），中断不损坏数据，
      下个周期会重试；正常网络下增量同步通常数秒内完成，落在窗口内；
    · **不采用"拉起主应用同步"** —— 那会每 30 分钟弹出一次界面，体验不可接受。

配额核算：卡片定时刷新官方上限为**每张卡片每天 50 次**；30 分钟一次 = 48 次/天，
**不超配额**。相比 workScheduler（受活跃分组压制到 ≥2 小时），频率提升约 4 倍。

验证：编译通过（BUILD SUCCESSFUL）；节流逻辑离线用例通过
（从未同步/30 分钟/26 分钟/正好 25 分钟 → 执行；24/5/1 分钟 → 跳过）。
 2026-10-14 16:42:04 +08:00
laoyang a49e7d03b1 0.0.8：系统日历账户显示名可切换 + 清理判定改为 bookId 身份校验 
背景：应用往系统日历写数据时，账户显示名固定为「同步日历 · <本名>」。多账号用户
无法看出某个日历本属于哪个账号；若把"应用名+账号名"都写上又太长，本名被挤压看不清。
方案见《镜像账户命名方案-去掉应用名前缀.md》，影响评估见《0.0.8升级影响评估.md》。

平台硬约束（已核实 @ohos.calendarManager）：
  **没有"修改账户"的 API**（只有 create/delete/get/getAll；CalendarConfig 仅
  enableReminder+color；CalendarAccount.name 为 readonly）→ displayName 只能在
  创建时定，改名必须"删账户 → 重建"。

实现：
1. **三种显示名格式**（分隔符统一半角点 `·` U+00B7、**无空格**）：
     1 = `同步日历·<本名>`
     2 = `同步日历·<账号>·<本名>`
     3 = `<账号>·<本名>`  ★默认
   ⚠️ **不提供"仅本名"**：裸本名与用户原有同名日历本无法区分 → 有误删风险；
      每个镜像账户名必须至少带一个归属标识（同步日历/账号名/二者）。
   displayName 上限 64 字符 → 超长自动截断。
2. ⭐ **一键重命名** `MirrorRenamer.reapplyDisplayNames`，顺序**不可调换**：
     ① `MirrorInbound.reconcile()` 先回读（把用户在系统日历里手动新建/改动的
        收进本地库并置 dirty）—— 因为 deleteCalendar 会删掉账户下**所有**日程，
        含用户手动加的，不回读就会丢数据；回读失败则**中止**重命名（宁可不改）。
     ② `removeAccountsByBookIds` 删旧账户（按 bookId 精确定位，与名字无关；
        含"清空日程后重试"降级）
     ③ `syncNow()` 按新格式重建并全量写回
   独立成模块的原因：MirrorInbound 已 import SystemCalendarMirror，反向 import 会成环。
3. ⭐⭐ **清理判定改为「bookId 身份校验」**（`isOurMirrorAccount`）—— 用户指出的关键改进：
     **两道闸**：① name 必须以 `synccalendar.mirror.` 开头（挡掉别人家的账户）；
     ② 从 name 切出 `accId`（取最后一个 `-` 之前）并确认在账号库中。
     ⭐ **附加安全阀**：账号库读不到 → **一律不认为是我们的**（宁可不清，不可误删）。
     `displayName` 兜底**降级为仅格式 1/2 可用**（格式 3 = `账号·本名` 与别的 App
     账户可能同名，参与兜底会误删）。
     ⇒ **删不删看 accId 是不是我们的；名字只用来显示。** 判定与名字彻底解耦。
4. `AppSettings` 新增 `mirror_display_format`（1|2|3，默认 3；非法值回落 3）。
5. 设置页新增「系统日历中的显示名称」：三种格式胶囊选择 + **用真实账号名/本名实时预览**
   + 「应用」按钮（未变化时禁用、失败自动回滚选项）+ 检测到旧格式时的弱提示
   + 说明"期间日程会短暂消失几秒"。
6. `ensureCalendar` 按格式创建（已有账户**不在此处改名** —— 改名是破坏性操作，
   必须由用户显式点「应用」触发）；`syncBook` 增加 format 参数并逐层传递。
7. `describeCal` / `purgeOrphans` 参数语义更新（aggressive → allowDisplayMark）。

**不做自动迁移**（用户决定）：升级后老账户名字不变、日程不动，用户想换才在设置页点。
理由：自动迁移期间日程会短暂消失，老用户可能正在开会/开车，看到"日程全没了"会惊慌；
且默认格式是主观偏好，强改所有人等于替用户做决定。

验证：
- 编译通过（BUILD SUCCESSFUL）；包内版本 800/0.0.8。
- 离线用例覆盖：三种格式生成（确认半角点、无空格）、64 字符截断、
  身份判定五种情形（含"别的 App 同名账户不被删""accId 失效的孤儿仍被清"
  "读不到账号时一律不删""格式 3 兜底失效"）—— **全部通过**。
- 手机未连接 → 未装机（待用户插线后安装测试）。
 2026-10-14 10:09:48 +08:00
laoyang 736a0a6587 新增系统日历镜像功能，镜像与备份目标统一改用 bookId；修复重复日程覆盖行、备份目标随勾选漂移等一批问题 
- 新增 SystemCalendarMirror / MirrorSnapshot / MirrorInbound：把选定的 CalDAV 日历本镜像写入系统日历（供小艺、桌面日历卡片、手表可见），并做入站对账，区分"自己写入的 / 用户改的 / 用户删的 / 用户新建的"，镜像标识一律用稳定的 bookId（accId-href哈希），不再用会随勾选顺序漂移的 calKey
- 后台同步接入镜像：同步前先做入站对账、同步后自动出站镜像，无需用户手动触发
- 系统日历备份目标改用 bookId：当用户取消同步某个日历本导致目标失效时，自动清空目标并把模式回退为"仅显示"；开启备份必须先选定目标本，不再自动挑第一个本
- EventDb：覆盖行保留 RECURRENCE-ID，排除主事件对应发生改用 overrideKey(calKey, uid, recurrenceId, startTime)，修复重复日程出现"幽灵条目"的问题
- 新增 WRITE_CALENDAR 权限声明及其用途说明；添加日历不再出现"本机"，日历本对齐显示；版本升至 0.0.3(300)
 2026-09-19 23:07:03 +08:00
laoyang 353473127a 应用在首次打开或运行中，在用户未主动点击权限对应的相关功能或服务时，提前向用户弹窗申请开启【读取全部日程】权限，不符合相关法律法规要求。该问题已被修复。 
Signed-off-by: laoyang <laoyang@example.com>
 2026-09-16 20:54:41 +08:00
laoyang 2173b06b43 新增了列表显示模式，用户可以在设置中进行选择。 
Signed-off-by: Yang Yongquan <i@yangyq.net>
 2026-09-16 10:07:57 +08:00
laoyang 7216024204 更改设置中软件特性和用户帮助为链接形式。 
Signed-off-by: Yang Yongquan <i@yangyq.net>
 2026-09-15 16:09:34 +08:00
laoyang 7cf9203ec3 修改了用户协议等打开方式。 
Signed-off-by: Yang Yongquan <i@yangyq.net>
 2026-09-15 15:07:42 +08:00
laoyang 088f7b3773 增加了用户隐私协议等，增加了引导卡片。 
Signed-off-by: Yang Yongquan <i@yangyq.net>
 2026-09-15 09:06:15 +08:00
laoyang c04a9a28cf 更改了日程的样式显示，现在按照时间轴显示。 
Signed-off-by: Yang Yongquan <i@yangyq.net>
 2026-09-14 21:28:51 +08:00
laoyang 5b6be08d9a 完成了用户账户加密，更改了只读日程的显示样式；日程中的地址，可以通过高德地图导航了。 2026-09-14 07:55:52 +08:00
laoyang 6899a5074b 修改了通知相关的功能，能够正常通知了。 2026-09-13 23:35:52 +08:00
laoyang d9c212785d 新增了提醒静音功能，可以在设置中关闭某个日历本的提醒。 2026-09-13 21:56:51 +08:00
laoyang 0fef40c7f3 修复了部分日程没有提醒时间的问题。 2026-09-13 21:50:28 +08:00
laoyang 04fdf3d386 1.增加了重力感应，也就是横屏响应式布局。 
2.修改了沉浸式布局。
3.修改了添加日程和编辑日程页面，增加了重复、提醒等功能。
4.修改了权限问题，如果日历本是只读，则有删除线做标识。同时，对于只读的日程，点击后将不再进入编辑页面，而是展示详情。
5.系统日历的处理。给用户两个选择，第一个选择就是只显示系统日历。第二种选择，用户可以选择一个caldav账户中的某一个日历本，把系统日历中的日程，包括日历日程和应用创建的日程，都读取出来，然后加入到这个日历本下，最后同步到caldav的服务器上，这样的好处是，手机丢失了，或者换了手机品牌型号，手机上的日程仍然在自己的caldav服务器上有一个备份。当然，系统日历中的caldav日历，就不会再读取了。
 2026-09-13 20:25:18 +08:00
laoyang e27c8c36d7 添加了后台同步功能，应用置于后台，仍然可以进行同步。 2026-09-13 16:33:53 +08:00
laoyang bbb3ec5334 首次提交：SyncCalendar 项目 2026-09-13 15:50:37 +08:00