Getting kill signal on Android

Paul Colby

Disclaimer: I know a lot about how Qt's Android support works, but since there's been no definitive answers yet, I'll take stab in the dark... ;)

Looking at some Android docs, it looks like you'd want to be handling at least the Activity::onPause event.

Looking at the implementation of QtActivityDelegate::onPause (which appears to be the delegate that handles Android application events for Qt):

public void onPause()
{
    QtNative.setApplicationState(ApplicationInactive);
}

So perhaps connecting the QGuiApplication::applicationStateChanged signal to your own slot, and checking for the Qt::ApplicationInactive state (or perhaps any state other than Qt::ApplicationActive) will get you want you want?

If you haven't already, its probably worth browsing the source for QtActivity and QtActivityDelegate to see what else they do that might be useful for you.

Let us know how you go.

Cheers.

vlada

@Paul-Colby Yes, I've already got the advice to watch for this signal from BogDan Vatra in a discussion under his article.

I will try to watch what happens during the program lifecycle and if I can react to this signal. The problem is that my application must be working even in background (it is a music player). So it won't be simple.

I'll check it and will let you know the result.

vlada

I did some tests on Android and I found that immediately as my application is sent to background, the state changes to Inactive and then very quickly to Suspended. But even in this state the music player continues to work.

So there no use of these signals for me. In fact I need them but only to disable UI changes if application is not active.

So the only solution remains to save the app state every few seconds. because it might get killed anytime without any previous warning.

kshegunov

@vlada
Again, have you tried intercepting the SIGTERM signal sent to the runtime?
I don't know whether you program in Java for Android, but assuming you do this should be of help.

vlada

@kshegunov No, I haven't tried that yet. I was looking at the more simple (possible) solutions first.

Unfortunately my application doesn't have any Java part (written by me) yet. I know that I will have to learn it and I have already studied the articles from BogDan Vatra on how to use Qt Android Extras and JNI. But I'm not familiar with that yet.

kshegunov

@vlada

No, I haven't tried that yet. I was looking at the more simple (possible) solutions first.

Then you should attempt it and see if it works for you.

Unfortunately my application doesn't have any Java part (written by me) yet.

If you don't work with Java I then logically assume you use C++. The signal handling is part of the standard C runtime, so try that (for a link look at my first post in this thread).

vlada

@kshegunov Thanks a lot. At first I tried the example in your link which works fine. Then I tried to replace the signal SIGINT with SIGTERM. But the associated function gets never executed.

Have I done anything wrong or is the application simply unable to catch the signal? I have tried it on Windows and switched my app off using all possible ways (taskbar, regular close, task manager). But nothing ever happened.

kshegunov

@vlada said:

Thanks a lot. At first I tried the example in your link which works fine. Then I tried to replace the signal SIGINT with SIGTERM. But the associated function gets never executed.

Have I done anything wrong or is the application simply unable to catch the signal? I have tried it on Windows and switched my app off using all possible ways (taskbar, regular close, task manager). But nothing ever happened.

It really depends how the Android (or the OS you were experimenting with) is trying to stop your program. If it tries to close it normally, you should try catching the QCoreApplication::aboutToQuit signal (this is a Qt signal). If it tries to stop your application forcefully, it should send the application process the SIGTERM (this is a process signal). And if it kills it (the most forceful of all), you can't react to it, because the runtime simply stops the process without any warning or waiting.

PS. Sorry for the delay, I was pretty busy these two days.

vlada

@kshegunov I tried to catch all possible signals but I didn't get any of them. I think it is because of the way Qt applications are run on Android. Because on Android is run a Java application which runs my app as a library. Sorry for the probably incorrect wording.

In this case it is the Java application which receives an onDestroy() signal. I'm wondering if this signal si somehow exposed to the C++ part. Another option would be to look into JNI and try to implement a custom handler for this signal which calls a C++ function in my app.

But I'm trying to avoid the Java part as long as possible because I have no experience with that.

kshegunov

@vlada said:

I tried to catch all possible signals but I didn't get any of them. I think it is because of the way Qt applications are run on Android. Because on Android is run a Java application which runs my app as a library.

Assuming this is true, then indeed, you'll need to write a bit of java and only if the Java runtime allows interception of the signals. I don't know if it's worth it, but it shouldn't be too hard.