Android Bellek Limitleri: Play Store 2027'de Cezalandıracak

Google Play, Ağustos 2026'da uygulamalar için yeni bir bellek kalite gerekliliği duyurdu ve Android bellek limiti Play Store 2027 ceza takvimini netleştirdi: Şubat 2027'den itibaren cihaz RAM sınıfına göre belirlenen eşikleri aşan uygulamalar Play Store'da azaltılmış görünürlük ve yayınlama kısıtlamasıyla karşılaşabilir. Bu yazıda hangi eşiklerin geçerli olduğunu, bunların Android 17'nin cihaz-seviyesi MemoryLimiter'ından nasıl farklı olduğunu ve Şubat 2027'ye kadar uygulamanı nasıl hazırlayacağını adım adım göreceksin.

💡 Pro Tip: Bellek metrikleri Ağustos 2026 duyurusundan beri erişilebilir: Android vitals genel bakışındaki Memory başlığı altında ve Google Play Developer Reporting API üzerinden. Ekim 2026'dan Şubat 2027'ye kadarki dört ay, art arda dört tam 28 günlük P90 penceresi demek; bu pencereleri kullanmadan Şubat'ı beklemek riskli.

İçindekiler

• Politika özeti ve Şubat 2027 takvimi
• Cihaz sınıfına göre RAM eşikleri
• Android 17 MemoryLimiter ile ilişkisi (OS vs mağaza)
• Gerçek bellek kullanımını ölçmek
• En sık bellek şişmesi kaynakları
• Ölçüm-düzelt-doğrula döngüsü
• CI'da bellek regresyon kapısı kurmak
• Yol haritası: Ekim 2026'dan Şubat 2027'ye
• SSS
• Play Store bellek limiti nedir, ne zaman yürürlüğe giriyor?
• Uygulamamın RAM kullanımını nasıl ölçerim?
• Bellek eşiğini aşarsam Play Store'da ne olur?
• Android 17 MemoryLimiter ile Play politikası aynı şey mi?
• DEX kod optimizasyonu şartını nasıl karşılarım?
• Oyunlar için eşikler farklı mı?
• Sonuç
• Kaynaklar

Politika özeti ve Şubat 2027 takvimi

Google Play, 26 Ağustos 2026 tarihli resmi duyurusunda "bellek ayak izini azaltma" ve "güvenli cihaz göçü" olmak üzere iki yeni kalite gerekliliği tanımladı. Duyuruda şu cümle geçiyor: "Google Play is introducing two new quality requirements: one focused on reducing app memory footprint, and another on providing a secure, seamless device migration experience." Bu makale yalnızca bellek tarafını ele alıyor; cihaz göçü ayrı bir konu.

Zorunluluk tek bir tarihe bağlandı: "Starting in February 2027, apps and games must meet their respective bad behavior thresholds for Memory usage (Anonymous RSS + Swap), Bitmap memory usage and DEX code optimization." Yani üç ayrı metrik aynı anda devreye giriyor — Anonymous RSS + Swap (dinamik bellek kullanımı), bitmap belleği ve DEX kod optimizasyonu.

Eşikleri aşan uygulamalar için sonuç açık şekilde tanımlanmış: "Apps and games that do not meet these thresholds may see reduced app visibility and publishing capabilities on Google Play." Bu bir anlık askıya alma değil, kademeli bir görünürlük ve yayınlama kısıtlaması riski. Ekim 2026'dan Şubat 2027'ye kadar yaklaşık dört ay var — bu süre pratikte tek bir minör sürüm döngüsüne sığıyor, bu yüzden şimdiden ölçmeye başlamak gerekiyor.

Kapsam metrik başına değişiyor: bellek eşikleri yalnızca mobil ve tablet form faktöründe geçerli ("This requirement only applies to mobile and tablet form factors."), DEX şartı ise tüm form faktörlerini kapsıyor ("This requirement applies across all form factors."). Wear OS veya Android TV uygulaması bellek eşiklerinin dışında kalır ama DEX'ten muaf değildir.

