how to simulate low memory condition on the device or emulator.

[cht]

for the developer, we must to deal with the "low memory" exception.
when other applications run forground, sometimes our application will
be killed for "low memory" reason .

so we have to test our application's performance under this condition.
but it is not easy to case a low memory condition. is there a good way
to set up condition?

thank you!

--

You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[lbcoder]

You can do this simply by using up memory.
Write a console program that has a malloc() call in a loop. Run that
console application from a different foreground application. Then just
watch the logcat for when your application gets bumped from memory.

Post by cht
for the developer, we must to deal with the "low memory" exception.
when other applications run forground, sometimes our application will
be killed for "low memory" reason .
so we have to test our application's performance under this condition.
but it is not easy to case a low memory condition. is there a good way
to  set up condition?
thank you!

--

You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Dianne Hackborn]

You can just use the shell to kill your app's process. All the system does
when low on memory is select processes to kill to reclaim more, so your code
will be going through pretty much the same experience if you manually kill
it yourself.

Post by cht
for the developer, we must to deal with the "low memory" exception.
when other applications run forground, sometimes our application will
be killed for "low memory" reason .
so we have to test our application's performance under this condition.
but it is not easy to case a low memory condition. is there a good way
to set up condition?
thank you!
--
You received this message because you are subscribed to the Google Groups
"android-platform" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/android-platform?hl=en.

[lbcoder]

Really?
I was under the impression that there were several stages to
application shutdown, even in the event of memory shortages... onPause
(), onStop(), onDestroy()...

I.e., user selects to load a new activity, system calls onPause() on
current activity, system launches new activity (onCreate(), etc.),
system calls onStop() on old activity, system runs low on memory -->
runs onDestroy() on old activity. Yes, I realize that onStop() and
onDestroy() aren't guaranteed to be run, but it isn't exactly clear
what condition affects whether these do or do not run.... Is it
related to the activity being within the same process as the
foreground activity? I.e., if it *is* within the same process, then it
runs the sane shutdown on the old activity, if it isn't, it brutally
kills the old processes?
"onDestroy(): ....or because the system is temporarily destroying this
instance of the activity to save space."

Note that both cases *do* need to be tested independently, and killing
the process wouldn't be suitable for both cases (old activity in same
process as foreground activity, old activity in different process than
foreground activity).

You can just use the shell to kill your app's process.  All the system does
when low on memory is select processes to kill to reclaim more, so your code
will be going through pretty much the same experience if you manually kill
it yourself.

Post by cht
for the developer, we must to deal with the "low memory" exception.
when other applications run forground, sometimes our application will
be killed for "low memory" reason .
so we have to test our application's performance under this condition.
but it is not easy to case a low memory condition. is there a good way
to  set up condition?
thank you!
--
You received this message because you are subscribed to the Google Groups
"android-platform" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.

[Dianne Hackborn]

Post by lbcoder
Really?
I was under the impression that there were several stages to
application shutdown, even in the event of memory shortages... onPause
(), onStop(), onDestroy()...

Nope. Processes stay running until their memory is needed elsewhere, at
which point the kernel kills the process in its tracks.

Post by lbcoder
I.e., user selects to load a new activity, system calls onPause() on
current activity, system launches new activity (onCreate(), etc.),
system calls onStop() on old activity, system runs low on memory -->
runs onDestroy() on old activity. Yes, I realize that onStop() and
onDestroy() aren't guaranteed to be run, but it isn't exactly clear
what condition affects whether these do or do not run.... Is it
related to the activity being within the same process as the
foreground activity? I.e., if it *is* within the same process, then it
runs the sane shutdown on the old activity, if it isn't, it brutally
kills the old processes?

They don't run if the process is killed to free memory for others. The
decision about what order to kill processes in is driven by the lifecycle of
the components in the process, as described in the docs.

Post by lbcoder
"onDestroy(): ....or because the system is temporarily destroying this
instance of the activity to save space."

It may also ask individual activities to be destroyed if the process has a
larger number actively running in it. In practice this is a very rare case.

Post by lbcoder
Note that both cases *do* need to be tested independently, and killing
the process wouldn't be suitable for both cases (old activity in same
process as foreground activity, old activity in different process than
foreground activity).

The onDestroy() being called case is effectively the same as switching
orientation. If you are not skipping normal orientation switching (via the
activity being destroyed and restarted), then this is all you need to test.

And as I said, the situation when onDestroy() is called because of too many
activities is very rare, and something you would need to do some work to
make happen in your app.

[Kevin Kowalewski]

Hi Dianne,

Which signal is sent to processes on low memory?

Seems like the onDestroy method of my service is not being called.
Hopefully its not SIG 9.

Thanks,
Kevin

Post by Dianne Hackborn

Post by lbcoder
Really?
I was under the impression that there were several stages to
application shutdown, even in the event of memory shortages... onPause
(), onStop(), onDestroy()...

Nope. Processes stay running until their memory is needed elsewhere, at
which point the kernel kills the process in its tracks.

