Android 17'de Büyük Ekran Uyumu Artık Zorunlu

Android 17 (API 37), sabit yönlendirme ve "yeniden boyutlandırılamaz" işaretlemesiyle büyük ekranlardan kaçınan uygulamalar için kaçış kapısını kapatıyor. Hedef SDK'nı 37'ye çektiğinde, en küçük genişliği (smallest width) 600dp'den büyük ekranlarda screenOrientation, resizeableActivity, minAspectRatio ve maxAspectRatio sistem tarafından yok sayılıyor — bu bir öneri değil, çalışma zamanı zorlaması. Bu yazıda tam olarak neyin değiştiğini, hangi uygulamaların muaf olduğunu, uygulamanın kırılıp kırılmayacağını nasıl test edeceğini ve Compose ile adaptive layout'a geçiş yolunu kaynaklı şekilde anlatıyorum.

💡 Pro Tip: Hedef SDK'yı 37'ye yükseltmeden önce resizeableActivity="false" veya sabit screenOrientation kullanan her Activity'yi işaretle — göç planının ilk adımı bu envanter olmalı.

İçindekiler

• Tam olarak ne değişti
• Kimler muaf
• Uygulaman kırılacak mı: hızlı bir kontrol
• WindowSizeClass ile adaptive layout
• Compose'da canonical layout'lar
• Kamera ve medya için orientation tuzakları
• Katlanabilir ve masaüstü modunda test matrisi
• Aşamalı göç planı
• SSS
• Android 17'de screenOrientation=portrait neden çalışmıyor?
• resizeableActivity=false artık geçerli mi?
• Uygulamamı büyük ekrana nasıl uyarlarım?
• Hangi uygulamalar büyük ekran zorunluluğundan muaf?
• Değişiklik tüm Android 17 cihazlarını mı etkiliyor?
• Test için gerçek cihaza ihtiyacım var mı?
• Sonuç
• Kaynaklar

Tam olarak ne değişti

Android 17'yi hedefleyen (API level 37+) uygulamalarda, sistem artık en küçük genişliği 600dp'den büyük ekranlarda aşağıdaki manifest özniteliklerini ve runtime çağrılarını yok sayıyor — hem tam ekran hem de çoklu pencere modunda:

• android:screenOrientation: portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape dahil tüm sabit değerler etkisiz.
• android:resizeableActivity="false": artık hiçbir etkisi yok, sistem uygulamayı yeniden boyutlandırılabilir kabul ediyor.
• android:minAspectRatio / android:maxAspectRatio: en-boy oranı kısıtlamaları uygulanmıyor.
• setRequestedOrientation() / getRequestedOrientation(): runtime'da çağrılsa bile büyük ekranda etkisi yok.

