23

One query I would like to have if anyone could answer it like: Do not keep activities options to be checked during testing android mobile application from developers options.

I used it in my application and found that my application behaves inappropriately and crashed when I switched ON Do not keep activities in android.

My questions were few :

1: How much this option will affect mobile applications?

2: What exactly does this do?

It sounds like an app killer,I notice in the Developer Options there is a box that says Do not keep activities - destroy every activity as soon as the user leaves it .

Does this create any positive and or negative functionality on my apps?

Does that mean if I open an app and as soon as I leave it, it actually closes that app and I wouldn't see it in the task manager to manually kill it? If so, isn't this a good thing to keep the RAM usage low?

What were the advantages and disadvantages of using it while keeping Do not keep activities ,Kindly share the experience on it.

dinesh sharma
  • 3,312
  • 1
  • 22
  • 32
BlueBerry - Vignesh4303
  • 587
  • 1
  • 13
  • 36

6 Answers6

13

How much this option will affect mobile applications?

If they are well writen this option will not affect them.

What exactly does this do?

If you have this option turned on only variables kept in activity with method onSaveInstanceState will be saved when you go to another activity or app goes in background. All other variables will be removed immediately. When this option is off there is possibility that these variable will be kept

Does that mean if I open an app and as soon as I leave it, it actually closes that app and I wouldn't see it in the task manager to manually kill it?

No it means that all not kept variables will be removed. When you in example press home button.

Does this create any positive and or negative functionality on my apps?

No it only helps to develop application properly. It helps to predict unexpected situations.

Kirill
  • 7,580
  • 6
  • 44
  • 95
Adam Radomski
  • 2,515
  • 2
  • 17
  • 28
  • 3
    Not really. When this is enabled, `finish()` is called on an `Activity` when that `Activity` is no longer in the foreground. It doesn't explicitly reset/remove any variables. – David Wasser Jan 20 '14 at 11:15
  • 1
    I agree with David Wasser. I am running KitKat 4.4.2 on a Nexus 5 and have found that with this setting enabled that the Activity will in fact hit onStop() or onDestroy() when it is backgrounded, however, when returning to the foreground onCreate() is not necessarily hit and member variables that were not saved off still hold their original value. I believe this is because the system did not actually destroy the activity even though it had the option to (there was not memory shortage that forced the system to actually remove the object from memory). – neonDion May 29 '14 at 14:50
4

Do not Keep Activities is purely a developer option that will help you to check if

  1. You have Saved the state of the activity, before it goes background.

2̶.̶ ̶H̶a̶n̶d̶l̶e̶d̶ ̶L̶o̶w̶ ̶M̶e̶m̶o̶r̶y̶ ̶S̶i̶t̶u̶a̶t̶i̶o̶n̶s̶ ̶p̶r̶o̶p̶e̶r̶l̶y̶(̶i̶n̶ ̶w̶h̶i̶c̶h̶ ̶c̶a̶s̶e̶ ̶t̶h̶e̶ ̶a̶c̶t̶i̶v̶i̶t̶y̶ ̶w̶i̶l̶l̶ ̶b̶e̶ ̶d̶e̶s̶t̶r̶o̶y̶e̶d̶)̶.̶ ̶

Edit : This option does not emulate Low memory Situations. When the device experiences low memory, the system might ask the activity to Drop by calling Finish() or it may go ahead and kill the process completely, as the comment says.

It is still good to develop with this option enabled. You will have to properly code the onSaveInstanceState() and onRestoreInstanceState() methods. By doing this, even if the process gets killed, when the user navigates back to this activity, onCreate() will be called with the savedInstanceState that was saved in the onSaveInstanceState(Bundle) method.

siddharthsn
  • 1,709
  • 1
  • 21
  • 32
  • 6
    Comment to your second item: Not really. In real low-memory conditions Android will simply kill the process. It will not call `finish()` on existing Activities, and it does not selectively kill Activities. – David Wasser Jan 20 '14 at 11:09
1

ADVANTAGE :

Developer can check the abnormal behaviour of their application and fix the cases of low memory - framework kills the application

DISADVANTAGE :

If user has unknowingly enabled this option, then the device will work slow and every activities will be re-created across user navigation on his device. This will hinder user work

Very good answer is given in xda developer forum about usage of this option

Kushal
  • 8,100
  • 9
  • 63
  • 82
0

As an addition to answers above is another, not visible from the first look disadvantage that you can test only activity destroying/recreation issues with this option, but not the whole process of application recreation due to memory lack or other system conditions, because all independent from activity memory stays.

Imagine that you have some singleton on which your classes are dependent. After system have killed app your singletons will be also cleared and restored with beginning state in case you haven't implemented its restoring by yourself. So, despite of your activity view state & fields would be restored in case onSaveInstanceState & onRestoreInstanceState was implemented correctly, that's not guarantee a correct app behavior after restoring, even on the particular screen. That should be considered

So to test such fully case you should stop application manually, but don't drop it from task manager. Easiest way - with stop red square button in android studio. And open app again.

See more

Beloo
  • 9,723
  • 7
  • 40
  • 71
0

Android OS has this property to wipe the activities running in background if the device is on low memory, prioritising only activity which is running on the top.

The option Do not keep activities in side the Developer options allows developers to replicate the same scenario easily.

Ideally a well developed Android application should handle onSaveInstanceState and onRestoreInstanceState saving and restoring the local variables of all activities.

More details are given here in official Android developer site.

Ankur
  • 1,268
  • 18
  • 22
-1

"Do not keep activities" advantage is that it emulate system low memory situation when it start killing different parts of the app. Your app must maintain this situation. Disadvantage is that this option is kind of stricted and kill only activities when there is no way emulate this for services

Androider
  • 257
  • 3
  • 11
  • 5
    Not really. In real low-memory conditions Android will simply kill the process. It will not call `finish()` on existing Activities, and it does not selectively kill Activities. – David Wasser Jan 20 '14 at 11:08
  • "Do not keep activities" will not just call finish(). It will emulate system kill, that mean when you will back to your activity it will call onCreate() with savedInstance witch can have some saved params, all fragments that has setRetainInstance(true) will restore their class members. Now why each activity - you don't know where user can leave your app to a phone call or email so you need to check them all. – Androider Jan 20 '14 at 14:59
  • 3
    No, it doesn't "emulate system kill". To "emulate system kill" it would have to kill the process, which this setting **does not do**. In real low memory conditions Android does not selectively kill Activities, it merely kills the process. There is a difference and the difference is significant. – David Wasser Jan 20 '14 at 15:19
  • I agree that it does not like system kill and thats why i wrot the disadvantage for it but it defenetly can help in tests. On my oppinion its good way to test activity or fragment restoring process. The only problem that this will not cover service restoring. – Androider Jan 20 '14 at 17:32
  • 5
    I wasn't trying to imply that this setting isn't useful for testing. However, you need to understand what it actually does. OP is asking for a clarification of what it actually does. Therefore, an incorrect answer isn't of much value to him or anyone who reads this. – David Wasser Jan 20 '14 at 18:28
  • As other comments have said, this is an incorrect description of what is going on. Apparently the answerer wishes to complain that android does not have a similar feature for services. That desire to complain about something else that is missing, does not justify the presence of an answer that is so confused - Not helpful answer. – ToolmakerSteve Sep 27 '15 at 08:05