懒熊闹钟已经在华为应用市场上线了。
它最初的想法很简单：普通闹钟太容易被人在半睡半醒时顺手关掉，能不能把"关闭闹钟"变成一个需要真正完成的动作。用户可以预先设置计算、记忆、手势、运动、朗读、扫码等任务，闹钟响起后，只有完成任务，关闭按钮才会生效。
真正开始开发后，我发现最难的并不是任务有多少种，也不是响铃页做成什么样，而是怎样让一个第三方应用在系统的生命周期约束下，尽可能可靠地把用户从"收到提醒"带到"完成任务"。
这里有一个绕不开的平台背景：在当前 HarmonyOS 面向第三方应用开放的能力里，我没有找到类似 iOS AlarmKit 的专用闹钟框架。
iOS 和 iPadOS 26 的 AlarmKit 提供的是系统级闹钟语义。应用通过 AlarmManager 创建一次性或重复闹钟，系统管理授权、计划、提醒中、贪睡、停止和取消等状态，还提供锁屏、灵动岛、待机显示与 Apple Watch 上的系统提醒界面。它的告警可以在需要时突破静音和专注模式。开发者面对的是一个由系统管理生命周期的"闹钟对象"。
HarmonyOS 当前提供给第三方应用的对应入口，是 Background Tasks Kit 中的后台代理提醒。它可以在应用被冻结或进程结束后，替应用按时发出通知和铃声，但核心仍是"系统代理的一条定时通知"。文档中虽然存在 maxScreenWantAgent，看起来可以在提醒到达时拉起全屏 Ability，但官方 API 参考明确标注它是预留接口、暂不支持使用。实际在 Mate 60 上配置这个字段后，锁屏到点也没有自动亮屏或进入全屏响铃页。
所以从平台原生能力看，单独发布一条代理提醒，得到的更像一个"通知式闹钟"，而不是拥有完整响铃界面和状态机的真正闹钟。懒熊闹钟真正要解决的问题，就是怎样在这个基础上补齐通知触达、全屏入口、声音接力、误触恢复、任务会话和后台续响，拼出一条更接近真实闹钟的产品链路。
应用在前台、后台、进程被清理、手机锁屏，声音的所有者都可能不同。用户点击通知、按音量键或电源键、把应用划走，也会改变当前链路。只写一个定时器，到点后创建播放器，在最理想的演示路径里可以工作，但它不是一个可靠的闹钟方案。
这篇文章不贴具体代码，主要整理懒熊闹钟怎样从一条代理通知出发，逐步补出系统响铃、任务关闭、五次提醒和后台续响，以及怎样把 Sensor Service Kit、Core Speech Kit、Scan Kit、Camera Kit 等系统能力变成真正和起床场景有关的玩法。
图 1：懒熊闹钟宣传详情
HarmonyOS 提供的不是 Alarm Kit，而是代理提醒
普通应用不能假设自己会一直活着。退到后台后，进程可能被冻结，也可能被系统终止；用户还可能从最近任务中划掉应用。此时应用里的普通定时器和页面生命周期都不再可靠。
应用把闹钟计划发布给后台代理提醒，系统负责在目标时间触发通知和铃声。即使应用退到后台或进程已经结束，计划仍然由系统服务持有。这解决了"应用不活着时，谁负责计时"的问题，却没有自动解决"用户看到什么、怎样进入响铃页、声音如何不断、什么时候才算真正结束"。
| 能力 | iOS / iPadOS 26 AlarmKit | HarmonyOS 后台代理提醒 |
| 系统抽象 | 系统管理的闹钟和计时器 | 系统代理的定时提醒通知 |
| 生命周期 | 计划、提醒中、贪睡、暂停、恢复、停止、取消 | 发布、更新、取消提醒；业务会话由应用补充 |
| 系统展示 | 锁屏、灵动岛、待机显示、Apple Watch 等告警展示 | Notification Kit 通知；样式和入口受通知策略约束 |
| 静音与专注模式 | AlarmKit 告警可以在需要时突破 | 依赖代理提醒的铃声通道和系统通知策略 |
| 自动进入应用全屏页 | 系统告警展示和自定义动作由 AlarmKit 管理 | maxScreenWantAgent 是预留接口，当前不可依赖 |
| 应用进程结束后 | 系统继续管理闹钟 | 系统继续代理已发布的提醒 |
这个对比不是为了判断哪个平台更好，而是为了确认实现起点。HarmonyOS 的代理提醒解决了"后台计时和发声"，剩余的闹钟语义需要应用自己编排。
这决定了懒熊闹钟的第一条架构原则：到点触发不能依赖应用进程，必须交给系统代理；同时不能把"系统已经发出一条通知"当成闹钟链路完成。应用还要围绕同一个 alarm ID，补齐以下五段：
• 系统代理负责应用不在时的定时触发。
• Notification Kit 提供用户可见、可点击的入口。
• 独立响铃 Ability 在用户进入后建立任务会话。
• 应用播放器和系统代理在前后台之间交接声音所有权。
• 追推与后台续响负责弥补通知被静音、应用被划走和任务尚未完成的空档。
图 2：在通知权限、代理提醒权益和设备正常工作的前提下，系统代理负责到点触达，应用响铃会话负责"怎样才允许结束"。
这里还有三个容易漏掉的前置条件。
第一，代理提醒属于受管控的开放能力。除了在工程中声明 PUBLISH_AGENT_REMINDER，还要在 AppGallery Connect 申请对应能力，重新生成包含权益的 Profile，并用它签名。这里的 Profile 是参与应用签名并承载开放能力授权信息的配置。代码编译通过不代表设备上已经具备代理提醒权限。
第二，代理提醒最终通过通知触达用户，所以还需要通知授权和合适的通知槽位（slot）。权限被关闭时，应用不能假装系统计划已经可用，需要明确提示用户去开启。
第三，系统能托管提醒，不等于第三方应用可以强制点亮设备并自动弹出全屏页。maxScreenWantAgent 在当前 SDK 中有类型声明，所以代码可以填写并通过编译；但官方文档同时明确写着"预留接口，暂不支持使用"。我们在 Mate 60 上也验证到：锁屏时声音和通知可以正常出现，却不会自动亮屏或进入全屏页。一个"字段存在但行为不可用"的 API，不能进入产品的可靠性承诺，流程仍然只能以用户点击通知正文进入任务页为基线。
这也是整条方案最不理想、却必须诚实面对的一点：应用无法保证闹钟一到点就像系统时钟那样直接占满屏幕。所谓"更真实的闹钟"，不是伪装成已经拥有这个能力，而是在可用边界内，让声音、通知和后续任务会话尽量连续。
一条铃声链路里有两个声音所有者
开发中最容易混淆的问题，是"现在到底是谁在播放声音"。
应用还没被打开时，铃声属于系统代理提醒。这个阶段最可靠，因为它不依赖应用进程，但应用无法像控制自己的播放器那样控制每一次音频状态。
用户点击通知进入响铃页后，应用获得前台焦点。此时可以用自己的 AVPlayer 播放内置铃声，接管音量变化和页面反馈。问题在于，系统铃声切到应用播放器的过程不能出现空档。
最终采用的是"前台自管、后台托管"的双层方案：
• 系统代理先负责触发和兜底。
• 应用播放器真正进入播放状态后，才取消当前系统铃声。
• 如果应用播放器启动失败，立即恢复系统代理提醒。
• 响铃页退到后台或 Ability 被销毁时，停止应用播放器，把声音所有权重新交还系统。
• 任务完成后，才同时结束当前提醒会话，并为重复闹钟安排下一次计划。
切换顺序很重要。如果先取消系统提醒，再等待应用播放器初始化，任何资源加载、音频会话或状态机错误都会制造一段完全无声的时间。正确顺序是先确认接棒者已经开始工作，再让上一层退出。
图 3：系统和应用播放器之间不是二选一，而是一次有失败回退的所有权交接。
系统按键为什么会让闹钟突然安静
早期真机测试中出现过一个很反直觉的现象：铃声正在播放，用户按音量键或电源键后，当前系统提醒可能不再出声。最开始很容易把它理解成页面调用了停止播放，沿着页面生命周期去找，结果找不到任何对应逻辑。
原因在于当时声音并不属于页面，而属于系统代理提醒。系统如何响应硬件键，是系统提醒阶段的行为，应用播放器的音量接口不会影响这一段。
进入前台后，应用可以通过 Input Kit 监听音量加减键，优先消费按键事件，并把它们映射为响铃页里的音量调整。这个监听只应在响铃 Ability 位于前台焦点时注册，离开前台就注销。否则一个为闹钟设计的特殊按键规则，可能影响应用其他页面甚至系统原有交互。
但只处理前台按键仍然不够。用户可能在通知阶段按键，应用还没有前台窗口，根本没有机会拦截。更重要的是，不同设备和系统版本对硬件键与通知铃声的组合行为可能不同。
所以后来的方案没有把希望寄托在"判断用户按了哪个键"，而是设计了独立追推。硬件键能否被识别不再决定下一次提醒是否存在。
追推不是贪睡，而是一组提前建立的独立机会
懒熊闹钟的追推目标是：闹钟已经到点，但用户还没有真正进入任务流程时，即使当前通知因为误触、系统按键或其他原因安静下来，后面仍然有独立的提醒机会。当前方案共五次提醒：T 时刻首次提醒，加上 T+1、T+2、T+3、T+4 分钟的四次追加提醒。
最先想到的是使用系统提醒里的贪睡次数和间隔。但查完文档和 SDK 后，没有证据表明音量键或电源键让通知静音时，一定会触发一次 snooze。把核心可靠性建立在这个假设上，真机行为很容易失控。
最终的做法是，在创建闹钟时直接发布这组独立提醒。它们拥有不同的系统 reminder ID 和 notification ID，但共享同一个业务 alarm ID，因此在产品上仍然属于同一次起床任务。业务 alarm ID 表示用户看到的那一个闹钟；reminder ID 用来取消某一条系统计划；notification ID 用来区分或更新通知展示。
这样设计有几个好处：
• 不需要判断当前铃声为什么停止。
• 不依赖硬件键是否会触发系统贪睡语义。
• 应用进程不在时，后续提醒仍然由系统计划持有。
• 删除、禁用、修改或完成闹钟时，可以按同一业务 ID 找到并取消整组提醒。
代价也很明确。每个闹钟会占用多个有效提醒名额，系统对普通应用的有效代理提醒数量有限，所以追推次数不能无限增加。批量发布还要具备事务思维：如果发布到第三条时失败，前两条必须清理，不能在用户界面显示创建失败后，系统里还残留两个会突然响的提醒。
跨午夜也是一个实际问题。23:58 的闹钟，第五次追推已经进入第二天。重复周期和星期值需要随日期偏移，不能只在分钟字段上机械加四。
图 4：追推只服务于"用户尚未进入任务"的阶段；一旦应用接管，后续由正常续响状态机负责。
这个边界后来还踩过一次坑。第一版追推实现中，用户已经打开任务页后，退到后台又重新发布了一整组提醒。结果"无人响应追推"和"任务未完成续响"在语义上混在一起，迟到的通知还可能重新进入当前会话。
最终采用的状态机把打开响铃页当成明确的交接点：进入任务状态后，先取消初始追推批次；后面如果应用退后台，只发布属于当前任务会话的续响批次，不再把它解释成"用户尚未响应"。当前实现中，两类批次都可以包含五条系统提醒，但业务语义和创建时机不同。任务完成是另一个终点，它负责取消续响、保存完成状态，并处理单次或重复闹钟的下一步。
| 对比项 | 初始追推 | 任务会话续响 |
| 创建时机 | 创建或更新闹钟时 | 已进入任务，随后退后台或响铃 Ability 销毁时 |
| 解决的问题 | 用户还没有进入任务，当前提醒可能被误触静音 | 用户已经进入任务，但任务尚未完成，应用不再位于前台 |
| 当前计划 | T 时刻首次提醒 + 四次每分钟追加提醒 | 约 1 秒后首次续响 + 四次每分钟追加提醒 |
| 任务进度 | 尚未建立任务会话 | 保留同一 alarm ID 下的任务会话语义 |
| 取消条件 | 用户进入响铃任务页、修改、禁用或删除闹钟 | 用户完成任务并确认关闭，或会话重新回到前台后完成声音接管 |
"必须完成任务"不等于对抗系统
产品文案里可以说"完成任务才能关闭闹钟"，实现时要把这句话拆开。
应用能控制的是自己的普通退出路径。响铃页可以屏蔽返回键，隐藏绕过任务的关闭按钮，不在通知上提供直接结束入口，并且只有任务判定完成后才开放最终关闭动作。用户按 Home 键或把应用划走时，应用会尝试把声音恢复为系统托管；恢复成功后，后续响铃不再依赖应用进程继续存活。
应用不能控制的是系统最高权限边界。用户仍然可以强制停止应用、撤销通知权限、关闭设备，或者使用系统提供的其他管理入口。第三方应用不应该尝试伪装成无法退出的系统界面，也不能承诺在关机、断电或权限被撤销后继续响铃。
这条边界反而让产品设计更清楚：目标不是"无论如何都不让用户关"，而是让半睡半醒时最常见的无意识操作不能轻易结束同一闹钟会话，同时保留系统级安全出口。
任务页还需要处理权限失败和硬件缺失。一个闹钟如果绑定了语音或运动任务，而用户在响铃时才发现麦克风权限被拒绝、设备没有对应传感器，就可能真的无法完成。懒熊闹钟在设置任务时提前申请必要权限；真正响铃时如果权限已被撤销，则把权限相关任务替换成可完成的降级任务。传感器本身不存在或启动失败时，当前实现会明确报错，这一类仍需要在产品上继续补齐不会锁死用户的统一兜底。
用鸿蒙 Kit 把"关闹钟"做成不同玩法
前面的系统代理、通知入口、声音接力和续响是在补平台闹钟语义；下面这些 Kit 玩法不是可靠性补丁，而是在闹钟链路稳定之后增加的产品差异化。
任务系统没有把每种玩法都写进响铃页面。页面只负责当前任务进度和会话状态，具体能力由各自的任务组件与服务负责。这样增加一种传感器玩法时，不需要碰系统提醒和铃声接管这条高风险链路。
目前的任务按脑力、触控、运动、语音和实景分组。真正有鸿蒙设备感的部分，主要来自几类 Kit。
Sensor Service Kit：让身体动作成为输入
图 5：同一套传感器数据可以组合成摇动、翻面、端平、转向、接近、计步和举高等不同任务。
加速度、线性加速度、重力、方向、接近、环境光和计步数据，可以组合成完全不同的任务。
线性加速度适合识别有效摇动；重力向量可以判断手机翻面、保持水平，也可以驱动一个倾斜迷宫；方向数据可以要求用户按随机顺序转向；接近传感器能实现"捂住再放开"；环境光可以要求用户走到明亮处；计步器则直接把"下床走几步"变成完成条件。举高手机、深蹲等动作，可以从连续加速度的阶段变化中识别，而不是只看某一次瞬时值。
这里最重要的不是调用 sensor.on，而是判定算法。真实传感器有噪声，用户动作也不会完全标准。开发时需要设置阈值、去抖、冷却时间和状态转换。例如"捂住再放开"必须看到一次接近到远离的完整转换，不能把连续上报的十个接近值算成十次；摇动也要有最小间隔，避免一次动作被重复计数。
设备差异同样要提前处理。启动任务前先查询传感器是否存在，计步能力可以在步数累计传感器和单步检测传感器之间选择。页面退出、任务完成和异常时都要取消订阅，否则下一次进入会出现重复回调，后台也会继续消耗资源。
Core Speech Kit 与 Audio Kit：让"出声"成为任务
语音识别可以支持完整朗读、记忆复述、验证码复述、连续倒数、绕口令和语音口算。这里不能把一次识别回调当成任务完成。流式识别会分段返回，语音片段结束也不代表用户已经读完整段内容。需要在任务层累积文本，再按顺序、完整度和具体规则判断。
Audio Kit 则适合做不关心文字内容的任务，例如达到一定音量、复现拍手节奏、听音计数。采集原始音频后可以计算短时能量和峰值，识别一次有效拍手，但仍然需要峰值间隔和环境噪声阈值。
这类任务都依赖麦克风权限，也可能和其他音频业务发生资源竞争。权限应该在用户选择任务时就说明用途，响铃时再次检查；无法启动采集时必须有替代路径。
Scan Kit、Camera Kit 与文字识别：把人带到真实空间
扫码任务的价值不是"展示一下扫码能力"，而是让用户提前登记一个真实物品，例如洗手间或厨房里的商品条码。闹钟响起后，必须走到那个位置并扫到同一条码，才能完成任务。
OCR 文字卡也是同样思路。用户预先登记一段文字，响铃时通过 Camera Kit 调起拍摄，再用文字识别判断画面中是否包含目标内容。它比普通选择题更难在床上闭眼完成，但也带来了相机可用性、识别超时、光线不足和服务异常等边界。
这类"实景任务"需要把注册和执行设计成两个阶段。只在响铃时让用户输入一个目标没有意义；设置闹钟时就要完成登记、去重和试扫，确保第二天真的有可识别对象。
振动与触觉反馈：把提示变成节奏
振动不仅可以作为铃声的补充，也能成为任务本身。系统按随机节奏振动，用户在屏幕上复现；或者在触控任务完成关键一步时，用不同触觉反馈提示正确、错误和阶段结束。
设计这类玩法时要避免把振动当成单纯装饰。节奏长度、间隔和重复次数需要让刚醒的人能够分辨，同时不能因为触觉反馈太密集影响铃声和页面操作。
任务越多，越需要保持同一个会话模型
任务系统后来扩展到计算、闪记、五子棋残局、24 点、舒尔特方格、色词冲突、拖拽排序、方向手势、运动、朗读、扫码和 OCR 等多种玩法。数量增加后，最危险的做法是让每个任务自己决定什么时候关闭闹钟。
懒熊闹钟把任务完成和闹钟结束分成两层。任务只上报自己的进度和完成结果；任务编排层决定一组任务是否全部完成；响铃页最后调用统一的结束动作。系统提醒、重复周期和页面销毁只由外层会话处理。
这样做还有一个好处：一个闹钟可以串联最多五项任务，任务顺序和难度属于配置，提醒系统只认识 alarm ID，不需要知道当前正在做计算还是扫码。新增玩法时，稳定的闹钟核心可以保持不动。
产品上也不应该只追求"难"。刚醒时的认知和动作能力都有限。好的任务应该有清晰目标、即时进度和有限失败成本。运动任务要避免鼓励危险动作，语音任务要考虑安静环境，实景任务要提供权限或硬件不可用时的降级。让用户清醒，比让用户挫败更重要。
几个实际踩过的坑
发布成功不等于闹钟已经可靠
publishReminder 返回 reminder ID，只能说明系统接受了这条计划。它不能证明通知授权还在、签名 Profile 包含开放能力、目标设备会按预期展示通知，也不能证明锁屏、退后台和杀进程后的整条路径。
本地业务记录必须保存系统 reminder ID。修改、删除、禁用和完成闹钟时，都要同步取消系统计划。后来加入追推后，一个闹钟对应的不再是单个 ID，而是一组 ID；旧数据仍可能只有单个字段，因此读取时还要把旧 ID 合并进新结构。
通知被点击后，原铃声可能已经结束
用户点击通知正文进入应用，并不意味着原来的系统铃声会继续陪着任务页。最小版本里，通知跳转后需要立刻建立新的系统续响提醒；后来增加应用播放器后，也必须等播放器真正开始，再取消系统阶段。
这是一个典型的"页面已经打开，但业务闭环断了"的问题。只验证路由跳转，会误以为功能已经完成。
同一个闹钟的多个提醒不能只取消第一个
追推引入多个 reminder ID 后，所有关闭路径都要按整组处理。创建失败要回滚整组，编辑要先建立新计划再取消旧计划，删除和任务完成要尽量取消每一个 ID。
取消过程中某一个 ID 已经过期或不存在，不应该阻止后面的 ID 继续取消。否则列表看起来已经关闭，几分钟后残留提醒仍可能响起。
迟到的 Want 会制造生命周期竞态
几条追推通知可能在很接近的时间送达。HarmonyOS 用 Want 携带一次页面拉起所需的目标和参数；如果同一个响铃 Ability 已经存在，后续通知可能不再创建新实例，而是通过 onNewWant 把新参数交给旧实例。如果每次收到 Want 都重置"未完成"状态，任务刚结束，迟到的通知又可能把会话重新拉回响铃。
因此会话需要明确的 alarm ID、完成标志和序列化的恢复操作。来自其他闹钟的重叠触发也不能直接覆盖当前会话，应按产品规则结束、合并或延后处理。
编译、安装、启动和真机行为是四件事
这次开发中，"已经完成"也曾被说得太早。构建成功只说明工程能打包；安装成功只说明签名 HAP 能进入设备；启动成功只说明 Ability 能拉起。闹钟是否真的可靠，要等真实时间触发，并操作音量键、电源键、锁屏、Home、最近任务和任务完成路径。
后来固定了一组真机检查：
| 场景 | 需要确认的结果 |
| 应用在前台到点 | 直接进入响铃会话，声音正常 |
| 应用在后台到点 | 系统通知与铃声出现 |
| 从最近任务清除后到点 | 仍由系统代理触发 |
| 锁屏到点 | 能听到声音并看到通知；不假设自动全屏 |
| 按音量键或电源键 | 当前声音变化后，后续追推仍存在 |
| 点击通知进入任务 | 初始追推取消，应用或续响链路接管 |
| 任务中按 Home 或划走应用 | 系统恢复续响，再次点击可回到同一会话 |
| 完成全部任务 | 声音和本次全部提醒停止 |
| 重复闹钟完成 | 本次结束，并正确安排下个周期 |
| 23:58 等跨日时间 | 追推日期和重复星期正确偏移 |
这张表比"测试一下闹钟"更有用。闹钟问题通常不在主路径，而在所有权切换的缝隙里。
AI 参与开发时，先找能力所有者
这个项目继续使用了上一款鸿蒙应用中形成的方法：先查官方文档、本地官方示例和当前 SDK 声明，再让 AI 回到工程里找真正的责任模块。
代理提醒先对照 Background Tasks Kit 的 ReminderAgentManager 示例；音量键先看 Input Kit 的按键优先响应；传感器任务对照 Sensor Service Kit 的订阅和取消；扫码、相机、语音分别从对应 Kit 的示例确认对象和生命周期。
AI 在这类问题上最有价值的工作，不是一次生成整套代码，而是把日志和调用关系分层。例如铃声突然停止，先判断声音属于系统代理还是应用播放器；任务无法关闭，再区分任务判定、任务组完成、最终取消 reminder 三个阶段；后台不响，则继续拆成计划是否发布、权限是否可用、Profile 是否有权益、系统是否触发。
每次改动也尽量收窄。响铃和提醒链路稳定后，新增任务不再顺手修改 AlarmReminderService；改任务页面时，也不重写 AlarmRingAbility。高风险核心保持稳定，新的玩法从组件和服务边界向外扩展。
没有真正的 Alarm Kit，就自己补齐闹钟语义
做完这一轮后，我对闹钟产品的理解发生了一点变化。
如果平台已经提供完整 Alarm Kit，开发者主要是在系统闹钟生命周期上增加自己的产品内容。HarmonyOS 当前不是这个起点。它给第三方应用的是一条能在后台按时发声的代理提醒，剩下的闹钟语义需要自己补。
第一层是系统可靠性：应用不在时，提醒仍然能够到达。第二层是入口补偿：没有可依赖的自动全屏能力，就把通知正文设计成明确的任务入口。第三层是会话连续性：通知、页面、播放器和后台之间切换时，同一次闹钟不能被意外结束。第四层才是任务玩法：用思考、动作、语音和真实空间，把"我听见了"推进到"我已经起身并完成了一件事"。
这四层不能倒过来。任务再丰富，如果应用被清理后不响，就不是闹钟；系统通知再稳定，如果点击后立刻安静，也没有完成产品目标；技术链路都跑通后，任务如果只有惩罚感，用户仍然不会长期使用。
懒熊闹钟已经实现了从系统代理触发、通知进入任务、前后台声音接力，到任务完成后结束会话的代码链路。基础版本在 Mate 60 上验证过应用被清理后触发、通知进入任务、任务中再次清理应用后系统续响，以及完成任务后停止；五次分钟级追推、硬件键和不同锁屏状态仍应按前面的真机矩阵持续回归，不能由构建、安装或上架结果替代。
如果也在 HarmonyOS 上做闹钟、日程提醒或需要后台可靠触达的工具，我最想分享的一条经验是：不要因为 ReminderRequest 的类型名称里有 Alarm，就默认自己已经获得了完整闹钟能力。先确认系统真正提供的是定时、发声、通知还是界面，再逐段补齐系统和应用之间的生命周期。很多看起来像"播放器没写好"或"通知没弹出"的问题，本质上都是把代理通知误当成了完整闹钟。
也期待 HarmonyOS 尽快推出真正面向第三方应用的 Alarm Kit，补齐系统级告警展示、锁屏入口、静音与专注模式策略，以及计划、提醒中、贪睡和停止等完整生命周期，让开发者能够把精力更多放在产品体验上，而不是继续用代理通知拼接一套"更像闹钟"的链路。
应用已经上线。如果刚好在使用鸿蒙手机，也经常在闹钟响起后顺手把它关掉，可以在华为应用市场搜索"懒熊闹钟"。
延伸阅读关键词
• Apple AlarmKit：官方文档、WWDC25：Wake up to the AlarmKit API
• Background Tasks Kit：代理提醒、reminderAgentManager
• Notification Kit：通知授权、通知槽位、提醒状态
• Input Kit：系统功能键优先响应、inputConsumer
• Sensor Service Kit：加速度、重力、方向、接近、环境光、计步与振动
• Core Speech Kit：流式语音识别
• Audio Kit：音频采集、AVPlayer 与音频流
• Scan Kit：条码扫描
• Camera Kit 与文字识别：实景任务采集和 OCR