this new behaviour still takes care of not going online when quickly
checking for the time but it also includes systems that don’t have a
lock screen or incorrectly report being unlocked.
This is a feature of WebRTC that's [not standardized][1] and only
supported by libwebrtc. Since there's no support in jingle for passing
this capability from one peer to another, we're currently hard-coding
this option into both the local candidate and also the remote candidate
so they can use it.
But I'm trying to call a user that isn't using WebRTC, and renomination
is causing the call to stay in "connecting..." state for 10 or 20
seconds, sometimes longer, while both sides wait for the other to
nominate something based on their individual beliefs about the standards
they're using.
Removing this seems to make connecting relatively instantaneous.
If we want to reintroduce this feature, we should probably make a XEP so
the peers can negotiate honestly about it, and only use it if both sides
truely support the feature.
[1]: https://datatracker.ietf.org/doc/html/draft-thatcher-ice-renomination-01
Conversations used to deduplicate disco queries based on their hash.
However that relies on the first query to go through (device to actually
respond) and to respond properly (hash matches).
Creating a proper retry behaviour for this is actually quite challanging.
(which one would you try next, how long do you wait?)
DIGEST and HMAC were static variables. Those are initialized by
what ever concrete implementation gets executed first.
(Perform SCRAM-SHA1 first and those variables got initialized with
SHA1 variants)
For subsequent SHA256 executions those variables contained wrong
values.
- In some places, we weren't nulling out references to destroyed objects. This
fixes that.
- (These were all discovered via LeakCanary instrumentation, and the fixes are
hopefully rather straightforward-looking.)
- When the `viewHolder.messageBody` `TextView` created by a `MessageAdapter` is
set to selectable, it leaks an `android.widget.Editor` (because that editor
registers a view observer that never gets unregistered).
- This memory leak is really quite problematic, as the message adapter is used
a lot!
- Having the text be selectable is useless anyway, though; there isn't any way
to select it (because long pressing just opens the context menu anyway).
- It looks like the ListSelectionManager was meant to track selections across
multiple messages. However, I'm not sure this feature ever gets used.
- Accordingly, this commit removes the entire feature, thus fixing the memory
leak (since no `Editor` objects are ever created).
- It should also reduce memory usage in general, since we aren't attaching an
`Editor` to every single textview we create.
- A `TextView` only allocates an `Editor` if you ask it to do certain things,
like make the text selectable or register custom selection callbacks.
leaving a MUC before joining it was a work around for servers that did not treat a
<x/> join as a full join and didn’t send the full user list if they thought the user was
still in the room.
this happens if Conversations restarts after an inproper disconnect. The MUC will think
the user is still in the room.
however nowadays most modern servers will treat <x/> joins as full joins. on the user hand
leave before join would trigger flood prevention on ejabberds and race the first message
with the actual join (making the message arrive before the user is considered in the room)
we don’t want 'manage accounts' and 'settings' to show up when within a conversation.
we also move out disable notifications and add to favorites into an overflow overflow
to make the menu shorter (after adding 'Search messages' it became very crowded)
Conversations would attempt to feed any candidates found in the session-accept into
WebRTC; even if the session wasn’t setup correctly.
this commit processes the candidates only if the session was setup correctly
fixes#3867
JingleRTPConnection shuts down the WebRTCWrapper before transitioning into a terminal state.
(This allows us to make sure it is actually closed when reaching that state);
However that means that, when we get a UI redrawn inbetween closing and transitioning we might
still be in SESSION_ACCEPTED but with no PeerConnection. This traditionally has triggered
an IllegalStateException on getting the EndUserState.
This commit catches the ISE and returns 'ENDING' instead.
Chances are that this is only visibiliy for a very brief time in the UI before the transition
triggers the UI to redraw with the proper state.
fixes#3848
Currently Conversations lacks any keyboard shortcut to send a message if enter_is_send is disabled.
KeyboardListener has been extended to include the original KeyEvent as an argument.
fixes#3829
some implementations will transform the following SDP coming from Firefox
m=audio 12346 RTP/AVP 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
to
<payload-type channels="1" name="telephone-event" clockrate="8000" id="101">
<parameter value="0-15" xmlns="urn:xmpp:jingle:apps:rtp:1"/>
</payload-type>
While a missing name attribute is not legal according to the XEP; and 0-15 are
technically not just one value the following commit will accept it if there is
just one paramater.
on some phones the onBackendConnected finishes prior to the onActivityResult()
leading to the pending photo uri being cleared before processing the result.
this leads to 'Take photo' not working.
but we probably don’t need to clear the photo uri if there is to activiyResult
to clear as well
