Restart Phone - Recent Apps not cleared

dhhdjbd

I just noticed/ started wondering, is the "Recent Apps" (swipe up, app cards) screen supposed to not be cleared after restarting the phone? because i always thought this would also be like apps that are currently in memory... thank you

Mystified3527

dhhdjbd
When you reboot, the RAM/memory is cleared, so it clears the recent apps.

K8y

dhhdjbd yes I would like these to be cleared when we turn off or restart phone too, please gos developers. Having these screens not auto cleared is a liability as apps appear to run and become alive because of this.

Toiletterider

Mystified3527

It doesnt. Just tried.

Open accresent in owner
Open accresent in private space
Restart phone
Accresent shows in recent list
Accresent shows in recent list, after unlocking private space

de0u

Toiletterider I believe this is a standard Android behavior for some time, e.g.: https://forums.androidcentral.com/threads/all-open-apps-still-showing-after-restart-and-some-other-issues-too.526044/

The OS can record the screen image and which activity was active even if the app is not running, and can relaunch the app into that activity if the image is tapped on. In fact, if the system runs out of memory, the OS stops the app from running (without telling the user) and restarts it later.

Further info:

All in all, an app may be running without appearing in the launcher active-activities display, and an app can appear in that display without being running.

dhhdjbd

de0u thank you

de0u

K8y Having these screens not auto cleared is a liability as apps appear to run and become alive because of this.

If an app runs when the system is started, it's because the app registered to be run when the system is started, not because the launcher saved an image of the app as it appeared the last time it was running. The images present the illusion that the app is still running, but the illusion does not mean that they are running.

Once again (de0u): All in all, an app may be running without appearing in the launcher active-activities display, and an app can appear in that display without being running.

K8y

de0u does GOS have an option to automatically close out and delete, including cache, of all these windows/screens that stay open and collect in the background once closing the app?

de0u

K8y does GOS have an option to automatically close out and delete, including cache, of all these windows/screens that stay open and collect in the background once closing the app?

I think part of the problem is that "closing the app" is more an appearance than reality. If one uses the launcher gesture to flick an app away, that will probably cancel the app's current activity, but the app might still be running. Even if it doesn't continue running after it's "closed", some system event might immediately cause it to start running again (without it being visible).

Sometimes an app that appears to not be running actually isn't running, and it is possible to get a non-visible app to run less often, but the only ways I am aware of to be sure than an app is actually not running are to "End session" a user profile that the app is in or to mark the app as "disabled".

In terms of the launcher's cached activity images, I'm not aware of an option to automatically delete them. It is possible to swipe away the images, though that may result in the app launching "fresh" as opposed to resuming what it was doing the last time it was interacted with. And, again, making the image go away does not mean that the app isn't running in the background.

K8y

de0u I think part of the problem is that "closing the app" is more an appearance than reality.

maybe this is something the GoS developers can fix?

Since it's a security issue, that the apps seem to be able to do questionable things when flicked off.

Maybe allow them to run in background with restrictions, preventing them from opening and using AI to read message apps...

de0u

K8y Maybe this is something the GoS developers can fix?

In theory, yes. In practice, since it would be a lot of work to write and then maintain the code, the first step would be a clear statement of how the current situation is a problem. If it's not broken then they're not likely to "fix" it.

K8y Since it's a security issue, that the apps seem to be able to do questionable things when flicked off.

So far it's not clear to me how it's a security issue. Running in the background doesn't enable an app to do more things than it could do in the foreground.

It's not even clear to me how it's a significant privacy issue. For example, a mapping app that is running in the background could gather location data continuously, and I hypothetically it could report the location data continuously. But if there is a concern that a particular app will maliciously leak location information, it would probably be best to not run the app. As a middle ground, the app could be placed in a secondary profile; if "End session" is used on that profile then the app will definitely not be running.

K8y Maybe allow them to run in background with restrictions, preventing them from opening and using AI to read message apps...

I think it is important to distinguish between two things that are very different:

If something is definitely a security or privacy threat, with published exploits or due to the agreement of security experts that it's a big deal, the GrapheneOS team is likely to act.
If something sounds like it would be really bad if it could happen, but there is no evidence that it's happening and there are things that would stand in the way of it happening, the GrapheneOS team is not likely to act -- even if it sounds really bad.

So if there is evidence of apps running in the background and using AI to read messages from other apps, that's potentially actionable. But if the hypothetical idea that maybe apps running in the background might capture data from other apps and then use AI to do something bad sounds really scary but has no evidence, that's very different, especially since regular mechanisms that are part of GrapheneOS protect one app's data against another app no matter which ones are running.

GrapheneOS already has two ways to stop an app from running:

"End session" the profile that the app is in,
Disable the app.

Adding more ways isn't impossible, but I suspect the case would need to be pretty strong.

K8y

de0u In theory, yes. In practice, since it would be a lot of work to write and then maintain the code, the first step would be a clear statement of how the current situation is a problem.

Basically secret message apps like Session are opening up and going into threads by itself. Presumably to read and scan. I caught it mysteriously opening itself, even to a thread, a few times. If this is not Pegasus type action, but due to it still nearly being completely open even when flicked off (which doesn't clear it), then it is acting on its own to re-open threads, likely using AI.

Major Red Flag.

Johnnyloans

Since it's a security issue, that the apps seem to be able to do questionable things when flicked off.

There is an avenue for this:
You can go to the app's info page and tap on "force stop". Now it isnt running anymore.

Another app or the OS can wake it up. For example, if it has permission to do so, it can schedule a specific wake up time. (E.g. 09:00)

Or apps that use google play service for notifications, play services will wake up the app to say it got a message.

de0u

K8y Secret message apps like Session are opening up and going into threads by itself.

I'm aware of a recent thread (#34048) in which such a concern has been discussed. To my eyes that thread has not convinced anybody other than the original poster; several alternate scenarios have been proposed. I would suggest pausing discussion in this thread until at least one person in the other thread, other than the original poster, has been convinced that an unseen force opened the messenger. I suspect that before the GrapheneOS developers might potentially take action it will be necessary that the scenario is believed by quite a few people.