Don't keep activities - What is it for?

Question

The title is pretty self-explanatory. I understand what this developer option does.

What I don't understand are the following points:

1. Why was that option introduced, in the first place?
2. After all the changes that the framework has seen throughout the years, is it still useful?

I am eager to know the reasons behind this option.

Crewelwork

Answer 1

I believe it's a feature used for debugging purpose.

From the Titanium doc:

Don't keep activities under the Developer Options menu. When this option is enabled, the Android OS will destroy an activity as soon as it is stopped. It is intended to help developers debug their apps. For example, it can simulate the case that Android will kill an activity in the background due to memory pressure. In normal use, it is not recommended to turn this option on because this may lead to unexpected issues on the apps, such as freezes, force closes and reboots.

It sounds like it basically helps testing deterministically how your app behaves when the OS shuts it down due to any reason (out of memory and so on).

So, this replied to point 1. Point 2 is: Yes, I guess :)

EDIT: further references

• On SO How to know "Don't keep activities" is enabled in ICS?
• an interesting thread about that on androidcentral (reply from MagouyaWare)

Mccay

It does not seem to work for me. The behavior with it turned on seems the same as when it is turned off. – Rapid

I'm surprised this answer hasn't been accepted because it answers the question straight to the point +1 – Organic

For example, it can simulate the case that Android will kill an activity in the background due to memory pressure. Can this be true? I mean I would say the entire process is killed instead of a single or few activities when memory is under pressure. – Inculcate

Answer 2

The Android framework may destroy your activity any time it's in the background or backstack, and you should write your activities so they behave correctly when this happens. Exactly what that entails varies depending on what the activity does, but it generally includes implementing onSaveInstanceState(...) and restoring any previous state in onCreate(...).

The "don't keep activities" developer option simply changes the framework's behavior so it will always destroy your activity when it goes into the background or backstack. This allows you to test how your activity responds to what is normally a rare occurrence.

A link cited in another answer says:

In normal use, it is not recommended to turn this option on because this may lead to unexpected issues on the apps, such as freezes, force closes and reboots.

This is incorrect. If your activities are written properly, the only effect of having "don't keep activities" turned on should be (possibly) slightly higher battery and CPU usage from constantly saving and restoring persistent state. Any apps that exhibit "unexpected issues" or force closes when this option is on are broken and need to be fixed. As a developer, I habitually leave "don't keep activities" turned on all the time. I've seen a lot of buggy apps, even some of Google's own. But it's never caused a reboot, and I don't think there's any way it could.

Orchid

FYI, activities are only destroyed by the system when the process is destroyed. Common misconception that was cleared up by Dianne Hackborn of the core android team. – Microcurie

@skaar When there's a difference between the spec and the implementation, you should always write to the spec. – Orchid

@KevinKrumwiede : Does 'don't keep activity' also terminate the application? For eg - when you open the 1st screen of the app and press the home button - And suppose the 'don't keep activity setting' was on. WIll android destroy the application along with the activity? – Pyromancy

@KevinKrumwiede : I am asking because the application class's 'onLowMemory()' and 'onTerminate()' are not being called. – Pyromancy

@Pyromancy That depends on exactly what you mean by "terminate the application." The framework may decide to kill the VM and process. But Application has no teardown lifecycle methods, so nothing will be called on it. – Orchid

Keeping the option always on is not a good idea, when it's low on memory android will kill the entire process, not just singles activities. Which means that don't keep activites might create artificial situation that would never happen otherwise. As @Microcurie wrote, Dianne Hackborn made it clear, here's her SO answer – Freeboard

@Freeboard It creates a situation that is documented to be possible but doesn't currently happen in practice. That may change in a future Android version. – Orchid

@KevinKrumwiede thanks for the reply, I just asked a question about this, feel free to weigh in – Freeboard

onSaveStateInstance does not fire for me when the Activity is killed by the OS. Any idea why? – Mischievous

@Mischievous That's not the right name, so if you wrote a method with that name and didn't use @Override, it would compile but do nothing. If you got the name right, it should be called immediately before or after onStop. AFAIK, Android does not kill individual activities, although the docs suggest it could, so you should assume that it might someday. – Orchid

Answer 3

I had at least two issues when this was enabled:

1) I was getting an error "Unable to complete previous operation due to low memory" that prevented uploading of any attachment to a website using Chrome, but not with Firefox. I found elsewhere that enabling the "Don't keep activities open" option could have been the problem - it was.

2) I was unable to move files to the SD card. Disabling the "Don't keep activities open" option got round this problem.

Also found elsewhere it can slow things up generally because caching is compromised.

Sometimes apps that I had moved to the SD card suddenly 'greyed out' and became inaccessible. Rebooting solved this, but was becoming an irritation. Too soon to tell if that was another problem caused by this 'feature'.

These problems (and issues with the microphone in Zoom) all started within the last month. I don't know how DKAO ever got enabled, but it's a no-no as far as I'm concerned.

Vastitude