Introduction

In Android custom views, attribute names defined in attrs.xml are not scoped only to one view in the way many developers first expect. The attribute itself is effectively global within the resource namespace, while declare-styleable groups decide which views reference it. That means same-named attributes should usually be declared once and then reused, not redefined separately with conflicting meanings.

Define the Attribute Once

A common pattern is to declare the attribute itself once, then include it in one or more declare-styleable blocks.

1<resources>
2    <attr name="labelColor" format="color" />
3
4    <declare-styleable name="PrimaryBadgeView">
5        <attr name="labelColor" />
6    </declare-styleable>
7
8    <declare-styleable name="SecondaryBadgeView">
9        <attr name="labelColor" />
10    </declare-styleable>
11</resources>

This means both custom views can read labelColor, and the attribute has one consistent definition.

Why Redefining the Same Name Causes Trouble

If you try to define the same attribute name again with a different format or meaning, resource merging becomes confusing and can fail.

Problematic pattern:

1<resources>
2    <attr name="labelColor" format="color" />
3    <attr name="labelColor" format="string" />
4</resources>

Even if the intent is "one for one view, another for another view," Android does not treat those as safely separate concepts. The name is the same, so the definition collides.

That is the key mental model: declare-styleable groups attributes, but the attribute resource name itself is shared.

Read the Attribute from a Custom View

Once the attribute is declared, the custom view can read it in the usual way.

1class PrimaryBadgeView @JvmOverloads constructor(
2    context: Context,
3    attrs: AttributeSet? = null,
4    defStyleAttr: Int = 0
5) : View(context, attrs, defStyleAttr) {
6
7    private var labelColor: Int = Color.BLACK
8
9    init {
10        val typedArray = context.obtainStyledAttributes(
11            attrs,
12            R.styleable.PrimaryBadgeView,
13            defStyleAttr,
14            0
15        )
16
17        labelColor = typedArray.getColor(
18            R.styleable.PrimaryBadgeView_labelColor,
19            Color.BLACK
20        )
21
22        typedArray.recycle()
23    }
24}

The important part is that R.styleable.PrimaryBadgeView_labelColor refers to the shared attribute within that specific styleable group.

Reuse Names Only When Meaning Matches

Using the same attribute name across multiple views is a good idea when the meaning is genuinely the same. For example, labelColor meaning "text or label color" can be shared across several components.

It becomes a bad idea when the same name would mean different things in different views. In that case, choose distinct names instead of overloading one attribute concept.

Good reuse:

• 'labelColor means the same visual role in several custom views'

Bad reuse:

• 'state means one thing in one widget and something unrelated in another'

Shared names work best when they represent shared semantics, not just a desire to keep names short.

Inheritance and Composition Make This More Important

The same-name question often appears when one custom view extends another or when several custom views are composed into a small design system. Reusing one attribute definition keeps the XML API consistent across related components.

That consistency is valuable, but only if the attribute contract stays stable. Once meanings diverge, separate names are clearer than clever reuse.

Keep Formats Consistent

If multiple views reference the same custom attribute, its format should remain consistent. Do not make one view expect a color and another expect a dimension for the same attribute name. That creates a confusing API and can break resource processing.

The attribute name, type, and meaning should all line up.

Common Pitfalls

• Declaring the same attribute name multiple times with conflicting formats.
• Assuming declare-styleable creates a private attribute namespace for each view.
• Reusing one attribute name for different meanings just because the text label is convenient.
• Forgetting to call recycle() on the obtained typed array.
• Designing a custom XML API around short names instead of clear, stable semantics.

Summary

• In attrs.xml, the attribute resource name is effectively global within the namespace.
• Declare a same-named custom attribute once and reuse it across multiple declare-styleable blocks when the meaning is the same.
• Do not redefine one attribute name with conflicting formats or semantics.
• Read the shared attribute through the styleable group for the specific view.
• Reuse names for shared concepts, not for unrelated settings that only happen to need a label.