音视频移动开发【免费下载链接】streamyfinA modern Jellyfin client built with Expo项目地址https://gitcode.com/gh_mirrors/st/streamyfin点击查看免费下载本文聚焦 Streamyfin 原生下载模块modules/background-downloader在 Android 上踩过的一个系统级崩溃坑用startForegroundService()启动服务后如果onStartCommand没有先调用startForeground()就stopSelf()进程会被ForegroundServiceDidNotStartInTimeException直接杀死。文章结合 Android 框架AOSP内部语义、一次真实事故Sentry REACT-NATIVE-9V的复盘以及仓库中ForegroundPromotion.kt的落地实现与 JVM 测试给出可直接复用的四条编码规则帮助你写出在任何 Android 版本上都不会因前台服务未按时应答而崩溃的下载/同步类服务。背景startForegroundService()是一笔必须偿还的债务在 Android 8.0API 26之后应用必须使用Context.startForegroundService()才能从后台启动前台服务。与普通startService()不同startForegroundService()会在系统内部的服务记录上标记一笔欠债fgRequired系统承诺服务会在数秒内调用startForeground()从而把自己提升为前台服务。Streamyfin 的下载链路正是走这条路。在 BackgroundDownloaderModule.kt 中startDownloadService()先调用context.startForegroundService(intent)再bindService(...)private fun startDownloadService() { if (!serviceBound) { val intent Intent(context, DownloadService::class.java) context.startForegroundService(intent) context.bindService(intent, serviceConnection, Context.BIND_AUTO_CREATE) } }从这一刻起DownloadService就欠系统一次startForeground()调用。这笔债必须在数秒内还清否则系统会以最严厉的方式追责——杀掉整个进程。值得强调的是每一次onStartCommand都是一笔独立的债务**。即使服务此刻已经在运行、已经处于前台再次投递的 start 命令同样要求一次应答。这就是后文规则中每一次启动都要调用而不是只在第一次调用的由来。未应答的后果两种殊途同归的进程击杀路径债务未偿还时系统会通过两条路径击杀进程最终都表现为同一类致命异常主动停止即击杀如果服务在onStartCommand中、尚未绑定任何客户端时直接调用stopSelf()服务会立刻被拉下bring down。此时债务仍然敞口系统直接以ForegroundServiceDidNotStartInTimeException击杀进程。这是最快的死法——崩溃发生在启动动作之后零点几秒。超时兜底击杀如果服务既不调用startForeground()也不停止那么在数秒超时后系统会自行停止服务这与主动停止是同一个击杀。唯一的例外是如果有一个 binding 让服务保持存活系统就不会杀进程而是上报一个ANR其文本同样是 did not then call Service.startForeground()。也就是说债务未清导致的进程死亡有崩溃和ANR两种表现形式但根因完全一致。仓库的 ForegroundPromotion.kt 类注释对这套语义给出了精确概括Context.startForegroundService() is a promise that the service calls startForeground() within a few seconds, on every start. The system kills the process with ForegroundServiceDidNotStartInTimeException when the service stops, or the time runs out, with that promise open. So a start command is answered first, and whether the service has anything to run for is decided after.注意最后一句的次序思想先应答启动命令再决定服务是否有事可做。应答与是否继续运行是两个独立的决策绝不能因为反正会被拒绝/反正没活儿干就跳过应答。应答的真正时机startForeground()内部先清债、后校验一个反直觉但至关重要的细节是债务是在startForeground()内部、系统校验这次提升是否被允许之前就被清除的。从 AOSP 的实现看ActiveServices.setServiceForegroundInnerLocked中r.fgRequired false清债这一行排在 BOOT_COMPLETED 广播约束、后台启动约束和时间限制检查之前。换句话说一次会抛出ForegroundServiceStartNotAllowedException的startForeground()调用仍然算作已回答了启动因此在 try/catch 中捕获该异常后选择停止服务是安全的——债务已清stopSelf()不会触发击杀而因为估计会被拒绝就跳过startForeground()调用才是唯一真正致命的行为——债务永远敞口任何停止或超时都会带走进程。这一机制正是整条规则的基石调用必须无条件发生结果由系统裁决而不是由应用猜测。事故复盘Sentry REACT-NATIVE-9V 与 uptime 启发式判断文档记录了一次真实的线上崩溃Sentry 事件号 REACT-NATIVE-9V展示了违反上述机制会付出什么代价。旧的onStartCommand实现试图聪明地判断启动上下文它用SystemClock.elapsedRealtime() 10 min来猜测本次启动是否来自 BOOT_COMPLETEDAndroid 15 对 dataSync 类型前台服务在开机广播后有严格的启动限制一旦命中该分支就直接stopSelf()完全跳过startForeground()。结果任何在系统重启后 10 分钟内发起的下载都会走进这个分支。事故设备开机仅 5 分 55 秒用户开始季集season下载后 0.2 秒进程即被杀。崩溃栈只有框架帧framework frames没有应用代码帧这正是债务未清被系统击杀的典型特征。修复方向非常明确永远不要用 uptime 或其他任何启发式手段推断启动上下文。启动上下文由系统判定应用的唯一正确动作是无条件应答然后把是否允许继续的判断权交给系统。为什么这个坑如此隐蔽bindService()竞争条件该 bug 之所以只在少数设备上偶发、难以复现是因为模块在startForegroundService()之后紧接着调用了bindService()二者形成了一场竞争当 bind 先注册成功stopSelf()无法真正拉下服务服务已被绑定随后onServiceConnected会走另一条路径完成前台提升。于是那个危险分支看起来无害——下载正常继续从未崩溃。当stopSelf()赢得竞争服务在没有任何 binding 的情况下被拉下债务敞口进程死亡。因此这是一个概率性崩溃同一段代码在多数设备上因为 bind 先到而侥幸无事在少数时序下则必死无疑。这也解释了为什么这类问题极难在开发机上复现——它取决于两个系统调用之间的微秒级时序。四条编码规则无条件应答、捕获后决策结合 AOSP 语义与事故教训对于任何用startForegroundService()启动的服务必须遵守在onStartCommand中第一个调用startForeground()前面不能有任何条件判断并且是每一次启动都调用不是只在第一次。用 try/catch 包裹startForeground()在捕获到拒绝异常后再决定是否停止服务此时债务已清停止是安全的。重复调用可能被拒绝而第一次没有被拒绝Android 15 对 dataSync 这类有时限类型的前台服务会在每次调用时重新检查应用状态但此前的提升仍然有效因此不要因为一次被拒绝就去停止服务。绝不用 uptime 或其他任何启发式手段推断启动上下文。Streamyfin 的落地实现ForegroundPromotion 与 DownloadService事故后仓库将应答策略抽成了独立的可测试类 ForegroundPromotion.kt刻意不依赖任何 Android 类型以便用纯 JVM 测试钉死语义。它接收两个函数参数promote封装Service.startForeground()系统拒绝时返回 false和demote封装ServiceCompat.stopForeground(...)。onStartCommand()先应答后决策Synchronized fun onStartCommand(): Boolean { // A repeat can be refused where the first call was not: Android 15 checks again, on every // call, whether a dataSync service may start from where the app is now. That refusal // leaves the earlier promotion standing, so it is no reason to stop. if (promote()) promoted true return promoted }这里没有任何前置条件——不检查服务是否已在前台不检查 uptime不检查启动来源。因为系统只认自己记录的债务而本类只有自己的promoted标志可用来猜测所以干脆不猜每次都调用promote()由系统裁决。返回值仅用于告知调用方服务是否值得继续存在。onActiveDownloads(count)跟随下载数升降级Synchronized fun onActiveDownloads(count: Int): Boolean { if (count 0) { if (!promoted) promoted promote() return promoted } if (promoted) { demote() promoted false } return false }当有下载任务时确保提升为前台当任务清空时降级demote并建议停止。注意它只在没有前台状态时才发起 promote避免重复调用而onStartCommand则相反每次都调用——两者的差异正是系统语义每次 start 都要应答与模块状态前台状态只需建立一次的区别。DownloadServiceonStartCommand中Nothing may come before thisDownloadService.kt 是这套策略的消费者override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { Log.d(TAG, DownloadService started) // Nothing may come before this, see ForegroundPromotion. Where the promotion is not // allowed (a dataSync service started from BOOT_COMPLETED on Android 15) // startForeground() throws, and the system counts the start as answered before it does. // Guessing at that context from the uptime instead skipped the call for any download // started within ten minutes of a reboot, and stopping with the start unanswered is what // kills the process. if (!foreground.onStartCommand()) { stopSelf() } return START_STICKY }关键点注释明确写着 Nothing may come before this——foreground.onStartCommand()必须是最先执行的动作stopSelf()只发生在onStartCommand()返回 false 之后即系统已经拒绝了这次提升而债务已被startForeground()清除时此时停止是安全的返回START_STICKY保证系统杀死服务后有机会重建。实际的提升动作在 startForegroundSafely() 中实现Android 14API 34使用ServiceCompat.startForeground并显式携带ServiceInfo.FOREGROUND_SERVICE_TYPE_DATA_SYNC类型旧版本走传统startForeground。整个调用被 try/catch 包裹任何异常都被吞掉并返回 false交由上层决定是否停止。清单配置dataSync 类型声明AndroidManifest.xml 为这一设计补齐了权限与类型声明uses-permission android:nameandroid.permission.FOREGROUND_SERVICE / uses-permission android:nameandroid.permission.FOREGROUND_SERVICE_DATA_SYNC / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS / uses-permission android:nameandroid.permission.WAKE_LOCK / application service android:name.DownloadService android:foregroundServiceTypedataSync android:exportedfalse / /applicationandroid:foregroundServiceTypedataSync与运行时传入的FOREGROUND_SERVICE_TYPE_DATA_SYNC保持一致这是 Android 14 强制要求、也是 Android 15 对有时限类型做重复校验的前提。测试验证用 JVM 测试钉死系统语义由于 ForegroundPromotion.kt 不含任何 Android 类型仓库用 ForegroundPromotionTest.kt 以纯 JUnit 测试完整锁定了所有边界语义其中最值得关注的三组1. 每一次启动都要应答对应 Sentry REACT-NATIVE-9V 的根因// Sentry REACT-NATIVE-9V: a start command that returned without calling startForeground() // killed the process. Each one is a separate promise to the system, so each one is answered. Test fun answersEveryStartCommand() { assertTrue(foreground.onStartCommand()) assertTrue(foreground.onStartCommand()) assertEquals(2, promotions) }即使服务已经在跑已提升后续的 start 命令仍要再次调用promote()两次命令产生两次提升调用。2. 拒绝只能通过询问得知不能靠猜测跳过// The refusal is only known by asking: the call that throws is also the one that settles // the start with the system, so it cannot be skipped on a guess. Test fun asksTheSystemBeforeReportingARefusal() { systemAllows false assertFalse(foreground.onStartCommand()) assertEquals(1, promotions) }系统拒绝时仍然发生了 1 次 promote 调用——因为抛出异常的那次调用恰恰就是向系统结清债务的那次调用。3. 早期提升在后续被拒绝时依然有效Android 15 重复校验场景Test fun keepsAnEarlierPromotionWhenALaterStartIsRefused() { foreground.onStartCommand() systemAllows false assertTrue(foreground.onStartCommand()) assertTrue(foreground.onActiveDownloads(1)) assertEquals(2, promotions) foreground.onActiveDownloads(0) assertEquals(1, demotions) }第一次提升成功第二次 start 被系统拒绝但服务继续运行、保持前台直到下载全部结束后才 demote——完全符合规则 3。其余测试promotesOnceForAnyNumberOfRunningDownloads、leavesTheForegroundAndAsksToStopWhenNothingRuns、doesNotLeaveAForegroundItNeverHad、asksToStopWhenARunningDownloadCannotBePromoted等分别覆盖了前台状态只建立一次、任务清零才降级、从未提升就不降级、下载运行中无法提升则停止等边界构成了对整套应答策略的完备性证明。整个模块的用法与 API 可参考 模块 README。症状模式如何快速识别这类崩溃在线上监控与崩溃排查中ForegroundServiceDidNotStartInTimeException有非常鲜明的特征组合异常类型致命异常RemoteServiceException$ForegroundServiceDidNotStartInTimeException栈特征崩溃栈只有框架framework帧没有任何应用代码帧——因为击杀发生在系统侧时间特征发生在启动服务的那次动作之后零点几秒内事故中为 0.2 秒设备特征崩溃设备往往在几分钟前刚完成开机这正是旧代码 uptime 启发式判断的触发窗口。若崩溃同时满足上述四点基本可以断定是start 未被应答而非其他原因。修复时只需对照四条规则检查onStartCommandstartForeground()是否无条件先行、是否被 try/catch 包裹、失败后是否才停止、是否引入了任何基于 uptime 的启发式判断。小结Streamyfin 的这次事故是一个典型的系统契约 vs 应用猜测教训Android 把必须应答前台启动设计成了硬性系统约束任何试图预测系统裁决结果uptime 推断 BOOT_COMPLETED、估算会被拒绝而跳过调用的代码最终都会以进程被击杀收场。正确的做法永远只有一条——无条件调用startForeground()应答每一次启动把裁决交给系统再把拒绝当做一个可以安全停止的信号。仓库将这套语义抽成无 Android 依赖的 ForegroundPromotion.kt 并用 JVM 测试 锁死是同类服务组件值得借鉴的工程范式。赞分享音视频移动开发【免费下载链接】streamyfinA modern Jellyfin client built with Expo项目地址https://gitcode.com/gh_mirrors/st/streamyfin点击查看免费下载相关推荐GoodbyeDPI服务启动问题分析与解决方案GoodbyeDPI服务启动问题分析与解决方案 问题现象 在使用GoodbyeDPI工具时用户报告了一个关于Windows服务启动的异常情况。具体表现为系统网络通信7个.dom最佳实践打造高性能前端应用的终极指南7个.dom最佳实践打造高性能前端应用的终极指南 .dom是一个仅512字节的超轻量虚拟DOM模板引擎它借鉴了React的设计理念但保持了极简的体积。对于追Android Service 组件详解前台服务、后台服务与绑定服务的完整实践指南Android Service 组件详解前台服务、后台服务与绑定服务的完整实践指南 Android 中的 Service 是四大应用组件之一用于在没有用户界文档教程知识库上一篇深入 Roc 编译器快照测试四层嵌套 Nominal Tag 的完整编译管道剖析下一篇StarRocks char_length 函数完全指南字符长度与字节长度的区别、底层实现与低基数优化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考