Android Question ExitApplication - I'm confused

JackKirk

Well-Known Member
Licensed User
Longtime User
I have been exploring ExitApplication as a means of managing out of memory errors.

In the Starter service I have:
B4X:
'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:
B4X:
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:
B4X:
Main:Activity_Pause:IsPaused(Starter) false
implying the Starter service was running.

This is inconsistent is it not?
 
Last edited:

JackKirk

Well-Known Member
Licensed User
Longtime User
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...
 
Upvote 0

JackKirk

Well-Known Member
Licensed User
Longtime User
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.
 
Upvote 0

JackKirk

Well-Known Member
Licensed User
Longtime User
OK, so if I want to guarantee a relaunch after an OOM I would have this in the Starter service:
B4X:
'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:
B4X:
Sub Activity_Pause(UserClosed As Boolean)

    If UserClosed Then

        StopService(Starter)
  
        ExitApplication
  
    End If
  
End Sub
Is this correct (aversion to ExitApplication noted)?
 
Last edited:
Upvote 0

JackKirk

Well-Known Member
Licensed User
Longtime User
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...
 
Upvote 0
Top