Introduction

In Android, textStyle is an XML attribute, but the same idea can be applied at runtime with Typeface APIs. That matters when the style depends on user actions, validation state, downloaded fonts, or view recycling in a list. The key is to change the TextView's typeface or style intentionally instead of searching for a nonexistent setTextStyle method.

The Simplest Programmatic Style Change

If you only want bold, italic, or bold-italic using the current font family, call setTypeface with the existing typeface and a style constant.

TextView titleView = findViewById(R.id.titleView);
titleView.setTypeface(titleView.getTypeface(), Typeface.BOLD);

Available style constants are:

• 'Typeface.NORMAL'
• 'Typeface.BOLD'
• 'Typeface.ITALIC'
• 'Typeface.BOLD_ITALIC'

This is the most common answer because it preserves the current font family while changing the style.

Full Example in an Activity

1import android.graphics.Typeface;
2import android.os.Bundle;
3import android.widget.Button;
4import android.widget.TextView;
5import androidx.appcompat.app.AppCompatActivity;
6
7public class MainActivity extends AppCompatActivity {
8
9    @Override
10    protected void onCreate(Bundle savedInstanceState) {
11        super.onCreate(savedInstanceState);
12        setContentView(R.layout.activity_main);
13
14        TextView message = findViewById(R.id.message);
15        Button toggle = findViewById(R.id.toggleButton);
16
17        toggle.setOnClickListener(v -> {
18            boolean isBold = message.getTypeface() != null
19                    && message.getTypeface().isBold();
20
21            if (isBold) {
22                message.setTypeface(message.getTypeface(), Typeface.NORMAL);
23            } else {
24                message.setTypeface(message.getTypeface(), Typeface.BOLD);
25            }
26        });
27    }
28}

This pattern is useful in forms, filter bars, or any UI where visual emphasis changes based on interaction.

Kotlin Version

The same idea in Kotlin is concise.

val subtitle: TextView = findViewById(R.id.subtitle)
subtitle.setTypeface(subtitle.typeface, Typeface.ITALIC)

If you want to switch between styles at runtime:

button.setOnClickListener {
    subtitle.setTypeface(subtitle.typeface, Typeface.BOLD_ITALIC)
}

That is enough for most runtime styling needs.

Using a Custom Font and a Style Together

If the TextView uses a custom font, be careful. Replacing the typeface outright can accidentally throw away the font family you intended to keep. A better pattern is to load the font once, then create a styled version from that font.

val base = ResourcesCompat.getFont(this, R.font.roboto_slab)
val styled = Typeface.create(base, Typeface.BOLD)
textView.typeface = styled

This makes the relationship explicit: keep the custom family, change the style.

For newer apps using downloadable or bundled fonts, this is usually more predictable than mixing XML font resources and ad hoc runtime changes.

Style Versus Weight and Appearance

Developers often use "text style" to mean several different things. In Android, bold and italic are only one part of text appearance. Size, color, letter spacing, all-caps behavior, and font family are controlled separately. If you need a richer visual change, you may want to update multiple properties together.

For example, an error state might combine bold text, a red color, and a slightly larger size. Programmatic styling works best when you think of it as a full state update, not only a style flag.

Common Pitfalls

A common mistake is calling setTypeface(Typeface.DEFAULT_BOLD) and unintentionally replacing a custom font family with the system default. If the current font matters, pass the existing typeface into setTypeface(current, style) or create a styled version from the custom font.

Another mistake is expecting XML textStyle changes to update recycled views automatically in adapters or RecyclerView. If a view changes style based on data, reapply the correct style every time the row binds. Otherwise, styles leak between rows.

Developers also sometimes confuse fake bold rendering with a true bold font file. Some fonts do not have a strong bold variant, so the visual result may look uneven. If typography matters, provide the correct font resources rather than relying only on synthetic styling.

Finally, do not assume getTypeface() is always non-null in every edge case. In normal UI code it usually is, but null-safe handling is still a good habit in reusable components.

Summary

• Programmatic TextView style changes are usually done with setTypeface and a Typeface style constant.
• 'setTypeface(textView.getTypeface(), Typeface.BOLD) preserves the current font family while changing style.'
• Kotlin and Java both support the same underlying approach.
• Custom fonts need extra care so you do not accidentally replace the chosen font family.
• Reapply style in recycled views because runtime styling is view state, not automatic data state.