Fixed
Status Update
No update yet.
Comments
al...@google.com
Or when changing to textView.textMetricsParamsCompat still crash.
private fun setAsyncText(textView: AppCompatTextView, text: String?) {
if (!text.isNullOrEmpty()) {
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
textView.setTextFuture(textFuture) //Crash
}
}
private fun setAsyncText(textView: AppCompatTextView, text: String?) {
if (!text.isNullOrEmpty()) {
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
textView.setTextFuture(textFuture) //Crash
}
}
al...@google.com
add this line :
textView.setLayoutDirection(ViewCompat.getLayoutDirection(textView));
before :
setTextFuture(....)
textView.setLayoutDirection(ViewCompat.getLayoutDirection(textView));
before :
setTextFuture(....)
al...@google.com
Thanks, #3. It worked.
But I think it is better when set before this line
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
Set android:layoutDirection="locale" or android:layoutDirection="inherit" for AppCompatTextView in the XML layout didn't this problem.
The new method btw re-set layoutDirector. Weird! This should handle in the AppcompatTextView.
private fun setAsyncText(textView: AppCompatTextView, text: String?) {
if (!text.isNullOrEmpty()) {
textView.layoutDirection = textView.layoutDirection
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
textView.setTextFuture(textFuture) //Crash
}
}
But I think it is better when set before this line
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
Set android:layoutDirection="locale" or android:layoutDirection="inherit" for AppCompatTextView in the XML layout didn't this problem.
The new method btw re-set layoutDirector. Weird! This should handle in the AppcompatTextView.
private fun setAsyncText(textView: AppCompatTextView, text: String?) {
if (!text.isNullOrEmpty()) {
textView.layoutDirection = textView.layoutDirection
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
textView.setTextFuture(textFuture) //Crash
}
}
al...@google.com
Sorry. I forgot the info.
minSdk 21
targetSdk 28
Thanks #3 again.
minSdk 21
targetSdk 28
Thanks #3 again.
ap...@google.com
App Crash at
TextViewCompat.java:889
if (!param.equals(precomputed.getParams())) {
throw new IllegalArgumentException("Given text can not be applied to TextView.");
}
PrecomputedTextCompat.class:334
with : this.mTextDir != other.getTextDirection() == true
So,
TextDirection on TextView and TextDirection on Param is difference
maybe, it handled wrong or missing conditional on getTextDirectionHeuristic of TextViewCompat
TextViewCompat.java:889
if (!param.equals(precomputed.getParams())) {
throw new IllegalArgumentException("Given text can not be applied to TextView.");
}
PrecomputedTextCompat.class:334
with : this.mTextDir != other.getTextDirection() == true
So,
TextDirection on TextView and TextDirection on Param is difference
maybe, it handled wrong or missing conditional on getTextDirectionHeuristic of TextViewCompat
al...@google.com
With reference to
al...@google.com
bu...@google.com
Yes. textView.layoutDirection = textView.layoutDirection(>= API17) or ViewCompat.setLayoutDirection(textView, ViewCompat.getLayoutDirection(textView)) will resolve this bug.
But I think you should handle it in the AppcompatTextView. It is better. If a developer forgets testing with RTL. I think this is the nightmare(it is difficult to determine the bug) when they update their app on the Play Store.
I read this article, in the part databing he noted about set the direction
https://medium.com/google-developers/prefetch-text-layout-in-recyclerview-4acf9103f438 '
fun asyncText
..........
// first, set all measurement affecting properties of the text
// (size, locale, typeface, direction, etc)
But in the offical document isn't good (lack direction)
https://developer.android.com/reference/androidx/appcompat/widget/AppCompatTextView.html#setTextFuture(java.util.concurrent.Future%3Candroidx.core.text.PrecomputedTextCompat%3E)
Anything layout related property changes, text size, typeface, letter spacing, etc after this method call will causes IllegalArgumentException during View measurement.
My view: Handling this in the AppcompatTextView is the best choice if you can do it.
Thanks!
But I think you should handle it in the AppcompatTextView. It is better. If a developer forgets testing with RTL. I think this is the nightmare(it is difficult to determine the bug) when they update their app on the Play Store.
I read this article, in the part databing he noted about set the direction
fun asyncText
..........
// first, set all measurement affecting properties of the text
// (size, locale, typeface, direction, etc)
But in the offical document isn't good (lack direction)
Anything layout related property changes, text size, typeface, letter spacing, etc after this method call will causes IllegalArgumentException during View measurement.
My view: Handling this in the AppcompatTextView is the best choice if you can do it.
Thanks!
ap...@google.com
I think should handle setLayoutDirection in the AppcompatTextView when setTextFuture, it will simpler for dev when implement TextFuture.
ap...@google.com
We have passed this to the development team and will update this issue with more information as it becomes available.
Description
The conditional compatibility checking based on experimental annotations only checks if an API is currently experimental, and raises compatibility errors if a previously experimental API changes. This creates compatibility errors that weren't present before.
As an example:
androidx.benchmark.macro.junit4.BaselineProfileRulewas experimental in 1.1.0-beta05 with a method namedcollectBaselineProfile.public_plus_experimental_1.1.0-beta05.txtbut not1.1.0-beta05.txt.BaselineProfileRulehad the experimental annotation removed, and thecollectBaselineProfilemethod was renamed tocollect.BaselineProfileRulewas previously experimental and not present in1.1.0-beta05.txt, renaming thecollectmethod did not cause a compatibility error.1.1.0-beta05.txtadds an entry forBaselineProfileRulewith the experimental annotation since experimental APIs are now tracked in the main API file.checkApifor1.1.0-beta05.txtandcurrent.txtnow raises a compatibility error saying the methodcollectBaselineProfilewas removed.