Introduction

On Android, "device name" can mean several different things: manufacturer plus model, a Bluetooth name, or a user-facing device label shown in system settings. For most app code, the practical answer is to build a readable name from Build.MANUFACTURER and Build.MODEL, because that works consistently without relying on hardware-specific or settings-specific behavior.

The Reliable Baseline: Manufacturer and Model

The most common programmatic device name is a combination of manufacturer and model.

1import android.os.Build
2import java.util.Locale
3
4fun getDeviceName(): String {
5    val manufacturer = Build.MANUFACTURER
6    val model = Build.MODEL
7
8    return if (model.startsWith(manufacturer, ignoreCase = true)) {
9        model.replaceFirstChar {
10            if (it.isLowerCase()) it.titlecase(Locale.getDefault()) else it.toString()
11        }
12    } else {
13        "${manufacturer.replaceFirstChar {
14            if (it.isLowerCase()) it.titlecase(Locale.getDefault()) else it.toString()
15        }} $model"
16    }
17}

This avoids awkward results such as "Samsung Samsung Galaxy S23" when the model already includes the manufacturer name.

Why This Is Usually Good Enough

For analytics, debugging, support logs, or conditional UI tweaks, manufacturer and model are usually what you actually need. They are stable, available through the standard Android API, and do not require special permissions.

Typical examples:

• '"Google Pixel 8"'
• '"Samsung SM-S918B"'
• '"Xiaomi 13"'

These values are not perfect marketing names in every case, but they are good enough for most app-side device identification.

Bluetooth Name Is a Different Thing

Some developers look at the Bluetooth adapter name because it may reflect a user-assigned device name. That is a different concept and may be unavailable, permission-sensitive, or not representative of the actual hardware model.

Historically it looked something like this:

1import android.bluetooth.BluetoothAdapter
2
3fun getBluetoothName(): String? {
4    return BluetoothAdapter.getDefaultAdapter()?.name
5}

This can be useful if your feature is specifically about Bluetooth pairing or nearby-device UX. It is not the best general answer for "what device is this?"

Settings-Based Names Are Not Uniform

Android system settings may expose a device label shown to the user, but access and behavior can vary by OS version, manufacturer customization, and privacy boundaries. That means an app should not assume there is one universal settings key that always returns the same user-visible device name on every Android device.

If you need a robust, cross-device answer, rely on Build fields first and treat anything more user-customized as optional.

Java Version

The same logic in Java is straightforward:

1import android.os.Build;
2
3public class DeviceUtil {
4    public static String getDeviceName() {
5        String manufacturer = Build.MANUFACTURER;
6        String model = Build.MODEL;
7
8        if (model.toLowerCase().startsWith(manufacturer.toLowerCase())) {
9            return capitalize(model);
10        }
11        return capitalize(manufacturer) + " " + model;
12    }
13
14    private static String capitalize(String value) {
15        if (value == null || value.isEmpty()) {
16            return "";
17        }
18        return Character.toUpperCase(value.charAt(0)) + value.substring(1);
19    }
20}

This is enough for most support and diagnostics screens.

Common Pitfalls

The biggest mistake is assuming "device name" always means the same thing. Hardware model, Bluetooth name, and user-visible settings labels are related but not identical.

Another issue is using Bluetooth names as a generic identifier. They may be absent, permission-sensitive, or changed by the user.

Developers also sometimes expect a polished marketing name from Android APIs. In reality, some devices expose technical model strings instead.

Finally, avoid using device names as stable identifiers. A model string is useful for display and diagnostics, but not for uniquely identifying one installation or one user device over time.

Summary

• For most apps, combine Build.MANUFACTURER and Build.MODEL to get a readable Android device name.
• This is the most reliable cross-device approach for diagnostics and UI display.
• Bluetooth names and settings-based labels represent different concepts and should be used only when that specific behavior is needed.
• Do not expect every device to expose a perfect marketing name.
• Treat device names as descriptive strings, not as durable unique identifiers.