Ftyjtk

Some background: one of the apps I worked on makes use of HCE (Host Card Emulation) - when the device is close to the custom hardware, the implementation of HostApduService is created and started by the system. Upon its start, it reads some info from SharedPreferences and handles the communication with the custom hardware accordingly. So far, so good.

At some point I noticed the strange crashes gathering in Google Play Vitals - as it turns out, since Android 8.1 ContextImpl checks the if the user has already authorized or not; if not, the Exception is thrown. This is how I learned about Direct Boot implications.

The documentation on Direct Boot mode mentions that the Credential Storage encryption prohibits anybody from accessing the data until the user has provided some authorization. I can not point to exact place in the documentation atm, but I am pretty sure that once the device was [re]booted and the user has entered authentication data, anything stored in the Credential Storage area (including, but not limited to the SharedPreferences) should become available for read/write.

But, some of the app's users claim that sometimes the device-hardware communication does not work even if they weren't rebooting the device for pretty long time. And the only way to cope with that is to autenticate the device - enter the pin code, touch the fingerprint scanner, etc.

So this got me wondering - how does this part of encryption work and is it possible that some vendors change this feature's implementation so that sometimes it kicks in after the device being in the locked state for, say, one hour or so? I can understand the need to turn the device's screen on so that NFC starts working - documentation on NFC mentions that NFC is put to sleep when the screen is off, for the security reasons. But why would that require the device to be unlocked? Or it's not about vendors per se, and my understanding is just plain wrong?