Introduction

On Android, the usual way to get device model information is through the android.os.Build class. The important detail is that "device name" can mean different things, so you should decide whether you want a hardware identifier, a manufacturer plus model string, or a more user-facing label.

The Core Build Fields

The most commonly used fields are:

• 'Build.MANUFACTURER'
• 'Build.MODEL'
• 'Build.DEVICE'
• 'Build.PRODUCT'

A basic example:

1import android.os.Build
2
3val manufacturer = Build.MANUFACTURER
4val model = Build.MODEL
5val device = Build.DEVICE
6val product = Build.PRODUCT
7
8println("manufacturer=$manufacturer")
9println("model=$model")
10println("device=$device")
11println("product=$product")

These values come from the OS build and are available without special permissions.

What Most Apps Really Want

In most apps, the best user-facing string is a cleaned combination of manufacturer and model.

1import android.os.Build
2import java.util.Locale
3
4fun getReadableDeviceName(): String {
5    val manufacturer = Build.MANUFACTURER.orEmpty().trim()
6    val model = Build.MODEL.orEmpty().trim()
7
8    return if (model.lowercase(Locale.US).startsWith(manufacturer.lowercase(Locale.US))) {
9        model.replaceFirstChar { it.uppercase() }
10    } else {
11        "${manufacturer.replaceFirstChar { it.uppercase() }} $model"
12    }
13}

This avoids awkward outputs such as Samsung Samsung SM-A546U when the model already includes the manufacturer name.

Hardware Identifier Versus User-Friendly Name

These fields are not interchangeable:

• 'Build.MODEL is usually the most recognizable model name.'
• 'Build.DEVICE is more of a build or device code name.'
• 'Build.PRODUCT is another product identifier that may be less friendly.'

If you are logging diagnostics for internal use, DEVICE and PRODUCT can be valuable. If you are showing information in a settings screen, MANUFACTURER plus MODEL is usually the better choice.

Example in an Activity

Here is a minimal activity example that displays the readable device name.

1import android.os.Bundle
2import android.widget.TextView
3import androidx.appcompat.app.AppCompatActivity
4
5class MainActivity : AppCompatActivity() {
6    override fun onCreate(savedInstanceState: Bundle?) {
7        super.onCreate(savedInstanceState)
8
9        val textView = TextView(this)
10        textView.text = getReadableDeviceName()
11        setContentView(textView)
12    }
13}

This is enough for a device-info screen, a bug-report view, or support diagnostics shown to the user.

What About the User-Assigned Device Name

Developers sometimes expect Android to expose the exact user-assigned phone name from system settings in a universal way. That is much less consistent across devices and OS customizations than Build.MODEL.

So if the requirement is "show the phone model," Build.MODEL is the stable answer. If the requirement is "show the exact friendly name the user sees in settings," you need to be much more careful because that is not uniformly exposed in the same way across all devices.

Use Device Data Responsibly

Device model information is often collected for analytics, debugging, compatibility workarounds, or support flows. That is fine, but do not collect more than you need, and do not confuse device model data with a reliable unique identifier.

Model information tells you the hardware family, not who the user is.

Common Pitfalls

• Using Build.DEVICE when the actual requirement was a user-friendly model name.
• Displaying MANUFACTURER + MODEL without checking whether the model already includes the manufacturer.
• Expecting a universal API for the exact user-assigned phone name in settings.
• Treating model information as a unique device identifier.
• Sending device details to a server without considering whether the data is actually needed.

Summary

• Use Build.MODEL for the common case of showing the phone model.
• Combine Build.MANUFACTURER and Build.MODEL for a more readable display string.
• Use Build.DEVICE and Build.PRODUCT for lower-level diagnostics, not for normal UI.
• Be careful with the phrase "device name" because it can mean different things.
• Device model data is useful for diagnostics, but it is not a unique identity for a user or device.