- CallKit decides what action to to take when pressing the hardware lock button based on where the audio is routed to. Using the speaker will make it lock the phone while using the headset will make it end the call.
- Before the introduction of CallKit we had to manually setup the AudioSession to keep the audio live in the background. This is now clashing with CallKit making it bevelie the audio is not routed to the speaker and causing the call be terminated when pressing the lock button.
* Add EncryptionReset password entry screen
* Expose client proxy identity reset method
* Update the IdentityConfirmationScreen to the latest designs
* Replace the old recovery key reset screen with a new EncryptionReset one
* Fixes#3102 - Add support for resetting the user's whole crypto identity
* Address review comments
* Bump the SDK to v1.0.30
* Reorder some properties.
No code changes.
* Refactor TimelineItemSendInfo out of the styler.
* Add (unused) examples of encryption shields.
* Rename file.
* Add inviter property to RoomProxyProtocol.
* Extract the room cell inviter label into it's own view.
* Use the new RoomInviterLabel in the JoinRoomScreen.
* Fix bug with invite to a public room.
- the room summary API is indeed enabled on matrix.org and working fine for most rooms
- it is not however capable of giving us data about non-joined + private rooms
- the SDK addresses that by first trying to use known rooms before resorting to the preview endpoint
- that fails if it's a brand new room that the client doesn't know about yet i.e. a sync hasn't ran, which is exactly what's happening here
- the ClientProxy instead does wait for the room list to go into the first loaded before returning the room
* Refactor the timeline item menu action provider.
- Move it into its own struct.
- Use an item, not an ID so it doesn't randomly change.
- Move permissions into the room screen view model.
* Use the stable ID when redacting/editing/forwarding a message.
Just like we do when fetching the item in the actions menu.
- not completely sure why this happens but `reportOutgoingCall` interferes with how the WebView gets access to video streams
- the call itself isn't really necessary so removing it is the simplest way forward
