fix: 1:1 calls can not be established on staging environment (WPB-9359) #3026
Conversation
ohassine
requested review from
a team,
yamilmedina,
alexandreferris,
vitorhugods,
mchenani and
Garzas
and removed request for
a team
| @@ -85,6 +89,7 @@ class CallActivity : AppCompatActivity() { | |||
|
|
|||
| setUpCallingFlags() | |||
| setUpScreenShootPreventionFlag() | |||
| lifecycle.addObserver(currentScreenManager) | |||
There was a problem hiding this comment.
question: won't that create a race condition between CallActivity and WireActivity if both Activities lifecycles are observed at the same time by the currentScreenManager? Shouldn't we also removeObserver when opening and closing another Activity?
There was a problem hiding this comment.
According to the documentation:
so first onStart from new Activity and then onStop from old one.
We have visibilityCount there so it shouldn't have a negative impact in case of switching between activities, but still if we have multiple Activities now we should also remove these observers when Activity is destroyed.
Also, logs from CurrentScreenManager will probably become hard to understand as they don't say which Activity is stopped or started, so when opening second Activity, in logs we will get onStart and then onStop so from logs it will look like app is not visible, but it's only the previous activity that has become stopped, not the whole app. 🤔
There was a problem hiding this comment.
Actually there will be no race condition because visibilityCount is update when starting CallActivity onStart and it get updated onStop of WireActivity.
But yeah in logs it will not be clear which is which.
Test Results23 tests 23 ✅ 0s ⏱️ Results for commit 44567ed. ♻️ This comment has been updated with latest results. |
|
Build 4906 failed. |
…ne-call-could-not-be-established-rc
|
|
Build 4981 failed. |
|
Closing it in favour of #3037 |
PR Submission Checklist for internal contributors
The PR Title
SQPIT-764The PR Description
What's new in this PR?
Issues
When the user starts a call from android and answer the receiver answer, the call does not establish and stays on connecting state.
Causes (Optional)
When we start the call, websocket closes immediately.
This happens after moving calling feature to a separate activity in separate task. The app thinks that it's on background when we start the call so it changes the connectivity policy to
DISCONNECT_AFTER_PENDING_EVENTSwhich cause to close websocket and therefore no calling messages will be received to establish the call.Solutions
Observe lifecycle of
CallActivityas well so we the app can correctly know if the app is visible or not (not just WireActivity as it was before)Needs releases with:
Testing
Test Coverage (Optional)
How to Test
Briefly describe how this change was tested and if applicable the exact steps taken to verify that it works as expected.
Notes (Optional)
Specify here any other facts that you think are important for this issue.
Attachments (Optional)
Attachments like images, videos, etc. (drag and drop in the text box)
PR Post Submission Checklist for internal contributors (Optional)
PR Post Merge Checklist for internal contributors
References
feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.