really Thank You very Much 
1 Like
The Android Developer link pretty much describes the distinction between onPause and onStop.
Essentially onPause is not killable by the OS, but onStop is.
So do anything important in onPause, as onStop may not fully execute....
Did you check it yourself?
I had tested it extensively on dozens of devices at the time, and as I already pointed out, after on Pause (at least on non-tablets) onStop is always executed. As you can see in my tests, I was able to store something with onPause as well as with onStop. However, it may be that this behaves differently on tablets (as Evan Patton said; I haven't tested it).
No, I did not test it myself, but I do believe what I read on the Android Developer page (which is linked to right at the top of your extension description)
I'm NOT saying onStop never happens straight after onPause, but the docs say it is possible that onStop may not reach the end of execution.
The OS may destroy the app before it concludes - this may not always be the case, and hence why it appears to be OK to use onStop.
BUT as they do document it, I'd consider that it is risky to reliably use onStop for important things like saving configs, but onPause will not get aborted by the OS so that's where it should take place.
A distinct but important difference I'd say 
Cheers, Ray
But what I will add is your extension has proven invaluable to solve a problem I had with the Paho MQTT client extension entering a world of networking hurt when the phone shut shop.
All was good when open and running, but once the app was put to sleep it would then have problems once awakened.
So now I force the connection closed in onPause, then reopen in onResume - far more stable.
So thank you very much for providing this extension.
1 Like
As I said before, this may be relevant for tablets.
What does not work?
I checked it on Android 14 & 15. No problem at all.
1 Like
Have you tested in a compiled APK?
The app is not in the background (but still visible). Press the Home button of your device and then come back. Then all 3 events (Pause, Stop, Resume) are triggered, in this (chronological) order.
See also here: Extension - Activity Lifecycle of an app (onPause → onStop → onResume) - #7 by Taifun and here: Extension - Activity Lifecycle of an app (onPause → onStop → onResume) - #8 by ewpatton
...or use this method:
yes this is compiled app not connected to live testing
What he showed in the first video, I think it should trigger OnPause
Use three 3 labels (Label1, Label2, Label3, one for each event) and try again.
Use the Notifier LogInfo method together with Logcat to find out, that the OnPause event gets triggered
What you see in the video is a snapshot of the last screen which was active before moving to the back
Taifun
1 Like
okay will try
