[☕Vibe Coding🤖] Android 12+ 把 LockActivity 这条路打死了, 我只剩 Overlay 一条窄路

那是一个周三凌晨两点。 我盯着 Android Studio 的 logcat, 第八次发现: 时间到了, 我写的那个"锁屏页"压根没起来。 我家娃的手机静静地躺在桌上, 他常刷的那个短视频还在继续播。 我打开侧锁屏, 确认我的代码确实运行了 —— Activity 启动指令发出去了, 系统回了一个...
[☕Vibe Coding🤖] Android 12+ 把 LockActivity 这条路打死了, 我只剩 Overlay 一条窄路
[☕Vibe Coding🤖] Android 12+ 把 LockActivity 这条路打死了, 我只剩 Overlay 一条窄路

那是一个周三凌晨两点。

我盯着 Android Studio 的 logcat, 第八次发现: 时间到了, 我写的那个"锁屏页"压根没起来。

我家娃的手机静静地躺在桌上, 他常刷的那个短视频还在继续播。

我打开侧锁屏, 确认我的代码确实运行了 —— Activity 启动指令发出去了, 系统回了一个我没见过的 warning, 然后什么都没发生。

那一瞬间我有一个挺荒谬的念头: 我做这个 App 一年, 是不是从一开始就走在一条已经被堵死的路上?


一、我以为这是一个 Android 入门题

我做儿童 App, 核心功能就一句话: 时间到了, 不让孩子切回去继续刷。

我当时的设计极其朴素 —— 起一个 LockActivity, 铺满屏幕, 写一个 PIN 输入框。家长输 PIN, 孩子继续玩; 不输 PIN, 就一直挡着。

按 Android 的标准做法, 时间到了就调用 startActivity() 把这个 Lock 页拉起来。

如果担心系统不给拉起, 那就再加一个 fullScreenIntent 通知 —— 全屏意图, 专门给闹钟、来电、紧急提醒这类场景用, 系统会强制把你的 Activity 拉到最前面。

我写了, 跑了, 在我自己的 Pixel 上一次过。

那天晚上我特别开心, 跟我老婆说: "核心功能搞定了。"

她问: "就这么简单?"

我说: "就这么简单。Android 给了现成的 API 。"

那是我整个项目里, **最后一次说"就这么简单"**。


二、Android 12 之后, 这条路被一刀切了

第二天我换了一台手机测, Android 12 的。

LockActivity 没起来。

我以为是我代码写错了。

调了一整天, 找不到原因。所有的日志都告诉我"启动成功", 但屏幕上什么都没有。

第三天我才在 Google 的官方文档里翻到一篇说明 —— Android 12 之后, 引入了一个叫 BAL 的东西, 全称 Background Activity Launch 限制。

翻译成人话就是: 从后台拉起一个 Activity 这件事, 被默认禁止了

只剩极少数情况能起来: 用户刚跟你的 App 交互完不到几秒、有可见的 Window 、是系统级权限。我的"时间监控服务"在后台跑, 时间到了想拉起一个 Activity —— 全部不符合。

fullScreenIntent 呢? 我加了啊。

我又翻了一晚上文档。结论是: 从 Android 10 开始, 系统会悄悄把全屏意图降级成一条普通通知, 除非用户在设置里手动给你这个 App 开权限。

这两条加在一起, 等于 Android 12 之后, 我设计的整条阻断路径 —— 从代码逻辑上是对的, 从用户感受上完全不存在


三、为什么 Google 要这么做? 我得承认它是对的

我有一个晚上在床上想这件事, 越想越烦躁。

我做的是儿童保护, 又不是恶意软件, 凭什么把我也一刀切?

但我后来去看了那个 BAL 引入的初衷 —— 当时市面上有大量的 App 在后台偷偷拉起广告 Activity 。你把手机放桌上, 它突然弹一个全屏视频广告。还有更坏的, 模拟登录页、模拟支付页, 专门做钓鱼。

Google 是被这些东西逼到必须出手的。

我能理解。

但理解归理解 —— 理解不能让我家娃的手机在时间到了之后真的停下来

这是做底层产品的一个尴尬: 你的产品哲学跟系统的产品哲学冲突的时候, 输的永远是你。

Google 不会因为我做的是"温柔的儿童 App"就给我开后门。在系统眼里, 我跟那些钓鱼 App 是同一种东西 —— 想在用户没主动操作的情况下, 强行占据屏幕

那段时间我反复问自己一个问题: 我做的这件事, 从系统的角度看, 到底是不是合理的?

我得承认, 从系统的角度, 它不合理。

但从一个父亲的角度, 它必须合理。

这两个"合理"之间的那条窄缝, 就是我接下来要找的路。


四、能走的路只剩三条, 前两条都不能选

我列出了所有理论上能阻断 App 切换的方案:

**第一条, Accessibility (无障碍服务)**。这是 Android 给残障辅助用的, 能读到全局的应用切换事件, 理论上能"看到孩子切走"然后阻断。

但 Google Play 这两年专门盯这条 —— 任何不是真为残障人士设计的 App, 用了无障碍权限都会被下架。我看过太多儿童管控类、防沉迷类的 App, 因为这个被一夜清掉。

这条路死了, 是产品死, 不是技术死

第二条, 双进程互锁。我开两个 Service, 一个挂了另一个把它拉起来。

这个技术上能做, 但它是 Google Play 政策里明确标红的"abusive behavior"。短期能活, 等于在一颗定时炸弹上盖房子。

死了, 是商业死

第三条, SYSTEM_ALERT_WINDOW。也就是悬浮窗权限 —— 你常见的微信视频通话小窗、滴滴司机端的接单浮窗, 用的就是这个。

它的本质是: 让我的 App 可以在别的 App 上面画一层东西。

