人们在安卓手机上存储了大量敏感数据,因此他们不愿意把手机交给不信任的人也就不足为奇了。即便你愿意让朋友或家人借用你的设备,你可能仍然有一些不希望他们看到的数据。锁定特定应用是保护隐私的好方法,但安卓系统本身仍缺乏原生支持,这迫使许多用户——尤其是 Pixel 用户——不得不依赖第三方工具。幸运的是,谷歌可能会在明年的 Android 17 更新中通过新增“应用锁”功能来解决这一问题。

除了“私人空间”之外,安卓缺乏一种原生方式,可以通过屏幕锁或生物识别来保护应用。私人空间的问题在于它并不方便。当你将应用移入私人空间时,它会被隔离;这对于不常用的应用还可以,但对于每日使用的应用,很快就会变得麻烦。私人空间内的应用无法放在主屏幕上,容器本身也没有快捷方式。要访问这些应用,你每次都必须先打开应用抽屉,再滚动或搜索才能找到并解锁。
此外,私人空间内的应用完全与系统的其他部分隔离,因为它们运行在独立的用户配置文件中。这种隔离防止它们轻易访问主配置文件中的文件——这对隐私保护很好,但对工作效率却是个麻烦。虽然你可以手动在文件间来回移动,但这并不是一个你希望每天都要做的操作流程。

这也是为什么许多手机厂商为各自的安卓定制系统开发了自己的“应用锁”解决方案。然而,由于核心系统没有原生选项,Pixel 用户不得不依赖第三方应用锁,而这些工具本质上存在缺陷。由于这些工具只是普通应用程序,它们可以被轻易绕过——只需卸载即可。这些应用的开发者通常会尝试通过请求设备管理员权限来弥补这一漏洞,但将如此高权限交给第三方应用,需要极高的信任。此外,这些检测方法往往很粗糙,依赖辅助功能(Accessibility API)来监控屏幕中是否打开了特定窗口——这不仅带来隐私问题,也会影响性能。
原生系统级的“应用锁”可以解决所有这些问题。它无法被卸载,本身更值得信赖,也不需要依靠不稳定的变通方法来检测受保护应用的启动。好消息是,有强有力的证据表明谷歌正在为安卓开发原生应用锁,而且该功能似乎将对所有启动器开放,而不仅仅是系统默认启动器。
在分析最新的 2512 版 Android Canary 发布时,我在 Android 框架包中发现了暗示新“应用锁”API 的代码。访问该 API 需要新的 LOCK_APPS 权限,该权限仅限系统内部应用以及拥有 HOME 角色的应用使用。由于用户的默认启动器会自动获得 HOME 角色,因此它有资格拥有此权限。
<permission android:featureFlag="android.security.app_lock_apis" android:name="android.permission.LOCK_APPS" android:protectionLevel="internal|role"/>
拥有该权限后,默认启动器可以通过 SET_APP_LOCK 意图动作启动安卓的“应用锁”活动来调用该 API。系统随后会验证请求:检查目标应用是否有启动器条目、是否不在系统豁免列表中,并检查其当前的锁定状态。如果该应用符合锁定条件,用户会看到提示:“锁定 [应用名称]?”相反,如果启动器请求解锁,弹窗会显示:“从 [应用名称] 移除应用锁?” 一旦用户确认操作,系统会显示一个提示消息(toast)来确认更改已生效。

以下是与这些对话框相关的字符串:
<string name="enable_app_lock_dialog_enable_button_text">Lock</string>
<string name="enable_app_lock_dialog_title">Lock %1$s?</string>
<string name="enable_app_lock_failure_toast_message">"Can't lock %1$s"</string>
<string name="enable_app_lock_success_toast_message">%1$s is locked</string>
<string name="disable_app_lock_dialog_disable_button_text">Remove lock</string>
<string name="disable_app_lock_dialog_title">Remove App Lock from %1$s?</string>
<string name="disable_app_lock_success_toast_message">App Lock is removed from %1$s</string>
安卓还包括多个检查机制,以确保“应用锁”功能按预期使用。首先,它会验证设备类型,以排除 Wear OS、Android Automotive 和 Android TV,因为该功能主要针对手持设备。其次,它会检查当前用户是否为受监管的配置文件,将应用锁功能限制为主用户使用。
你可能会好奇,实际如何触发锁定。由于该 API 对启动器开放,具体的界面实现由启动器开发者决定。我推测大多数启动器会简单地在长按应用图标时的上下文菜单中添加一个新的锁定按钮或操作。
至于锁定机制本身,代码实际上尚未实现,至少在这个 Canary 版本中是如此。不过,如果谷歌不利用安卓现有的生物识别提示(Biometric Prompt API),我会感到惊讶。这将提供一个标准化的方式,通过生物识别来保护应用,并无缝回退到设备 PIN 或图案锁。
至于该功能的预计发布日期,目前尚不确定。在当前 Canary 版本中,该功能尚未上线,因为控制它的标志(flags)被禁用。考虑到 Android 16 的第三季度更新(QPR3)不会引入新的开发者 API,我们也不指望它会在该版本中推出。因此,我们预计最早可能会在明年的 Android 17 更新中看到“应用锁”功能,但这并没有保证。
Android Authority 将持续关注这一功能的发展。我们尤其关注“应用锁”将如何处理受保护应用的通知,具体来说,是显示完整内容,还是对内容进行遮蔽。虽然后者对这一功能来说更符合逻辑,但我尚未发现任何代码表明通知会被修改,当然谷歌在正式发布前完全可能添加这一功能。