Notifications and restarts of Jitsi service

[jitsi-jenkins]

Android will shutdown Jitsi service from time to time when it needs more resources. It will happen more often when Jitsi doesn't show it's icon(hidden in the settings). That's because it will no longer work in foreground mode. We have to make sure that all notifications will work properly between restarts.

(Issue migrated from https://trac.jitsi.org/ticket/1268)

[jitsi-jenkins]

Fixed in e0e4cdda0975c2fae8291dad980929c5c052d839.

[jitsi-jenkins]

Altough there is a fix for situation when jitsi process is killed(and restarted) before the notification is clicked it will not work when MetaContact is not found for meta UID stored in notification.

Sometimes it will also crash after click with the following stacktrace(the reason is unknown at the moment):

java.lang.NullPointerException
    at org.jitsi.android.gui.chat.ChatActivity.displaySelectedChatInfo(ChatActivity.java:374)
    at org.jitsi.android.gui.chat.ChatActivity.onPageScrolled(ChatActivity.java:361)
    at android.support.v4.view.ViewPager.onPageScrolled(ViewPager.java:1712)
    at android.support.v4.view.ViewPager.pageScrolled(ViewPager.java:1650)
    at android.support.v4.view.ViewPager.computeScroll(ViewPager.java:1615)
    at android.view.View.draw(View.java:13242)
    at android.view.ViewGroup.drawChild(ViewGroup.java:2947)
    at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2817)
    at android.view.View.draw(View.java:13561)
    at android.view.View.draw(View.java:13442)
    at android.view.ViewGroup.drawChild(ViewGroup.java:2947)
    at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2817)
    at android.view.View.draw(View.java:13440)
    at android.view.ViewGroup.drawChild(ViewGroup.java:2947)
    at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2817)
    at android.view.View.draw(View.java:13440)
    at android.view.ViewGroup.drawChild(ViewGroup.java:2947)
    at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2817)
    at android.view.View.draw(View.java:13561)
    at android.widget.FrameLayout.draw(FrameLayout.java:467)
    at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:2265)
    at android.view.ViewRootImpl.drawSoftware(ViewRootImpl.java:2563)
    at android.view.ViewRootImpl.draw(ViewRootImpl.java:2454)
    at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2285)
    at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2067)
    at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1160)
    at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:4682)
    at android.view.Choreographer$CallbackRecord.run(Choreographer.java:738)
    at android.view.Choreographer.doCallbacks(Choreographer.java:564)
    at android.view.Choreographer.doFrame(Choreographer.java:532)
    at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:723)
    at android.os.Handler.handleCallback(Handler.java:615)
    at android.os.Handler.dispatchMessage(Handler.java:92)
    at android.os.Looper.loop(Looper.java:155)
    at android.app.ActivityThread.main(ActivityThread.java:5520)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:511)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1029)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:796)
    at dalvik.system.NativeStart.main(Native Method)

[jitsi-jenkins]

Perhaps it would be possible, even when History is disabled, to keep the current conversation or at least last incoming message stored until the user ends/closes that chat, so that if Jitsi does crash, the user doesn't lose the current conversation or incoming message that he hasn't replied to yet. If doing this, this temporary store would need to be securely erased once it's finished with (and in case Jitsi crashes before it gets to erase this store after the chat is closed, some way would need to be found to ensure it's erased when restarting Jitsi but not if it's still needed), otherwise it would compromise the security of having History disabled and users might not be aware of this and even if they were, it would upset those users who want/need to ensure that no permanent History is stored.