我不需要"启动一个 Activity", 我只需要"在你正在用的那个 App 上面, 盖一块布"。

这块布我自己控制 —— 大小、内容、能不能点穿。

这条路活着。但它有它自己的代价。


五、悬浮窗这条窄路, 本身也有三个大坑

我以为找到了 SYSTEM_ALERT_WINDOW 就解放了。

不是。

第一个坑: 权限要用户手动去设置里开。装完 App 不会主动给你, 要跳到一个深埋在系统设置里的页面, 让用户找到你的 App 名字、打开开关。我做了三版引导, 从最初的 5 步跳转到现在的 1 步, 光是这个引导我返工了大概 20 次。

第二个坑: 国产 ROM 各家有各家的掐法。小米要单独的"后台弹出界面"权限。华为有"应用启动管理"。OPPO 把它叫别的名字。同一个 API, 八个厂商八种行为。我专门为这个写了一个能力探测模块, 运行时去试到底能不能画 —— 而不是相信权限申请的返回值。

第三个坑也是最难的: 悬浮窗本身是个"高敏感"权限。系统认为开了这个的 App 都有"行为不端"的潜力, 所以会在各种地方默默降级你 —— 锁屏后不让画、全屏视频时不让画、某些应用类型上不让画。

每一个降级路径我都得有一条兜底。

最后这个东西被我写成了一个 5 状态 9 事件的状态机, 专门管"什么时候该画、画什么样的、有没有画上、没画上怎么办"。它叫 OverlayStateMachine 。

它的核心逻辑就一句话: 画上了就是赢, 没画上就要立刻知道并补救


六、BLOCKING 和 HINT, 是温柔工具的两副脸

这个状态机往外有两种"画法"。

HINT —— 软提醒。顶部一条 80dp 高的横幅, 不拦截点击, 孩子可以继续操作底下的 App 。用在六阶段提醒的前三档: 60%、75%、90% 的时候各冒一次, 告诉孩子"快到时间了"。

BLOCKING —— 硬阻断。全屏覆盖, 拦截所有点击和系统按键, 中间放 PIN 输入框。只在 100% 之后用。

为什么要分两种?

因为如果只有"硬阻断", 那这个 App 就退化成了我最开头骂的那种"机器代替家长吼"的产品 —— 没有过渡, 直接黑屏。

而 HINT 这一层, 是给孩子"自己结束"留的台阶。

我做这两种模式的时候, 反复跟我自己吵过一个问题: HINT 那一档要不要拦截点击?

技术上做拦截更省事, 反正是悬浮窗, 全拦了完事。但拦了之后, 孩子滑手指会感到"卡了一下", 那个体感非常不好 —— 像是被人冷不防戳了一下。

最后我决定, HINT 这一层坚决不拦点击。它就是一条横幅, 画在最上面, 孩子手指划过去, 底下的 App 该怎么用怎么用。

它的存在感是视觉的, 不是触感的

让孩子"看见一个提醒"和"感到被打扰"是两件不一样的事, 做家长的应该懂这个区别。


七、那天晚上, Overlay 第一次起来的时候

我把整套机制接通的那天晚上, 又是一个周三。

我把手机递给我家娃, 让他打开他平时刷的那个 App 。我把今天的剩余时间设到了最短 —— 5 分钟。

过了一会儿, HINT 横幅冒出来 —— 顶部一条小小的"快到时间啦", 停留几秒, 自动消失。他眼睛瞄了一下, 继续看。

又过了一会儿, 第二条 HINT 。这次他嘟囔了一句"快结束了"。

5 分钟到的那一刻, BLOCKING 弹出来了。底下的 App 还在播, 但屏幕中间多了一张卡片 —— 上面画着一只小乌龟, 旁边一行字告诉他该休息一会儿了, 卡片下方是 PIN 输入框。

他没有大哭。

他只是抬头看了我一眼, 说: "爸爸, 时间到了。"

我那一刻心里特别复杂。

因为这张挡住他的卡片, 背后是我跟 Android 系统较劲那段时间写的全部代码 —— BAL 限制、fullScreenIntent 降级、八个厂商的兼容差异、一个状态机、五种状态、九种事件、还有大概 40 多种从"画上了"到"没画上"再到"用户自己关了"的转换路径。

而这一切, **最后呈现给我家娃的样子, 就是一只小乌龟和一句"该休息一会儿啦"**。

他根本看不到背后的代码。他只看到一件事: 屏幕在告诉他时间到了, 但没有人在吼他


八、最后

这条路技术上不优雅 —— 用一个本来给"小窗视频"做的 API 去做"全屏阻断", 怎么看都歪。

但它有一件事, 是我最初想的那条"标准路"做不到的 —— 那张卡片没有"关掉"任何东西。底下那个 App 还活着, 孩子刚看到哪一帧, 还停在哪一帧。家长输 PIN, 卡片撤掉, 他还能继续。

强行关闭做不到这一点。强行关闭一关就是真关 —— 孩子刚刚攒到的进度、看到一半的剧情, 全没了。

很久以后我才想明白一件事: 我一开始就不应该想着"关掉"它。我应该想着"挡住"它

关和挡, 差一个字。但前者留给孩子的是"我的东西被人拿走了"; 后者留给孩子的是"我的东西在那, 只是现在不让动"。

第二种, 孩子才学得会接受。


如果你也在做这种被系统一刀刀砍权限砍到墙角的事 —— 我想说的是, 那条系统留给你的窄路, 可能比你以为的, 更接近你本来想做的那件事。

只是它要求你, 把"关掉"这两个字从你脑子里彻底删掉。

那两个字, 是父母最容易做出的动作, 也是孩子最难承受的动作。

来源: v2ex查看原文