Android'de cihaz modelini nasıl elde edilir ve doğru şekilde kullanılır

Kerem Aydın·7 Temmuz 2026·⏱3 dk

Build.MODEL, cihaz modelini döndüren bir dizedir (örneğin, "Pixel 5" veya "SM‑G991B"). Doğrudan kod içinde Build.MODEL aracılığıyla veya ADB üzerinden (ro.product.model) elde edilir ve günlük kaydı tutma, hata analitiği ve testleri hedefleme amacıyla kullanılır.

Build.MODEL nedir ve nerede saklanır

Build.MODEL, Android SDK'da (android.os.Build) bulunan ve cihazın pazarlama/sistem adını yansıtan bir alandır. Teknik olarak bu değer sistem özelliklerinden (ro.product.model) okunur. Benzersizliği garanti etmez ve bölgeye veya yazılıma göre farklılık gösterebilir, ancak teşhis sırasında hızlı bir tanımlayıcı olarak faydalıdır.

Modeli doğru şekilde nasıl elde edilir: örnekler ve öneriler

  • Android kodunda (Java/Kotlin):
    • Java: String model = android.os.Build.MODEL;
    • Kotlin: val model = Build.MODEL
  • ADB üzerinden (bağlı cihaz/emülatör):
    • adb shell getprop ro.product.model
  • Teşhis günlükleri için Build.MANUFACTURER, Build.MODEL, Build.VERSION.RELEASE ve Build.VERSION.SDK_INT kombinasyonunu toplamanız önerilir.

Hata raporuna işletim sistemi sürümü ve derleme kimliği ile birlikte modeli ekleyin; bu, hatanın yeniden oluşturulmasını ve önceliklendirilmesini hızlandırır.

Yardımcı yöntem örneği (Kotlin): fun deviceInfo(): String { return "${Build.MANUFACTURER} ${Build.MODEL} — Android ${Build.VERSION.RELEASE} (SDK ${Build.VERSION.SDK_INT})" }

Build.MODEL'ü pratikte nerede ve neden kullanmalısınız

  • Günlük kaydı ve hata raporları: Sorunu belirli donanım yapılandırmasıyla eşleştirmeye yardımcı olur.
  • Test planları: Test için gerçek cihazları seçerken hedef kitlenize göre en popüler modelleri dahil edin.
  • Özellikler ve optimizasyonlar: Kritik işlevler (grafik, kodekler, sensörler) için belirli modellerdeki bilinen kısıtlamaları dikkate alın.
  • Analitik: Cihazlar ve hatalar arasındaki korelasyonları ortaya çıkarmak için telemetriyi modellere göre segmentlere ayırın.

Pratik teknikler ve şablonlar

  • Teşhis için minimum set olarak modeli üretici, işletim sistemi sürümü ve root/adb bayrağı ile birlikte toplayın.
  • Raporlarda model adlarını normalize edin (gereksiz boşlukları/sonekleri kaldırın) ve depolarken orijinali + kullanıcı dostu adı kullanın.
  • Hedef kitlenizin en popüler 10 modelinin listesini bilinen özelliklerle (örneğin, bilinen GPU hataları) işaretleyerek saklayın.

Daha kapsamlı bağlam için alan karşılaştırması

AlanNe sağlar
Build.MANUFACTURERÜretici (Samsung, Google)
Build.MODELModel/pazarlama adı
ro.product.modelBuild.MODEL ile aynı olan sistem özelliği
Build.FINGERPRINTKesin tanımlama için tam yazılım dizesi

Uyumluluk kararları almak için yalnızca Build.MODEL'e güvenmeyin; çipseti, sürücüleri, kitaplık sürümlerini (OpenGL/Vulkan) ve gerçek testleri dikkate alın.

Sık yapılan hatalar

  • Yanlış benzersizlik varsayımı: Farklı cihazlar aynı Build.MODEL değerine sahip olabilir.
  • Kararlı format beklentisi: Üreticiler sonekler/yerelleştirmeler ekler.
  • Günlüklerde yalnızca modeli işletim sistemi sürümü ve uygulama derlemesi olmadan saklamak; yeniden oluşturmayı zorlaştırır.

SSS

  • Build.MODEL ile ayarlardaki pazarlama adı arasındaki fark nedir?
    Build.MODEL sistem değeridir; ayarlar pazarlama veya yerelleştirilmiş adı gösterebilir; geliştirici için kesin sistem çıktısı önemlidir.

  • Build.MODEL'e göre işlevleri engelleyebilir miyim?
    Modele göre katı engellemeden kaçınmak daha iyidir. Özellik algılama (API/sensör varlığı/sürücü sürümü kontrolü) kullanın ve yalnızca son çare olarak belirli modeller için istisnalar ekleyin.

  • Yerelleştirmenin model adı üzerindeki etkisini nasıl kontrol edebilirim?
    Build.MODEL çıktısını hedef bölgelerdeki cihazlarda test edin ve bağlam için hem ro.product.brand hem de ro.product.name alanlarını saklayın.

Gerekirse makaleyi belirli bir kitleye (QA, teknik destek, mobil analitik) göre uyarlayabilir veya telemetri toplama ve bunu hata izleyiciye gönderme için kod örneği ekleyebilirim.