Eşiğin yazımı iki resmi sayfa arasında ayrışıyor: birincil değişiklik sayfası "greater than 600dp" (yalnızca 600dp'nin üzeri) diyor — bu yazı boyunca esas aldığım ifade bu; uyumluluk-modu rehberi ise aynı API 37 davranışını "at least sw600dp" (600dp dahil) olarak yazıyor. 600dp'nin üzerindeki ekranlarda sistemin bu öznitelikleri yok saydığı kesin; tam 600dp sınır vakasında davranışı kendi referans cihazında doğrula. Bu değişiklik yeni bir kısıtlama eklemiyor; tam tersine, Android 16'da geliştiricilere tanınan geçici bir opt-out mekanizmasını kapatıyor. Yani "neden şimdi" sorusunun cevabı basit: geçiş dönemi bitti, kalıcı kural yürürlüğe girdi.

Pratikte bunun anlamı şu: telefonunda mükemmel çalışan, portrait'e kilitlenmiş bir Activity'n varsa, aynı APK bir tablette veya katlanabilir cihazın açık halinde artık sistem tarafından zorla yeniden boyutlandırılabilir ve yön kısıtlaman uygulanmaz. Uygulaman buna hazır değilse, kullanıcı arayüzün gerilmiş, kırpılmış veya yanlış konumlanmış görünebilir.

1<!-- ÖNCE (Android 16 ve altı hedeflendiğinde çalışırdı) -->
2<activity
3    android:name=".MainActivity"
4    android:screenOrientation="portrait"
5    android:resizeableActivity="false" />
6 
7<!-- SONRA (targetSdk=37, sw>600dp ekranda bu öznitelikler YOK SAYILIR) -->
8<activity
9    android:name=".MainActivity" />
10<!-- Yön kısıtlaması yerine adaptive layout kodu (bkz. WindowSizeClass bölümü) -->

Kimler muaf

Kısıtlama zorunluluğunun üç istisnası var:

• Oyunlar: Manifest'te android:appCategory="game" ile işaretlenmiş oyunlar bu kısıtlamalardan muaf tutuluyor.
• Kullanıcı tercihi: Kullanıcı, cihazın en-boy oranı ayarlarından uygulamanın varsayılan davranışını açıkça seçerse kısıtlamalar uygulanmıyor.
• Küçük ekranlar: En küçük genişliği 600dp veya altında olan cihazlarda (standart telefonların büyük çoğunluğu) bu öznitelikler çalışmaya devam ediyor, yani davranış değişikliğini hiç görmüyorlar.

Tablet, katlanabilir (açık hal), masaüstü pencereleme modu ve harici bağlı ekranlar — hepsi 600dp eşiğini kolayca aşıyor, dolayısıyla hepsinde sistem bu öznitelikleri yok sayıyor.

Uygulaman kırılacak mı: hızlı bir kontrol

Hedef SDK'yı yükseltmeden önce mevcut davranışını gerçek referans cihazlarda doğrulaman gerekiyor. Resmi rehber iki test yolu öneriyor: Firebase destekli Android Device Streaming ile gerçek büyük ekranlı cihazlara erişim, ve Android Studio'nun yeniden boyutlandırılabilir emülatörü ile lokal test.

Letterbox (siyah şeritli, ortalanmış) davranışı programatik olarak da doğrulayabilirsin:

1import android.app.Activity
2import androidx.window.layout.WindowMetricsCalculator
3 
4fun Activity.isLetterboxed(): Boolean {
5    // Çoklu pencerede küçük pencere letterbox sayılmaz
6    if (isInMultiWindowMode) return false
7 
8    val wmc = WindowMetricsCalculator.getOrCreate()
9    val currentBounds = wmc.computeCurrentWindowMetrics(this).bounds
10    val maxBounds = wmc.computeMaximumWindowMetrics(this).bounds
11 
12    val isScreenPortrait = maxBounds.height() > maxBounds.width()
13 
14    return if (isScreenPortrait) {
15        currentBounds.height() < maxBounds.height()
16    } else {
17        currentBounds.width() < maxBounds.width()
18    }
19}

1import androidx.test.ext.junit.rules.ActivityScenarioRule
2import androidx.test.ext.junit.runners.AndroidJUnit4
3import org.junit.Assert.assertFalse
4import org.junit.Rule
5import org.junit.Test
6import org.junit.runner.RunWith
7 
8// Test: Activity büyük ekranda letterbox OLMAMALI
9// JUnit4 yalnızca sınıfları tarar; top-level @Test fonksiyonu sessizce hiç koşmaz.
10@RunWith(AndroidJUnit4::class)
11class LetterboxTest {
12 
13    @get:Rule
14    val activityRule = ActivityScenarioRule(MainActivity::class.java)
15 
16    @Test
17    fun activity_launched_notLetterBoxed() {
18        activityRule.scenario.onActivity { activity ->
19            assertFalse(activity.isLetterboxed())
20        }
21    }
22}

Test sürecinde şu sırayı izlemeni öneririm: önce hedef SDK'yı değiştirmeden, mevcut APK'nı büyük ekranlı bir referans cihazda çalıştırıp sistemin şu an senin lehine uyguladığı yön kısıtlamasını gözlemle. Ardından isLetterboxed() yardımcısını gerçek uygulamanın ana ekranlarına ekleyip CI'da otomatik olarak koştur — böylece regresyonu her build'de erken yakalarsın. Son adım, hedef SDK'yı geçici olarak 37 yapan ayrı bir debug flavor oluşturup davranışı asıl release yapılandırmasını bozmadan gözlemlemektir.

Test matrisinde en az şu cihaz kategorilerini bulundur:

Her kategori, uygulamanın per-app override ihtiyacını ortaya çıkarabilir — bu yüzden tek bir tablet testi yeterli değil, katlama/açma ve ekran bağlama anlarını da test matrisine dahil et.

WindowSizeClass ile adaptive layout

Sabit yön yerine, pencere boyutuna göre layout seçen adaptive yaklaşıma geçmek gerekiyor. Compose Material3 adaptive kütüphanesi, genişliği sınıflara ayırıyor:

Kritik nokta: bu sınıflar cihaz temelli değil, pencere temelli ve dinamiktir — yön değişimi, çoklu pencere ve katlama/açma anında değişebilir. Yani sınıfı bir kez hesaplayıp önbelleğe almak yanlış; her recomposition'da güncel değeri okumalısın.

Compose tarafında dallanma şöyle görünür:

1import androidx.compose.material3.adaptive.currentWindowAdaptiveInfo
2import androidx.compose.runtime.Composable
3import androidx.window.core.layout.WindowSizeClass
4 
5@Composable
6fun CompactLayout() { /* tek panel */ }
7 
8@Composable
9fun MediumLayout() { /* tek panel, geniş kenar boşluğu */ }
10 
11@Composable
12fun ExpandedLayout() { /* iki panel yan yana */ }
13 
14@Composable
15fun AdaptiveScreen() {
16    val windowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
17 
18    when {
19        windowSizeClass.isWidthAtLeastBreakpoint(
20            WindowSizeClass.WIDTH_DP_EXPANDED_LOWER_BOUND
21        ) -> ExpandedLayout()
22        windowSizeClass.isWidthAtLeastBreakpoint(
23            WindowSizeClass.WIDTH_DP_MEDIUM_LOWER_BOUND
24        ) -> MediumLayout()
25        else -> CompactLayout()
26    }
27}

Large ve Extra-large sınıflarını da ayırt etmek istersen supportLargeAndXLargeWidth = true parametresini kullan:

1val windowSizeClass =
2    currentWindowAdaptiveInfo(supportLargeAndXLargeWidth = true).windowSizeClass

Henüz tamamen Compose'a geçmemiş, View tabanlı (XML layout) bir uygulaman varsa da aynı androidx.window altyapısını kullanabilirsin — WindowSizeClass yalnızca Compose'a özgü değil, WindowMetricsCalculator üzerinden View dünyasında da erişilebilir:

1import android.content.res.Configuration
2import android.os.Bundle
3import android.widget.FrameLayout
4import androidx.appcompat.app.AppCompatActivity
5import androidx.window.core.layout.WindowSizeClass
6import androidx.window.layout.WindowMetricsCalculator
7 
8class MainActivity : AppCompatActivity() {
9    override fun onCreate(savedInstanceState: Bundle?) {
10        super.onCreate(savedInstanceState)
11        setContentView(R.layout.activity_main)
12        updateLayoutForWindowSize()
13    }
14 
15    override fun onConfigurationChanged(newConfig: Configuration) {
16        super.onConfigurationChanged(newConfig)
17        updateLayoutForWindowSize()
18    }
19 
20    private fun updateLayoutForWindowSize() {
21        val metrics = WindowMetricsCalculator.getOrCreate()
22            .computeCurrentWindowMetrics(this)
23        val widthDp = metrics.bounds.width() / resources.displayMetrics.density
24        val container = findViewById<FrameLayout>(R.id.container)
25        if (widthDp >= WindowSizeClass.WIDTH_DP_EXPANDED_LOWER_BOUND) {
26            // Expanded: iki panelli layout inflate et
27            container.removeAllViews()
28            layoutInflater.inflate(R.layout.layout_two_pane, container, true)
29        } else {
30            // Compact/Medium: tek panelli layout
31            container.removeAllViews()
32            layoutInflater.inflate(R.layout.layout_single_pane, container, true)
33        }
34    }
35}

onConfigurationChanged yalnızca manifest'te ilgili configChanges değerleri bildirildiğinde çağrılır; bildirilmezse Activity yeniden oluşturulur ve boyut hesabı onCreate yolundan geçer. Bu yaklaşım Compose'daki kadar zarif değil (layout'u elle şişirmen gerekiyor), ancak kademeli göç yapan ekipler için Compose'a tam geçmeden önce sabit yön varsayımını kaldırmanın pratik bir yolu.

Compose'da canonical layout'lar

WindowSizeClass'ı elle dallandırmak yerine, Material3 adaptive kütüphanesinin hazır canonical layout bileşenlerini kullanmak daha az hataya açık. İki desen öne çıkıyor:

• List-detail: Kullanıcının öğe listesini keşfedip her öğe için açıklayıcı ek bilgi gördüğü desen. ListDetailPaneScaffold + rememberListDetailPaneScaffoldNavigator() ile uygulanır; expanded genişlikte liste ve detay yan yana, compact/medium'da tek panel gösterilir.
• Supporting pane: İçeriği birincil ve ikincil alanlara ayırır; resmi rehber genişletilmiş (expanded) genişlikte alanın %70'ini ana içeriğe, %30'unu destekleyici içeriğe vermeyi, orta (medium) genişlikte ise alanı eşit bölmeyi öneriyor. Fark şu: list-detail'in detay paneli ana içerik olmadan da anlamlıyken, supporting pane'in ikincil içeriği yalnızca birincil içerikle birlikte anlam taşır. SupportingPaneScaffold + rememberSupportingPaneScaffoldNavigator() ile uygulanır.

Her iki bileşen de kendi navigator'ını taşıdığı için, pane'ler arası geçiş ve durum saklama (state restoration) senin elle yazman gereken bir şey değil: navigator geri yığınını tutar, geri davranışını ise BackNavigationBehavior ile ayarlayabilirsin. Bu, elle yazılmış if (windowSizeClass == Compact) { ... } else { ... } dallanmalarına göre önemli bir bakım avantajı: pencere boyutu her değiştiğinde manuel navigation state senkronizasyonu yazmak zorunda kalmıyorsun.

List-detail deseninin en yalın hâli şöyle:

1import androidx.compose.material3.adaptive.ExperimentalMaterial3AdaptiveApi
2import androidx.compose.material3.adaptive.layout.ListDetailPaneScaffold
3import androidx.compose.material3.adaptive.layout.ListDetailPaneScaffoldRole
4import androidx.compose.material3.adaptive.navigation.rememberListDetailPaneScaffoldNavigator
5import androidx.compose.runtime.Composable
6import androidx.compose.runtime.rememberCoroutineScope
7import kotlinx.coroutines.launch
8 
9typealias EmailId = Long
10 
11@Composable
12fun EmailList(onEmailClick: (EmailId) -> Unit) { /* liste paneli */ }
13 
14@Composable
15fun EmailDetail(emailId: EmailId) { /* detay paneli */ }
16 
17@OptIn(ExperimentalMaterial3AdaptiveApi::class)
18@Composable
19fun EmailApp() {
20    val scope = rememberCoroutineScope()
21    val navigator = rememberListDetailPaneScaffoldNavigator<EmailId>()
22 
23    ListDetailPaneScaffold(
24        directive = navigator.scaffoldDirective,
25        value = navigator.scaffoldValue,
26        listPane = {
27            EmailList(onEmailClick = { id ->
28                scope.launch {
29                    navigator.navigateTo(ListDetailPaneScaffoldRole.Detail, id)
30                }
31            })
32        },
33        detailPane = {
34            navigator.currentDestination?.contentKey?.let { id ->
35                EmailDetail(emailId = id)
36            }
37        }
38    )
39}

Hangi deseni seçeceğine karar verirken şu soruyu sor: ikincil panel içeriği, birincil içerik olmadan tek başına anlamlı mı? Cevap "evet" ise list-detail, "hayır, yalnızca bağlamla anlamlı" ise supporting pane doğru seçim.

Kamera ve medya için orientation tuzakları

Resmi dokümantasyon uyarıyor: kamera uygulamalarının önizlemesi (viewfinder) tablet, dizüstü ve katlanabilir ekranlarda hizasız veya bozulmuş görünebiliyor. Kök neden, uygulamaların kamera özellikleri (en-boy oranı, sensör yönü) ile cihaz özellikleri (cihaz yönü, doğal yön) arasında sabit bir ilişki varsaydığı için ortaya çıkıyor — Android 17'de bu varsayım artık geçerli değil, çünkü cihaz yönü ile pencere yönü ayrışabiliyor.

Tipik kırılma noktası şu: kamera önizleme SurfaceView'ini oluştururken sensör yönünü cihazın fiziksel yönünden okuyup sabit bir dönüştürme matrisi uyguluyorsan, kullanıcı uygulamanı masaüstü pencereleme modunda döndürülmüş bir pencerede açtığında bu matris artık gerçek pencere yönüyle uyuşmaz. Güvenli yaklaşım, dönüştürme matrisini pencere yapılandırması her değiştiğinde (onConfigurationChanged veya Compose'da LocalConfiguration okuması ile) yeniden hesaplamak, cihazın fiziksel yönünü tek kaynak olarak varsaymamaktır.

Katlanabilir ve masaüstü modunda test matrisi

Yukarıdaki cihaz kategorileri listesini test akışına dönüştürürken üç geçiş anına özellikle odaklan: katlama/açma, çoklu pencere girişi/çıkışı ve harici ekran bağlama/çıkarma. Bu üç geçiş, aynı Activity örneğinin sw değerinin çalışma zamanında değişmesine yol açıyor — sabit yön varsayan kod burada patlıyor.

• Katlanabilir flip telefon: kapalıyken küçük landscape ekran, açıkken portrait — iki farklı windowSizeClass arasında state kaybı olmadan geçiş test edilmeli.
• Landscape katlanabilir (Pixel Fold tipi): kapalıyken portrait, açıkken landscape — yön varsayımı tersine dönüyor.
• Masaüstü pencereleme: bazı cihazlar harici ekrana bağlandığında masaüstü pencereleme oturumu başlatabiliyor; uygulaman serbestçe yeniden boyutlandırılabilir bir pencerede çalışmaya hazır olmalı.

Emülatör tarafında hızlı bir manuel kontrol için, çalışan bir emülatörün pencere boyutunu doğrudan komut satırından değiştirip uygulamanın davranışını gözlemleyebilirsin:

1# Emülatörde ekran yoğunluğunu ve çözünürlüğü büyük ekran (tablet sınıfı) değerlerine getir
2adb shell wm size 1600x2560
3adb shell wm density 320
4 
5# Uygulamayı yeniden başlatıp davranışı gözlemle
6adb shell am force-stop com.example.app
7adb shell monkey -p com.example.app -c android.intent.category.LAUNCHER 1
8 
9# Test sonrası orijinal boyuta dönmeyi unutma
10adb shell wm size reset
11adb shell wm density reset

Bu komutlar gerçek bir tablet veya katlanabilir cihazın yerini tutmaz, ancak hızlı bir sağlık kontrolü olarak faydalıdır — özellikle layout'unun geniş genişlikte hiç crash olmadan açıldığını doğrulamak için göç sürecinin ilk aşamasında kullanışlıdır. Gerçek regresyon avı için yine de Device Streaming veya resizable emülatör üzerinden, kullanıcı akışlarının tamamını manuel gezerek test etmen gerekiyor; komut satırı boyut değişimi yalnızca ilk elemeyi hızlandırır.

Aşamalı göç planı

Android 17 stable, 16 Haziran 2026'da Pixel cihazlarına dağıtıldı. Yani bu makalenin ilk yayın tarihi olan 29 Haziran 2026'da kısıtlama zaten yürürlükteydi. Önerilen göç sırası:

1. Envanter çıkar: resizeableActivity, sabit screenOrientation, minAspectRatio/maxAspectRatio kullanan tüm Activity'leri listele.
2. Hedef SDK'yı yükseltmeden test et: Device Streaming veya resizable emülatörle mevcut davranışı gözlemle, isLetterboxed() yardımcısıyla otomatik test ekle.
3. Adaptive layout'a geç: WindowSizeClass dallanması veya canonical layout (list-detail/supporting-pane) ile sabit yön varsayımını kaldır.
4. Kamera/medya kodunu gözden geçir: cihaz yönü ile pencere yönü arasındaki sabit ilişki varsayımını temizle.
5. Hedef SDK'yı 37'ye yükselt ve tüm test matrisini (tablet, katlanabilir, masaüstü, harici ekran) tekrar koş.

SSS

Android 17'de screenOrientation=portrait neden çalışmıyor?

API 37'yi hedefleyen ve en küçük genişliği 600dp'den büyük bir ekranda çalışan uygulamalarda android:screenOrientation (portrait dahil tüm sabit değerler) sistem tarafından yok sayılır. Bu, Android 16'daki geçici geliştirici opt-out'unun Android 17'de tamamen kaldırılmasının doğrudan sonucudur.

resizeableActivity=false artık geçerli mi?

Hayır. API 37 hedefleyen uygulamalarda büyük ekranlarda android:resizeableActivity="false" hiçbir etki üretmiyor; sistem uygulamayı yine de yeniden boyutlandırılabilir kabul ediyor.

Uygulamamı büyük ekrana nasıl uyarlarım?

Sabit yön ve aspect-ratio varsayımlarını kaldırıp WindowSizeClass tabanlı dallanma veya Material3'ün hazır canonical layout'ları (list-detail, supporting-pane) ile pencere boyutuna duyarlı bir arayüz kur. Kamera ve medya kodunda cihaz yönü ile pencere yönü arasındaki sabit ilişki varsayımını da gözden geçir.

Hangi uygulamalar büyük ekran zorunluluğundan muaf?

Manifest'te android:appCategory="game" ile işaretli oyunlar muaf tutuluyor. Kullanıcı, cihazın en-boy oranı ayarlarından uygulamanın varsayılan davranışını açıkça seçerse de kısıtlamalar uygulanmıyor. Ayrıca en küçük genişliği 600dp veya altında olan cihazlar eşiğin dışında kaldığı için kısıtlama zaten onları etkilemiyor.

Değişiklik tüm Android 17 cihazlarını mı etkiliyor?

Hayır, yalnızca hedef SDK'sı 37 veya üzeri olan uygulamaları etkiliyor. Android 17 çalıştıran bir cihazda, hedef SDK'sı düşük bir uygulama eski davranışını (sabit yön dahil) korumaya devam eder.

Test için gerçek cihaza ihtiyacım var mı?

Zorunlu değil — Firebase destekli Android Device Streaming ile uzaktan gerçek cihaza erişebilir veya Android Studio'nun yeniden boyutlandırılabilir emülatörüyle lokal test yapabilirsin; ikisi de resmi olarak önerilen yollar.

Sonuç

Android 17'nin büyük ekran zorunluluğu, aslında yeni bir kısıtlama değil, Android 16'dan beri süregelen geçici bir kaçış kapısının kapanması. Hedef SDK'nı 37'ye yükseltmeden önce sabit yön ve resizeableActivity kullanımını envanterle, gerçek cihaz veya emülatörde test et, ardından WindowSizeClass ya da canonical layout'larla adaptive bir arayüze geç. Konuyu daha geniş bağlamda görmek istersen, aynı sürümün diğer davranış değişikliklerine baktığım Android 17 (API 37): Uygulamayı Kıracak 6 Değişiklik yazısına göz atabilirsin. Compose tarafında performans ile adaptive layout'u bir arada düşünmek için Jetpack Compose 1.7 Performance: Strong Skipping + Stability faydalı olacaktır. Tasarım dili tarafında Material 3 Expressive: Android 16 Design System yazısı, adaptive layout'unu hangi görsel diline oturtacağını netleştirir. Edge-to-edge ve foreground service değişikliklerini de kapsayan Android 15 Developer Rehberi: Privacy Sandbox, Edge-to-Edge, Foreground Services yazısı, hedef SDK yükseltme sürecinde karşına çıkacak diğer zorunlulukları özetliyor. Google Play tarafındaki hedef SDK son tarihlerini kaçırdıysan Google Play API 36 Son Tarihi Geçti: Şimdi Ne Yapmalı? yazısı yol haritası sunuyor.

Kaynaklar

• Android 17 değişiklikler: FF restrictions ignored — sw>600dp eşiği, yok sayılan manifest öznitelikleri ve üç istisnanın birincil kaynağı.
• Android Developers Blog: Android 17 duyurusu — 16 Haziran 2026 stable yayın duyurusu ve adaptive-first geliştirme çağrısı.
• Android 17 release notes — sürümün resmi davranış değişiklikleri listesi.
• Large screen compatibility mode rehberi — test cihaz kategorileri, Device Streaming ve resizable emülatör önerisi.
• Canonical layouts (Compose adaptive) — list-detail ve supporting-pane desenlerinin resmi tanımı.
• WindowSizeClass kullanım rehberi — genişlik/yükseklik sınıfları ve currentWindowAdaptiveInfo() API'si.
• WindowSizeClass API referansı — WIDTH_DP_* sabitleri (600/840/1200/1600) ve isWidthAtLeastBreakpoint imzası.