第一次把这东西拿给身边朋友看的时候十个人里有八个问我这名字是不是有点太“地狱”了剩下两个直接笑出声。但等我把应用装到家里的安卓备用机上设好紧急联系人又连续三天没有误报之后家人沉默了一下说了一句“这玩意儿比手环靠谱。”这个项目的全称叫“死了么APP安卓版”正式一点的代号是 Keep Alive Lite。一句话解释就是一款专门为独居老人场景设计的安卓端安全监测工具免费、开源、无广告、不需要额外硬件只依赖手机本身的传感器就能完成活动检测、跌倒识别和紧急报警。很多关注居家养老的开发者、家里有独居老人的普通用户以及做社区安防产品的人都在问这个项目到底怎么用、原理是什么、能不能自己改。这篇文章我把思路、算法、踩过的坑、配置方法一次说清楚。1. 为什么做“死了么”独居老人监测的真实痛点1.1 核心需求拆解独居老人最怕的事用一句话概括就是出了事没人知道。跌倒、心梗、脑卒中很多时候不是当场致命而是摔倒后长时间无人发现错过了黄金救援时间。传统方案其实不少但都有各自的硬伤。智能手环/手表老人不愿意戴、忘充电、洗澡摘下来就再也想不起来戴数据再准也没用。家用摄像头隐私问题非常敏感很多老人强烈抵触而且需要在固定位置供电、联网覆盖只有客厅或卧室。社区紧急呼叫设备大多是固定式话机或者特定运营商设备安装成本高跨品牌联动也麻烦。人工定期电话回访频率低、成本高夜间和清晨的空白时段完全覆盖不到。我最初的思考逻辑很简单**老人可以忘记戴手环、可以讨厌摄像头但基本不会离开手机。**无论多老的人只要还能正常生活手机大概率就在身边——至少在家里时手机一定在某个固定位置。那能不能不要求老人做任何额外操作只把安卓手机变成一个“无感监测器”这就是 Keep Alive Lite 的起点。项目的核心目标被压缩成三个词无感、可靠、兜底。无感是老人完全不需要打开或操作这个APP可靠是后台不被系统杀掉、报警能送出去兜底是它解决的是“最后一个电话没打出去”的问题而不是替代医疗急救。1.2 为什么叫“死了么”和 Keep Alive Lite名字有争议但传播效果确实拉满。我当时在某个开源社区刷到一个讨论有人开玩笑说“给独居老人做个APP应该叫‘死了么’”。结果评论区一堆人真的在讨论这个需求。后来我发现真正愿意给父母装这套东西的人恰恰是平时很少跟老人聊“万一出事怎么办”这种沉重话题的子女。而这名字的自嘲和直白反而让人有勇气去面对这个隐患。正式代号 Keep Alive 是双关语一层意思是安卓开发里的“进程保活”保证APP在后台不被回收另一层意思就是最直白的“人还在还活着”——用传感器持续感知用户的“生命活力”。Lite 则代表轻量、极简、不折腾不搞云平台、不搞人脸识别、不需要额外硬件一个APK装好就能跑。这种定位决定了后续所有的技术选型都是在向“低门槛”和“高可靠”倾斜。它不追求做一个功能庞大的智能养老平台只做一件事当老人长时间没有可见活动时用几套互相冗余的机制把消息递出去。2. 核心机制拆解传感器活动检测与保活对抗2.1 加速度传感器与“无活动判断”的逻辑安卓手机里最通用、最不需要权限的传感器就是加速度计。无论几百块的低端机还是旗舰机几乎都有三轴加速度传感器。Keep Alive Lite 的活动检测完全基于它来设计。核心算法不复杂分三层采集。后台注册 SensorManager 的加速度传感器监听每隔固定时间默认10秒取一次三轴数据。为了省电实际代码里用的是系统推荐的延迟级别而不是极限频率。合成。三轴分别是x横向、y纵向、z垂直方向合加速度的计算是下面这个公式magnitude sqrt(x*x y*y z*z)静止放置时合加速度约等于重力加速度g约9.8m/s²。人正常走动、翻身、拿手机看消息时合加速度会产生明显波动。阈值判断。对当前时间窗内的合加速度做峰值统计和方差分析超过一定波动幅度就认为“有活动”。如果持续在设定的窗口期默认2小时内都没有任何一次有效活动系统就会标记为“疑似无活动”。这里有一个非常关键的设计细节**只看合加速度的大小不看具体方向。**因为不同的人放手机的方式不同——有人喜欢屏幕朝上放桌上有人放口袋里有人随手扔床上。如果对姿态变化做硬编码判断误报率会高到没法用。合加速度的波动才是普适的“活人信号”。跌倒检测则稍微复杂一点用的是经典的“冲击姿态静止”三步判断冲击合加速度瞬时超过2.5g以上比如1.5g加到3g左右时间窗口前后各取500ms姿态跌倒前后设备倾角发生大幅变化用重力分量推算俯仰角和翻滚角静止冲击发生后检测到持续20秒以上的低活动状态基本可以确认为跌倒而不是站住或者弯腰。逻辑上有三层防线实际运行中误报率还是有的特别是老人用力把手机拍在桌上、或者手机从沙发掉到地上。所以我的处理策略是**只把跌倒检测作为辅助线索不当成唯一依据。**最终兜底的其实是无活动超时判定。2.2 安卓保活与“前台服务”的实战安卓应用的保活是另一个大坑。理论上你只要用Service就能后台运行但现实是国产安卓系统普遍有激进的后台清理机制如果APP不做对抗几分钟内就会被杀掉。Keep Alive 这个名字想保住的第一条命其实就是进程的命。我在项目里采用的组合方案如下前台服务Foreground Service给Service绑定一个常驻通知栏通知让系统把进程优先级提升到“用户可见”级别。这是最基础的保活手段也是Android 8.0之后官方推荐的方式。通知栏上会显示“监测中”的状态老人或家属能直观确认APP在运行。用户引导设置白名单这是决定保活成败的关键。项目代码里做了一个“一键检测”功能会在首次启动时提示用户前往系统设置把应用加入电池优化白名单、后台运行白名单、自启动名单。不同品牌的定制系统入口不同我在源码里内置了几套常见的跳转Action。AlarmManager 定时自检即使前台服务偶尔被系统阴掉AlarmManager 的闹钟任务仍然可以在预定时间唤起应用检查监测服务是否还活着如果死了就重启。这是第二层保命网。WorkManager 兜底联动部分系统会连闹钟一起限制所以我还注册了一个周期性的 WorkManager 任务每20分钟执行一次存活检查。三个机制互相冗余实测下来绝大多数手机上能稳定运行48小时以上。这里要特别提醒**千万别用那些所谓“1像素保活”“锁屏弹Activity”之类的黑科技。**那些手段属于系统漏洞利用非常容易被安全软件标记为恶意行为用户也反感。Keep Alive Lite 走的是完全合规的路线只靠系统公开API好处是上架安全、行为透明、代码可审计坏处是必须“求用户配合”做白名单设置。为了保证这一点首次启用时的引导做得比较啰嗦但也只能这么做。3. 报警链路设计从本地提醒到紧急联系人的闭环3.1 三级确认报警机制如果检测到“长时间无活动”直接狂打电话或者发短信是不现实的。老人可能只是在午睡、在浴室没带手机、或者手机落在阳台了。所以 Keep Alive Lite 的报警设计必须是分级的。整个流程是三级递进的本地提醒。默认在“疑似无活动”时间点例如连续2小时无活动触发手机最大音量播放一段指定铃声同时持续震动。这是给老人本人的最后确认机会——如果人没事按一下“我没事”按钮就会取消警报并且重新计时。短信通知。如果本地提醒发出后20分钟内没有任何确认APP自动给预设的紧急联系人发送一条短信内容大致是“您关注的设备手机名/号码已连续X小时无活动可能发生意外请尽快联系确认。”这条短信会附带当前基站定位的粗略位置方便家属快速判断。持续升级。短信发出后再等待15分钟如果依然没有确认系统会再次向紧急联系人发送短信并且每隔30分钟自动补发一条。如果到了第三轮仍然无确认APP才会尝试直接呼叫紧急联系人——因为语音通话权在用户侧更敏感所以呼叫之前会先弹窗确认一次防止误报导致骚扰。这个“先响铃、再短信、最后电话”的三级链路核心目的是平衡“救急”和“误报”。我实测过午睡两小时不碰手机是很多人正常的休息节奏如果直接打电话一中午能打好几个家属和老人都会被折磨疯。有了20分钟的本地确认缓冲期大部分误报在第一步就消化掉了。3.2 短息发送、定位与隐私边界短信发送用的是安卓系统的SmsManager。这个方案在技术实现上最直接不依赖任何第三方云服务但有个现实麻烦**安卓系统对短信权限的管控越来越严。**从 Android 4.4 开始只有默认短信应用才能直接写短信数据库从 Android 10 开始SEND_SMS权限被列入高风险权限应用商店审核也会重点审查。所以我在应用里做的是“双通道”优先直接发短信如果系统限制导致失败就通过系统自带的Intent.ACTION_SENDTO唤起短信编辑界面把内容预填好让用户按一下发送键。这个降级方案牺牲了一点“全自动”但保住了兼容性和应用商店上架资格。对真正独居老人的使用场景来说这一步手动发送的接受度是OK的——因为按键的是家属而不是老人家属愿意配合。隐私方面我把隐私设计原则写进了项目文档的第一页**默认不联网、数据不上传。**所有活动数据、报警记录、位置信息只存在手机本地SQLite数据库里。只有触发报警时才会申请发送短信位置信息只取基站定位不需要GPS权限只需要粗略定位权限而且只挂在短信正文里。整条链路没有云服务器、没有统计分析SDK对这类敏感场景来说这反而是最大的卖点。4. 安装部署与配置指南4.1 从源码到APK开箱即用的构建流程这个项目完全开源代码托管在公开的代码托管平台上仓库名就叫 keep-alive-lite。整个应用是用 Kotlin 写的基于 Gradle 构建工程结构非常常规。如果你只是想拿来用可以直接在开源页面下载我打包好的 release APK如果你想自己改功能也可以完整编译一遍。编译需要准备的东西不多Android Studio建议最新稳定版JDK 11 或以上一个安卓 SDK项目最低编译版本是 Android 8.0对应 API 26。在 Android Studio 里打开工程后直接选Build Build APK(s)等待 Gradle 同步和编译完成就能在输出目录找到安装包。整个项目没有引入任何第三方付费SDK依赖列表里只有安卓官方库和几个常见工具库。第一编译时间通常3-5分钟改代码后增量编译基本几十秒门槛比较低。4.2 配置文件与关键参数运行之后设置入口在主界面的齿轮图标里。这里把几个关键参数列出来对排查问题很有帮助参数默认值说明无活动判定时间120分钟连续无有效活动的最长时间建议按老人作息调整本地提醒持续时间20分钟本地响铃震动后等待确认的时长太短容易误报短信重发间隔30分钟报警短信的最短重复周期紧急联系人最多3个按优先级顺序发送可配置多个号码检测灵敏度中控制活动判定阈值高灵敏度更易判为“有活动”免打扰时段无例如晚间11点到早7点可降低检测频率避免洗澡和睡觉导致大量误报提醒铃声系统默认可自定义为更醒目的音频文件这些参数在首次启动时都会经过一次“引导检查”要求用户先做一次运动模拟比如拿着手机走几步然后把手机关屏放桌上两分钟系统会分别记录到“有活动”和“无活动”两个样例用来校准阈值。这是我后来加的功能因为不同老人的手机使用习惯差异太大固定阈值必然导致个别用户不适用。5. 踩坑实录与常见问题排查5.1 典型运行问题速查表开发过程中我踩过的坑比预想中多得多。很多问题在模拟器上根本不可能发现必须拿到真实手机、真实老年用户手里跑一段时间才会暴露。现象可能原因解决方案收不到报警短信短信权限被系统拦截手机是双卡且发送卡欠费检查权限设置切换默认发送卡改用系统短信编辑器降级方案后台运行一段时间后应用消失厂商定制系统清理了后台服务重新进入应用点击“一键优化”把电池、自启动、后台运行都设为白名单误报率偏高人明明在家却报警老人习惯把手机放在固定位置长时间不看调低灵敏度或把无活动判定时间从2小时延长到3小时再开启免打扰时段耗电异常快传感器采样频率过高定位权限过度使用把传感器采样从“最高频率”改回“标准频率”关闭GPS定位只保留基站定位本地响铃不响媒体音量过低或免打扰模式开启响铃使用AudioManager的STREAM_ALARM通道并提示用户关闭免打扰还有一个特别容易踩的坑是双卡手机。很多老人用双卡一张电话卡一张流量卡结果报警短信从流量卡发出去了流量卡没有余额短信实际发送失败。代码里我做了个处理优先使用系统默认短信卡读取 SIM1/SIM2 状态如果发现默认卡余量异常就尝试切换SIM卡发送。但注意切换SIM卡发短信这个操作在部分定制系统上不支持最后还是得靠降级方案兜底。5.2 设备适配与真实体验中的反馈在真实用户反馈中给我最大启发的是一个某社区养老项目负责人的建议。他们试用后发现很多老人会把手机放在客厅充电人在卧室睡觉。如果按我默认的“手机不动人不动”逻辑这种场景必然误报。所以后来加了“免打扰时段”和“低活动容忍”两个开关。现在的情况是晚上10点到早上8点这个时段只要合加速度方差不过分异常系统会自动把无活动判定时间放宽到4小时。另一个重要反馈来自一位家属老人的手机是低端机运行内存只有2GB系统自带应用已经占掉大半Keep Alive Lite 长期前台运行会不会卡我做了两轮优化所有界面只保留必要的布局文件主界面只有一个设置页和一个状态卡片APK体积控制在3MB左右监测服务里不持有任何Activity引用不保存历史传感器数据只在内存中保留最近10秒的窗口数据有效降低内存占用。实测2GB内存的机器上应用常驻内存约80MB通知栏显示正常后台一周没有被杀这个成绩对低端安卓机来说已经算体面了。6. 后续扩展与私人定制思路开源的好处是你不需要等我去做所有功能。项目代码结构我按模块拆得很清晰sensor包负责传感器采集alarm包负责报警逻辑config包负责参数管理notify包负责通知和短信。想做二次开发不需要读懂全部代码只改对应模块就行。我目前已经在考虑的扩展方向有三个本地AI跌倒检测。现在的三步判断法其实是“暴力的阈值方案”误报和漏报都存在。下一步计划在本地跑一个轻量级分类模型TensorFlow Lite输入是连续5秒的加速度时序数据输出是“正常/跌倒/剧烈运动”三类标签。只是模型训练缺少真实跌倒样本这块进展比较慢。语音交互确认。本地提醒响铃时老人如果行动不便可能无法点击按钮。如果能在“本地提醒”阶段加入语音识别老人说一句“我没事”就能解除警报体验会好很多。考虑到老人说话模糊离线语音识别模型的准确率还需要打磨。多设备联动与家属端看板。让家属在另一台手机上能看到老人的活动时间线这个需求咨询的人非常多。但有一个核心矛盾只要云端参与隐私边界就要重新定义。目前比较稳妥的做法是局域网内联动或者把数据加密后放在用户的家庭服务器上这条路还在设计。还有一点要说清楚Keep Alive Lite 不是也不应该替代专业医疗设备。心梗、脑卒中的监测需要心电图、血氧、血压等生理参数这不是一个普通安卓APP的传感器能完全覆盖的。这个项目的定位从来都是“最后的通信保障”——当意外发生时把发现时间从几小时缩短到几十分钟把求救消息递出去。能做到这一点价值就已经非常大了。开发这个项目我最大的体会是技术本身并不复杂复杂的是对人生活习惯的理解和尊重。一个监测工具如果不尊重老人午睡的习惯、不尊重他们对隐私的敏感、不尊重低端手机的性能限制技术做得再花哨也落不了地。开源之后陆续收到一些用户反馈说“装了之后家里老人并没有觉得被打扰反而有时候忘记放手机充电听到提醒还会觉得蛮温暖”。这种反馈让我觉得做这样一个不智能但诚实的工具是对的。
第一次把这东西拿给身边朋友看的时候十个人里有八个问我这名字是不是有点太“地狱”了剩下两个直接笑出声。但等我把应用装到家里的安卓备用机上设好紧急联系人又连续三天没有误报之后家人沉默了一下说了一句“这玩意儿比手环靠谱。”这个项目的全称叫“死了么APP安卓版”正式一点的代号是 Keep Alive Lite。一句话解释就是一款专门为独居老人场景设计的安卓端安全监测工具免费、开源、无广告、不需要额外硬件只依赖手机本身的传感器就能完成活动检测、跌倒识别和紧急报警。很多关注居家养老的开发者、家里有独居老人的普通用户以及做社区安防产品的人都在问这个项目到底怎么用、原理是什么、能不能自己改。这篇文章我把思路、算法、踩过的坑、配置方法一次说清楚。1. 为什么做“死了么”独居老人监测的真实痛点1.1 核心需求拆解独居老人最怕的事用一句话概括就是出了事没人知道。跌倒、心梗、脑卒中很多时候不是当场致命而是摔倒后长时间无人发现错过了黄金救援时间。传统方案其实不少但都有各自的硬伤。智能手环/手表老人不愿意戴、忘充电、洗澡摘下来就再也想不起来戴数据再准也没用。家用摄像头隐私问题非常敏感很多老人强烈抵触而且需要在固定位置供电、联网覆盖只有客厅或卧室。社区紧急呼叫设备大多是固定式话机或者特定运营商设备安装成本高跨品牌联动也麻烦。人工定期电话回访频率低、成本高夜间和清晨的空白时段完全覆盖不到。我最初的思考逻辑很简单**老人可以忘记戴手环、可以讨厌摄像头但基本不会离开手机。**无论多老的人只要还能正常生活手机大概率就在身边——至少在家里时手机一定在某个固定位置。那能不能不要求老人做任何额外操作只把安卓手机变成一个“无感监测器”这就是 Keep Alive Lite 的起点。项目的核心目标被压缩成三个词无感、可靠、兜底。无感是老人完全不需要打开或操作这个APP可靠是后台不被系统杀掉、报警能送出去兜底是它解决的是“最后一个电话没打出去”的问题而不是替代医疗急救。1.2 为什么叫“死了么”和 Keep Alive Lite名字有争议但传播效果确实拉满。我当时在某个开源社区刷到一个讨论有人开玩笑说“给独居老人做个APP应该叫‘死了么’”。结果评论区一堆人真的在讨论这个需求。后来我发现真正愿意给父母装这套东西的人恰恰是平时很少跟老人聊“万一出事怎么办”这种沉重话题的子女。而这名字的自嘲和直白反而让人有勇气去面对这个隐患。正式代号 Keep Alive 是双关语一层意思是安卓开发里的“进程保活”保证APP在后台不被回收另一层意思就是最直白的“人还在还活着”——用传感器持续感知用户的“生命活力”。Lite 则代表轻量、极简、不折腾不搞云平台、不搞人脸识别、不需要额外硬件一个APK装好就能跑。这种定位决定了后续所有的技术选型都是在向“低门槛”和“高可靠”倾斜。它不追求做一个功能庞大的智能养老平台只做一件事当老人长时间没有可见活动时用几套互相冗余的机制把消息递出去。2. 核心机制拆解传感器活动检测与保活对抗2.1 加速度传感器与“无活动判断”的逻辑安卓手机里最通用、最不需要权限的传感器就是加速度计。无论几百块的低端机还是旗舰机几乎都有三轴加速度传感器。Keep Alive Lite 的活动检测完全基于它来设计。核心算法不复杂分三层采集。后台注册 SensorManager 的加速度传感器监听每隔固定时间默认10秒取一次三轴数据。为了省电实际代码里用的是系统推荐的延迟级别而不是极限频率。合成。三轴分别是x横向、y纵向、z垂直方向合加速度的计算是下面这个公式magnitude sqrt(x*x y*y z*z)静止放置时合加速度约等于重力加速度g约9.8m/s²。人正常走动、翻身、拿手机看消息时合加速度会产生明显波动。阈值判断。对当前时间窗内的合加速度做峰值统计和方差分析超过一定波动幅度就认为“有活动”。如果持续在设定的窗口期默认2小时内都没有任何一次有效活动系统就会标记为“疑似无活动”。这里有一个非常关键的设计细节**只看合加速度的大小不看具体方向。**因为不同的人放手机的方式不同——有人喜欢屏幕朝上放桌上有人放口袋里有人随手扔床上。如果对姿态变化做硬编码判断误报率会高到没法用。合加速度的波动才是普适的“活人信号”。跌倒检测则稍微复杂一点用的是经典的“冲击姿态静止”三步判断冲击合加速度瞬时超过2.5g以上比如1.5g加到3g左右时间窗口前后各取500ms姿态跌倒前后设备倾角发生大幅变化用重力分量推算俯仰角和翻滚角静止冲击发生后检测到持续20秒以上的低活动状态基本可以确认为跌倒而不是站住或者弯腰。逻辑上有三层防线实际运行中误报率还是有的特别是老人用力把手机拍在桌上、或者手机从沙发掉到地上。所以我的处理策略是**只把跌倒检测作为辅助线索不当成唯一依据。**最终兜底的其实是无活动超时判定。2.2 安卓保活与“前台服务”的实战安卓应用的保活是另一个大坑。理论上你只要用Service就能后台运行但现实是国产安卓系统普遍有激进的后台清理机制如果APP不做对抗几分钟内就会被杀掉。Keep Alive 这个名字想保住的第一条命其实就是进程的命。我在项目里采用的组合方案如下前台服务Foreground Service给Service绑定一个常驻通知栏通知让系统把进程优先级提升到“用户可见”级别。这是最基础的保活手段也是Android 8.0之后官方推荐的方式。通知栏上会显示“监测中”的状态老人或家属能直观确认APP在运行。用户引导设置白名单这是决定保活成败的关键。项目代码里做了一个“一键检测”功能会在首次启动时提示用户前往系统设置把应用加入电池优化白名单、后台运行白名单、自启动名单。不同品牌的定制系统入口不同我在源码里内置了几套常见的跳转Action。AlarmManager 定时自检即使前台服务偶尔被系统阴掉AlarmManager 的闹钟任务仍然可以在预定时间唤起应用检查监测服务是否还活着如果死了就重启。这是第二层保命网。WorkManager 兜底联动部分系统会连闹钟一起限制所以我还注册了一个周期性的 WorkManager 任务每20分钟执行一次存活检查。三个机制互相冗余实测下来绝大多数手机上能稳定运行48小时以上。这里要特别提醒**千万别用那些所谓“1像素保活”“锁屏弹Activity”之类的黑科技。**那些手段属于系统漏洞利用非常容易被安全软件标记为恶意行为用户也反感。Keep Alive Lite 走的是完全合规的路线只靠系统公开API好处是上架安全、行为透明、代码可审计坏处是必须“求用户配合”做白名单设置。为了保证这一点首次启用时的引导做得比较啰嗦但也只能这么做。3. 报警链路设计从本地提醒到紧急联系人的闭环3.1 三级确认报警机制如果检测到“长时间无活动”直接狂打电话或者发短信是不现实的。老人可能只是在午睡、在浴室没带手机、或者手机落在阳台了。所以 Keep Alive Lite 的报警设计必须是分级的。整个流程是三级递进的本地提醒。默认在“疑似无活动”时间点例如连续2小时无活动触发手机最大音量播放一段指定铃声同时持续震动。这是给老人本人的最后确认机会——如果人没事按一下“我没事”按钮就会取消警报并且重新计时。短信通知。如果本地提醒发出后20分钟内没有任何确认APP自动给预设的紧急联系人发送一条短信内容大致是“您关注的设备手机名/号码已连续X小时无活动可能发生意外请尽快联系确认。”这条短信会附带当前基站定位的粗略位置方便家属快速判断。持续升级。短信发出后再等待15分钟如果依然没有确认系统会再次向紧急联系人发送短信并且每隔30分钟自动补发一条。如果到了第三轮仍然无确认APP才会尝试直接呼叫紧急联系人——因为语音通话权在用户侧更敏感所以呼叫之前会先弹窗确认一次防止误报导致骚扰。这个“先响铃、再短信、最后电话”的三级链路核心目的是平衡“救急”和“误报”。我实测过午睡两小时不碰手机是很多人正常的休息节奏如果直接打电话一中午能打好几个家属和老人都会被折磨疯。有了20分钟的本地确认缓冲期大部分误报在第一步就消化掉了。3.2 短息发送、定位与隐私边界短信发送用的是安卓系统的SmsManager。这个方案在技术实现上最直接不依赖任何第三方云服务但有个现实麻烦**安卓系统对短信权限的管控越来越严。**从 Android 4.4 开始只有默认短信应用才能直接写短信数据库从 Android 10 开始SEND_SMS权限被列入高风险权限应用商店审核也会重点审查。所以我在应用里做的是“双通道”优先直接发短信如果系统限制导致失败就通过系统自带的Intent.ACTION_SENDTO唤起短信编辑界面把内容预填好让用户按一下发送键。这个降级方案牺牲了一点“全自动”但保住了兼容性和应用商店上架资格。对真正独居老人的使用场景来说这一步手动发送的接受度是OK的——因为按键的是家属而不是老人家属愿意配合。隐私方面我把隐私设计原则写进了项目文档的第一页**默认不联网、数据不上传。**所有活动数据、报警记录、位置信息只存在手机本地SQLite数据库里。只有触发报警时才会申请发送短信位置信息只取基站定位不需要GPS权限只需要粗略定位权限而且只挂在短信正文里。整条链路没有云服务器、没有统计分析SDK对这类敏感场景来说这反而是最大的卖点。4. 安装部署与配置指南4.1 从源码到APK开箱即用的构建流程这个项目完全开源代码托管在公开的代码托管平台上仓库名就叫 keep-alive-lite。整个应用是用 Kotlin 写的基于 Gradle 构建工程结构非常常规。如果你只是想拿来用可以直接在开源页面下载我打包好的 release APK如果你想自己改功能也可以完整编译一遍。编译需要准备的东西不多Android Studio建议最新稳定版JDK 11 或以上一个安卓 SDK项目最低编译版本是 Android 8.0对应 API 26。在 Android Studio 里打开工程后直接选Build Build APK(s)等待 Gradle 同步和编译完成就能在输出目录找到安装包。整个项目没有引入任何第三方付费SDK依赖列表里只有安卓官方库和几个常见工具库。第一编译时间通常3-5分钟改代码后增量编译基本几十秒门槛比较低。4.2 配置文件与关键参数运行之后设置入口在主界面的齿轮图标里。这里把几个关键参数列出来对排查问题很有帮助参数默认值说明无活动判定时间120分钟连续无有效活动的最长时间建议按老人作息调整本地提醒持续时间20分钟本地响铃震动后等待确认的时长太短容易误报短信重发间隔30分钟报警短信的最短重复周期紧急联系人最多3个按优先级顺序发送可配置多个号码检测灵敏度中控制活动判定阈值高灵敏度更易判为“有活动”免打扰时段无例如晚间11点到早7点可降低检测频率避免洗澡和睡觉导致大量误报提醒铃声系统默认可自定义为更醒目的音频文件这些参数在首次启动时都会经过一次“引导检查”要求用户先做一次运动模拟比如拿着手机走几步然后把手机关屏放桌上两分钟系统会分别记录到“有活动”和“无活动”两个样例用来校准阈值。这是我后来加的功能因为不同老人的手机使用习惯差异太大固定阈值必然导致个别用户不适用。5. 踩坑实录与常见问题排查5.1 典型运行问题速查表开发过程中我踩过的坑比预想中多得多。很多问题在模拟器上根本不可能发现必须拿到真实手机、真实老年用户手里跑一段时间才会暴露。现象可能原因解决方案收不到报警短信短信权限被系统拦截手机是双卡且发送卡欠费检查权限设置切换默认发送卡改用系统短信编辑器降级方案后台运行一段时间后应用消失厂商定制系统清理了后台服务重新进入应用点击“一键优化”把电池、自启动、后台运行都设为白名单误报率偏高人明明在家却报警老人习惯把手机放在固定位置长时间不看调低灵敏度或把无活动判定时间从2小时延长到3小时再开启免打扰时段耗电异常快传感器采样频率过高定位权限过度使用把传感器采样从“最高频率”改回“标准频率”关闭GPS定位只保留基站定位本地响铃不响媒体音量过低或免打扰模式开启响铃使用AudioManager的STREAM_ALARM通道并提示用户关闭免打扰还有一个特别容易踩的坑是双卡手机。很多老人用双卡一张电话卡一张流量卡结果报警短信从流量卡发出去了流量卡没有余额短信实际发送失败。代码里我做了个处理优先使用系统默认短信卡读取 SIM1/SIM2 状态如果发现默认卡余量异常就尝试切换SIM卡发送。但注意切换SIM卡发短信这个操作在部分定制系统上不支持最后还是得靠降级方案兜底。5.2 设备适配与真实体验中的反馈在真实用户反馈中给我最大启发的是一个某社区养老项目负责人的建议。他们试用后发现很多老人会把手机放在客厅充电人在卧室睡觉。如果按我默认的“手机不动人不动”逻辑这种场景必然误报。所以后来加了“免打扰时段”和“低活动容忍”两个开关。现在的情况是晚上10点到早上8点这个时段只要合加速度方差不过分异常系统会自动把无活动判定时间放宽到4小时。另一个重要反馈来自一位家属老人的手机是低端机运行内存只有2GB系统自带应用已经占掉大半Keep Alive Lite 长期前台运行会不会卡我做了两轮优化所有界面只保留必要的布局文件主界面只有一个设置页和一个状态卡片APK体积控制在3MB左右监测服务里不持有任何Activity引用不保存历史传感器数据只在内存中保留最近10秒的窗口数据有效降低内存占用。实测2GB内存的机器上应用常驻内存约80MB通知栏显示正常后台一周没有被杀这个成绩对低端安卓机来说已经算体面了。6. 后续扩展与私人定制思路开源的好处是你不需要等我去做所有功能。项目代码结构我按模块拆得很清晰sensor包负责传感器采集alarm包负责报警逻辑config包负责参数管理notify包负责通知和短信。想做二次开发不需要读懂全部代码只改对应模块就行。我目前已经在考虑的扩展方向有三个本地AI跌倒检测。现在的三步判断法其实是“暴力的阈值方案”误报和漏报都存在。下一步计划在本地跑一个轻量级分类模型TensorFlow Lite输入是连续5秒的加速度时序数据输出是“正常/跌倒/剧烈运动”三类标签。只是模型训练缺少真实跌倒样本这块进展比较慢。语音交互确认。本地提醒响铃时老人如果行动不便可能无法点击按钮。如果能在“本地提醒”阶段加入语音识别老人说一句“我没事”就能解除警报体验会好很多。考虑到老人说话模糊离线语音识别模型的准确率还需要打磨。多设备联动与家属端看板。让家属在另一台手机上能看到老人的活动时间线这个需求咨询的人非常多。但有一个核心矛盾只要云端参与隐私边界就要重新定义。目前比较稳妥的做法是局域网内联动或者把数据加密后放在用户的家庭服务器上这条路还在设计。还有一点要说清楚Keep Alive Lite 不是也不应该替代专业医疗设备。心梗、脑卒中的监测需要心电图、血氧、血压等生理参数这不是一个普通安卓APP的传感器能完全覆盖的。这个项目的定位从来都是“最后的通信保障”——当意外发生时把发现时间从几小时缩短到几十分钟把求救消息递出去。能做到这一点价值就已经非常大了。开发这个项目我最大的体会是技术本身并不复杂复杂的是对人生活习惯的理解和尊重。一个监测工具如果不尊重老人午睡的习惯、不尊重他们对隐私的敏感、不尊重低端手机的性能限制技术做得再花哨也落不了地。开源之后陆续收到一些用户反馈说“装了之后家里老人并没有觉得被打扰反而有时候忘记放手机充电听到提醒还会觉得蛮温暖”。这种反馈让我觉得做这样一个不智能但诚实的工具是对的。