Bu üç metriğin (Anonymous RSS + Swap, bitmap belleği, DEX optimizasyonu) aynı zorunluluk paketinin parçası olması, onları tek tek değil bir bütün olarak ele almanı gerektiriyor. Örneğin yalnızca DEX optimizasyonunu (R8) açıp bitmap yönetimini ihmal eden bir ekip, üç metrikten birini sağlasa bile diğer ikisinde eşiğin üzerinde kalabilir — duyuru üç eşiği ayrı ayrı sayıyor. Bu yüzden bir sonraki bölümde eşikleri, ardından ölçüm ve düzeltme adımlarını ayrı ayrı ele alacağız.

Cihaz sınıfına göre RAM eşikleri

Google, cihazın toplam RAM'ine göre kademeli eşikler belirledi ve bunları son 28 günlük kullanıcı verisinin 90. persentili (P90) üzerinden değerlendiriyor: "Play uses the last 28 days of data to evaluate your app's quality… the 90th percentile, which is used to evaluate your app's performance against the bad behavior thresholds." Yani tek bir kötü oturum seni etkilemiyor; kullanıcılarının onda dokuzunun deneyimi eşiğin altında kalmalı.

Uygulamalar için resmi eşik tablosu (P90 değerleri) şöyle:

Not: Kaynaktaki resmi tabloda beşinci bir sütun daha var (Cached); uygulamalar için bu sütunda tüm satırlar eşiksiz ("-"), bu yüzden yukarıdaki tabloya alınmadı.

Tabloda eşiksiz ("-") olan yalnız iki uç var: toplam belleği 3200 MB'ın altındaki ve 18432 MB'ın üzerindeki cihazlar. Yani "16 GB" etiketli telefonların büyük kısmı (14336-18432 MB bandı) muaf değil, 4.25 GB foreground eşiğine tabi. 6GB ile 8GB foreground'da aynı değeri paylaşır ama arka plan eşikleri ayrışır.

Oyunlar için eşikler uygulamalardan daha gevşek tutulmuş: 8GB sınıfında oyunların foreground eşiği 3.5GB, uygulamalarınki ise 2.25GB.

Bu fark, oyun motorlarının doğal olarak daha yoğun bellek kullandığının Google tarafından kabul edildiğini gösteriyor — ama bu bir muafiyet değil, sadece daha yüksek bir tavan.

Pratikte bu tablo sana iki şey söylüyor. Birincisi, hedef kitlenin RAM dağılımını bilmeden optimizasyon önceliklendirmesi yapamazsın — Android vitals içindeki bellek metriklerini persentil ve RAM bucket kırılımında inceleyebilirsin, o kırılım bu tablo ile birlikte okunmalı. İkincisi, eşiğin "sabit bir sayı" değil "cihaz sınıfına göre değişen bir tavan" olması, tek bir global optimizasyon hedefi yerine cihaz sınıfı bazlı test senaryoları kurmanı gerektiriyor — örneğin CI'da yalnızca üst segment bir emülatörde test etmek, 4GB sınıfındaki daha sıkı eşiği kaçırmana yol açabilir.

Android 17 MemoryLimiter ile ilişkisi (OS vs mağaza)

Burada iki farklı mekanizmayı birbirine karıştırmamak kritik. Android 17'de Google, Pixel cihazlarla başlayan bir "per-app memory limit" (uygulama başına bellek limiti) mekanizması tanıttı: "In Android 17, we introduced per-app memory limits, starting with Pixel devices… If your app exceeds these limits, it will be slowed down and may be terminated." Bu, işletim sistemi seviyesinde çalışan, gerçek zamanlı bir mekanizma.

MemoryLimiter iki aşamalı çalışıyor. Önce sıkıştırma: "zRAM Swapping: If your app reaches its allocated limit, the system forces your app's pages into zRAM." Ardından sonlandırma: "Process Termination: If your app continues to increase its memory usage beyond the zRAM threshold, it will be terminated by the system." Yani limiti aşan bir uygulama önce yavaşlar (zRAM sıkıştırma/açma CPU maliyeti getirir), devam ederse sistem tarafından kapatılır.

