Android Question ExitApplication - I'm confused

[JackKirk]

I have been exploring ExitApplication as a means of managing out of memory errors.

In the Starter service I have:

'Return true to allow the OS default exceptions handler to handle the uncaught exception.
Sub Application_Error (Error As Exception, StackTrace As String) As Boolean

    ExitApplication

    'Do not allow normal OS default exceptions handler to handle uncaught exception
    Return False

End Sub

When the ExitApplication is executed the app dies and is immediately relaunched - but with its memory reset.

According to Erel in this post:
https://www.b4x.com/android/forum/threads/exit-application-and-activitiy-finish.26557/#post-161247
the immediate relaunch is because:

ExitApplication will kill the process. If there is any service running then the process will be restarted. You should close all activities and services before calling it.

As the ExitApplication statement is in the Application_Error sub which in turn is in the Starter service then obviously a service is running and this explains why the app is immediately relaunched.

HOWEVER

In the Main activity of the app I have:

Sub Activity_Pause(UserClosed As Boolean)

    If UserClosed Then

        Log("Main:Activity_Pause:IsPaused(Starter) " & IsPaused(Starter))
   
        ExitApplication

    End If

End Sub

When the app is running normally (no OOM problems), if I tap the Back button (thus firing the above sub), then the app dies but is not immediately relaunched.

But the log says:

Main:Activity_Pause:IsPaused(Starter) false

implying the Starter service was running.

This is inconsistent is it not?

 

[Erel]

ExitApplication is not the correct solution. Why are there memory issues?

 

[JackKirk]

Erel,

I am still working on sorting things in this thread:
https://www.b4x.com/android/forum/t...ty-containing-a-google-map.68023/#post-431953

I believe I am getting closer to solving it but I am not yet sure.

To be sure I am running long term stress tests - programmatically randomly running through all the activities with constrained available memory.

This takes a lot of waiting.

In the meantime I am looking at workarounds - what to do if I can not solve it - or maybe just added insurance.

If the app were published with the OOM problem unresolved then obviously every so often the user is likely to encounter it.

If the app instance blows up with OOM and then stays in memory then attempts at restarting the app will bring up the current (memory allocation clogged) instance - to get out of this problem the user would have to know how to manually destroy the app instance - hardly user friendly.

Putting ExitApplication in Starter.Application_Error seems to solve this issue pretty well.

Also, users will encounter it more frequently if the app instance is sitting in memory between uses with its memory allocation semi-clogged.

If I destroy the app instance after every use by using ExitApplication in Main.Activity_Pause then the likelihood of the user encountering the problem at all is diminished.

None of this is really to the point of the question in post #1 - which basically is why does ExitApplication behave differently in different settings.

Could you also give some explanation as to why ExitApplication should be avoided (aside from protocol/accepted practice etc.).

Thanks as always for your efforts...

 

[Erel]

ExitApplication should be avoided because in Android the OS manages the processes life cycle. When you call ExitApplication the OS thinks that the process has crashed.

To minimize the chances that the OS will restart the process, make sure to first stop all services and close the activities.

 

[JackKirk]

ExitApplication should be avoided because in Android the OS manages the processes life cycle. When you call ExitApplication the OS thinks that the process has crashed.

I understand this.

If you are faced with an unresolvable OOM problem and an ExitApplication induced pseudo crash and relaunch cleans it up - surely that is reasonable.

To minimize the chances that the OS will restart the process, make sure to first stop all services and close the activities.

In post #1 I point out (I think) that restarting the process is not guaranteed if a service is still running - and was looking for an explanation (I guess) as to exactly what circumstances will cause a restart to occur.

 

[Erel]

It is hard to say whether the OS will restart the crashed process or not. Using a sticky service will increase the chances that it will be restarted.

 

[JackKirk]

OK, so if I want to guarantee a relaunch after an OOM I would have this in the Starter service:

'Return true to allow the OS default exceptions handler to handle the uncaught exception.
Sub Application_Error (Error As Exception, StackTrace As String) As Boolean
  
    'Just in case ExitApplication does not cause a restart
    StartServiceAt("", DateTime.Now + 5000, False)
  
    ExitApplication
  
    'Do not allow normal OS default exceptions handler to handle uncaught exception
    '(this statement is probabaly superfluous - ExitApplication supposedly cans
    'app there and then)
    Return False
  
End Sub

And if I want to destroy the app instance after every use and guarantee no relaunch then in Main activity of the app I should have:

Sub Activity_Pause(UserClosed As Boolean)

    If UserClosed Then

        StopService(Starter)
  
        ExitApplication
  
    End If
  
End Sub

Is this correct (aversion to ExitApplication noted)?

 

[Erel]

I don't think that there is any way to guarantee a relaunch after a call to ExitApplication. The best thing that you can do is to try to reproduce the OOM error in small project and then we can help you solve it.

Many applications use Google Maps.

 

[JackKirk]

The best thing that you can do is to try to reproduce the OOM error in small project

Erel, I've tried to do this without success.

My stress testing on my android device (Samsung S5) is tending to indicate stability (i.e. no OOM) when the effective maximum memory is about 152MB (compared with a "standard heap" limit of 128MB).

I'm beginning to think maybe I've just got a large app on my hands.

I'm reluctant to show the world my app - I'd like to think it has some commercial value - if I emailed it to you asis would you be willing to have a look at it?

Regards...

 

[Erel]

If this error doesn't happen when you set the large heap option then I think that it is fine...