I remember I was super excited when Autosizing TextView s were announced with Oreo. When I played a little with iOS development a few years ago, I was surprised to see they've already had an out of the box solution for that ever since 2.0 (even though it has its limits), so it was great to see we were finally catching up on this.

If this is something new to you, check out the documentation — it's pretty good. If you like videos, there's also a quick and great introduction to the subject by Florina Muntenescu.

Overall, autosizing on Android is awesome and it works great. It's so easy to use and it's finally a way out of our own complicated custom solutions to this issue, with the usual support for old (Android 4.0, API level 14) and future versions of Android.

However, if everything about it was great, I wouldn't be here writing a blogpost about it. So let's get our hands dirty.

Ellipsize

Ellipsize is a hard topic, and it gets especially hard when you mash it together with autosizing. I heard something along those lines when I asked the Android UI Toolkit team about this in the last I/O, and I couldn't agree more.

Before autosizing was an option, the best we could do whenever text wouldn't fit was to ellipsize it. It's fine if some text won't fit in our app— we can't blame authors for long book titles and we shouldn't make our book item view huge just to accommodate it, for instance. Users understand that as long as we're clear about it, and the clarity comes from the ellipsis. If we simply crop text that won't fit, we're basically breaking the user experience and making users aware that we failed to properly present the content for them.

I've always felt like ellipsize is an underrated feature, especially given the vast amount of cropped text bugs I've seen in most of the apps I've worked on so far. And I can't stress this enough: cropped text is bad and we should always avoid it. Let me repeat that one last time with a bigger italic font:

Cropped text is ba

Anyway, the best thing about autosizing is that it adds one more safety layer to make sure our text will show up properly. If for some reason the text won't fit, we don't need to ellipsize it anymore: we can decrease the font size until it fits well.

But what if it doesn't? What if the autoSizeMinTextSize specified isn't small enough? Then the text gets cropped. "It makes sense!", I thought when it first happened to me. "I haven't defined any ellipsize yet!", so I added an ellipsize="end" and the problem wasn't fixed.

Let's look at some code. Here's a very simple example to reproduce the situation I just described:

This is what this layout produces:

The minimum size of 40dp isn't enough for the whole text to fit, so it gets cropped even though I have an ellipsize="end" there. The ellipsis only shows up after I add a maxLines="2" there:

If you know in advance what's the maximum number of lines you want to allow, then that's not an issue for you. But the whole point of autosizing is to be able to have everything dynamic. Ideally, I don't want to have to set a maximum number of lines, I just want to say "hey, you decrease the font size until it fits, and if the minimum size isn't enough, then just ellipsize it", but unfortunately that's not possible at the moment.

However, we can be a little creative and come up with a workaround. We can write some code to check how many lines we have there, and set that as the maxLines on runtime.

And then we can simply call textView.setMaxLinesToEllipsize() whenever is appropriate. This works fine but unfortunately might lead to performance degradation on lists during scrolling, for instance, due to the extra layout processing it demands. Make sure you take that into account when deciding to do something like this.

If you google "android autosizing ellipsize", you'll most likely end up in this Stack Overflow question I created when I first faced this. I had some hope that maybe I was missing something, but in the end the only answer I got was my own — which is basically what you've just seen above.

Word Break

Here's another query for you: "android autosizing split word". If you google that, you'll also most likely end up in this other Stack Overflow question I also created a while ago. So let's start by looking at some code again:

This is exactly the same code presented before with only two differences:

The text is now composed of a single long word: "magnanimous "

The autoSizeMinTextSize is now 1 dp

Given our minimum font size is 1 dp, I'm sure we can fit "magnanimous" in that rectangle, right? Wrong.

Since we have some vertical space left, instead of decreasing the font size, the word is split up so that vertical space is used. The same happens if we add hyphenationFrequency as none . If we make it normal or full , we at least get proper hyphenation:

But this isn't what I want. Splitting up a word isn't as bad as cropping it, but it's still pretty bad depending on the situation. I'd like to be able to say "hey, only split up words if you've already reached the minimum font size", but it seems that's also not possible at the moment.

There's another attribute that might seem relevant for this which is called breakStrategy , but I played with all its values, in combination with different hyphenationFrequency values, and it always splits the word regardless — it just changes where the split happens sometimes.

At first I really thought HYPHENATION_FREQUENCY_NONE would get the job done, but if we read the documentation it's pretty clear it can't entirely prevent word breaks:

Value for hyphenation frequency indicating no automatic hyphenation. Useful for backward compatibility, and for cases where the automatic hyphenation algorithm results in incorrect hyphenation. Mid-word breaks may still happen when a word is wider than the layout and there is otherwise no valid break. Soft hyphens are ignored and will not be used as suggestions for potential line breaks.