Activity.Finish() Called But Activity Stays Loaded in Memory

Activity.finish() called but activity stays loaded in memory

You don't control when your app leaves main memory, the OS does. Look closely at Activity.finish...

Call this when your activity is done
and should be closed. The
ActivityResult is propagated back to
whoever launched you via
onActivityResult().

Note that is says nothing about memory. As to calling Activity.onResume, that's exactly what you would expect for the lifecycle; remeber that onResume is not just called after a resume but even when the app is first launched after onCreate.

While not exactly what you asked I suggest you read this article about exit buttons which goes on to say something very important

[Activity.finish] is exactly equivalent to hitting the back button.

Android: Application still running after call finish()

Duplicated Question!

You can't control when your app leaves the main memory, the OS does. Look closely at Activity.finish()

I think there will be no way of stopping the application completely, avoiding battery and memory consumption after the activity is destroyed.

Answer(Link) is :
Activity.finish() called but activity stays loaded in memory

Android startactivity and stacks keep in memory

In the Android Manifest in the [activity] tag you can specify android:noHistory - Whether or not the activity should be removed from the activity stack and finished (its finish() method called) when the user navigates away from it and it's no longer visible on screen —"true" if it should be finished, and "false" if not. The default value is "false".
A value of "true" means that the activity will not leave a historical trace. It will not remain in the activity stack for the task, so the user will not be able to return to it. This attribute was introduced in API Level 3.

Using finish() to end an activity manually: To or Not to?

If you call finish(), android takes your activity out of the activity stack. If you don't call it, the activity remains in the stack and if you press back button on your android phone, the default behavior is that the android will pop back the top activity on the stack. You can of course override the back button functionality. The most common use of calling finish on an activity is when you don't want to comeback to this activity, like for example if you have a splash screen activity. You would want to call finish on it when you move away from it. Other use cases totally depend on application specific navigation hierarchy and performance goals.

onCreate() called while Activity is stopped (but not destroyed). Only after installation

Ok, this is how I solved it, in case anyone else bumps into this wall.

This might affect especially people coming from the Processing Developing Environment, as it converts a "Processing sketch" into the only activity of the project.

The original problem (Android managing apps in a different -wrong?- way when launching them from the Package Installer) is well explained here: https://code.google.com/p/android/issues/detail?id=26658

Solutions posted there might solve most cases,but if -like me- your launcher activity is the one that carries out all the work, you will need to create a specific launcher activity that just starts the main one... and commits suicide when the Android bug happens.

Add this bit to the onCreate() method of the launcher activity:

if (!isTaskRoot()) {
 finish();
 return;
} 

I hope this helps.

Having trouble freeing up memory in android app after Activities are done running

There are a couple of things to consider here. First, take a good look at the life-cycle of an activity.

Now, if you want to make the GC run on an activity, calling finish() would achieve this. So, now the control will go to the onDestroy().

According to the documentation, the activity is destroyed and all its resources are queued for garbage collection, because a reference to this activity becomes inaccessible. So, all memory that was being used by the activity will be freed during next GC cycle.

To see, if that is indeed happening, add this to the onDestroy() method for your activity: Runtime.getRuntime().gc().

Now, to remove the previous activity from the stack, I will refrain from duplicating some great answers like these, StackOverflow Post_1 StackOverflow Post_2.

How to release memory when activity goes to stack?

Activity's resources (which are not released in onPause, onStop, ...) do not get released when the Activity goes to the background.

• You can remove the background in onPause(), this way the GC will
  be able to destroy it. However, the "empty background" will be there
  for a fraction of a second. It is important to mention, you have to
  do this in onPause(). (I think changes after onPause (like changes in onStop) take effect when the Activity comes to the foreground, so the reference to the background would still be hold by the Activity while it is in the background.)
• Other way is to call finish(), and manage the stack yourself. You
  would have to remember the starting Activity, and navigate to it
  manually when the user presses the back button.
• And the last solution that pops into my mind is to make every Activity that contains huge resources a separate process by declaring the android:process attribute in the manifest. This way all of your Activities would have a separate full sized heap to use.

Activity instance remains in the memory after onDestroy()

Yes, the system works fine.
When you press the back button, your activity is removed from the activity stack.

onDestroy() may have been called, this doesn't mean that the instance was actually unallocated from the memory.

Pro and cons calling finish

I want to know what are the pro and cons when you try to open a new activity with android and destroy the previous one straight away by calling finish.

Either you want the user to return to the previous activity via the BACK button, or you do not.

• If you want the user to return to the previous activity via BACK, do not call finish()

• If you do not want the user to return to the previous activity via BACK, there are a multitude of options, depending upon where you do want the user to go when the user presses BACK

People think that is a bad idea because Android can take care of the activity and drop them when there is too much memory used

No, Android does not do this.

is better to kill the activity with finish or leave android to have this activity in the background for who knows for how long time?

It is "better" to have the activity implement onTrimMemory() and reduce its memory footprint as needed. Do not harm the user expectations of the BACK button.

that you kind of help the system to GC the activity that you closed and make sure that the user wont need to tap the back button 100 times before getting out of the application

Few users will "tap the back button 100 times". They will press HOME, or bring up the overview screen (a.k.a., recent-tasks list), or navigate to another app by other means.

Now, that being said, there will be times when you want to clear the task (back stack), again with an eye towards providing a logical flow for the user. For example, in an email app:

• The user launches the app, and a fresh task is created, with the user going to the app's launcher activity, which shows the messages in the user's inbox (A)

• The user taps on a "search" action bar item, bringing up a search activity, where they can search by various criteria (B)

• The user fills in search criteria and clicks the "Go!" button, which does the search and shows matching email messages (C)

• The user taps on an email message, bringing up an email-viewing activity (D)

• The user taps a "delete" action bar item, which should delete the message and return the user... somewhere

If you believe that the user should return to the search results (C), you could call finish() in D. If, however, you believe that the user should return to the inbox (A), you would call startActivity() on A with appropriate flags (e.g., Intent.FLAG_ACTIVITY_CLEAR_TASK), to clear out the back stack and return the user to A.

In sum: do NOT call finish() to deal with heap space; implement onTrimMemory() instead. However, if navigation calls for finish(), then use it.

---

Related Topics