Play Store'un Şubat 2027 eşikleri ise tamamen farklı bir katman: mağaza politikası seviyesinde, son 28 günün toplu ve anonimleştirilmiş verisine dayanan bir denetim. Biri (MemoryLimiter) cihaz üzerinde, senin uygulamanla ilgili anlık bir davranışı yönetiyor; diğeri (Play politikası) mağazadaki uzun vadeli görünürlüğünü etkiliyor. Bir uygulama MemoryLimiter tarafından hiç sonlandırılmasa bile, P90 eşiğini aşıyorsa Play Store cezasıyla karşılaşabilir — ve tersi de mümkün. Android 17 (API 37) davranış değişikliklerini daha geniş bağlamda ele aldığımız yazıda bu iki katmanın diğer etkilerini de bulabilirsin.

Bu ayrımı pratik terimlere çevirmek gerekirse: MemoryLimiter senin kontrolünde olmayan, işletim sisteminin kendi kararıdır — sen sadece uygulamanın limite ne kadar yaklaştığını gözlemleyebilir, doğrudan devre dışı bırakamazsın. Play Store politikası ise senin doğrudan etki edebileceğin bir metrik hedefidir; kod optimizasyonu, kaynak yönetimi ve bellek hijyeni ile P90 değerini eşiğin altında tutmak tamamen elinde. Bu yüzden yol haritanı kurarken önceliği ikinciye vermek daha mantıklı — MemoryLimiter'ı iyi bir erken uyarı sinyali, Play politikasını ise asıl hedef olarak görebilirsin.

Gerçek bellek kullanımını ölçmek

Ölçüme cihaz üzerinde başlamalısın. adb shell dumpsys meminfo <paket-adı> komutu, uygulamanın PSS (proportional set size) dağılımını canlı olarak verir:

1adb shell dumpsys meminfo com.example.app
2 
3** MEMINFO in pid 8421 [com.example.app] **
4                   Pss  Private  Private  SwapPss     Heap     Heap     Heap
5                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
6                ------   ------   ------   ------   ------   ------   ------
7  Native Heap    41208    41156        0    18344    53248    46870     6377
8  Dalvik Heap    12480    12384        0     3120    18432    14210     4222
9        Stack     1024      988        0        0
10       Ashmem      312       48        0        0
11     Gfx dev     9840     9840        0        0
12      Unknown     6112     4980      132     1408
13        TOTAL    70976    69396      132    22872

Bu çıktıdaki SwapPss sütunu, Android 17'nin zRAM sıkıştırmasıyla doğrudan ilgili — sayı büyüdükçe uygulaman MemoryLimiter'ın ilk aşamasına (sıkıştırma) yaklaşıyor demektir.

İkinci araç, uygulamanın neden sonlandırıldığını anlamak için ApplicationExitInfo. Google'ın duyurusuna göre MemoryLimiter tarafından kapatılan bir süreçte çıkış sebebi şöyle raporlanıyor: "the exit reason is reported as REASON_OTHER and the description string will contain 'MemoryLimiter:AnonSwap'."

1val exitInfos = activityManager.getHistoricalProcessExitReasons(
2    packageName, 0, 10
3)
4exitInfos.forEach { info ->
5    if (info.reason == ApplicationExitInfo.REASON_OTHER &&
6        info.description?.contains("MemoryLimiter:AnonSwap") == true) {
7        // MemoryLimiter tarafından zRAM eşiği aşıldığı için sonlandırıldı
8        analytics.logMemoryLimiterKill(info.description, info.pss)
9    }
10}