Post by lbcoder
I.e., user selects to load a new activity, system calls onPause() on
current activity, system launches new activity (onCreate(), etc.),
system calls onStop() on old activity, system runs low on memory -->
runs onDestroy() on old activity. Yes, I realize that onStop() and
onDestroy() aren't guaranteed to be run, but it isn't exactly clear
what condition affects whether these do or do not run.... Is it
related to the activity being within the same process as the
foreground activity? I.e., if it *is* within the same process, then it
runs the sane shutdown on the old activity, if it isn't, it brutally
kills the old processes?

They don't run if the process is killed to free memory for others. The
decision about what order to kill processes in is driven by the lifecycle
of the components in the process, as described in the docs.

Post by lbcoder
"onDestroy(): ....or because the system is temporarily destroying this
instance of the activity to save space."

It may also ask individual activities to be destroyed if the process has a
larger number actively running in it. In practice this is a very rare case.

Post by lbcoder
Note that both cases *do* need to be tested independently, and killing
the process wouldn't be suitable for both cases (old activity in same
process as foreground activity, old activity in different process than
foreground activity).

The onDestroy() being called case is effectively the same as switching
orientation. If you are not skipping normal orientation switching (via the
activity being destroyed and restarted), then this is all you need to test.
And as I said, the situation when onDestroy() is called because of too
many activities is very rare, and something you would need to do some work
to make happen in your app.
--
Dianne Hackborn
Android framework engineer
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

[Dianne Hackborn]

On Tue, Jul 31, 2012 at 11:42 AM, Kevin Kowalewski <

Post by Kevin Kowalewski
Which signal is sent to processes on low memory?

The process is killed, period. It is SIG KILL.
--
Dianne Hackborn
Android framework engineer
hackbod-***@public.gmane.org

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

[Octo]

When this happens Android seems to remember which activity to start.

For instance:
- start your app opens activity1
- do something opens activity2 and finishes activity1
- go play with other applications or leave device idle until your process
is killed by Android
- re-open your app by clicking on the icon
- the app is opened on activity2

When I kill the process manually, it always re-open on activity1.

Post by Dianne Hackborn

Post by lbcoder
Really?
I was under the impression that there were several stages to
application shutdown, even in the event of memory shortages... onPause
(), onStop(), onDestroy()...

Nope. Processes stay running until their memory is needed elsewhere, at
which point the kernel kills the process in its tracks.

Post by lbcoder
I.e., user selects to load a new activity, system calls onPause() on
current activity, system launches new activity (onCreate(), etc.),
system calls onStop() on old activity, system runs low on memory -->
runs onDestroy() on old activity. Yes, I realize that onStop() and
onDestroy() aren't guaranteed to be run, but it isn't exactly clear
what condition affects whether these do or do not run.... Is it
related to the activity being within the same process as the
foreground activity? I.e., if it *is* within the same process, then it
runs the sane shutdown on the old activity, if it isn't, it brutally
kills the old processes?

They don't run if the process is killed to free memory for others. The
decision about what order to kill processes in is driven by the lifecycle
of the components in the process, as described in the docs.

Post by lbcoder
"onDestroy(): ....or because the system is temporarily destroying this
instance of the activity to save space."

It may also ask individual activities to be destroyed if the process has a
larger number actively running in it. In practice this is a very rare case.

Post by lbcoder
Note that both cases *do* need to be tested independently, and killing
the process wouldn't be suitable for both cases (old activity in same
process as foreground activity, old activity in different process than
foreground activity).

The onDestroy() being called case is effectively the same as switching
orientation. If you are not skipping normal orientation switching (via the
activity being destroyed and restarted), then this is all you need to test.
And as I said, the situation when onDestroy() is called because of too
many activities is very rare, and something you would need to do some work
to make happen in your app.
--
Dianne Hackborn
Android framework engineer
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

[Dianne Hackborn]

Post by Octo
When this happens Android seems to remember which activity to start.
- start your app opens activity1
- do something opens activity2 and finishes activity1
- go play with other applications or leave device idle until your process
is killed by Android
- re-open your app by clicking on the icon
- the app is opened on activity2
When I kill the process manually, it always re-open on activity1.

Are you killing them while in the foreground? If the app is in the
foreground, it hasn't had a chance to save its state, so it can't be
restored. This is the reason behind much of the activity lifecycle, for
activities to go into the background in a controlled way with their state
being saved along the way, so once there their process can be killed as
needed.
--
Dianne Hackborn
Android framework engineer
hackbod-***@public.gmane.org

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

[Shai Barack]

I'm not sure I understand your question, but if you're just looking to
trigger your application's onTrimMemory callbacks, then you can use this:

adb shell am send-trim-memory <process-name> <level>

e.g. adb shell am send-trim-memory com.example.app MODERATE

Post by cht
for the developer, we must to deal with the "low memory" exception.
when other applications run forground, sometimes our application will
be killed for "low memory" reason .
so we have to test our application's performance under this condition.
but it is not easy to case a low memory condition. is there a good way
to set up condition?
thank you!