Google Play'in 31 Ağustos 2026 son tarihi geride kaldı ve Play Console'undaki Policy status ekranında hâlâ bir uyum uyarısı görüyorsan yalnız değilsin. Google Play target API 36 son tarih uzatma sürecinin bugün (2026-09-08 itibarıyla) nasıl işlediğini, hangi uygulamaların hâlâ risk altında olduğunu ve targetSdkVersion'ı 36'ya çıkarırken nelerin kırılacağını bu yazıda adım adım anlatıyorum.
💡 Pro Tip: Panik yapma — mevcut kullanıcıların uygulaman elinden alınmıyor. Riskli olan tek şey, yeni Android sürümü çalıştıran cihazlardaki yeni kullanıcıların seni Play'de bulamaması. Önce Play Console'daki Policy status ekranına bak, sonra bu yazıdaki sırayı izle.
İçindekiler
- Zorunluluk Tam Olarak Nedir: Yeni Uygulama mı, Güncelleme mi
- 31 Ağustos'u Kaçırdıysanız Ne Oluyor
- Play Console'dan Uzatma Nasıl İstenir
- targetSdk 36'ya Çıkarken Kırılan Davranışlar
- Edge-to-Edge ve Foreground Service Zorunlulukları
- Test ve Aşamalı Yayın Planı
- Bir Sonraki Dalga: API 37 Takvimi
- SSS
- Google Play API 36 son tarihini kaçırırsam uygulamam kaldırılır mı?
- Target API 36 uzatması nasıl alınır, son gün ne zaman?
- Hangi uygulamalar API 35'te kalabilir?
- targetSdkVersion 36'ya yükseltince ne kırılır?
- targetSdk'ı yükseltmeden önce hangi sırayı izlemeliyim?
- Sonuç
- Kaynaklar
Zorunluluk Tam Olarak Nedir: Yeni Uygulama mı, Güncelleme mi
Google'ın resmi Play Console Yardım sayfasına göre 31 Ağustos 2026'dan itibaren hem yeni uygulamalar hem de mevcut uygulamalara gönderilen güncellemeler Android 16 (API level 36) veya üstünü hedeflemek zorunda. Bu kural Play'e gönderilen her yeni sürüm için geçerli; yalnızca "yeni uygulama" değil, üretimde zaten yayında olan bir uygulamaya attığın her güncelleme de bu şartı sağlamak zorunda.
Kuralın istisnaları var ve bunları bilmek çoğu geliştirici için gereksiz bir migrasyon telaşını önlüyor:
- Wear OS ve Android Automotive OS uygulamaları: Android 15 (API level 35) veya üstü yeterli.
- Android TV ve Android XR uygulamaları: Android 14 (API level 34) veya üstü yeterli.
- Telefon, tablet, katlanabilir ve standart Android Auto companion uygulamaları için taban her zaman API 36.
Bu istisnaları tek tek ezberlemek yerine, hangi kategori hangi tabana bağlı olduğunu bir tabloya dökmek karar vermeyi kolaylaştırıyor:
Uygulama Kategorisi | Zorunlu Taban API |
|---|---|
Telefon / tablet / katlanabilir | API 36 (Android 16) |
Standart Android Auto companion | API 36 (Android 16) |
Wear OS | API 35 (Android 15) |
Android Automotive OS | API 35 (Android 15) |
Android TV | API 34 (Android 14) |
Android XR | API 34 (Android 14) |
Birden fazla form-faktörü hedefleyen bir uygulaman varsa (ör. telefon + Wear OS modülü), her modülün kendi manifest'inde doğru targetSdkVersion değerini taşıdığından emin olmak gerekiyor — tek bir proje içinde iki farklı taban aynı anda geçerli olabiliyor.
Burada karıştırılan bir kavram var: targetSdkVersion ile minSdkVersion. minSdkVersion, uygulamanın destekleyeceği en eski Android sürümünü belirler ve bu zorunluluktan hiç etkilenmez — minSdk'ını yükseltmen gerekmiyor. targetSdkVersion ise Android'e "uygulamam hangi sürümün davranış kurallarına göre çalışıyor" sözünü verir. Yani mevcut cihaz desteğini daraltmadan, yalnızca uygulamanın derlendiği ve test edildiği davranış katmanını 36'ya taşıyorsun.
31 Ağustos'u Kaçırdıysanız Ne Oluyor
Bugün Eylül ayındaysan ve hâlâ eski target API ile yayında bir uygulaman varsa, önce şunu bil: uygulaman kaldırılmadı ve kaldırılmayacak. Mevcut kullanıcıların uygulaman elinde duruyor, indirmeye ve güncellemeye (eski sürümü) devam edebiliyorlar.
Asıl kısıtlama iki katmanlı işliyor:
- Yeni sürüm gönderemezsin. 31 Ağustos'tan sonra API 35 veya altını hedefleyen herhangi bir yeni sürüm Play tarafından reddediliyor. Yani bugün bir bugfix güncellemesi göndermek istesen bile, önce targetSdk'ı 36'ya çekmen şart.
- Yeni kullanıcılara görünmezlik riski. Play Console resmi kaynağına göre mevcut uygulamalar, kendi target API seviyesinden daha yeni bir Android çalıştıran cihazlardaki yeni kullanıcılara görünür kalabilmek için API 35 veya üstünü hedeflemek zorunda. Bu eşiği karşılamayan bir uygulama, o cihazlarda yeni kullanıcılara görünür ve kullanılabilir olmaktan çıkıyor — mevcut kullanıcı tabanın etkilenmiyor, ama yeni kullanıcı akışın kesiliyor.
Pratikte bu, "hemen şu an düşer miyim" korkusunu ortadan kaldırıyor ama "her gün yeni kullanıcı kaybediyor olabilirim" riskini gündeme getiriyor.
Play Console'dan Uzatma Nasıl İstenir
Google'ın resmi Play Console Yardım sayfasına göre yalnızca politikayla uyumlu olmayan uygulamalar Play Console'da politika uyarısı ve bildirim alıyor; uzatma formuna da bu uyarının ya da sorunun Policy status sayfasındaki detay sayfası üzerinden erişiliyor. Play politikasını izleyen bağımsız kaynaklara göre bu detay ekranındaki eylem "Request more time" etiketini taşıyor.
Onaylanan bir uzatma, uyum tarihini 1 Kasım 2026'ya kadar erteliyor. Ancak burada mutlaka netleştirilmesi gereken bir nüans var: bu bir "istediğin an başvurabileceğin, sürekli açık bir pencere" değil. Play politikasını yakından izleyen bağımsız kaynaklar, uzatmaların her uygulama için garanti edilmediğini belirtiyor — yani her hesap veya her uygulama için otomatik bir onay söz konusu değil.
Eğer bugün Play Console'unu açtığında "Request more time" seçeneği artık görünmüyorsa, en gerçekçi yol budur: uzatmayı beklemek yerine doğrudan targetSdk 36 geçişine odaklanmak. Çünkü tek garantili çıkış yolu, uygulamanın gerçekten API 36'yı hedefleyen bir sürümünü yayınlamak.
Kendi hesabında bu ekranı kontrol ederken iki şeye bak: uyarının durumu (aktif mi, temizlenmiş mi) ve detay sayfasında bir uzatma formunun açılıp açılmadığı. İkisi de netse, bir sonraki adımına karar vermen kolaylaşır.
Burada sık yapılan bir hata var: uzatmayı "her geliştiriciye açık, istediğin zaman doldurabileceğin genel bir form" sanmak. Oysa resmi kaynak formun yalnızca etkilenen uygulamalara bildirim yoluyla ulaştığını söylüyor. Yani hesabına hiç bildirim gelmediyse, bu formun senin için henüz (ya da hiç) açılmadığı anlamına gelebilir — bu durumda beklemek yerine doğrudan geçişe odaklanmak zaman kaybettirmiyor.
Uzatma sürecini bir "kaçış yolu" değil, geçiş sürecine ek zaman kazandıran bir tampon olarak görmek daha sağlıklı bir çerçeve. Çünkü tarih ne olursa olsun sonunda ulaşman gereken tek nokta aynı: production'da API 36 hedefleyen, davranış değişikliklerine karşı test edilmiş bir sürüm.
targetSdk 36'ya Çıkarken Kırılan Davranışlar
targetSdkVersion'ı 36'ya çektiğinde derleme hatası almazsın ama çalışma zamanında sessizce kırılan birkaç davranış var. Android 16'nın resmi davranış değişiklikleri sayfasına göre bunların başında predictive back geliyor: API 36 hedefleyen ve Android 16+ çalıştıran cihazlarda sistem geri animasyonları (ana ekrana dönüş, görevler arası, aktiviteler arası) varsayılan olarak açık. Hâlâ eski onBackPressed() sözleşmesine güveniyorsan, bu artık çağrılmıyor ve KeyEvent.KEYCODE_BACK de dispatch edilmiyor.
- OnBackPressedDispatcher: geri tuşu davranışını
onBackPressed()yerine kaydettiğin geri callback'leri üzerinden yönetmeni sağlayan API; predictive back animasyonlarının çalışması için bu modele geçiş şart. - Üç tuşlu (3-button) navigasyon genişlemesi: Android Developers Blog'un Android 16 duyurusuna göre Android 16, predictive back navigasyonunu üç tuşlu navigasyona da genişletiyor; geri tuşuna uzun basan kullanıcılar geri gitmeden önce önceki ekranın bir kesitini görüyor.
kotlin
1// Eski desen (API 36'da çalışmaz):2override fun onBackPressed() {3 if (isEditing) { cancelEdit() } else { super.onBackPressed() }4}5 6// Yeni desen: OnBackPressedDispatcher ile callback kaydı7val callback = object : OnBackPressedCallback(true) {8 override fun handleOnBackPressed() {9 if (isEditing) cancelEdit() else {10 isEnabled = false11 onBackPressedDispatcher.onBackPressed()12 }13 }14}15onBackPressedDispatcher.addCallback(this, callback)Bu geçişi atlarsan uygulama çökmez ama geri tuşu/gesture'ı kullanıcı için tutarsız çalışır — özellikle özel geri davranışı olan düzenleme ekranlarında (form, editör, medya oynatıcı) fark edilir.
İkinci kırılma noktası medya erişimi. Android 16 davranış değişiklikleri sayfasındaki tanıma göre, SDK 36 veya üstünü hedefleyen bir uygulama Android 16 veya üstü çalıştıran bir cihazda fotoğraf ve video izni istediğinde, erişimi seçili medyayla sınırlamayı tercih eden kullanıcılar fotoğraf seçicide uygulamanın kendi sahip olduğu fotoğrafları ön-seçili görüyor. Kullanıcı bu ön-seçili öğelerin seçimini kaldırabiliyor ve seçimi kaldırdığında uygulamanın o fotoğraf ve videolara erişimi geri alınıyor. Yani seçili-medya akışında bir kez erişilen içeriğin kalıcı olduğunu varsayan kodun, erişimin kullanıcı tarafından geri alınabildiği bu modele göre gözden geçirilmesi gerekiyor.
Üçüncüsü, büyük ekran ve katlanabilir cihaz davranışı: resmi ifadeye göre Android 16 (API level 36) hedefleyen uygulamalarda orientation, resizability ve aspect ratio kısıtlamaları en küçük genişliği 600dp ve üstü olan ekranlarda artık uygulanmıyor. Yani manifest'inde screenOrientation="portrait" gibi bir kısıtlama tanımlasan bile, bu ekranlarda uygulama tüm pencereyi dolduruyor — layout'unun landscape ve split-screen modunda gerçekten test edilmesi gerekiyor, aksi halde kırpılmış veya taşan arayüzlerle karşılaşabilirsin. Aynı kaynak geçici bir çıkış yolu da tanımlıyor: PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest özelliğiyle bu davranışın dışında kalabiliyorsun; ancak bu opt-out API level 37 hedefleyen uygulamalarda geçerli olmayacak.
Bu listeye ait sanılan ama aslında API 36 ile gelmeyen bir madde de var: tam ekran bildirimler. Android 14 (API level 34) veya üstünü hedefleyen uygulamalarda USE_FULL_SCREEN_INTENT iznini kullanabilenler yalnızca arama ve alarm sunan uygulamalarla sınırlı; Google Play, bu profile uymayan uygulamalar için varsayılan izni geri alıyor. Yani bu kural API 34'ten beri geçerli — targetSdk 36 geçişinde ilk kez karşına çıkıyorsa, yeni bir kısıtlama olduğu için değil, atlanmış eski bir borç olduğu için çıkıyor.
Son olarak, targetSdk'tan bağımsız ama aynı geçiş penceresinde karşına çıkan bir değişiklik var: ön plan servisinden (foreground service) başlatılan arka plan görevleri artık kendi runtime kotalarına uymak zorunda. Bu kural Android 16 veya üstünde çalışan uygulamalar için, hedefledikleri API seviyesinden bağımsız geçerli — bunu bir sonraki bölümde ayrıca ele alıyorum, çünkü foreground service kuralları kendi başına bir kırılma kategorisi oluşturuyor.
Edge-to-Edge ve Foreground Service Zorunlulukları
Android 16'nın davranış değişiklikleri sayfasına göre, edge-to-edge için uzun süredir var olan "opt-out" kaçış kapısı — R.attr#windowOptOutEdgeToEdgeEnforcement — targetSdk 36 uygulamaları için artık işe yaramıyor. Resmi ifade net: bu attribute kullanımdan kaldırıldı ve devre dışı bırakıldı; API 36 hedefleyen bir uygulama artık edge-to-edge çizimden çıkamıyor. Bunu daha önce hiç ele almadıysan, status bar ve navigation bar'ın üstüne bindiği veya arkasında kaybolan içerik sorunlarıyla karşılaşman olası.
Pratikte kontrol etmen gereken üç nokta:
Alan | Eski davranış (opt-out ile) | targetSdk 36 davranışı |
|---|---|---|
Status bar / nav bar | Sistem otomatik boşluk (inset) bırakırdı | Uygulama kendi inset'lerini yönetmek zorunda |
windowOptOutEdgeToEdgeEnforcement | Edge-to-edge'i devre dışı bırakabilirdi | targetSdk 36'da etkisiz |
Compose / View içerik | Manuel padding olmadan da güvenliydi | WindowInsets ile padding uygulaman şart |
Foreground service tarafında ise değişiklik daha sinsi: ön plan servisinden tetiklenen arka plan işleri (ör. bir bildirim servisi içinden başlatılan senkronizasyon), Android 16 veya üstünde çalışan uygulamalarda artık kendi runtime kotalarına tabi. Yani "foreground service içindeyim, kota beni bağlamaz" varsayımı Android 16 ve üstünde geçerliliğini kaybediyor. Resmi dokümantasyon bu kapsama JobScheduler ile doğrudan planlanan işlerin yanı sıra WorkManager veya DownloadManager gibi kütüphanelerin oluşturduğu işleri de açıkça dahil ediyor. Yani WorkManager kotadan kaçış yolu değil; sağladığı şey, işin ertelenip yeniden denenebilir bir kısıt modeliyle tanımlanması.
kotlin
1// Foreground service içinden "sınırsız" arka plan işi varsayımı artık geçerli değil.2// WorkManager işleri de aynı runtime kotasına tabi (JobScheduler/DownloadManager ile birlikte).3val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()4 .setConstraints(5 Constraints.Builder()6 .setRequiredNetworkType(NetworkType.CONNECTED)7 .build()8 )9 .build()10WorkManager.getInstance(context).enqueue(syncRequest)Test ve Aşamalı Yayın Planı
targetSdk 36 geçişini tek seferde production'a atmak, yukarıdaki davranış değişikliklerinin hepsini aynı anda kullanıcıya göstermek demek. Bunun yerine adım adım bir sıra izlemek riski azaltıyor:
- Bağımlılık envanteri çıkar: Kullandığın üçüncü parti SDK'ların API 36 uyumlu sürüm yayınlayıp yayınlamadığını kontrol et. Bir kütüphane henüz uyumlu sürüm çıkarmadıysa, geçişin o kütüphaneye bağımlı kalır — bu bir blokaj noktası.
compileSdkvetargetSdk'ı ayrı ayrı yükselt: Önce derleme hedefini 36'ya çek, derleme hatalarını gör; sonratargetSdkVersion'ı değiştirip davranış farklarını gözlemle.- Predictive back, edge-to-edge ve büyük ekran davranışını manuel test et: Bunlar lint veya derleyici tarafından yakalanmıyor, yalnızca gerçek cihazda veya emülatörde elle test edilerek görülüyor.
- Kapalı test kanalına (internal/closed testing) at: Üretime geçmeden önce gerçek davranışı gözlemlemek için Play Console'un test kanallarını kullan.
- Production'a aşamalı yayınla (staged rollout): Yüzde bazlı kademeli yayın ile crash/ANR oranını izleyerek yayılımı genişlet.
Önemli bir pratik not: mevcut, zaten yayında olan bir uygulama için bu targetSdk güncellemesini göndermek, "12 test kullanıcısı / 14 gün" kapalı test şartını yeniden tetiklemiyor. O şart yalnızca ilk production sürümünü yayınlayan yeni bireysel geliştirici hesapları için geçerli — yani mevcut bir uygulamayı güncelliyorsan bu ek bekleme süresiyle uğraşmana gerek yok.
Uyumlu sürüm production'da yayına girdiğinde, Play Console'daki policy uyarısı otomatik temizleniyor ve Google onay bildirimi gönderiyor — yani geçişin başarılı olduğunu tahmin etmene gerek kalmıyor, bildirim seni bilgilendiriyor.
Bağımlılık envanterini çıkarırken tek tek kütüphanenin changelog'una bakmak yerine, ./gradlew :app:dependencies çıktısını alıp sürüm numaralarını bilinen uyumlu sürümlerle karşılaştırmak zaman kazandırıyor. Envanteri sprint'in ilk günü çıkarmak, geçişin sonunda sürpriz bir blokaj yaşamanı önlüyor.
Kapalı test kanalında geçirdiğin süre boyunca özellikle şu üç senaryoyu manuel olarak tekrar tekrar dene: özel geri davranışı olan bir ekrandan (form, editör) sistem geri hareketiyle çıkmak, status bar ve navigation bar arkasına kadar çizen bir ekranda inset'lerin doğru uygulandığını kontrol etmek ve uygulamayı bir tablet veya katlanabilir cihazda hem dikey hem yatay modda açmak. Bu üç senaryo, yukarıda sayılan davranış değişikliklerinin büyük kısmını tek oturumda gözle görülür hale getiriyor.
Bir Sonraki Dalga: API 37 Takvimi
Google Play'in target API zorunluluğu yıllık bir döngü olarak işliyor — bu yılki API 36 dalgası ilk defa yaşanan bir şey değil, geçen yıllarda API 34 ve API 35 için de aynı mekanizma çalıştı. Bu döngünün doğası gereği, Android 17 (API level 37) için de benzer bir target API zorunluluğunun ilerleyen zamanda gündeme geleceğini bekleyebilirsin.
Şu an için net olan şu: Android'in resmi geliştirici sitesinde Android 17 hedefleyen uygulamalar için davranış değişiklikleri sayfası zaten yayında ve büyük ekran/katlanabilir cihazlarda orientation-resizability opt-out'unun kaldırılması gibi konular bu sayfada işleniyor. Ancak Google Play'in API 37'yi ne zaman zorunlu kılacağına dair resmi, kesin bir tarih bu yazının yazıldığı sırada Play Console yardım sayfasında yayınlanmış değil — bu yüzden burada spesifik bir ay/tarih vermiyorum. Kararlı bir varsayım yapmak yerine en doğru strateji, her yıl bir target API güncellemesi bütçelemek ve Play Console'daki Policy status sayfasını düzenli kontrol etmek.
Bu bütçeleme yaklaşımını build.gradle.kts'te net bir şekilde görünür tutmak, ekip içinde "hangi SDK'ı hedefliyoruz" tartışmasını da önlüyor:
kotlin
1android {2 compileSdk = 363 4 defaultConfig {5 minSdk = 246 targetSdk = 36 // Play zorunluluğu: 31 Ağustos 2026'dan beri şart7 }8}Yıllık bump'ı bir "acil durum" değil, sürüm takvimine gömülü rutin bir bakım işi olarak planlarsan, bir sonraki dalgada bu yazıyı tekrar okumana gerek kalmaz.
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ü
Bu yazıyı buraya kadar okuduysan, targetSdk 36 geçişini tek oturumda bitirebileceğin kısa bir kontrol listesi hazırladım. Yazdırıp masana yapıştırabileceğin, adım adım ilerleyen bir sıra.
SSS
Google Play API 36 son tarihini kaçırırsam uygulamam kaldırılır mı?
Hayır, kaldırılmaz. Mevcut kullanıcıların uygulaman elinde kalmaya devam ediyor; indirme ve kullanım kesintiye uğramıyor. Kesilen tek şey, kendi target API seviyenden daha yeni bir Android sürümü çalıştıran cihazlardaki yeni kullanıcıların seni Play'de bulabilmesi. O cihazlarda uygulaman yeni kullanıcılara görünür ve kullanılabilir olmaktan çıkıyor; kaldırma değil görünmezlik söz konusu.
Target API 36 uzatması nasıl alınır, son gün ne zaman?
Google'ın resmi tanımına göre uzatma formuna, Play Console'daki Policy status sayfasında ilgili uyarının ya da sorunun detay sayfası üzerinden erişiliyor; uyumsuz uygulamalar bu uyarıyı ve bir Play Console bildirimini alıyor. Onaylanırsa uyum tarihi 1 Kasım 2026'ya erteleniyor. Ama bu garanti edilen bir hak değil — Play politikasını izleyen bağımsız kaynaklar uzatmaların her uygulama için garanti olmadığını belirtiyor, bu yüzden uzatmayı beklemeden geçişe başlamak en güvenli yol.
Hangi uygulamalar API 35'te kalabilir?
Yalnızca Wear OS ve Android Automotive OS uygulamaları API 35 (Android 15) veya üstüyle yetiniyor. Android TV ve Android XR uygulamaları için taban API 34. Telefon, tablet, katlanabilir cihaz ve standart Android Auto companion uygulamaları için ise taban her zaman API 36 — bu kategoride bir istisna yok.
targetSdkVersion 36'ya yükseltince ne kırılır?
En sık karşılaşılan üç değişiklik: predictive back animasyonlarının onBackPressed() yerine OnBackPressedDispatcher gerektirmesi, edge-to-edge çizimin artık opt-out edilememesi ve en küçük genişliği 600dp ve üstü olan ekranlarda orientation, resizability ile aspect ratio kısıtlamalarının göz ardı edilmesi (bu sonuncusundan API 36'da geçici olarak çıkabiliyorsun, API 37'de bu imkân kalkıyor). Buna ek olarak, targetSdk'tan bağımsız biçimde Android 16 veya üstünde çalışan uygulamalarda foreground service'ten tetiklenen arka plan işleri kendi runtime kotasına tabi. Hiçbiri derleme hatası vermiyor, hepsi çalışma zamanında elle test edilerek yakalanıyor.
targetSdk'ı yükseltmeden önce hangi sırayı izlemeliyim?
Önce üçüncü parti SDK bağımlılıklarının uyumluluğunu kontrol et, sonra compileSdk'ı yükselt ve derleme hatalarını çöz, ardından targetSdkVersion'ı değiştirip davranış farklarını kapalı test kanalında gözlemle, en son aşamalı yayınla production'a çık.
Sonuç
Google Play target API 36 zorunluluğu 31 Ağustos'ta yürürlüğe girdi ve bugün için asıl mesele "uygulamam düşer mi" korkusu değil, "yeni kullanıcı kaybediyor muyum" sorusu. Play Console'daki Policy status ekranını kontrol et, uzatma formunu bir kurtarma planı değil ek tampon olarak gör ve targetSdk 36 geçişini üçüncü parti bağımlılık kontrolüyle başlatıp aşamalı yayınla bitir.
Edge-to-edge zorunluluğunun kökenini ve Material 3 Expressive ile birlikte nasıl bir tasarım diline evrildiğini Material 3 Expressive ve Android 16 tasarım sistemi yazımda daha derinlemesine ele aldım. Kotaya tabi arka plan işlerini WorkManager ile tanımlarken kullandığın coroutine tabanlı yaklaşımı WorkManager 2.10 ve coroutine tabanlı arka plan işleri yazısında bulabilirsin. Jetpack Compose tarafında performans regresyonlarını yakalamak istiyorsan Jetpack Compose 1.7 performans ve strong skipping yazısı işine yarayacak.
Play Console'daki abonelik ve faturalandırma akışlarını da aynı geçiş penceresinde gözden geçirecek olan ekipler için Google Play Billing v7 abonelik entegrasyonu yazısı iyi bir tamamlayıcı. targetSdk 36'nın gizlilik ve edge-to-edge zorunluluklarının bir önceki dalgada (API 35) nasıl geldiğini görmek istersen Android 15 geliştirici gizlilik sandbox'ı ve edge-to-edge yazısı bu yazının doğal öncülü sayılır. Android Auto companion uygulaman varsa, target API 36 taban şartının orada da geçerli olduğunu unutma — detayları Android Auto dashboard production rehberi yazısında bulabilirsin.
Kaynaklar
- Google Play target API level gereklilikleri (Play Console Yardım) — 31 Ağustos 2026 zorunluluğu, istisnalar (Wear OS/Automotive API 35, TV/XR API 34) ve 1 Kasım 2026 uzatma penceresinin resmi tanımı.
- Android 16 davranış değişiklikleri: API 36+ hedefleyen uygulamalar (Android Developers) — predictive back, edge-to-edge zorunluluğu ve foreground service runtime kotası için resmi teknik referans.
- Android 16 is here (Android Developers Blog) — predictive back'in üç tuşlu navigasyona genişletilmesinin resmi duyurusu.
- Android 14 davranış değişiklikleri: API 34+ hedefleyen uygulamalar (Android Developers) —
USE_FULL_SCREEN_INTENTizninin arama ve alarm uygulamalarıyla sınırlanmasının resmi kaynağı. - Android 17 davranış değişiklikleri: API 37+ hedefleyen uygulamalar (Android Developers) — bir sonraki dalgada gündeme gelmesi beklenen büyük ekran/orientation değişikliklerinin resmi ön izlemesi.
- Target API seviyeni 31 Ağustos 2026'ya kadar güncelle (Testers Community) — Play Console uyarı ekranının görsel akışı, kapalı test istisnası ve yıllık döngü açıklaması.
- Android API 36 Ağustos son tarihi: şimdi ne yapmalı (stora.sh) — üçüncü parti SDK bağımlılık riski ve targetSdk 36 geçiş adımlarının pratik özeti.
- Foreground service değişiklikleri (Android Developers) — foreground service'ten tetiklenen arka plan işlerinin runtime kotasına tabi olmasının ayrıntılı teknik dokümantasyonu.
