textview – Android sp vs dp texts – what would adjust the 'scale' and what is the philosophy of support-ThrowExceptions

Exception or error:

So we know from many other posts that we should use sp rather than dp for text in Android, and we know the reason for this is to respect a ‘user’s preferences’.

But precisely what are these preferences?
How might a user change this setting?

I cannot find any reference through the settings on my phone (I would have expected something in ‘Accessibility’ or ‘Display’). So what is a user setting? Is it only done through the likes of an app such as ‘Big Font’?

Assuming that it is (set by something like big font) – I have played with Google Docs and some other Google apps with the font set to 130%. While most layout stays fine, some gets a bit cut off and can’t be read (and that is on a big screened SGS2). So, what is the approach to developing apps with text sizes using ‘sp’? Do we make sure it works on 100% scaling and then ignore other settings – call it a special case that the user can worry about, or do we go out of our way to make sure things expand or are scrollable, in case the text overflows?

One argument is that we should use ‘dp’ to guarantee a user has a chance of seeing the text (even if they have to use a magnifying glass)


How to solve:

It is exposed in the settings menu on some Android devices (manufacturer dependent). It may also be altered by some accessibility options (device-dependent).

In general, you should always used scale-independent pixels, especially for a large body of text.

However if your text has to fit into a bounding-box of known size then you should use density independent pixels in order to ensure that the text always fits properly and that all characters are visible regardless of the users’ setting.

In a nutshell: would increasing the text-size by around 5sp result in the text being unreadable or mangle your UI? If so use density-independent pixels. If not, use scale-independent pixels. However you should generally aim to use scale-independent pixels wherever possible, which means designing a UI that can accommodate different text sizes.


Using the sp unit is recommended for text because in ICS and above (could be Honeycomb too, correct me if I’m wrong), there is a preference for a user’s font size. So, if you’re using Gingerbread or lower, you won’t be able to find this setting.

The preference is under Settings, Display, Font Size. There’s also an option under Settings, Accessibility, Large text, too.

To address your question about how to go about using sp, note that by default, without changing any of the font size preferences, 1sp is equivalent to 1dp (also, they are equivalent before the preference was introduced). Like you’ve noted, designing for the case where a user has huge text would probably require you to assume things are going to need to scroll where you might otherwise not expect them to.


The answer lies in looking at this particular issue holistically.

The motivation for using “sp” for font sizes lies in giving the developer power to control their layout in the face of user changing the font size on their device.


Lets look at 2 extreme cases:

1) User selects font size “small”

This is what my layout looks like:


Here is the layout xml:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"

    android:text="Material-Design ist die Scheiße"
    android:background="#ffff0000" />
    android:text="Material-Design ist die Scheiße"
    android:background="#ffff0000" />

2) If the user selects font size “huge”:

This i what my layout looks like:


My layout xml is same as above in case 1).

So, as you can see what happened here is the top TextView has sort of perfect font-size in sp because it does not wrap for the entirety of the range of font sizes (small to huge). But the bottom TextView completely messes up your layout/design in case 2).

So you as a developer can iterate and decide what size in sp works for your design and android will draw it for you.

Leave a Reply

Your email address will not be published. Required fields are marked *