Android 17 (API seviyesi 37) canlıya çıktı ve bu sürümdeki altı davranış değişikliğinin dördü hiçbir hata fırlatmadan uygulamanı production'da bozabilir: bellek sınırı aşıldığında process'in neden öldüğünü göremezsin, arka plan ses isteğin AUDIOFOCUS_REQUEST_FAILED ile geri döner, SMS tabanlı OTP akışın üç saat gecikir. Bu yazıda developer.android.com'un resmi "Android 17 is Here" duyurusuna ve behavior-changes referans sayfalarına dayanarak altı değişikliği tek tek, kod örnekleriyle inceliyoruz.
💡 Pro Tip: targetSdk'ı 37'ye yükseltmeden önce bu altı maddeyi bir checklist'e dönüştür ve her birini gerçek cihazda (emülatörde değil) test et — özellikle MemoryLimiter ve cross-profile loopback değişiklikleri donanım/profil bağımlı davranıyor.
İçindekiler
- Android 17 = API Seviyesi 37: Sürüm Netliği ve Takvim
- MemoryLimiter: Yeni Bellek Sınırı ve ApplicationExitInfo ile Teşhis
- Anomali tetikleyicisini kaydetmek
- Önceki oturumun ölüm nedenini okumak
- Arka Plan Ses İsteklerinin Sessizce Reddedilmesi
- Configuration Change'lerde Activity Restart'ın Kalkması
- Cross-Profile Loopback Trafiğinin Engellenmesi
- SMS OTP'de 3 Saatlik Gecikme ve SMS Retriever'a Geçiş
- SMS Retriever ile gecikmeyi aşmak
- NPU Erişimi İçin Yeni Zorunlu İzin: FEATURE_NEURAL_PROCESSING_UNIT
- targetSdk 37 Öncesi Test Matrisi
- Altı Değişikliğin Tek Bakışta Özeti
- Bu Yazının Kapsamı Dışında Kalan Diğer Önemli Değişiklikler
- Native kütüphane yüklemede salt-okunur zorunluluğu
- Yerel ağ erişimi artık runtime izni istiyor
- Certificate transparency varsayılan olarak açık geliyor
- SSS
- Android 17'de uygulamam neden arka planda ses çalmıyor?
- ApplicationExitInfo 'MemoryLimiter' ne demek?
- Android 17'de Activity neden yeniden başlatılmıyor?
- API 37'de SMS OTP okuma neden gecikiyor?
- targetSdk'ımı hemen 37'ye çekmezsem bu değişikliklerden etkilenir miyim?
- Sonuç
- Kaynaklar
Android 17 = API Seviyesi 37: Sürüm Netliği ve Takvim
Android 17'nin API seviyesi 37'dir (developer.android.com/about/versions/17). Google, sürümü resmi Android Developers Blog'da "Android 17 is Here" başlıklı yazıyla duyurdu; beta programı 13 Şubat 2026'da Beta 1 ile başladı, Platform Stability aşamasına 26 Mart 2026'da Beta 3 ile ulaşıldı ve 1 Haziran 2026'da Beta 4.1 yayınlandı. Kararlı sürüm 16 Haziran 2026'da yayınlandı ve desteklenen Pixel cihazların çoğuna sunuldu. Release notes sayfası bu yazının hazırlandığı tarihe en yakın olarak 2 Eylül 2026'da güncellenmiş durumda.
targetSdk'ı 37'ye çekmek, aşağıdaki altı değişikliğin hepsiyle aynı anda yüzleşmen anlamına gelir — bazıları (cross-profile loopback bloğu gibi) targetSdk'dan bağımsız olarak cihaz Android 17'ye güncellendiği anda devreye girer, bazıları ise yalnızca targetSdk 37 hedefleyen uygulamaları etkiler. Bu fark, test matrisini planlarken kritik.
Android 15 Developer Rehberi: Privacy Sandbox, Edge-to-Edge, Foreground Services yazımızda ele aldığımız Privacy Sandbox ve edge-to-edge zorunluluğu, bu yazının doğal selefi; iki sürüm arasındaki API seviyesi sıçramasını (35 → 37) takip etmek istersen oradan başlayabilirsin.
MemoryLimiter: Yeni Bellek Sınırı ve ApplicationExitInfo ile Teşhis
Android 17, cihazın toplam RAM'ine göre hesaplanan bir bellek sınırı getiriyor. Bu sınır aşıldığında sistem process'i sonlandırıyor ve bunu debug ederken ilk bakacağın yer ApplicationExitInfo API'si. Resmi referansa göre: uygulaman bu limit nedeniyle sonlandırılırsa çıkış nedeni REASON_OTHER olur ve ApplicationExitInfo.getDescription() açıklaması "MemoryLimiter:AnonSwap" string'ini başka bilgilerle birlikte içerir — bu yüzden eşitlik değil, contains kontrolü yapman gerekir.
Bunu tek başına loglamak yeterli değil — Android 17 ayrıca ProfilingManager üzerinden on-device anomaly detection sunuyor: ProfilingTrigger.TRIGGER_TYPE_ANOMALY tetikleyicisini kaydederek bellek anomalisi anındaki profil verisini toplatabilirsin.
Anomali tetikleyicisini kaydetmek
kotlin
1import android.os.ProfilingManager2import android.os.ProfilingTrigger3 4val profilingManager = applicationContext5 .getSystemService(ProfilingManager::class.java)6 7val triggers = ArrayList<ProfilingTrigger>().apply {8 add(ProfilingTrigger.Builder(9 ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build())10}11profilingManager.addProfilingTriggers(triggers)Önceki oturumun ölüm nedenini okumak
Uygulamanın önceki oturumda bu nedenle mi öldüğünü kontrol etmek için başlangıçta şunu çalıştır:
kotlin
1val am = getSystemService(ActivityManager::class.java)2val exitInfos = am.getHistoricalProcessExitReasons(3 packageName, 0, 104)5 6exitInfos.forEach { info ->7 if (info.reason == ApplicationExitInfo.REASON_OTHER &&8 info.description?.contains("MemoryLimiter:AnonSwap") == true9 ) {10 Log.w("MemoryWatch", "Bellek limiti nedeniyle sonlandırıldı")11 }12}Bu kontrolü Jetpack Compose 1.7 Performance: Strong Skipping + Stability yazımızda anlattığımız recomposition kaynaklı bellek şişmelerini teşhis ederken de kullanabilirsin — gereksiz obje alokasyonu bellek tavanına yaklaşmanı hızlandırabilir.
Arka Plan Ses İsteklerinin Sessizce Reddedilmesi
Android 17, arka plandaki uygulamaların ses çalma, audio focus isteği ve ses seviyesi değiştirme API'lerini kısıtlıyor; bu kısıtlamanın iki katmanı var. Temel kural targetSdk'dan bağımsız: resmi referansa göre bu etkileşimlere sahip tüm uygulamaların görünür bir Activity'si ya da SHORT_SERVICE tipinde olmayan bir foreground service'i olmak zorunda ve bu, "uygulamanın API seviyesi 37'yi hedefleyip hedeflemediğinden bağımsız". İkinci katman targetSdk'a bağlı: uygulama API 37 hedefliyor ve arka plandaysa, foreground service'inin ayrıca "while-in-use" (WIU) capability'si olmalı. Uygulama geçerli bir yaşam döngüsünde değilken ses çalma ve ses seviyesi değiştirme API'leri hiçbir istisna ya da hata mesajı vermeden sessizce başarısız oluyor; audio focus API'si ise AUDIOFOCUS_REQUEST_FAILED sonuç koduyla başarısız oluyor. WIU şartı yalnızca exact alarm izni verilmişse ve değiştirilen ses akışları USAGE_ALARM öznitelikliyse kalkıyor.
kotlin
1val audioManager = getSystemService(AudioManager::class.java)2val focusRequest = AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN)3 .setAudioAttributes(4 AudioAttributes.Builder()5 .setUsage(AudioAttributes.USAGE_MEDIA)6 .build()7 )8 .setOnAudioFocusChangeListener { /* ... */ }9 .build()10 11val result = audioManager.requestAudioFocus(focusRequest)12if (result == AudioManager.AUDIOFOCUS_REQUEST_FAILED) {13 // Android 17'de bu artık arka planda SESSİZCE gerçekleşebilir —14 // kullanıcıya bildirim göstermeden önce foreground/WIU durumunu kontrol et15}Pratik sonuç: müzik/podcast/arka plan indirme bildirimi çalan uygulamalarda foreground service tipini ve WIU capability deklarasyonunu targetSdk 37'ye geçmeden önce gözden geçir.
Configuration Change'lerde Activity Restart'ın Kalkması
Android 17'ye kadar birçok configuration change (klavye takılması, klavyenin gizlenmesi, navigasyon modu değişimi, dokunmatik ekran durumu, renk modu) Activity'yi baştan yaratıyordu. Android 17'den itibaren sistem, tam bir UI yeniden çizimi gerektirmeyen şu değişikliklerde artık Activity'yi varsayılan olarak restart etmiyor: CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN ve CONFIG_COLOR_MODE. Release notes sayfası bu listeye altıncı madde olarak CONFIG_UI_MODE'u da ekliyor, ama yalnızca UI modu UI_MODE_TYPE_DESK'e ya da UI_MODE_TYPE_DESK'ten başka bir tipe değiştiğinde. Bunun yerine çalışan Activity, onConfigurationChanged() callback'i üzerinden güncellemeyi alıyor.
Eğer uygulaman bu değişikliklerde kaynakları yeniden yüklemek için tam restart'a açıkça bağımlıysa, yeni android:recreateOnConfigChanges manifest attribute'u ile eski davranışa dönebilirsin:
xml
1<activity2 android:name=".MainActivity"3 android:recreateOnConfigChanges="keyboard|keyboardHidden|navigation|touchscreen|colorMode">4</activity>Dikkat: R.attr referansındaki değer tablosu bu attribute için mcc, mnc, touchscreen, keyboard, keyboardHidden, navigation ve colorMode dışında bir değer kabul etmiyor — uiMode listede yok, yani DESK moduna geçişte kalkan restart'ı bu yolla geri açamazsın.
Bu değişiklik özellikle harici klavye/mouse bağlanan katlanabilir ve tablet formundaki cihazlarda önemli — kullanıcı klavyeyi taktığında ekranın "flaş" edip yeniden çizilmesi artık varsayılan olarak yaşanmıyor.
Cross-Profile Loopback Trafiğinin Engellenmesi
Bu maddenin diğerlerinden kritik bir farkı var: targetSdk'dan bağımsız çalışıyor. Resmi kaynağa göre Android 17'den itibaren cross-profile loopback trafiği varsayılan olarak engelleniyor; aynı profil içindeki loopback trafiği etkilenmiyor. Bu değişiklik, cihaz Android 17'ye güncellendiği anda hangi API seviyesini hedeflediğine bakılmaksızın tüm uygulamalar için geçerli oluyor.
Work profile (iş profili) kullanan kurumsal cihazlarda local debug proxy'leri, localhost üzerinden IPC yapan SDK'lar veya profiller arası loopback varsayan test altyapıları bu değişiklikten doğrudan etkilenir. targetSdk 37'ye geçmesen bile, kullanıcının cihazı Android 17'ye güncellendiğinde bu davranışla karşılaşırsın — bu yüzden test matrisine mutlaka dahil et.
SMS OTP'de 3 Saatlik Gecikme ve SMS Retriever'a Geçiş
OTP hijacking'i azaltmak için Android 17, SMS tabanlı tek kullanımlık şifre korumasını genişletiyor: SMS mesajları alındıktan üç saat sonrasına kadar erişilebilir olmuyor. Resmi referans (behavior-changes-17) bu gecikmeyi iki senaryoya ayırıyor:
- WebOTP formatı: amaçlanan alıcı olmayan (domain uyuşmazlığı olan) tüm uygulamalar için gecikmeli.
- Standart SMS OTP: SDK 37+ hedefleyen çoğu uygulama için gecikmeli.
- Muafiyetler: varsayılan SMS uygulaması, asistan uygulaması ve bağlı companion cihaz uygulamaları bu gecikmeden muaf.
Bu üç saatlik pencere sırasında SMS_RECEIVED_ACTION broadcast'i tutuluyor ve SMS provider veritabanı sorguları filtreleniyor. Google, OTP çıkarımı için SMS okumaya dayanan tüm uygulamaların SMS Retriever ya da SMS User Consent API'lerine geçmesini öneriyor. Retriever'da gecikmeden kaçmanı sağlayan mekanizma şu: resmi referansa göre retriever hash'i içeren mesajların teslimi çoğu uygulama için üç saat geciktiriliyor, ancak hash'in sahibi olan uygulama muaf tutuluyor.
SMS Retriever ile gecikmeyi aşmak
kotlin
1val client = SmsRetriever.getClient(this)2val task = client.startSmsRetriever()3 4task.addOnSuccessListener {5 // SMS Retriever API dinlemeye başladı; app-hash imzalı SMS'ler6 // 3 saatlik gecikmeye takılmadan BroadcastReceiver'a düşer7}8 9task.addOnFailureListener {10 // Fallback: SMS User Consent API'ye geç11}SMS Retriever'a geçiş yalnızca gecikmeyi aşmakla kalmıyor, uygulamana READ_SMS izni de gerektirmiyor.
NPU Erişimi İçin Yeni Zorunlu İzin: FEATURE_NEURAL_PROCESSING_UNIT
targetSdk 37 hedefleyen ve NPU'ya (Neural Processing Unit) doğrudan erişmek isteyen uygulamalar artık manifestlerinde FEATURE_NEURAL_PROCESSING_UNIT donanım özelliğini deklare etmek zorunda — aksi halde NPU erişimi engelleniyor. Bu kural; LiteRT NPU delegate kullanan uygulamaları, vendor-özel SDK'ları ve deprecated NNAPI'yi kullanan uygulamaları da kapsıyor.
Dikkat: manifeste yazacağın şey sabitin adı değil, değeri. PackageManager referansına göre FEATURE_NEURAL_PROCESSING_UNIT API 37'de eklendi ve sabit değeri "android.hardware.npu"; sabit adını yazarsan deklarasyon sessizce etkisiz kalır.
xml
1<uses-feature2 android:name="android.hardware.npu"3 android:required="false" />android:required="false" çoğu uygulama için önerilir: bu ayarla uygulaman NPU olan cihazlarda hızlandırmadan yararlanır, NPU'suz cihazlarda ise Play Store'da görünmez olmaz. required="true" yaparsan uygulaman NPU'su olmayan cihazlarda Play Store'da hiç görünmez.
On-device AI özelliklerini Gemini Nano iOS + Android: Cross-platform On-Device AI yazımızda ele aldığımız gibi genişletiyorsan, bu manifest deklarasyonunu atlaman NPU hızlandırmalı modelin sessizce CPU'ya düşmesine (ya da hiç çalışmamasına) yol açabilir.
targetSdk 37 Öncesi Test Matrisi
Altı değişikliğin hepsini aynı anda gözden geçirmek yerine, aşağıdaki tabloyu bir kontrol listesi olarak kullan:
Değişiklik | targetSdk'a bağlı mı | Test edilecek senaryo |
|---|---|---|
MemoryLimiter | Hayır (cihaz Android 17 olunca) | Düşük RAM'li cihazda uzun oturum + heap dump |
Arka plan ses | Kısmen — temel kural tüm uygulamalar, WIU targetSdk 37+ | Arka plana alınmış uygulamada ses/focus isteği |
Config restart kalkması | Kaynakta targetSdk şartı belirtilmemiş | Harici klavye tak/çıkar, katlanabilir açma/kapama |
Cross-profile loopback | Hayır (cihaz Android 17 olunca) | Work profile + localhost/loopback bağımlı SDK |
SMS OTP gecikmesi | Kısmen — WebOTP/Retriever formatı tüm uygulamalar, standart SMS targetSdk 37+ | OTP akışını SMS Retriever'sız test et |
NPU izin deklarasyonu | Evet (NPU erişimi varsa) | Manifestte FEATURE_NEURAL_PROCESSING_UNIT kontrolü |
Bu matrisi CI'daki WorkManager 2.10 Coroutines: Background Task Modern Yaklaşım rehberimizdeki background task testleriyle birleştirirsen, arka plan ses ve MemoryLimiter senaryolarını otomatik regresyon testine dönüştürebilirsin.
Altı Değişikliğin Tek Bakışta Özeti
Değişiklik | Kaynak sayfa | Sessiz mi çalışıyor |
|---|---|---|
MemoryLimiter bellek sınırı | Android 17 is Here + behavior-changes-all | Evet — process loglamadan sonlanır |
Arka plan ses reddi | changes/bg-audio | Evet — istisna yok; focus AUDIOFOCUS_REQUEST_FAILED döner |
Config restart kalkması | Android 17 is Here | Hayır — onConfigurationChanged() çağrılır |
Cross-profile loopback bloğu | behavior-changes-all | Evet — bağlantı sessizce reddedilir |
SMS OTP 3 saat gecikmesi | behavior-changes-17 | Evet — broadcast tutulur, hata dönmez |
NPU izin zorunluluğu | Android 17 is Here | Hayır — NPU erişimi engellenir (log'da görünür) |
Bu Yazının Kapsamı Dışında Kalan Diğer Önemli Değişiklikler
Yukarıdaki altı madde, targetSdk 37 geçişinde en çok iş kıran davranış değişikliklerine odaklanıyor; ama Android 17 duyurusu bundan daha geniş bir platform güncellemesi içeriyor ve targetSdk 37'ye geçerken bunları da not almanı öneririz. Resmi duyuruya göre, en küçük genişliği (sw) 600dp'yi aşan büyük ekran cihazlarda (masaüstü modunda çalışan mobil cihazlar dahil) targetSdk 37 hedefleyen uygulamalar için sistem artık screenOrientation, setRequestedOrientation(), resizeableActivity=false ve minAspectRatio/maxAspectRatio gibi legacy manifest attribute'larını ve runtime API'lerini görmezden geliyor — uygulamanın herhangi bir pencere boyutuna uyum sağlaması zorunlu hale geliyor. Google Play'deki oyun kategorisindeki uygulamalar bu kısıtlamadan muaf.
Bu değişiklik, Material 3 Expressive ile gelen Material 3 Expressive: Android 16 Design System tasarım sistemi güncellemelerini kullanan uygulamalar için özellikle önemli — sabit oryantasyon varsayımıyla yazılmış layout'lar targetSdk 37'de doğrudan bozulabilir. Ayrıca Android 17 ile birlikte platformun kaynak kodu Android Open Source Project (AOSP) üzerinden yayınlandı; davranış değişikliklerinin implementasyon detaylarını incelemek istersen bu da bir seçenek.
Native kütüphane yüklemede salt-okunur zorunluluğu
Android 14'te DEX ve JAR dosyaları için gelen Safer Dynamic Code Loading (DCL) koruması, Android 17 ile native kütüphanelere de uzanıyor. Dokümandaki ifade birebir şöyle: "the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries." Pratik karşılığı tek cümleye sığıyor — targetSdk 37 ya da üstünü hedefliyorsan, System.load() ile yüklediğin her native dosyanın salt-okunur (read-only) işaretlenmiş olması gerekiyor: "All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError."
Bu madde, yazının ana gövdesindeki sessiz kırılmaların aksine gürültülü davranıyor: bir istisna aldığın için crash raporlama araçlarında görünür ve QA aşamasında fark edilir. Yine de test matrisine ayrıca yazmanı öneririm; native kütüphaneyi APK içinden değil, çalışma zamanında indirdiğin bir dizinden yüklüyorsan o dosyanın izinlerini bugüne kadar hiç düşünmemiş olabilirsin. Google'ın bu maddedeki tavsiyesi ise sertleştirmenin bir adım ötesine geçiyor: "We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering." Yani birçok durumda doğru düzeltme, dosyayı salt-okunur yapmak değil, dinamik yüklemeyi tamamen ortadan kaldırmak.
Yerel ağ erişimi artık runtime izni istiyor
Android 17, yetkisiz yerel ağ erişimine karşı ACCESS_LOCAL_NETWORK runtime iznini getiriyor. İzin, hâlihazırdaki NEARBY_DEVICES izin grubunun altında yer alıyor; dokümanın ifadesiyle "users who have already granted other NEARBY_DEVICES permissions aren't prompted again" — bu gruptan başka bir izni zaten vermiş kullanıcılara ikinci bir soru sorulmuyor. Gerekçe de açıkça yazılı: yeni şart, kötü niyetli uygulamaların kısıtlanmamış yerel ağ erişimini "covert user tracking and fingerprinting" için sömürmesini engelliyor. İzni deklare edip istediğinde uygulaman, akıllı ev cihazları ya da yayın alıcıları gibi yerel ağdaki (LAN) cihazları keşfedip onlara bağlanabiliyor.
targetSdk 37 hedefleyen uygulamalar için doküman iki yol tarif ediyor: sistem aracılığıyla çalışan, gizliliği koruyan cihaz seçicilerini (device picker) benimseyip izin sorusunu tamamen atlamak, ya da izni çalışma zamanında açıkça isteyip yerel ağ iletişimini sürdürmek. Android 16'da bu koruma opsiyoneldi; sayfadaki not farkı birebir söylüyor: "In Android 16, apps could opt in to local network permissions. Beginning with Android 17, enforcement is mandatory for apps that target Android 17 (API level 37) or higher." Uygulaman LAN üzerinde keşif yapıyor, bir casting alıcısına bağlanıyor ya da yerel bir cihazla konuşuyorsa, bu maddeyi ana gövdedeki altı değişikliğin yanına aynı öncelikle koymalısın; doküman yerel ağ iletişimini sürdürmek için bu iki yoldan birini şart koşuyor.
Certificate transparency varsayılan olarak açık geliyor
targetSdk 37 ya da üstünü hedefleyen uygulamalarda certificate transparency (CT) artık varsayılan olarak etkin. Doküman Android 16 ile farkı parantez içinde belirtiyor: "On Android 16, CT is available but apps had to opt in." Yani daha önce bilinçli olarak açman gereken bir doğrulama katmanı, hedef API seviyeni yükselttiğin anda kendiliğinden devreye giriyor.
Bu maddenin uygulamana etkisini masa başında kestirmek zor; çünkü Android 16'da opt-in olduğu için bu yolu daha önce hiç açmamış olabilirsin. targetSdk 37 geçişinde ağ katmanını test ederken, uygulamanın bağlandığı TLS uç noktalarını tek tek listelemeni ve hedef seviye yükseltildikten sonra hepsini bir kez daha doğrulamanı öneririm — yalnızca public API'lerini değil, iç ağdaki ya da kurumsal altyapıdaki servisleri de bu listeye dahil et. Bu üç madde de behavior-changes-17 sayfasında, yani yalnızca targetSdk 37+ hedefleyen uygulamaları ilgilendiren bölümde yer alıyor; cihaz Android 17'ye güncellendiği anda değil, sen hedef seviyeni yükselttiğinde devreye giriyorlar.
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
targetSdk'ını 37'ye yükseltmeden önce takip edeceğin, bu yazıdaki altı değişikliğin hepsini kapsayan kısa bir hazırlık listesi bırakıyoruz. Her maddeyi işaretledikçe production'da sürpriz bir sessiz hata riskini azaltmış olursun.
SSS
Android 17'de uygulamam neden arka planda ses çalmıyor?
Android 17'de çalışan tüm uygulamalar için — targetSdk 37'yi hedeflesen de hedeflemesen de — arka plan ses etkileşimlerinde görünür bir Activity ya da SHORT_SERVICE tipinde olmayan bir foreground service şartı var; karşılanmazsa audio focus isteği AUDIOFOCUS_REQUEST_FAILED koduyla, ses çalma ve ses seviyesi API'leri ise sessizce başarısız oluyor. API 37 hedefliyorsan ek olarak foreground service'in while-in-use (WIU) yetkisi olmalı; bu ek şart yalnızca exact alarm izni verilmiş ve USAGE_ALARM öznitelikli akışları değiştiren uygulamalarda kalkıyor.
ApplicationExitInfo 'MemoryLimiter' ne demek?
Android 17'nin yeni bellek limiti aşıldığında sistem uygulamayı sonlandırıyor; bunu tespit etmek için ApplicationExitInfo.getDescription() çağrılır. Etkilenmişse sonlanma nedeni REASON_OTHER olur ve açıklama alanı "MemoryLimiter:AnonSwap" string'ini başka bilgilerle birlikte içerir; eşitlik değil contains kontrolü yap. ProfilingManager'a ProfilingTrigger.TRIGGER_TYPE_ANOMALY tetikleyicisi de kaydedilebilir.
Android 17'de Activity neden yeniden başlatılmıyor?
API 37'den itibaren sistem, tam UI yeniden çizimi gerektirmeyen klavye, klavye gizleme, navigasyon, dokunmatik ekran ve renk modu değişikliklerinde ve bir de UI modu UI_MODE_TYPE_DESK'e ya da ondan başka bir tipe geçtiğinde Activity'yi varsayılan olarak yeniden başlatmıyor; bunun yerine onConfigurationChanged() çağrılıyor. Eski restart davranışını istiyorsan android:recreateOnConfigChanges manifest attribute'unu açıkça belirtmen gerekiyor.
API 37'de SMS OTP okuma neden gecikiyor?
targetSdk 37 hedefleyen çoğu uygulama için OTP içeren standart SMS'ler alındıktan üç saat sonrasına kadar erişilebilir olmuyor; bu sürede SMS_RECEIVED_ACTION broadcast'i tutuluyor ve SMS provider veritabanı sorguları filtreleniyor. Varsayılan SMS uygulaması, asistan uygulaması ve bağlı companion cihaz uygulamaları muaf. Kalıcı çözüm SMS Retriever ya da SMS User Consent API'sine geçmek.
targetSdk'ımı hemen 37'ye çekmezsem bu değişikliklerden etkilenir miyim?
Kısmen. Cross-profile loopback bloğu ve MemoryLimiter bellek sınırı, cihaz Android 17'ye güncellendiği anda targetSdk'dan bağımsız uygulanıyor. Arka plan ses kısıtlamasının temel kuralı (görünür Activity ya da SHORT_SERVICE olmayan foreground service) da targetSdk'dan bağımsız; yalnızca ek WIU şartı targetSdk 37'ye bağlı. SMS tarafında WebOTP ve SMS Retriever formatındaki mesajların üç saatlik gecikmesi de targetSdk'dan bağımsız olarak tüm uygulamalara uygulanıyor; bu korumanın standart SMS mesajlarına uzanması ve NPU izin zorunluluğu ise targetSdk 37+ hedefleyen uygulamaları etkiliyor.
Sonuç
Android 17 (API 37), önceki sürümlere göre daha "sessiz" bir kırılma paketiyle geliyor: altı maddenin dördü — bellek limiti, arka plan ses kısıtlaması, cross-profile loopback bloğu ve SMS OTP gecikmesi — hata fırlatmadan çalışıyor, sen fark etmesen bile kullanıcı deneyimini etkiliyor. targetSdk'ı yükseltmeden önce bu altı maddeyi gerçek cihazlarda test etmen, Google Play yorumlarında "uygulama arka planda çalışmıyor" ya da "OTP gelmiyor" şikayetleri almadan sorunu yakalamanın en güvenilir yolu.
Android sürüm geçmişini takip ediyorsan Android 15 Developer Rehberi: Privacy Sandbox, Edge-to-Edge, Foreground Services yazımızla API 35'ten bu yana neyin değiştiğini görebilirsin. Bellek ve performans tarafında derinleşmek için Jetpack Compose 1.7 Performance: Strong Skipping + Stability rehberimiz, arka plan görev testleri için WorkManager 2.10 Coroutines: Background Task Modern Yaklaşım yazımız faydalı olacaktır. NPU ve on-device AI tarafında Gemini Nano iOS + Android: Cross-platform On-Device AI yazımıza, tasarım sistemi güncellemeleri için ise Material 3 Expressive: Android 16 Design System rehberimize göz atabilirsin.
Kaynaklar
- Android 17 is Here — resmi duyuru; beş değişikliğin (MemoryLimiter, arka plan ses, config restart, SMS OTP, NPU) birincil kaynağı; cross-profile loopback bloğu yalnız behavior-changes-all sayfasında yer alıyor.
- Behavior changes: all apps — MemoryLimiter ve cross-profile loopback bloğunun teknik referansı.
- Behavior changes: apps targeting Android 17 — SMS OTP üç saatlik gecikmenin detayları.
- Changes to background audio — arka plan ses kısıtlamasının teknik referansı.
- Android 17 release notes — sürüm geçmişi ve güncelleme kaydı.
- Prioritizing memory efficiency: steps for Android 17 — MemoryLimiter'ın arka planındaki motivasyon ve geliştirici rehberi.
