Includes display support for more genders, and more notably, skin tones.
These are not currently selectable in the UI, but they will be rendered
properly when other clients send them.
A new, fullscreen camera capture flow that easily allows you to capture
and edit a photo before sending it. Replaces the current half-screen
camera button.
This could cause us to think push messages were actually sent with
a SIM. We also now prevent rendering SIM info on push messages in
the conversation view.
Fixes#8176
Previously, we'd only show the attachment button when the user had
yet to enter any text. To add an attachment after text was entered,
you'd have to go to the three-dot menu. Now we just show a little
attach button in the text area.
I also took the opportunity to clean up other button paddings and
stuff in the compose area so things look better and react to text
sizes more predictably.
Apparently onAnimationEnd is not a reliable event on some Android
versions, so I've moved to instead using a simple postDelayed() that is
the same length as the animation.
In particular, there were many issues with drawing corners.
Unfortunately, there's no pretty way to get masking working on every
Android version, so we have to switch back to using custom backgrounds
and then using multiple masking methods depending on Android version.
Also, I had to remove attr references in drawables. They crash on 4.x.
We have to make some changes, and it's gotten to the point where
maintaining it as a separate library is more hassle than it's worth,
especially with Google releasing WorkManager as the preferred job
scheduling library.
Fixed an issue where jumbomoji were not properly being rendered
when using system emoji. Also fixed an issue where the text
content wasn't properly being recalculated when the view is
resized.
Fixes#7875
1. Switch to using default text rendering if there's no emoji present in
the string.
2. Reduce redudant redraws by skipping of setText() calls for identical
strings.
Together, these two changes should reduce the vast majority of
flickering we see with EmojiTextView ellipsizing.
Glide will use the dimensions of the target ImageView as the dimensions
for the image it's loading. This caused problems in the case of
ThumbnailView, as we were constantly changing the ImageView dimensions,
meaning Glide may not have the most recent values (it may be called in
between measure calls, for instance).
To solve this, we now will always override the default image dimensions
when we load an image. If no dimensions are present, we will default to
the layout_width and layout_height of the ThumbnailView.
Fixes#7810
The "contact" option in the attachments tray now brings you through an
optimized contact sharing flow, allowing you to select specific fields
to share. The contact is then presented as a special message type,
allowing you to interact with the card to add the contact to your system
contacts, invite them to signal, initiate a signal message, etc.
Did a refactor to better organize the camera flipping code. Also, I
wanted to make sure we handle the cases where the user doesn't have two
cameras (or no cameras, for that matter). In these cases, we just don't
show the appropriate buttons.
Unfortunately, the change wasn't as simple as just switching to use our
EmojiTextView. That view only supported single-line text. I added
support for multi-line text.
Fixes#7704.
Previously, we were always rendering images as squares. Instead of doing
that, we now render them as close to true-to-size as possible (within
reasonable min/max width/height boundaries).
1) The "obsolete" images like "swimmer" need to alias to
"man_swimming" so that they can be rendered correctly.
2) There are a whole bunch of emoji-data elements
(like white_frowning_face) that have "unified" code points which
have changed to include a "terminator."
Fixes#7212
Expiring message timers could end up leaking references and
executing work even after their conversation item was no longer
visible
Maybe fixes#6898
// FREEBIE
Eliminate the concept of 'Recipients' (plural). There is now just
a 'Recipient', which contains an Address that is either an individual
or a group ID.
MMS groups now exist as part of the group database, just like push
groups.
// FREEBIE
This was a holdover from Signal's origins as a pure SMS app.
It causes problems, depends on undefined device specific behavior,
and should no longer be necessary now that we have all the
information we need to E164 all numbers.
// FREEBIE