某些背景：我研究的其中一个应用程序利用了HCE（主机卡仿真）-当设备靠近自定义硬件时，HostApduService的实现由系统创建并启动。在启动时，它将从SharedPreferences中读取一些信息，并相应地处理与自定义硬件的通信。到目前为止，一切都很好。
在某个时候，我注意到Google Play Vitals中出现了奇怪的崩溃-事实证明，由于Android 8.1 ContextImpl在尝试读取共享首选项之前会检查用户是否已经授权；如果不是，则抛出异常。这就是我了解直接启动含义的方式。
有关“直接启动”模式的文档中提到，凭据存储加密禁止任何人访问数据，直到用户提供某些授权为止。我无法指出在atm文档中的确切位置，但是我很确定一旦设备重新启动并且用户输入了身份验证数据，凭据存储区域中存储的所有内容（包括但不限于SharedPreferences） ）应该可以读取/写入。
但是，某些应用程序用户声称，即使他们长时间不重新启动设备，有时仍无法进行设备-硬件通信。解决此问题的唯一方法是使设备自动充电-输入个人识别码，触摸指纹扫描仪等。
这让我想知道-加密的这一部分是如何工作的，某些供应商是否有可能更改此功能的实现，以便有时在设备处于锁定状态（例如大约一小时）后启动？我可以理解需要打开设备的屏幕以使NFC开始工作-NFC的文档提到出于安全原因，当屏幕关闭时NFC会进入睡眠状态。但是，为什么这要求将设备解锁？还是与供应商本身无关，我的理解是完全错误的？
已更新。我有一个广播接收器，一旦设备重启，该接收器便会唤醒应用程序-我需要在此处做一些工作，并且该工作的一部分包括从SharedPreferences读取数据。在我更改了广播接收器的动作过滤器，以便在用户实际授权自己后，启动后，绝大多数崩溃与尝试读取SharedPreferences的内容有关虽然处于加密状态时已经消失了，但是仍然很少（例如以前崩溃次数的0.1％）仍然存在。
那时，我非常确信必须将其连接到跳回加密状态的设备，但是
是否有潜在原因的任何想法，以及如何解决该问题？
已更新。 2：
直接启动模式文档现在包含以下语句：
凭据加密存储仅在用户成功解锁设备后才可用，直到用户再次重新启动设备为止。如果用户在解锁设备后启用了锁定屏幕，则不会锁定凭据加密存储。
因此，基本上，手机在屏幕锁定后不应跳入加密状态，而应该仅在重新启动后并在授权之前进行。