4

In the flow diagram for an Android app activity lifecycle (shown below) there is a route by which the 'App process' is killed and onDestroy() is not called. It seems this is most commonly done to free up memory resources for a different activity.

All that is fine, but how do I test this scenario? Either on device or in the simulator.

enter image description here

Wex
  • 4,434
  • 3
  • 33
  • 47

3 Answers3

2

If you force stop your app, all BroadcastReceivers and also app widgets, which extend BroadcastReceiver, will stop working. See also this SO post by Commonsware

So force stopping the app is not ideal for testing app behavior under low memory conditions. What else can you do?

  • One option: write your own task killer app and use ActivityManager.killBackgroundProcesses(). As the documentation says:

This is the same as the kernel killing those processes to reclaim memory

Community
  • 1
  • 1
Bö macht Blau
  • 12,820
  • 5
  • 40
  • 61
  • Accepting this answer as it seems to have caused the issue I'm trying to track down. I used Xavi Gil's answer, but I think that first option might be the best answer. – Wex Mar 02 '16 at 18:05
  • 1
    @Wex - I used this [code](https://github.com/commonsguy/cw-omnibus/tree/master/Tasks/Nukesalot) by CommonsWare – Bö macht Blau Mar 02 '16 at 18:08
0

Steps:

  1. Navigate to your app
  2. Press home button so the app will not get the onDestroy call
  3. Go to system settings and find the right place to "force close" your app
  4. Navigate back to your app

Important note: DO NOT use back button when leaving your app when you are going to system settings, use home button instead so the app does not get killed.

vilpe89
  • 4,656
  • 1
  • 29
  • 36
  • `use home button instead so the app does not get killed` Just to clear this up: There is no guarantee that your app will not be killed when you press the home button. Have a low resource device and even the default launcher might be "heavy" enough to get all apps in the background get killed by Android. – WarrenFaith Mar 02 '16 at 14:22
  • Yeah I know but this was just one example in the perfect world. – vilpe89 Mar 02 '16 at 14:25
  • `Yeah I know` should have prevented you from mentioning that. – WarrenFaith Mar 02 '16 at 14:26
-1

The easiest and most clean solution to test those life cycle is to enable the "Don't Keep Activities" settings in the developer settings on your device.

This way you even get your activity killed as soon as you start a new activity. So if you press back than the old activity will be recreated.

WarrenFaith
  • 57,492
  • 25
  • 134
  • 150
  • Tell me how this solution goes to that route what he wanted. This simply destroyes the activity through onDestroy... Or am I wrong? – vilpe89 Mar 02 '16 at 14:39
  • Both path are the same. OnDestroy is, as you can see in the docs and in this diagram, not guaranteed to be called. So either your app dies in onStop or your activity is killed and onDestroy might be called. Based on the "not guaranteed to be called" you shouldn't add any code in onDestroy in the first place. – WarrenFaith Mar 02 '16 at 14:47
  • I don't think that enabling "Don't Keep Activities" kills the whole app process. So holes in this one too. You are correct with that code adding stuff tho. It should be in onPause and checked with isFinishing method. – vilpe89 Mar 02 '16 at 15:05
  • When you consider the activity life cycle, both path are the same. The difference between "app process killed" and the "activity destroyed" path is only the lifecycle of the application class and the call to onDestroy. So closed you can get. – WarrenFaith Mar 02 '16 at 15:07
  • Ah now I got it. I've been running little slow today... :) – vilpe89 Mar 02 '16 at 15:16
  • Happens to the best of us :) – WarrenFaith Mar 02 '16 at 15:23