The issue here is in wanting that some functionality remains accessible when the screen is locked.
In that case, each app allowed to work in limited fashion while in a locked screen has responsibilities… (which are not architecturally enforced)
Taking a note w/ a locked screen for example.
Windows 10 Mobile also had a funny analogous bypass scenario…
At least on iOS, some info is set to not be accessible at all when the screen is locked, with the keys for those being wiped on screen lock.
iOS and Android require opting into portions of the data not being available when the screen is locked. On iOS, by changing the data class, and on Android via the keystore API. It's rarely used in practice on either platform. It's a little bit more common to use it on iOS.
Of course, it's possible for the OS to support logging out instead of simply locking and then nearly all data will be protected. Apps have to explicitly opt into being able to run before log in for each component and explicitly opt into each portion of their data being available.
Hardly any apps opt into running before being logged in and those that do rarely make much of their data available. It's really incredibly rare for apps to do this on either platform. Mostly only used by OS components. Means that at least nearly all data is protected pre-login.
In practice, nearly everything leaves the defaults alone. Even supposedly security-oriented apps don't use these features and don't use internal sandboxing features that are offered. Data not being available when locked would have to become default for new API levels to be used.
Android supports logging out rather than only locking but only for secondary users. Many system components run in the owner user and store data there there so it has to be logged in before using other users.
They regard this as an enterprise feature not normally shown in the UI.