Üçüncü katman ProfilingManager. API'nin kendisi Android 15 (API 35) ile geldi; TRIGGER_TYPE_ANOMALY tetikleyicisi ise Android 17 (API 37) ile eklendi ("Android 17 adds several new system triggers to ProfilingManager"). Google tetikleyiciyi şöyle tanımlıyor: "you can also leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached." Bu, kullanıcı cihazında bellek limiti aşıldığı anda otomatik heap dump alman anlamına geliyor — yani hatayı laboratuvarda tekrar üretmeye çalışmak yerine gerçek kullanıcı verisiyle çalışabiliyorsun.

Play Console tarafında da destek büyüyor: Google, Crashes ve ANR'lar için "we've added a new filter for Crashes and ANRs so you can easily identify when the OS terminated your app due to severe memory pressure" diyor — yani OS'in şiddetli bellek baskısı nedeniyle uygulamanı kapattığı vakaları artık ayrı bir filtreyle görebiliyorsun. Ayrıca Firebase Crashlytics 20.1.0 sürümü, "additional debug data to help you catch, prioritize, and fix Out-Of-Memory exceptions and memory limiter kills" sunuyor.

En sık bellek şişmesi kaynakları

Google'ın resmi rehberlerinde bellek şişmesine karşı önerilen ana başlıklar şunlar — bunlar "Google'ın söylediği %90 şudur" gibi bir istatistik değil, doğrudan önerilen optimizasyon alanları:

• Kod optimizasyonu (R8/DEX): Kullanılmayan sınıf ve metotların küçültülmemiş kalması, gereksiz bellek ayak izine yol açıyor. Google'ın minimum %25 kapsama şartı (aşağıda) bunu doğrudan hedefliyor.
• Görüntü/bitmap yönetimi: Ekran boyutuna göre ölçeklenmemiş büyük bitmap'lerin belleğe yüklenmesi, dinamik bellek eşiklerinin ayrı bir bileşeni olan "bitmap memory usage" metriğini doğrudan etkiliyor. Eşiklerin sıfırdan büyük tutulmasının nedeni de burada: uygulaman tam onTrimMemory'ye yanıt verip bitmap belleğini bırakırken örneklenebiliyor.
• Sızıntılar (leaks): Android Studio'nun bellek profilleme araçlarıyla tespit edilen, referansı bırakılmayan nesnelerin (ör. unutulmuş listener veya statik referanslar) canlı heap'te birikmesi.
• onTrimMemory callback'inin kullanılmaması: Sistem bellek baskısı sinyali gönderdiğinde önbellek ve geçici kaynakları serbest bırakmayan uygulamalar, arka planda daha uzun süre yüksek bellek tutmaya devam ediyor.

Not: Jetpack Compose'daki recomposition davranışının bu spesifik 2027 gerekliliğiyle resmi olarak ilişkilendirildiği bir Google kaynağı bulunmadı; Compose performansı ayrı bir konu olarak Jetpack Compose 1.7 Strong Skipping yazımızda ele alınıyor — burada genel bellek yönetimi ile karıştırmamak gerekiyor.

Bu dört başlığı önceliklendirirken şu sırayı izleyebilirsin: önce R8/DEX çünkü tek bir yapılandırma değişikliğiyle (gradle dosyasında iki satır) ölçülebilir bir kazanım sağlıyor; ardından bitmap yönetimi çünkü genelde en görünür ekranlarda (galeri, feed, profil) yoğunlaşıyor ve kullanıcı deneyimini de doğrudan iyileştiriyor; sızıntı avı ve onTrimMemory ise daha uzun soluklu, sürekli bir disiplin gerektiren kalemler. Kısa vadede eşiğe yaklaşmak istiyorsan ilk ikisi, uzun vadede eşiğin altında kalmak istiyorsan dördü de gerekiyor.

Ölçüm-düzelt-doğrula döngüsü

Eşiklere hazırlanmanın en verimli yolu tek seferlik bir "optimizasyon sprinti" değil, tekrarlanabilir bir döngü kurmak:

