这是最后的十分钟 高考客户介绍。
我是中刑,解释一个复杂的系统迁移, 当我的电话爆发 一个响亮,攻击性的铃声。
房间停了声,但我的手机没有 我拼了命想让它安静下来, 无意中撞到音量按钮, 却和屏幕相撞.
那种纯洁而未成熟的尴尬时刻 一直跟着我 这并不是第一次发生这种情况,但这是我决定 我终于有足够的时间 依靠我自己的记忆 在进入敏感环境之前切换音效配置。
我们大多数人生活在对我们的装置长期感到关切的状态。
我们走进电影院,参加宗教仪式,或者坐着进行医疗咨询,不断检查我们的口袋,以确保我们切开哑巴开关.
如果我们忘记了,我们面临着社会摩擦的破坏。
现有的解决方案要么是手动的,要么是需要我目前很少有意识地努力,要么是侵入性太强,要求不断获得位置许可,并排出电池进行简单的状态改变。
我想要一些能起到设定和遗忘背景作用的东西 我需要一个能理解我环境背景的系统 而不要求我每次改变常规时 都要与接口互动 为了建造这个,我不得不设计一个背景服务, 能够经受住现代Android, 特别是多泽模式的强力管理限制。
首要的挑战是确保我的声音传动逻辑在规则被触发时准确发射,即使设备已经闲置了数小时.
但Android的生命周期管理为了节约资源, 我转而使用一个坚持不懈的通知,这是长期任务的标准方法,但这只解决了能见度部分.
真正的障碍是祈祷时间或日历会议等活动所需的时间准确性。
我最终意识到仅仅依靠服务是个错误。
我需要与杠杆。
这使得系统能够从多泽模式将设备叫醒来发射一个广播,然后用它来触发状态变化.
该架构大致类似: kotlin val awarmManager =上下文.getSystemService(Context.ALARM SERVICE) 为AlmarmManager val entent (context, MuffleBroadcast Recessive: class.java) 为 val 未决 intent (Context, requestCode, intent.
FLAG IMMUTULE) 提醒管理器. setExactAndallow Whileidle(提醒管理器.RTC WAKEUP, 触发Time InMillis, 等待执行) 通过将时间安排与执行逻辑脱钩,我确保即使OS严格限制背景过程,内核仍然尊重提醒触发.
然后处理举重,对照任何相重叠的规则检查当前常规的优先顺序,然后呼吁在无声,振动,或者Do Not Disturb之间切换.
这种对关切的划分——通过时间表和通过执行——使系统在Android OS的不同制造商实施中保持稳定。
最让我惊讶的是, 我最初认为,仅仅使用这种方法就足以强制执行沉默。
我错了 在许多设备上,特别是来自自定义为重的UI外观的制造商的设备上,DND访问权限在主要系统更新后被取消或重置.
我花了好几天去调试 为什么我的应用程序会停止沉默电话 尽管服务运行完美。
结果发现检查需要比我预期的更频繁得多.
我不得不执行一个监听器,每次服务开始时都会重新验证这个许可,而不仅仅是在初始设置期间的一次.
依靠一次性的许可授权是一种建筑监督,它使应用程序在更新的API级别上对用户的可靠性几乎瘫痪.
另一边