"IN_CONVERSATION" was set when the activity was created and "state" in
the intent extras had the value "resume". However, there is no "state"
extra set by default in Android intents, it should be explicitly set,
but as it is not set anywhere in Talk Android code that would make it
dead code and safe to remove.
Moreover, the connection to the call should be initialized again in any
case rather than resumed when "onCreate" is called, as it is likely that
any previous connection would have been ended if the previous activity
instance was destroyed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This test respects different API versions and checks if default values are set as expected.
- remove deprecated+unused methods
- remove comments
- remove unnecessary double-bang operator
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
With server version 23.0.12 it happened that the chat did not load because values were null. Now default values in json model are set (because that's easier than changing the entity).
Additionally a check was added in CallActivity that a callStartTime of 0 would not be used (but it should not be used anyway if it would be 0 because then capability should also not be available).
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Starting with Talk 20 the signaling messages that provide updates to the
participants ("participants->update" in the external signaling server,
"usersInRoom" in the internal signaling server) now include "actorType"
and "actorId" properties for each participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "federation" values are used by the external signaling server to
establish a connection with the remote signaling server in a federated
room.
For now this is applied only in calls; when the room is joined in the
chat view again after a call it will still join it in the old way,
without federation properties, which will cause the connection with the
remote signaling server to be closed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Starting with Talk 20 the signaling settings include a "federation"
property that provide the values needed to join a federated room in the
external signaling settings. The "federation" property is specific to
each conversation, and it will be returned although empty for
non-federated conversations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
With this change, all links that target files in the same nextcloud instance will be opened in the files app, no matter on which screen the link was.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
To support federated rooms, capabilities have to be checked from the room which now also has capabilities.
If room is not federated, capabilities fromuser are still checked.
This is why CapabilitiesUtil had to be refactored to accept SpreedCapabilities which can come from room or user.
Other than that, many other changes were made as a result of this change.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
When declining recording consent, 404 might be returned when leaving the call (because the call was not joined before).
It might not be the best option to handle this via onError, but for the moment (18.0.0 release) it's the most robust/lowest-risk solution without to change some state handling to check if the call was joined).
finish was added which makes sense anyway, but for declining recording consent the error snackbar was removed.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
- replace remaining controllers with activities
- remove conductor lib
- modify some code related to account management and conductor
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
11-02 03:45:20.115 27450 27450 D CallActivity: initGridAdapter
11-02 03:45:20.116 27450 27450 D CallActivity: removeParticipantDisplayItem
11-02 03:45:20.116 27450 27450 D CallActivity: removeParticipantDisplayItem
11-02 03:45:20.119 27450 27450 W MagicWebRTCUtils: No payload types with name H264
11-02 03:45:20.141 27450 27450 W System.err: java.lang.NullPointerException: Parameter specified as non-null is null: method com.nextcloud.talk.activities.CallActiv
ity$OfferAnswerNickProvider$WebRtcMessageListener.onOffer, parameter nick
11-02 03:45:20.141 27450 27450 W System.err: at com.nextcloud.talk.activities.CallActivity$OfferAnswerNickProvider$WebRtcMessageListener.onOffer(Unknown Source:7
)
11-02 03:45:20.141 27450 27450 W System.err: at com.nextcloud.talk.signaling.WebRtcMessageNotifier.notifyOffer(WebRtcMessageNotifier.java:99)
11-02 03:45:20.141 27450 27450 W System.err: at com.nextcloud.talk.signaling.SignalingMessageReceiver.processSignalingMessage(SignalingMessageReceiver.java:746)
11-02 03:45:20.142 27450 27450 W System.err: at com.nextcloud.talk.activities.CallActivity$InternalSignalingMessageReceiver.process(CallActivity.kt:2707)
11-02 03:45:20.142 27450 27450 W System.err: at com.nextcloud.talk.activities.CallActivity.receivedSignalingMessage(CallActivity.kt:1889)
11-02 03:45:20.142 27450 27450 W System.err: at com.nextcloud.talk.activities.CallActivity.receivedSignalingMessages(CallActivity.kt:1865)
11-02 03:45:20.142 27450 27450 W System.err: at com.nextcloud.talk.activities.CallActivity.access$receivedSignalingMessages(CallActivity.kt:190)
11-02 03:45:20.142 27450 27450 W System.err: at com.nextcloud.talk.activities.CallActivity$pullSignalingMessages$5.onNext(CallActivity.kt:1768)
11-02 03:45:20.142 27450 27450 W System.err: at com.nextcloud.talk.activities.CallActivity$pullSignalingMessages$5.onNext(CallActivity.kt:1762)
11-02 03:45:20.142 27450 27450 W System.err: at io.reactivex.internal.util.HalfSerializer.onNext(HalfSerializer.java:107)
11-02 03:45:20.143 27450 27450 W System.err: at io.reactivex.internal.operators.observable.ObservableRetryWhen$RepeatWhenObserver.onNext(ObservableRetryWhen.java
:100)
11-02 03:45:20.143 27450 30048 W MagicWebRTCUtils: No payload types with name H264
11-02 03:45:20.143 27450 27450 W System.err: at io.reactivex.internal.operators.observable.ObservableDoOnEach$DoOnEachObserver.onNext(ObservableDoOnEach.java:101
)
11-02 03:45:20.143 27450 27450 W System.err: at io.reactivex.internal.operators.observable.ObservableTakeWhile$TakeWhileObserver.onNext(ObservableTakeWhile.java:
88)
11-02 03:45:20.143 27450 27450 W System.err: at io.reactivex.internal.util.HalfSerializer.onNext(HalfSerializer.java:107)
11-02 03:45:20.143 27450 27450 W System.err: at io.reactivex.internal.operators.observable.ObservableRepeatWhen$RepeatWhenObserver.onNext(ObservableRepeatWhen.ja
va:100)
11-02 03:45:20.143 27450 27450 W System.err: at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.
java:201)
11-02 03:45:20.143 27450 27450 W System.err: at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:255
)
11-02 03:45:20.144 27450 27450 W System.err: at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run(HandlerScheduler.java:124)
11-02 03:45:20.144 27450 27450 W System.err: at android.os.Handler.handleCallback(Handler.java:938)
11-02 03:45:20.144 27450 27450 W System.err: at android.os.Handler.dispatchMessage(Handler.java:99)
11-02 03:45:20.144 27450 27450 W System.err: at android.os.Looper.loop(Looper.java:223)
11-02 03:45:20.144 27450 27450 W System.err: at android.app.ActivityThread.main(ActivityThread.java:7664)
11-02 03:45:20.144 27450 27450 W System.err: at java.lang.reflect.Method.invoke(Native Method)
11-02 03:45:20.144 27450 27450 W System.err: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
11-02 03:45:20.144 27450 27450 W System.err: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
11-02 03:45:20.145 27450 27450 E AndroidRuntime: FATAL EXCEPTION: main
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this led to duplicated call of fetchSignalingSettings.
because it's already called from checkDevicePermissions().
From my pov it shouldn't be triggered in onMicrophoneClick() again, at least i can not think of any scenario and while testing everything worked as expected.
The duplicated call was there since ever(?), but after implementing #3216 this also caused the call duration timer to be run twice.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
