Как получить модель устройства в Android и правильно её использовать

Build.MODEL — это строка, возвращающая модель устройства (например, "Pixel 5" или "SM‑G991B"). Её получают напрямую в коде через Build.MODEL или через ADB (ro.product.model) и используют в логировании, аналитике багов и при таргетировании тестов.

Что такое Build.MODEL и где он хранится

Build.MODEL — поле в Android SDK (android.os.Build), которое отражает маркетинговое/системное имя модели устройства. Технически это значение считывается из системных свойств (ro.product.model). Оно не гарантирует уникальность и может отличаться по региону или прошивке, но полезно как быстрый идентификатор при диагностике.

Как правильно получить модель: примеры и рекомендации

  • В коде Android (Java/Kotlin):
    • Java: String model = android.os.Build.MODEL;
    • Kotlin: val model = Build.MODEL
  • Через ADB (на подключённом устройстве/эмуляторе):
    • adb shell getprop ro.product.model
  • Для диагностических логов рекомендуется собирать набор: Build.MANUFACTURER, Build.MODEL, Build.VERSION.RELEASE и Build.VERSION.SDK_INT.

Добавляйте модель в баг-репорт вместе с версией ОС и идентификатором сборки — это ускоряет воспроизведение и приоритизацию.

Пример утилитного метода (Kotlin): fun deviceInfo(): String { return "${Build.MANUFACTURER} ${Build.MODEL} — Android ${Build.VERSION.RELEASE} (SDK ${Build.VERSION.SDK_INT})" }

Где и зачем использовать Build.MODEL на практике

  • Логирование и баг-репорты: помогает сопоставить проблему с конкретной аппаратной конфигурацией.
  • Тест-планы: при выборе реальных устройств для тестирования включайте топ‑модели по вашей аудитории.
  • Фичи и оптимизации: для критичных функций (графика, кодеки, сенсоры) учитывайте известные ограничения на определённых моделях.
  • Аналитика: сегментируйте телеметрию по моделям, чтобы выявлять корреляции между устройствами и ошибками.

Практические приёмы и шаблоны

  • Собирайте модель вместе с производителем, версией ОС и флагом root/adb: это минимальный набор для диагностики.
  • Нормализуйте имена моделей в отчётах (убирайте лишние пробелы/суффиксы) и при хранении используйте оригинал + human‑friendly имя.
  • Храните справочник топ‑10 моделей вашей аудитории с отмеченными особенностями (например, known GPU bugs).

Сравнение полей для более полного контекста

ПолеЧто даёт
Build.MANUFACTURERПроизводитель (Samsung, Google)
Build.MODELМодель/маркетинговое имя
ro.product.modelСистемное свойство, совпадает с Build.MODEL
Build.FINGERPRINTПолная строка прошивки для точной идентификации

Не полагайтесь только на Build.MODEL для принятия решений о совместимости — учитывайте чипсет, драйверы, версии библиотек (OpenGL/Vulkan) и реальные тесты.

Частые ошибки

  • Ложная уникальность: разные устройства могут иметь идентичное Build.MODEL.
  • Ожидание стабильного формата: производители добавляют суффиксы/локализации.
  • Хранение только модели в логах без версии ОС и сборки приложения — затрудняет воспроизведение.

FAQ

  • В чем разница между Build.MODEL и маркетинговым названием в настройках?
    Build.MODEL — системное значение, настройки могут показывать маркетинговое или локализованное имя; для разработчика важен точный системный вывод.

  • Можно ли блокировать функции по Build.MODEL?
    Лучше избегать жёсткой блокировки по модели. Используйте feature detection (проверку API/наличия сенсора/версии драйвера) и только при крайней необходимости добавляйте исключения для конкретных моделей.

  • Как проверять влияние локализации на имя модели?
    Тестируйте вывод Build.MODEL на устройствах из целевых регионов и сохраняйте оба поля: ro.product.brand и ro.product.name для контекста.

Если нужно, адаптирую статью под конкретную аудиторию (QA, техподдержка, мобильная аналитика) или добавлю пример кода для сбора телеметрии и отправки её в баг‑трекер.