1. Ölç: dumpsys meminfo + Android Studio Memory Profiler ile geliştirme ortamında; Android vitals genel bakışındaki Memory başlığı (veya Play Developer Reporting API) ile üretimde.
2. Önceliklendir: ApplicationExitInfo ile MemoryLimiter kill'lerini ve OOM crash'lerini say, en çok etkilenen ekran/akışı bul.
3. Düzelt: R8 kapsamını artır, büyük bitmap'leri ölçekle, onTrimMemory'yi uygula, sızıntı zincirini kır.
4. Doğrula: Aynı akışı tekrar ölç, P90 değerinin RAM sınıfına göre eşiğin altına indiğini teyit et.

Bu döngüyü manuel yürütmek yerine derleme sürecine gömebilirsin — bir sonraki bölüm bunu ele alıyor.

Döngünün en çok atlanan adımı dördüncü madde: doğrulama. Bir düzeltmeyi production'a aldıktan sonra "muhtemelen iyileşmiştir" varsayımıyla geçmek yerine, aynı RAM sınıfında aynı akışı tekrar ölçüp gerçek P90 değerinin değiştiğini görmek gerekiyor. 28 günlük pencere bu doğrulamayı yavaşlatıyor — bir düzeltmenin etkisini görmek için en az bir tam pencere beklemen gerekebilir, bu yüzden döngüyü ne kadar erken başlatırsan Şubat 2027'ye o kadar rahat girersin.

CI'da bellek regresyon kapısı kurmak

DEX optimizasyonu tarafında Google net bir eşik veriyor: "apps published on Google Play must be optimized with a minimum of 25% coverage across optimization, shrinking, and obfuscation." Şartın iki niteliği var: yalnız "non-negligible DEX sizes" olan projelerde uygulanıyor (uygulamalarda 10 MB, oyunlarda 50 MB üzeri DEX) ve araç seçimi serbest — "You can use any tool, such as R8 or another app shrinker." R8 en yaygın yol, tek yol değil:

1// app/build.gradle.kts
2android {
3    buildTypes {
4        release {
5            isMinifyEnabled = true
6            isShrinkResources = true
7            proguardFiles(
8                getDefaultProguardFile("proguard-android-optimize.txt"),
9                "proguard-rules.pro"
10            )
11        }
12    }
13}

CI'da bunu bir regresyon kapısına çevirmek için release APK/AAB'yi her PR'da üretip DEX kapsamını ve boyutunu bir önceki başarılı build ile kıyaslayan basit bir adım eklemek yeterli:

1#!/usr/bin/env bash
2# ci/check-dex-coverage.sh — release build sonrası çalışır
3set -euo pipefail
4 
5APK=app/build/outputs/apk/release/app-release.apk
6BASELINE=ci/dex-size-baseline.txt   # haftalık cron günceller, PR build'i DEĞİL
7 
8./gradlew assembleRelease
9 
10# Yalnızca classes*.dex girdileri (KB) — APK'nın tamamı değil
11DEX_SIZE_KB=$(unzip -l "$APK" 'classes*.dex' | awk '/classes.*\.dex$/ { s += $1 } END { print int(s / 1024) }')
12 
13# Referans yoksa set -e altında düşme, mevcut ölçümü referans al
14BASELINE_KB=$(cat "$BASELINE" 2>/dev/null || echo "$DEX_SIZE_KB")
15LIMIT_KB=$((BASELINE_KB * 110 / 100))
16 
17if [ "$DEX_SIZE_KB" -gt "$LIMIT_KB" ]; then
18  echo "DEX boyutu haftalık referansın %10 üzerine çıktı: ${DEX_SIZE_KB}KB > ${LIMIT_KB}KB"
19  exit 1
20fi
21 
22echo "DEX boyutu limitin altında: ${DEX_SIZE_KB}KB <= ${LIMIT_KB}KB"

Bu script minifyEnabled/shrinkResources'ın gerçekten çalıştığını ve zaman içinde DEX şişmesini doğrudan DEX girdilerini ölçerek yakalar; Google'ın %25 kapsama şartını doğrudan ölçmek için Play Console'daki App Bundle Explorer raporlarını kullanman gerekiyor — CI script'i yalnızca erken uyarı katmanı.

