Fixed
Status Update
Comments
jb...@google.com <jb...@google.com>
ap...@google.com <ap...@google.com> #2
We started noticing this on Android 8 and 8.1 devices after we upgraded appcompat library from 1.3.1 to 1.4.0. Seems like that the newest library is using a different/newer classes for handling emojis.
ap...@google.com <ap...@google.com> #3
Thanks for the report, this is a combination we didn't predict and need to resolve.
In the current version of the libraries, precomputed text won't work with the presence of emoji in 1.4.0. There is no workaround using precomputed text in the current library, so the best solution is to `setText` as proposed.
Notes for resolution (options discussed):
1. Disabling emoji processing for precomputed text from InputFilter etc
2. Integrate emoji into PrecomputedTextCompat to apply emoji processing prior to precomputation (needs research)
In the current version of the libraries, precomputed text won't work with the presence of emoji in 1.4.0. There is no workaround using precomputed text in the current library, so the best solution is to `setText` as proposed.
Notes for resolution (options discussed):
1. Disabling emoji processing for precomputed text from InputFilter etc
2. Integrate emoji into PrecomputedTextCompat to apply emoji processing prior to precomputation (needs research)
jb...@google.com <jb...@google.com> #4
Going live in next release.
In current release I would recommend one of
- disabling emoji2 on TextViews with precomputed text
- disabling precomputed text if EmojiCompat.process(source) adds any Spans (this may be done/checked on background thread)
To resolve this, precomputed text will be discarded iff an EmojiSpan is being added. This cost will only be incurred if the text requires a replacement span due to platform missing an emoji.
Description
Component used: Activity
Version used: 1.7.2
As explained in the Predictive Back guide , you shouldn't use an
OnBackPressedCallback
for non-UI cases (for example, just for logging back). If you add a callback, you have to handle back completely in your callback.That means that calling
remove()
and triggering back viarequireActivity.onBackPressed()
oronBackPressedDispatcher.onBackPressed()
is always an anti-pattern and something that you should not do.It would be helpful if there was a Lint error that specifically catch this case and warn developers ahead of time that this is the wrong thing to do and offer alternatives or at least link to the guide for more information.