Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Mobile and Embedded
  4. Getting kill signal on Android
QtWS25 Last Chance

Getting kill signal on Android

Scheduled Pinned Locked Moved Unsolved Mobile and Embedded
androidkillsignalquit
14 Posts 4 Posters 10.2k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V Offline
    V Offline
    vlada
    wrote on 5 Apr 2016, 07:24 last edited by
    #1

    I have an Android application and I need to know when the system wants to kill it. I need to react to the situation and save the current state (to a text file or database).

    On Windows and desktop Linux I have implemented an eventFilter where I catch QEvent::Close. But this doesn't seem to work on Android.

    I need to catch that my application is about to close in following situations:

    • The app is killed from task switcher
    • Android is shutting down
    • Android shuts down my application to free up memory

    Is it possible to catch these situations and execute some code before my app is killed?

    K 1 Reply Last reply 5 Apr 2016, 23:05
    0
    • M Offline
      M Offline
      mvuori
      wrote on 5 Apr 2016, 19:24 last edited by
      #2

      I guess you can't get a kill signal, so you may need to settle for what you get, which may include
      Qt::ApplicationInactive
      Qt::ApplicationSuspended
      Qt::ApplicationHidden

      Some people with very small data in their app save it just in case every time the data changes. Of course it depends on the amount of data what strategy is the best.

      1 Reply Last reply
      0
      • V vlada
        5 Apr 2016, 07:24

        I have an Android application and I need to know when the system wants to kill it. I need to react to the situation and save the current state (to a text file or database).

        On Windows and desktop Linux I have implemented an eventFilter where I catch QEvent::Close. But this doesn't seem to work on Android.

        I need to catch that my application is about to close in following situations:

        • The app is killed from task switcher
        • Android is shutting down
        • Android shuts down my application to free up memory

        Is it possible to catch these situations and execute some code before my app is killed?

        K Offline
        K Offline
        kshegunov
        Moderators
        wrote on 5 Apr 2016, 23:05 last edited by kshegunov 4 May 2016, 23:06
        #3

        @vlada
        http://www.cplusplus.com/reference/csignal/signal/

        Try intercepting the termination signal (SIGTERM). However, depending on how Android handles things this might not be enough. If the OS kills your process there's nothing you can do about it.

        Read and abide by the Qt Code of Conduct

        1 Reply Last reply
        0
        • V Offline
          V Offline
          vlada
          wrote on 6 Apr 2016, 06:31 last edited by
          #4

          Thank you for your replies. I was afraid that it is not possible to catch the KILL signal.

          My application is a music player. I wrote it mainly for my car radio with Android. So my main concern is to store the player state when Android shuts down (which happens when I remove keys from my car).

          So I guess the best practice would be to save the main settings (player settings, playlists, shuffle list, queue etc.) when a song changes. Then save the current song progress let's say every 10 seconds.

          Now what would you suggest to do. Should I store the progress to a SQLite database (where I store all the settings) or would it be more effective to store it to a plain text file with just a single number (elapsed seconds)? What would be more effective?

          1 Reply Last reply
          0
          • P Offline
            P Offline
            Paul Colby
            wrote on 6 Apr 2016, 06:58 last edited by
            #5

            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.

            V 1 Reply Last reply 6 Apr 2016, 07:23
            0
            • P Paul Colby
              6 Apr 2016, 06:58

              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.

              V Offline
              V Offline
              vlada
              wrote on 6 Apr 2016, 07:23 last edited by
              #6

              @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.

              1 Reply Last reply
              0
              • V Offline
                V Offline
                vlada
                wrote on 6 Apr 2016, 13:45 last edited by
                #7

                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.

                K 1 Reply Last reply 6 Apr 2016, 13:55
                0
                • V vlada
                  6 Apr 2016, 13:45

                  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.

                  K Offline
                  K Offline
                  kshegunov
                  Moderators
                  wrote on 6 Apr 2016, 13:55 last edited by
                  #8

                  @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.

                  Read and abide by the Qt Code of Conduct

                  V 1 Reply Last reply 6 Apr 2016, 14:09
                  0
                  • K kshegunov
                    6 Apr 2016, 13:55

                    @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.

                    V Offline
                    V Offline
                    vlada
                    wrote on 6 Apr 2016, 14:09 last edited by
                    #9

                    @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.

                    K 1 Reply Last reply 6 Apr 2016, 14:11
                    0
                    • V vlada
                      6 Apr 2016, 14:09

                      @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.

                      K Offline
                      K Offline
                      kshegunov
                      Moderators
                      wrote on 6 Apr 2016, 14:11 last edited by
                      #10

                      @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).

                      Read and abide by the Qt Code of Conduct

                      V 1 Reply Last reply 6 Apr 2016, 15:02
                      0
                      • K kshegunov
                        6 Apr 2016, 14:11

                        @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).

                        V Offline
                        V Offline
                        vlada
                        wrote on 6 Apr 2016, 15:02 last edited by
                        #11

                        @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.

                        K 1 Reply Last reply 8 Apr 2016, 10:57
                        0
                        • V vlada
                          6 Apr 2016, 15:02

                          @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.

                          K Offline
                          K Offline
                          kshegunov
                          Moderators
                          wrote on 8 Apr 2016, 10:57 last edited by kshegunov 4 Aug 2016, 10:57
                          #12

                          @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.

                          Read and abide by the Qt Code of Conduct

                          V 1 Reply Last reply 8 Apr 2016, 13:58
                          0
                          • K kshegunov
                            8 Apr 2016, 10:57

                            @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.

                            V Offline
                            V Offline
                            vlada
                            wrote on 8 Apr 2016, 13:58 last edited by
                            #13

                            @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.

                            K 1 Reply Last reply 8 Apr 2016, 15:36
                            0
                            • V vlada
                              8 Apr 2016, 13:58

                              @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.

                              K Offline
                              K Offline
                              kshegunov
                              Moderators
                              wrote on 8 Apr 2016, 15:36 last edited by
                              #14

                              @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.

                              Read and abide by the Qt Code of Conduct

                              1 Reply Last reply
                              0

                              1/14

                              5 Apr 2016, 07:24

                              • Login

                              • Login or register to search.
                              1 out of 14
                              • First post
                                1/14
                                Last post
                              0
                              • Categories
                              • Recent
                              • Tags
                              • Popular
                              • Users
                              • Groups
                              • Search
                              • Get Qt Extensions
                              • Unsolved