Android
RadioGroup
Selected Index
Android Development
Android Studio

How to get the selected index of a RadioGroup in Android

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

RadioGroup does not give you a selected index directly. It gives you the checked child view ID, and if you need the position instead, the normal approach is to look up that checked view and ask the group for its child index.

Start With the Checked View ID

The API entry point is getCheckedRadioButtonId(). It returns the selected RadioButton ID or -1 when nothing is selected.

xml
1<RadioGroup
2    android:id="@+id/paymentGroup"
3    android:layout_width="wrap_content"
4    android:layout_height="wrap_content"
5    android:orientation="vertical">
6
7    <RadioButton
8        android:id="@+id/cardOption"
9        android:layout_width="wrap_content"
10        android:layout_height="wrap_content"
11        android:text="Card" />
12
13    <RadioButton
14        android:id="@+id/cashOption"
15        android:layout_width="wrap_content"
16        android:layout_height="wrap_content"
17        android:text="Cash" />
18
19    <RadioButton
20        android:id="@+id/walletOption"
21        android:layout_width="wrap_content"
22        android:layout_height="wrap_content"
23        android:text="Wallet" />
24</RadioGroup>

That ID is enough if your logic cares only about which option was chosen. If your code depends on the position in the group, there is one more step.

Convert the Checked ID to an Index

Find the selected view and pass it to indexOfChild.

kotlin
1val paymentGroup = findViewById<RadioGroup>(R.id.paymentGroup)
2
3val checkedId = paymentGroup.checkedRadioButtonId
4if (checkedId != -1) {
5    val selectedView = paymentGroup.findViewById<View>(checkedId)
6    val selectedIndex = paymentGroup.indexOfChild(selectedView)
7    Log.d("RadioGroup", "Selected index: $selectedIndex")
8}

The returned position is zero-based, so the first radio button is index 0.

Read the Index When the User Changes Selection

In a real screen, you often want the index as soon as the user taps a new option. The natural place to do that is the checked-change listener.

kotlin
1paymentGroup.setOnCheckedChangeListener { group, checkedId ->
2    if (checkedId == -1) return@setOnCheckedChangeListener
3
4    val selectedView = group.findViewById<View>(checkedId)
5    val selectedIndex = group.indexOfChild(selectedView)
6
7    Log.d("RadioGroup", "Now selected: $selectedIndex")
8}

This keeps the derived index synchronized with the actual UI state instead of recomputing it later from stale assumptions.

Prefer IDs When Order Is Not the Real Data

Even though getting the index is easy, IDs are often more stable than positions. If the UI order changes later, code that depends on hard-coded indexes can silently become wrong while ID-based logic still works.

A good rule is:

  • use the index when the visible order itself matters
  • use the checked ID when the option identity matters

That keeps business logic from becoming fragile as layouts evolve.

Handle Empty and Default States

checkedRadioButtonId returns -1 when nothing is selected. That case matters if the form starts empty or if your code clears the selection intentionally.

If the UI should always have a default option, set that explicitly in XML or call check(...) during setup. Starting from a known selected state makes downstream validation and index logic simpler.

Watch Out for Layout Structure

indexOfChild only measures direct children of the RadioGroup. If you start nesting RadioButton views inside extra layout containers, the returned index may no longer match the visual order you expected.

When the layout becomes more complex, flatten the children or maintain your own list of meaningful option IDs rather than relying on child order.

Common Pitfalls

Assuming getCheckedRadioButtonId() returns an index is the most common mistake. It returns a view ID.

Forgetting to handle the -1 case leads to crashes or incorrect logic when nothing is selected.

Hard-coding business behavior to child positions can become fragile when a designer later changes the order of the options.

Using nested layout containers inside the RadioGroup can make indexOfChild stop reflecting the visible choice order.

Recomputing the selection long after the click instead of reading it inside the change listener can create unnecessary state bugs.

Summary

  • 'RadioGroup reports the checked option by ID, not by index.'
  • Convert that ID to a position with findViewById and indexOfChild.
  • The returned index is zero-based.
  • Use a checked-change listener when you want the position at selection time.
  • Prefer stable IDs over indexes when option identity matters more than display order.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.