Design for security
Design for security
Posted Feb 23, 2019 17:34 UTC (Sat) by jezuch (subscriber, #52988)In reply to: Design for security by fest3er
Parent article: Design for security
How do you guarantee that the gateways do not cheat and are not sending data unencrypted? How do you verify this? It's like today's email: how do I know that my mail provider is not broadcasting my poorly written and utterly embarrassing (but really sweet to the addressee) love letters to other mail exchanges as plain text? (An obvious response to an obvious retort: mail encryption is rubbish and my girlfriend refuses to use it.)
BTW, you may be confused that when you "close" an app it is in fact closed. More likely it is just removed from the list of recent apps, unless you're going to the settings > applications > particular app > stop process > yes, I really want to kill it and I know it may break the app. It gets tiresome really quick.
Posted Feb 23, 2019 23:59 UTC (Sat)
by excors (subscriber, #95769)
[Link]
The "Recents" screen shows activities and tasks (which I think correspond to certain Java objects), not apps or processes. When the user closes something from that list, I think it does destroy the activity if it's still alive, per https://developer.android.com/guide/components/activities..., so it's doing more than just hiding it from the list. But it still probably won't terminate the process if that was its last activity - it just increases the likelihood of it being chosen by the Low Memory Killer when someone else wants the memory.
Conversely, an activity can remain in the Recents list after its process has been terminated by the LMK. A new process can be started and told to resume that activity. So there's little correlation between process lifetime and activity visibility.
Design for security