Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qt app unable to exit properly when using OneSignal Android SDK #102

Closed
Talkless opened this issue Sep 5, 2016 · 30 comments
Closed

Qt app unable to exit properly when using OneSignal Android SDK #102

Talkless opened this issue Sep 5, 2016 · 30 comments

Comments

@Talkless
Copy link
Contributor

Talkless commented Sep 5, 2016

Hi,

First of all, of course, this is non standard usage of this library, but please bear with me.

I was experimenting with OneSignal 2.3 - 3.1 APIs on Android (and iOS) with Qt C++ application.

With Qt and C++, it works like this:

  • Qt has implemented QtApplication and QtActivity Java classes, and you simply don't care about that. Qt build process copies jars into intermediate build directory and Android tools builds .apk from there.
  • Your normal C++ code is compiled into .so library which is loaded by Java QtActivity class.
  • In order to call native Android API's, you can write helper Java class which uses Activity.runOnUiTheead() to call in thread-safe manner to avoid mayhem, as Qt's int main() code runs from other thread.
  • Use JNI to call that wrapper class methods from C++.

Everything was working quite OK, but after upgrading to latest v3.1.0 program started to crash randomly (somewhere >50% of the time!) when starting, somewhere during startInit()-->init(). Program crashes when started after last instance was closed from android. Same for 2.x up to 3.1 versions. All I get is some random assembly output in QtCreator debugger page, and this Android log line:

I art     : Thread[2,tid=4511,WaitingInMainSignalCatcherLoop,Thread*=0xab2ad500,peer=0x12c710a0,"Signal Catcher"]: reacting to signal 3

Crash occurres when trying to setup OneSignal in wrapper Java method like this:

//helper wrapper class designed to be called from Qt side using JNI
public class PushNotificationManager
{
    public static void setup(Activity activity) {
        m_activity = activity; //useful for other class method calls
        Log.d("PushNotificationManager", "setup");
        final Semaphore sem = new Semaphore(0);

        // Qt is running on a different thread than Android UI.
        activity.runOnUiThread(new Runnable() {
            @Override
            public void run() {
                try {
                    OneSignal.startInit(m_activity)
                    .inFocusDisplaying(OneSignal.OSInFocusDisplayOption.None)
                    .setNotificationOpenedHandler(new CustomNotificationOpenedHandler())
                    .setNotificationReceivedHandler(new CustomNotificationReceivedHandler())
                    .init();
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    sem.release();
                }
            }});

        try {
            // implement inter-thread blocking call
            sem.acquire();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
//...
}

From Qt side, it's called through JNI like this (though I doubt it is relevant, but maybe useful for someone):

const std::array<JNINativeMethod, 2> methods = {
    JNINativeMethod{"onPushNotificationReceived", "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V", (void *)c_onPushNotificationReceived},
    JNINativeMethod{"onPushNotificationOpened", "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V", (void *)c_onPushNotificationOpened}
};

void PushNotificationManager::setupNative() {

    // register Java -> C++ interface functions:
    QAndroidJniObject javaClass("com/ourcompany/OneSignal/PushNotificationManager");
    QAndroidJniEnvironment env;
    jclass objectClass = env->GetObjectClass(javaClass.object<jobject>());
    env->RegisterNatives(objectClass,
                         methods.data(),
                         methods.size());

    // invoke Java wrapper method to setup OneSignal:
    QAndroidJniObject::callStaticMethod<void>(objectClass,
                                              "setup",
                                              "(Landroid/app/Activity;)V",
                                              QtAndroid::androidActivity().object());
    env->DeleteLocalRef(objectClass);
}

Crash happens after some seconds of being frozen.

Interestingly, I have tried to pass m_activity.getApplication() to starInit() instead of activity, and then it did not crash, notifications worked, BUT, inFocusDisplaying() options was totally ignored (always used Notification type).

Now the question is, is this line in documentation actually crucial:

Initializes OneSignal to register the device for push notifications. Should be call in the onCreate of your Application class.

In OneSignal 2.3 there was .init() method witch worked without this restriction. Maybe problem is that I cannot initialize OneSignal in proper place using Qt?

Problem with that is that Application class is implemented by Qt, as mentioned before, and Qt app creator has no control what happens during initialization, no way to implement onCreate(), unless one wishes to modify (and then merge) Qt code per-app basis...

So in retrospect, could that crash be because init() is called not within onCreate()? If yes, could it be workarounded, or maybe even fixed, somehow?

Thanks!

Update: Looks like issue is that Qt app cannot exit properly if OneSignal is initialzied, so launching another instance make's it crash (Android waits until last insntaces exist, but eventually it's killed, see later posts).

@Talkless
Copy link
Contributor Author

Talkless commented Sep 6, 2016

After more researching, the problem is actually a little different. It is not regression of v3 (same problem with older versions), and crash is not actually on startup, but when last app instances is closing. So to describe more precisely:

  • App is launched with attached debugger from QtCreator
  • In Android, open app list and swipe app out to close it.
  • I can see app is still running in debugger, app is not closed immediately
  • After 20 seconds, I receive SIG33 and only then app actually exists.

Here's log starting when app is swiped-away:

D OneSignal: onActivityDestroyed: org.qtproject.qt5.android.bindings.QtActivity
D OneSignal: curActivity is NOW: null
I art     : Thread[2,tid=5520,WaitingInMainSignalCatcherLoop,Thread*=0xaee82000,peer=0x22c1f0a0,"Signal Catcher"]: reacting to signal 3

So it might be problem with finalization when using within Qt app (with QtActivity/QtApplication?).

@Talkless
Copy link
Contributor Author

Talkless commented Sep 6, 2016

Some more details: if I launch app from Android and close it immediately, and then open it again within around 20 seconds after app was closed, that new app instance freezes with message:

isn't responding. Do you want to close it?

After that second instances it's killed, I can launch app successfully.

@Talkless
Copy link
Contributor Author

Talkless commented Sep 6, 2016

I've testes official OneSignal example from 3.1.0 tarball, and it works OK. I can open and close and open example app without problem. But in my case with Qt app, closing it makes it freeze for ~20 seconds.

@Talkless
Copy link
Contributor Author

Talkless commented Sep 6, 2016

Here's some interesting logcat output when I close app within Android (it actually dies after ~20s):

09-06 11:17:31.463  1514  1528 W ActivityManager: Activity destroy timeout for ActivityRecord{f2b9f29 u0 com.OURCOMPANY.APP/org.qtproject.qt5.android.bindings.QtActivity t21 f}
09-06 11:17:41.467  1514  1528 W ActivityManager: Timeout executing service: ServiceRecord{50345b u0 com.OURCOMPANY.APP/com.onesignal.SyncService}
09-06 11:17:43.299  1514  2011 W ActivityManager: Scheduling restart of crashed service com.OURCOMPANY.APP/com.onesignal.SyncService in 43684ms

Full log:

09-06 11:17:31.463  1514  1528 W ActivityManager: Activity destroy timeout for ActivityRecord{f2b9f29 u0 com.OURCOMPANY.APP/org.qtproject.qt5.android.bindings.QtActivity t21 f}
09-06 11:17:41.467  1514  1528 W ActivityManager: Timeout executing service: ServiceRecord{50345b u0 com.OURCOMPANY.APP/com.onesignal.SyncService}
09-06 11:17:41.470  1514  1528 I Process : Sending signal. PID: 4645 SIG: 3
09-06 11:17:41.470  4645  4650 I art     : Thread[2,tid=4650,WaitingInMainSignalCatcherLoop,Thread*=0xab36c500,peer=0x12c070a0,"Signal Catcher"]: reacting to signal 3
09-06 11:17:41.670  1514  1528 I Process : Sending signal. PID: 1514 SIG: 3
09-06 11:17:41.670  1514  1519 I art     : Thread[2,tid=1519,WaitingInMainSignalCatcherLoop,Thread*=0xab36c500,peer=0x12c010a0,"Signal Catcher"]: reacting to signal 3
09-06 11:17:41.675  4645  4650 I art     : Wrote stack traces to '/data/anr/traces.txt'
09-06 11:17:41.681  1514  1528 I Process : Sending signal. PID: 1845 SIG: 3
09-06 11:17:41.681  1845  1852 I art     : Thread[2,tid=1852,WaitingInMainSignalCatcherLoop,Thread*=0xab36c500,peer=0x12c420a0,"Signal Catcher"]: reacting to signal 3
09-06 11:17:41.792  1845  1852 I art     : Wrote stack traces to '/data/anr/traces.txt'
09-06 11:17:41.792  1514  1528 I Process : Sending signal. PID: 1608 SIG: 3
09-06 11:17:41.792  1608  1613 I art     : Thread[2,tid=1613,WaitingInMainSignalCatcherLoop,Thread*=0xab36c500,peer=0x12c2d0a0,"Signal Catcher"]: reacting to signal 3
09-06 11:17:41.876  1608  1613 I art     : Wrote stack traces to '/data/anr/traces.txt'
09-06 11:17:41.992  1514  1519 I art     : Wrote stack traces to '/data/anr/traces.txt'
09-06 11:17:43.123  1514  1528 I Process : Sending signal. PID: 1933 SIG: 3
09-06 11:17:43.123  1933  1940 I art     : Thread[2,tid=1940,WaitingInMainSignalCatcherLoop,Thread*=0xab36c500,peer=0x12c070a0,"Signal Catcher"]: reacting to signal 3
09-06 11:17:43.214  1933  1940 I art     : Wrote stack traces to '/data/anr/traces.txt'
09-06 11:17:43.216  1514  1528 E ActivityManager: ANR in com.OURCOMPANY.APP
09-06 11:17:43.216  1514  1528 E ActivityManager: PID: 4645
09-06 11:17:43.216  1514  1528 E ActivityManager: Reason: executing service com.OURCOMPANY.APP/com.onesignal.SyncService
09-06 11:17:43.216  1514  1528 E ActivityManager: Load: 0.72 / 0.65 / 0.49
09-06 11:17:43.216  1514  1528 E ActivityManager: CPU usage from 113773ms to 0ms ago:
09-06 11:17:43.216  1514  1528 E ActivityManager:   3.1% 1514/system_server: 0.9% user + 2.2% kernel / faults: 6577 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   2.7% 1933/com.google.android.googlequicksearchbox:search: 2.3% user + 0.4% kernel / faults: 3375 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   1.9% 1195/mediaserver: 0.9% user + 1% kernel / faults: 73 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   1.3% 1184/surfaceflinger: 0.3% user + 0.9% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   1.2% 1190/adbd: 0% user + 1.2% kernel / faults: 1227 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0.5% 1608/com.android.systemui: 0.1% user + 0.3% kernel / faults: 1528 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0.4% 1208/fingerprintd: 0% user + 0.4% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   0.4% 1193/rild: 0% user + 0.4% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   0.1% 1845/com.android.phone: 0% user + 0% kernel / faults: 1148 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0.1% 1858/com.google.android.googlequicksearchbox: 0% user + 0% kernel / faults: 864 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1192/debuggerd: 0% user + 0% kernel / faults: 2286 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 2127/com.google.android.gms: 0% user + 0% kernel / faults: 3383 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1827/com.google.android.gms.persistent: 0% user + 0% kernel / faults: 474 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1167/logd: 0% user + 0% kernel / faults: 13 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1183/servicemanager: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1908/android.process.acore: 0% user + 0% kernel / faults: 310 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 6/kworker/u4:0: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 8/rcu_preempt: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1155/kworker/1:1H: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1165/jbd2/vdc-8: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1182/lmkd: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1191/netd: 0% user + 0% kernel / faults: 133 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 1198/zygote: 0% user + 0% kernel / faults: 4979 minor
09-06 11:17:43.216  1514  1528 E ActivityManager:   0% 3370/kworker/0:1: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:  +0% 4645/com.OURCOMPANY.APP: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:  +0% 4663/logcat: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:  +0% 4666/kworker/0:2: 0% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager: 8.3% TOTAL: 3.3% user + 4.4% kernel + 0.5% iowait + 0% irq + 0% softirq
09-06 11:17:43.216  1514  1528 E ActivityManager: CPU usage from 1146ms to 1649ms later:
09-06 11:17:43.216  1514  1528 E ActivityManager:   5.7% 1195/mediaserver: 1.9% user + 3.8% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:     5.7% 4733/AudioIn_31: 1.9% user + 3.8% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   5.8% 1933/com.google.android.googlequicksearchbox:search: 3.8% user + 1.9% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:     3.8% 4729/HotwordRecognit: 3.8% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:     3.8% 4730/MicrophoneReade: 0% user + 3.8% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   3.9% 1514/system_server: 1.9% user + 1.9% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:     1.9% 1528/ActivityManager: 0% user + 1.9% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:     1.9% 1541/SensorService: 1.9% user + 0% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager:   1.9% 1190/adbd: 0% user + 1.9% kernel
09-06 11:17:43.216  1514  1528 E ActivityManager: 5.2% TOTAL: 2% user + 3.1% kernel
09-06 11:17:43.217  1514  1528 I ActivityManager: Killing 4645:com.OURCOMPANY.APP/u0a74 (adj 0): bg anr
09-06 11:17:43.299  1514  2011 W ActivityManager: Scheduling restart of crashed service com.OURCOMPANY.APP/com.onesignal.SyncService in 43684ms
09-06 11:17:43.300  1514  1842 D GraphicsStats: Buffer count: 3
09-06 11:17:43.326  2127  4741 D DropBoxEntryAddedChimeraService: User is not opted-in to Usage & Diagnostics.

@jkasten2
Copy link
Member

jkasten2 commented Sep 7, 2016

@Talkless Thanks for the details and digging into the issue. You only started seeing this issue after updating from 2.3.0 of our SDK to 3.1.0?

Can you pull the ANR log for your device?
You should be able to run adb pull to get it.
adb pull /data/anr/traces.txt destination_path

@Talkless
Copy link
Contributor Author

Talkless commented Sep 7, 2016

@jkasten2 Looks like it's the same with 2.x. I believe that earlier, when I was playing with 2.3, I was closing app directly from debugger, simply killing it, without noticing this freezing issue.

ANR:
data_anr_traces.txt

Iteresting part:

  kernel: futex_wait_queue_me+0xcd/0x113
  kernel: futex_wait+0xc5/0x197
  kernel: do_futex+0x9b/0x742
  kernel: SyS_futex+0xaf/0xf6
  kernel: syscall_call+0x7/0xb
  native: #00 pc 000171e0  /system/lib/libc.so (syscall+32)
  native: #01 pc 000276f1  /system/lib/libc.so (sem_wait+169)
  native: #02 pc 0001ab13  /data/data/com.OURCOMPANY.OURAPP/qt-reserved-files/plugins/platforms/android/libqtforandroid.so (???)
  native: #03 pc 005f8e6e  /data/app/com.OURCOMPANY.OURAPP-1/oat/x86/base.odex (void org.qtproject.qt5.android.QtNative.terminateQt()+98)
  native: #04 pc 005e1a44  /data/app/com.OURCOMPANY.OURAPP-1/oat/x86/base.odex (void org.qtproject.qt5.android.QtActivityDelegate.onDestroy()+120)
  native: #05 pc 00137a82  /system/lib/libart.so (art_quick_invoke_stub+338)
  native: #06 pc 001435c4  /system/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+212)
  native: #07 pc 0050f858  /system/lib/libart.so (art::InvokeMethod(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned int)+1736)
  native: #08 pc 0048c5e3  /system/lib/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobject*)+80)
  native: #09 pc 00314ca4  /data/dalvik-cache/x86/system@framework@boot.oat (???)
  at org.qtproject.qt5.android.QtNative.terminateQt(Native method)
  at org.qtproject.qt5.android.QtActivityDelegate.onDestroy(QtActivityDelegate.java:972)
  at java.lang.reflect.Method.invoke!(Native method)
  at org.qtproject.qt5.android.bindings.QtApplication.invokeDelegateMethod(QtApplication.java:153)
  at org.qtproject.qt5.android.bindings.QtApplication.invokeDelegate(QtApplication.java:142)
  at org.qtproject.qt5.android.bindings.QtActivity.onDestroy(QtActivity.java:1033)
  at android.app.Activity.performDestroy(Activity.java:6407)
  at android.app.Instrumentation.callActivityOnDestroy(Instrumentation.java:1142)
  at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3818)
  at android.app.ActivityThread.handleDestroyActivity(ActivityThread.java:3849)
  at android.app.ActivityThread.-wrap5(ActivityThread.java:-1)
  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1398)
  at android.os.Handler.dispatchMessage(Handler.java:102)
  at android.os.Looper.loop(Looper.java:148)
  at android.app.ActivityThread.main(ActivityThread.java:5417)
  at java.lang.reflect.Method.invoke!(Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

Looks like as Qt actually tries to quit, but it waits for something. Using OneSignal library prevents it to exit somehow.

Maybe I should produce minimal example app and post into Qt bug tracker..?

@Talkless Talkless changed the title Android SDK v3 crashes when using within Qt application Qt app unable to exit properly when using OneSigna Android SDK Sep 7, 2016
@Talkless Talkless changed the title Qt app unable to exit properly when using OneSigna Android SDK Qt app unable to exit properly when using OneSignal Android SDK Sep 7, 2016
@Talkless
Copy link
Contributor Author

Talkless commented Sep 7, 2016

I've created Qt bug report with attached working example source (without valid app IDs though).

@Talkless
Copy link
Contributor Author

Talkless commented Sep 9, 2016

@jkasten2 I've found interesting comment in SyncService, which describes my problem exactly:

/* Always make sure we are shutting down as quickly as possible here! We are on the main thread and have 20 sec before the process is forcefully killed.
Also if the user reopens the app or there is another task still open on the same process it will hang the startup/UI there.
*/

https://github.com/OneSignal/OneSignal-Android-SDK/blob/3.1.1/OneSignalSDK/onesignal/src/main/java/com/onesignal/SyncService.java#L92

Looks like it does not work in Qt app for some reason?

@Talkless
Copy link
Contributor Author

Talkless commented Sep 9, 2016

Looks like workaround is to set true in this line in manifest:
<service android:name="com.onesignal.SyncService" android:stopWithTask="true" />
What do I lose by not using false value as described in SDK documentation?

@jkasten2
Copy link
Member

@Talkless stopWithTask is set to false so onTaskRemoved(Intent) will fire on SyncService.java. This allows OneSignal to persist any tags, session fields, etc before the app is killed. I did some benchmarking and it finishes in under 100ms. I have also add some verbose logging, call setLogLevel to enable this and see if it is printing in your logcat. Add to the issue after you enable it, the logging will be included in the next release.

The line number does match up exactly to your stack but the issue seems to be point to this method.
http://code.qt.io/cgit/qt/qtbase.git/tree/src/android/jar/src/org/qtproject/qt5/android/QtActivityDelegate.java#n989
I tried to searching for terminateQt but didn't have any luck.

stopWithTask must be changing the process lifecycle in a way that Qt isn't excepting. I'll take a shot at seeing what are the full effects of the flag over the next week but without Qt's C/C++ code it may not help us much.

@Talkless
Copy link
Contributor Author

I tried to searching for terminateQt but didn't have any luck.

Looks like it's native method defined in androidjnimain.cpp.

I have also add some verbose logging

I'll try that.

stopWithTask must be changing the process lifecycle in a way that Qt isn't excepting.

Yeah, it kinda looks like it.

I'll take a shot at seeing what are the full effects of the flag over the next week

Thanks for your work!

jkasten2 added a commit that referenced this issue Sep 25, 2016
* android:stopWithTask is affecting the QT framework in an unexpected way which locks the process when closing it.
   - See QTBUG-55846 and OneSignal issue #102 for more details on the specific issue.
* Tested the flag removal on Android 4.4.2 and 6.0.1 and it had no side affects on onTaskRemoved.
@jkasten2
Copy link
Member

@Talkless Wasn't able to find any detailed information on stopWithTask but it seems it should be defaulting to false anyway from this comment.
https://github.com/android/platform_frameworks_base/blob/e71ecb2c4df15f727f51a0e1b65459f071853e35/core/res/res/values/attrs_manifest.xml#L1772-L1775

I have removed the flag in commit 07ba32f from the SDK's AndroidManifest.xml file since the behavior didn't change in my testing.

Feel free to reopen the issue if you see future issues with the service and Qt.

@Talkless
Copy link
Contributor Author

Sorry, I do not follow.

So
<service android:name="com.onesignal.SyncService" android:stopWithTask="false" />
is the same as
<service android:name="com.onesignal.SyncService"/> as per default ?

But my workaround was
<service android:name="com.onesignal.SyncService" android:stopWithTask="true" />
as mentioned in my earlier post.

@jkasten2
Copy link
Member

@Talkless Sorry you're right, though you stated that the removal of the flag also worked and didn't reread your Sept 8th comment before making that commit.

This seems to be a bug related to Qt handling services but I'll reopening the issue so this conflict can be tracked.

You might have better luck from Qt's end if you can reproduce the issue with a simple project without OneSignal so they have less to review. We just simply start the service like the following in the OneSignal SDK code.

startService(new Intent(context, ExampleService.class));

@jkasten2 jkasten2 reopened this Sep 27, 2016
@Talkless
Copy link
Contributor Author

but I'll reopening the issue so this conflict can be tracked

OK thanks, I'll inform about progress, if any.

@lukevear
Copy link

lukevear commented Nov 10, 2016

I've had the same issue as the one described here (with an identical ANR).

Explicitly setting

<service android:name="com.onesignal.SyncService" android:stopWithTask="true" />

in my AndroidManifest.xml did resolve the issue on my Samsung Galaxy S6 (Android 6.0.1), but did not resolve it on my Nexus 6 (Android 7.0.1).

@jkasten2
Copy link
Member

jkasten2 commented Nov 17, 2016

@lukevear Thanks for the additional details.

@Talkless @lukevear Can you try the test build attach to issue #138? I have added a selfStop() call the service which may fix this issue as well.

@lukevear
Copy link

@jkasten2 - Thanks! Testing it right now.

@lukevear
Copy link

@jkasten2 - Unfortunately it didn't work :(

@lukevear
Copy link

That was without:

<service android:name="com.onesignal.SyncService" android:stopWithTask="true" />

@alexleutgoeb
Copy link

Hi @Talkless, I'm experiencing the same issue, did you open a Qt bug as follow up for that one or is there a workaround you're using for now? Thanks

@Talkless
Copy link
Contributor Author

Talkless commented Nov 30, 2016

@alexleutgoeb There is bug report.

I haven't tried latest OneSignal SDK yet, my walkaround was this.

@alexleutgoeb
Copy link

@Talkless I see, did you experience any side effects so far?

@Talkless
Copy link
Contributor Author

Talkless commented Dec 1, 2016

@alexleutgoeb I have not experienced any specific side effects, it basically worked, but, that Qt project is on hold and there are not much actual experience.

@HamedMasafi
Copy link

I'm experiencing the same issue too. @alexleutgoeb did you solved this problem in v-play?

@alexleutgoeb
Copy link

Hi @HamedMasafi, yes we applied the mentioned workaround and it is working so far!

@jkasten2
Copy link
Member

jkasten2 commented Mar 6, 2018

@Talkless Looping back around to this issue in my investigation of our ANR issues. I was able to reproduce this ANR without OneSignal with your example project with just a blank Android Service. Left a comment on the Qt issue with more details below;
https://bugreports.qt.io/browse/QTBUG-55846?focusedCommentId=394115&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-394115

If you find any Qt documentation on limitations of Android Services please link them here and we can take a look. We are also currently looking into other ANRs so our future changes may end up fixing this one, depending on what we change. I'll leave this issue open until then

@jkasten2
Copy link
Member

We made some large changes to the SyncService which I believe should fix this issue in PR #470. This will released it this week under the version 3.8.2 which you can watch for on our Releases Page

@Talkless Feel free to follow up here about the Qt ticket even if this OneSignal update fixes your issue. Interested to know the root of the Qt issue as it may help us prevent an ANR like this with Qt or otherwise.

@Talkless
Copy link
Contributor Author

We made some large changes to the SyncService which I believe should fix this issue in PR #470

Amazing! Thanks!

So we will be able to remove that android:stopWithTask="true" fix right?

@jkasten2
Copy link
Member

jkasten2 commented Mar 13, 2018

Since persisting is done with Activity.onPause instead of Service.onTaskRemoved now this flag won't effect OneSignal itself. However since there seems to be a Qt issue with the way it handles Services started I noted in your Qt ticket, I recommend you keep android:stopWithTask="true". We defaulted to true as well in our aar on maven central.

Not sure if you are still using our .jar directly in your Qt project but we recommend adding our SDK through gradle with the following.

dependencies {
    compile 'com.onesignal:OneSignal:[3.8.2, 3.99.99]'
}

This way you won't have to maintain any future AndroidManifest.xml or dependency changes. I tested this with Qt and it works correctly. There are a few other recommend setting in the OneSignal gradle setup guide.
https://documentation.onesignal.com/docs/android-sdk-setup

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants