Exception java.lang.RuntimeException:
at android.app.ActivityThread.performDestroyActivity (ActivityThread.java:6032)
at android.app.ActivityThread.handleDestroyActivity (ActivityThread.java:6077)
at android.app.servertransaction.DestroyActivityItem.execute (DestroyActivityItem.java:47)
at android.app.servertransaction.ActivityTransactionItem.execute (ActivityTransactionItem.java:45)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:176)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2443)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8751)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Caused by java.lang.NullPointerException:
at com.nextcloud.talk.activities.CallActivity.onDestroy (CallActivity.java:1244)
at android.app.Activity.performDestroy (Activity.java:8571)
at android.app.Instrumentation.callActivityOnDestroy (Instrumentation.java:1364)
at android.app.ActivityThread.performDestroyActivity (ActivityThread.java:6019)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Note the slight difference in naming between the signaling message
("raiseHand", the action) and the stored data ("RaisedHand", the record
of the action).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
with this fix it's also not necessary to check for HPB in the app. The "recording" value from capabilities is set accordingly on server side.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
RecordingStartedState is set when the signaling message is received. There is no need to set this by CallStartRecordingObserver. Otherwise the toast "The call is being recorded" would have been shown twice when starting the recording.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
first it was tried with sampling rate 44100 but this showed an error on safari when try to playback.
by direct comparison to 44100, 22050 has lower quality but it's totally okay compared to the quality before when no sampling rate was set. I'm not sure why it failed on safari, because the iOS app also uses 44100.
see https://github.com/nextcloud/talk-android/pull/2714
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this could happen very rarely when clicking very fast to accept the call before the conversation was set.
Exception java.lang.NullPointerException:
at com.nextcloud.talk.activities.CallNotificationActivity.proceedToCall (CallNotificationActivity.kt:156)
at com.nextcloud.talk.activities.CallNotificationActivity.initClickListeners$lambda$0 (CallNotificationActivity.kt:126)
at com.nextcloud.talk.activities.CallNotificationActivity.$r8$lambda$0cnB_UmYcTD4PyxIBSZCZs1m_6s
at com.nextcloud.talk.activities.CallNotificationActivity$$ExternalSyntheticLambda0.onClick
at android.view.View.performClick (View.java:6612)
at android.view.View.performClickInternal (View.java:6581)
at android.view.View.access$3100 (View.java:785)
at android.view.View$PerformClick.run (View.java:25904)
at android.os.Handler.handleCallback (Handler.java:873)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:280)
at android.app.ActivityThread.main (ActivityThread.java:6706)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:858)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.activities.CallActivity.hangupNetworkCalls (CallActivity.java:1749)
at com.nextcloud.talk.activities.CallActivity.hangup (CallActivity.java:1741)
at com.nextcloud.talk.activities.CallActivity.lambda$initClickListeners$8$com-nextcloud-talk-activities-CallActivity (CallActivity.java:465)
at com.nextcloud.talk.activities.CallActivity$$ExternalSyntheticLambda16.onClick
at android.view.View.performClick (View.java:7792)
at android.view.View.performClickInternal (View.java:7769)
at android.view.View.access$3800 (View.java:910)
at android.view.View$PerformClick.run (View.java:30218)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8751)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
When the HPB is not used and a PeerConnectionWrapper is created it
always sent an offer if the local session ID is higher than the remote
session ID. However, in the case of screen shares the participant
sharing the screen always sends an offer, no matter the session ID.
Therefore, when that offer was received the new PeerConnectionWrapper
object sent a new offer, which in turn created an extra connection in
the browser.
Although the screen share connection happens to work the underlying
behaviour was wrong, so now no offer is sent for received screen share
connections and it is always waited until the offer is sent by the other
participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
logic for setting the placeholder was moved to getPayloadForImageLoader.
This is a better solution than in commit
9557bec9 where the onBind method had to be called in between other code.
This is still not the best solution because getPayloadForImageLoader now contains more logic than it should (which is also not only responsible for the placeholder). Anyway as this is a hotfix it's the best solution for the moment.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
follow up to commit 7464e6994b673d2b575903a76752bf39bed9d622
the problem was that the "super" methods also contain logic to show/hide the avatar. So this result must be overwritten again after calling the super method.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
