Introduction

Rounding specific corners of a View on Android is usually done with a shape drawable or a GradientDrawable configured with per-corner radii. The key detail is that Android wants the radii in a fixed order, so the code is straightforward once you know which values correspond to which corners.

XML Drawable Approach

For many views, an XML background is the simplest option:

1<shape xmlns:android="http://schemas.android.com/apk/res/android">
2    <solid android:color="#FF6B6B" />
3    <corners
4        android:topLeftRadius="16dp"
5        android:topRightRadius="16dp"
6        android:bottomRightRadius="0dp"
7        android:bottomLeftRadius="0dp" />
8</shape>

Apply it as the view background:

1<View
2    android:layout_width="120dp"
3    android:layout_height="60dp"
4    android:background="@drawable/rounded_top_only" />

This is clean, reusable, and easy to preview.

Programmatic Approach

If the corners depend on runtime state, use GradientDrawable:

1val shape = GradientDrawable().apply {
2    shape = GradientDrawable.RECTANGLE
3    setColor(Color.parseColor("#FF6B6B"))
4    cornerRadii = floatArrayOf(
5        16f, 16f,  // top-left
6        16f, 16f,  // top-right
7        0f, 0f,    // bottom-right
8        0f, 0f     // bottom-left
9    )
10}
11
12view.background = shape

The radii order is:

1. top-left x and y
2. top-right x and y
3. bottom-right x and y
4. bottom-left x and y

If that order is wrong, the rounded corners appear in the wrong places.

Rounded Corners and Clipping

Setting a rounded background does not automatically clip the contents of every child view the way people often expect. If you need children or images clipped to the same shape, you may need additional clipping behavior or a shape-aware container strategy.

This is why "the background looks rounded but my image still bleeds outside" is such a common complaint.

That distinction matters most with image-heavy cards, custom containers, and Material-style surfaces. Developers often solve the background shape and then assume the view hierarchy will clip itself automatically, but Android does not always behave that way unless clipping is explicitly part of the component strategy.

In other words, visual rounding and content clipping are related but separate concerns.

Practical Selection Guide

Use XML drawables when the shape is static and part of a reusable theme. Use programmatic drawables when the corner pattern changes at runtime, such as chat bubbles, grouped list items, or cards that change shape based on position. That choice keeps the layout simple while still giving you dynamic control where it is actually needed.

It also helps performance and maintainability. Static XML shapes are easy to reuse and preview, while code-based radii make sense only when the shape genuinely depends on runtime conditions.

That tradeoff is worth making deliberately.

It usually pays off.

When XML Is Better

Choose XML when:

• the shape is static
• the style is reused in several layouts
• designers want easy preview and theming

Choose code when:

• the corner combination changes dynamically
• the color and radii depend on runtime state
• you are generating views programmatically

Common Pitfalls

• Putting the radii in the wrong order for cornerRadii.
• Expecting the background to clip all child content automatically.
• Using pixel values directly instead of density-aware dimensions.
• Rebuilding many drawable objects unnecessarily in list-heavy UIs.
• Solving a static design problem in code when an XML drawable would be simpler.

Summary

• Specific Android view corners can be rounded with XML drawables or GradientDrawable.
• 'cornerRadii uses a fixed top-left to bottom-left ordering.'
• XML is best for reusable static styling.
• Runtime code is best for dynamic corner combinations.
• Rounded backgrounds and clipped child content are related but not identical problems.