Kapının kritik ayrıntısı, script'in referans dosyasına hiç yazmaması: her yeşil build'de üzerine yazsaydın yavaş ama sürekli bir büyümeyi (her PR'da %2-3 gibi artışlar) gözden kaçırırdın. Referansı haftalık cron ile kaydedip PR kıyaslamasını o değere göre yapmak, kademeli DEX şişmesini de yakalar. Aynı mantığı bitmap toplam boyutu için de uygulayabilirsin — du -sh app/src/main/res/drawable* çıktısını haftalık baseline'a karşı izlemek, DEX kapısına ek maliyeti olmayan bir ikinci sinyal verir.

Yol haritası: Ekim 2026'dan Şubat 2027'ye

Elindeki pencere yaklaşık dört ay. Önerilen sıralama:

• Ekim 2026: ApplicationExitInfo taramasını üretime ekle, mevcut MemoryLimiter kill oranını öğren (baseline olmadan iyileşmeyi ölçemezsin).
• Kasım 2026: Android vitals > Memory bölümünde RAM sınıfı bazında P90 verini incele, hangi tier'da eşiğe yakın olduğunu belirle.
• Aralık 2026: R8 kapsamını doğrula (%25 şartı), büyük bitmap kaynaklarını ölçekle, onTrimMemory eksikliklerini kapat.
• Ocak 2027: Düzeltmeleri production'a al, en az 28 günlük yeni P90 penceresinin oluşmasını bekle (enforcement 28 günlük pencereye dayandığı için son haftaya bırakmak riskli).
• Şubat 2027: Eşikler yürürlüğe girecek; bu tarihe kadar en az bir tam 28 günlük doğrulama döngüsü tamamlamış olman hedef.

Bu takvimde en riskli adım Aralık-Ocak arasındaki geçiş: düzeltmeleri yıl sonu tatil dönemine denk getirmek, hem trafik yoğunluğu hem ekip müsaitliği açısından zorlayıcı olabilir. Mümkünse büyük değişiklikleri (R8 yapılandırması, bitmap ölçekleme) Kasım ayı içinde tamamlayıp Aralık-Ocak'ı yalnızca doğrulama ve ince ayar için ayırmak, Şubat başına stressiz girmeni sağlar. Tek seferlik büyük bir refactor yerine küçük, ölçülebilir adımlarla ilerlemek — her adımdan sonra P90'ı tekrar kontrol ederek — regresyon riskini de düşürür.

SSS

Play Store bellek limiti nedir, ne zaman yürürlüğe giriyor?

Google Play, 26 Ağustos 2026'da duyurduğu yeni kalite gerekliliği kapsamında uygulamalar için cihaz RAM kategorisine göre bellek kullanım eşikleri (Anonymous RSS + Swap, bitmap belleği, DEX kod optimizasyonu) belirledi; örneğin 8GB RAM'li cihazlarda foreground kullanımı P90'da 2.25GB'ı aşmamalı. Kurallar Şubat 2027'den itibaren zorunlu hale gelecek; eşiği aşan uygulamalar azaltılmış görünürlük ve yayınlama kısıtlaması riskiyle karşılaşacak.

Uygulamamın RAM kullanımını nasıl ölçerim?

Geliştirme aşamasında adb shell dumpsys meminfo ve Android Studio Memory Profiler kullanabilirsin. Üretimde bu metrikler Android vitals genel bakışındaki Memory başlığı altında ve Google Play Developer Reporting API üzerinden erişilebilir durumda; ek olarak ApplicationExitInfo.getDescription() ile "MemoryLimiter:AnonSwap" nedenli sonlandırmaları tespit edebilirsin.

Bellek eşiğini aşarsam Play Store'da ne olur?

Google'a göre eşiği aşan uygulamalar "azaltılmış uygulama görünürlüğü ve yayınlama kapasitesi" ile karşılaşabilir — bu bir anlık kapatma değil, kademeli bir görünürlük cezası. Ayrı bir katmanda, Android 17'nin MemoryLimiter'ı sınırı aşan uygulamayı önce zRAM'e sıkıştırır, devam ederse cihazda sonlandırır.

Android 17 MemoryLimiter ile Play politikası aynı şey mi?

Hayır. MemoryLimiter işletim sistemi seviyesinde, cihaz üzerinde gerçek zamanlı çalışan bir mekanizma — Android 17 ile Pixel'de başladı, kaynağa göre önümüzdeki yıl içinde diğer üreticilerin 4GB-16GB+ cihazlarına yayılacak. Play Store'un Şubat 2027 eşikleri ise mağaza politikası seviyesinde, son 28 günün toplu verisine (P90) dayanan ayrı bir denetim. Biri anlık cihaz davranışını, diğeri mağazadaki uzun vadeli görünürlüğü yönetir.

DEX kod optimizasyonu şartını nasıl karşılarım?

Bir küçültücüyü release build'lerinde açık tutarak optimizasyon, küçültme ve obfuscation genelinde en az %25 kapsamaya ulaşman gerekiyor. R8 (isMinifyEnabled = true, isShrinkResources = true) zorunlu değil; Google "You can use any tool, such as R8 or another app shrinker" diyor. Şart yalnız DEX'i ihmal edilebilir olmayan projelerde uygulanıyor: uygulamalarda 10 MB, oyunlarda 50 MB üzeri.

Oyunlar için eşikler farklı mı?

Evet. 8GB RAM sınıfında uygulamalar için foreground eşiği 2.25GB iken oyunlar için 3.5GB — Google oyun motorlarının doğal olarak daha yoğun bellek kullandığını kabul ederek daha yüksek bir tavan tanımlamış. Ayrım Play Console'daki Store settings kategorisine göre yapılıyor; kategoriyi farklı eşiklere girmek için değiştirmek Metadata politikası ihlali sayılıyor.

Sonuç

Şubat 2027 eşikleri, "bir gün ele alırım" listesine atılamayacak kadar somut bir takvime bağlı: dört ay içinde P90 bellek kullanımını cihaz sınıfına göre belirlenen tavanın altına indirmen gerekiyor. En hızlı kazanım R8/DEX optimizasyonunu doğrulamak; en kalıcı kazanım ise ApplicationExitInfo ve Play Console Memory vitals ile sürekli bir ölçüm döngüsü kurmak. Android 17'nin MemoryLimiter'ını mağaza politikasıyla karıştırmadan, ikisini ayrı ayrı takip et.

Konuyu genişletmek istersen Android 17 (API 37) davranış değişiklikleri yazımızda MemoryLimiter'ın diğer etkilerini, Google Play API 36 son tarihi yazımızda benzer bir zorunlu takvimin nasıl yönetildiğini, Jetpack Compose 1.7 performans yazımızda genel bellek/performans optimizasyonunu, Google Play Billing v7 yazımızda Play Console'daki diğer kalite gerekliliklerini, iOS Memory Management yazımızda ise cross-platform bellek yönetimi karşılaştırmasını bulabilirsin.

Kaynaklar

• Elevating app quality: memory and device migration — Android Developers Blog — Şubat 2027 eşikleri, DEX %25 kuralı ve Play Console araçlarının resmi duyurusu.
• Play Console Help — Core quality vitals thresholds — RAM sınıfına göre foreground/background eşik tablosu ve P90 metodolojisi.
• Preparing your app for broader memory limits — Android Developers Blog — Android 17 MemoryLimiter'ın zRAM sıkıştırma ve sonlandırma davranışı.
• Prioritizing memory efficiency: steps for Android 17 — Android Developers Blog — ProfilingManager TRIGGER_TYPE_ANOMALY ve GC/jank etkileri.
• Google to impose new Android app memory limits — TheNextWeb — duyurunun bağımsız haber teyidi ve ekosistem bağlamı.