How to gracefully terminate an Android Toga app ?

[MarusGradinaru]

I have a button on my toga.App UI and when I press it I want the app to be terminated in a gracefull way, doing all cleanups, and be removed from the Android task manager, like it never existed.

So far, I've done like this:

In Toga:

  def onBStopPress(self, widget):
    if onAndroid: 
      from org.beeware.android import MainActivity
      activity = MainActivity.singletonThis
      activity.finishAndRemoveTask()
    self.exit() 

in MainActivity.onDestroy:

        super.onDestroy();
        Log.d(TAG, "MainActivity Destroyed");
        System.exit(0);

And it completelly terminate the app process. But it says that some cleanup was skipped:

D/MainActivity: MainActivity Destroyed
I/.marus.raspinas: System.exit called, status: 0
I/AndroidRuntime: VM exiting with result code 0, cleanup skipped.

So, what is the proper way to exit an Android Togga app ?
The AI recommended me to use "android.os.Process.killProcess(android.os.Process.myPid());" as it does more cleanup than "System.exit(0);", but it trows a big exception:

D/MainActivity: MainActivity Destroyed
I/Process : Process is going to kill itself!
I/Process : java.lang.Exception
I/Process : at android.os.Process.killProcess(Process.java:1344)
I/Process : at org.beeware.android.MainActivity.onDestroy(MainActivity.java:258)
I/Process : at android.app.Activity.performDestroy(Activity.java:8821)
I/Process : at android.app.Instrumentation.callActivityOnDestroy(Instrumentation.java:1473)
I/Process : at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:5611)
I/Process : at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:5664)
I/Process : at android.app.servertransaction.DestroyActivityItem.execute(DestroyActivityItem.java:47)
I/Process : at android.app.servertransaction.ActivityTransactionItem.execute(ActivityTransactionItem.java:45)
I/Process : at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
I/Process : at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
I/Process : at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2394)
I/Process : at android.os.Handler.dispatchMessage(Handler.java:106)
I/Process : at android.os.Looper.loopOnce(Looper.java:211)
I/Process : at android.os.Looper.loop(Looper.java:300)
I/Process : at android.app.ActivityThread.main(ActivityThread.java:8296)
I/Process : at java.lang.reflect.Method.invoke(Native Method)
I/Process : at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:559)
I/Process : at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:954)
I/Process : Sending signal. PID: 14297 SIG: 9

[freakboy3742]

The short answer is "you don't." Mobile apps don't generally have "quit menus" or an equivalent action to exit, and as a result, we don't expose app.exit() as an API at present.

There has been some discussion about this in the past; see #1623 for details.

[freakboy3742]

Correct - but that's because, for most purposes you don't ever exit an Android app. Mobile apps can be suspended - but they're generally not exited. There is room for Toga to provide better hooks for mobile app lifecycle events; but "exit" in the desktop sense isn't really one of those events. Again, see #1623 for a discussion on the topic.

[MarusGradinaru]

Every time I'm done working with my Android phone, before I close the screen, I enter Task Manager and I tap the X button to close all active apps. I don't like keeping active apps that can drain my battery... If I'm done with an app, I don't see any reason for it to stay active and consume resources.

[mhsmith]

That's a reasonable point, and I've seen other people do the same thing. As #1623 says, there would be some use for an event, or a variation of an existing event, which notifies the app that it's exiting without giving an option to reject it.

[freakboy3742]

The "shut down all unused apps" behavior is definitely common, but it's worth pointing out that the benefit to system resources is somewhere between futile and negative.

Unless an app has actually installed a background task (such as a continual location tracker), it isn't using resources by sitting in the background. It takes no more energy to hold a memory bit at 0 than it does at 1. If the app is in memory and inactive, it doesn't cost any more resources to keep it in memory, and the operating system needs more memory to run another app, it will page the least recently used app out of memory to recover resources. By forcing shutdown, you force that paging out - which takes resources because you are using CPU to perform the paging operation. And if you then give the app focus again, you lose any benefit of the app already being in memory and configured, and you use resources to load it back into memory again, and run the "cold start" configuration mechansim (which is, by definition, more work than the "warm start" of bringing an app back from background in-memory state). So, this practice of "force shutdown of apps", in aggregate, uses more system resources than "just leaving them there", (unless, as stated, they're performing background work - in which case the reason you keep them in memory is so that they can run in the background).

Regardless - that doesn't remove the need for a handler for the event, and other hooks into the mobile app lifecycle, as discussed in #1623. For that matter, we should probably expose the analogous hooks on desktop, as laptops can be put to sleep as well, and there may be activities that need to be triggered on sleep and on wake.

[mhsmith]

the benefit to system resources is somewhere between futile and negative

That's probably true, especially on newer versions of Android where they've become a lot more aggressive about limiting what an app can do in the background.

Also @MarusGradinaru, you should be aware that just because an app is visible in the "task manager", doesn't mean it's actually running. When Android shuts down a background app, it saves a screenshot of its last state, on the assumption that the app will be able to restore that state the next time you open it. That screenshot may literally be the only thing left in memory.