Android Target API 36 Geçişi: 31 Ağustos 2026 Öncesi Yol Haritası

Kısa özet: Google Play, 31 Ağustos 2026'dan itibaren standart Android uygulamalarının yeni sürümlerinde Android 16, yani API level 36 hedeflenmesini zorunlu tutacak. Değişiklik yalnızca targetSdk değerini yükseltmekten ibaret değil. Edge-to-edge arayüz, predictive back, büyük ekran davranışları, sağlık izinleri ve bazı çalışma zamanı varsayımları yeniden test edilmeli.

Kısa doğrudan cevap

31 Ağustos 2026'dan itibaren Google Play'e gönderilecek yeni telefon, tablet ve Android Auto uygulamaları ile bu uygulamaların güncellemeleri Android 16'yı, yani API level 36'yı hedeflemelidir. Wear OS ve Android Automotive OS uygulamalarında yeni gönderim eşiği API 35; Android TV ve Android XR uygulamalarında ise API 34'tür. Mevcut standart uygulamaların yeni Android sürümündeki kullanıcılara görünür kalması için en az API 35'i hedeflemesi gerekir. Uygun uygulamalar için son tarih 1 Kasım 2026'ya kadar uzatılabilecektir. Ancak geçiş planı yalnızca aşağıdaki değeri değiştirmek olmamalıdır:

targetSdk = 36

Android 16'yı hedefleyen uygulamalarda sistem çubuklarının arkasına uzanan edge-to-edge arayüz zorunlu hale gelir, predictive back varsayılan olarak etkinleşir ve büyük ekranlarda yön ile en-boy oranı kısıtlamaları belirli koşullarda yok sayılır. Bu nedenle geçiş, yapılandırma değişikliği değil; kullanıcı arayüzü, navigasyon ve cihaz uyumluluğu testidir.

Duyurunun tarihi ve durumu

Android 16, 10 Haziran 2025'te kararlı sürüm olarak yayımlandı. Dolayısıyla 2026 Google Play zorunluluğu bir beta veya preview SDK'ya geçiş değildir; bir yıldan uzun süredir kararlı olan platform sürümünün mağaza gönderim şartı haline gelmesidir.

Google Play'de hangi uygulama hangi API seviyesini hedeflemeli?

Google Play'in 31 Ağustos 2026 tablosu, uygulamanın çalıştığı cihaz kategorisine ve yeni gönderim mi yoksa mevcut uygulama mı olduğuna göre değişiyor.

Burada iki farklı yaptırım birbirine karıştırılmamalıdır.

Yeni uygulama ve güncelleme gönderimleri

Telefon ve tablet uygulamanız API 35'i hedefliyorsa 31 Ağustos 2026'dan sonra yeni bir sürümü Google Play'e gönderemezsiniz. Yeni gönderim veya güncelleme için API 36 gerekir.

Mağazada bulunan mevcut uygulamalar

Mevcut telefon ve tablet uygulamanız API 34 veya daha düşük bir seviyeyi hedefliyorsa uygulama doğrudan bütün kullanıcılar için silinmez. Ancak uygulama, hedef API seviyesinden daha yeni Android sürümünü çalıştıran yeni kullanıcılara sunulmaz. Bu nedenle “31 Ağustos'ta bütün eski uygulamalar mağazadan kaldırılacak” ifadesi doğru değildir. Yaptırım; güncelleme gönderiminin engellenmesi ve güncel Android cihazlardaki yeni kullanıcı görünürlüğünün sınırlandırılmasıdır.

Uzatma seçeneği

Google, uygulamasını zamanında güncelleyemeyen uygun geliştiricilerin 1 Kasım 2026'ya kadar uzatma talep edebileceğini belirtiyor. Uzatma formlarının Play Console içerisinde ilgili uygulamalara açılması bekleniyor. Bu seçenek bir migration planı değil, gecikme riskini azaltan geçici bir önlemdir.

minSdk, compileSdk ve targetSdk aynı şey değildir

Target API migration'larında en sık yapılan hata, üç SDK seviyesinin aynı görevi gördüğünü varsaymaktır.

targetSdk değerinin 36 yapılması, uygulamanın yalnızca Android 16 cihazlarda çalışacağı anlamına gelmez. Desteklenen en eski cihaz sürümünü minSdk belirlemeye devam eder. Buna karşılık targetSdk = 36, Android 16 üzerinde çalışırken yeni hedefe bağlı davranışların devreye alınmasını sağlar.

Teknik geçişin ilk adımı: geliştirme ortamını hazırlamak

Google'ın Android 16 SDK kurulum dokümanı, Android Studio Meerkat 2024.3.1 veya daha yeni bir sürümün kullanılmasını ve Android Gradle Plugin'in en az 8.9.0-rc01 seviyesine çıkarılmasını istiyor. Güncel bir projede eski minimum sürüme sabitlenmek yerine desteklenen kararlı Android Studio ve AGP sürümünü kullanmak daha doğru olur.

Kotlin DSL

android {
compileSdk = 36
defaultConfig {
targetSdk = 36

} }

Groovy

android {

compileSdk 36

defaultConfig {

targetSdk 36 } } Android SDK Manager üzerinden Android SDK Platform 36 ve güncel 36.x.x Build Tools paketi kurulmalıdır. Ancak compileSdk ve targetSdk değerlerini aynı commit içinde değiştirip bütün sorunları birlikte çözmeye çalışmak hata ayıklamayı zorlaştırır. Daha güvenli sıra şöyledir:

• Önce compileSdk değerini 36 yapın.
• Derleme ve bağımlılık sorunlarını çözün.
• Uygulamayı Android 16 üzerinde mevcut target seviyesinde test edin.
• Ardından targetSdk değerini 36 yapın.
• Hedef API'ye bağlı davranış değişikliklerini ayrı ayrı test edin.

Bu ayrım, Android 16 üzerinde bütün uygulamaları etkileyen değişikliklerle yalnızca API 36'yı hedefleyen uygulamaları etkileyen değişiklikleri birbirinden ayırır.

Android 16'yı hedeflediğinizde değişen temel davranışlar

1. Edge-to-edge arayüzden çıkış yolu kaldırılıyor

Android 15, API 35'i hedefleyen uygulamalarda edge-to-edge arayüzü devreye aldı; ancak uygulamalar windowOptOutEdgeToEdgeEnforcement özelliğiyle geçici olarak bundan çıkabiliyordu. Android 16'yı hedefleyen ve Android 16 cihazda çalışan uygulamalarda bu seçenek devre dışıdır. Uygulamanın içerik alanı durum ve navigasyon çubuklarının arkasına uzanabilir. Bu değişiklik özellikle şu alanlarda hata üretir:

• Üst başlığın durum çubuğunun altında kalması
• Alt CTA butonunun gesture alanıyla çakışması
• Klavye açıldığında form alanlarının kapanması
• Modal ve bottom sheet bileşenlerinde yanlış inset kullanımı
• Sabit piksel padding değerleri
• Kamera deliği ve ekran çentiği bulunan cihazlar

Kontrol edilmesi gerekenler

• Tüm ana ekranlarda system bar inset'leri
• Açılış ve kimlik doğrulama ekranları
• Bottom navigation
• Modal, drawer ve bottom sheet bileşenleri
• Klavye açılan formlar
• Tam ekran medya ve kamera akışları
• React Native projelerinde güvenli alan bileşenleri

Edge-to-edge uyumluluğu yalnızca ana sayfada test edilmemelidir. En sık kırılan ekranlar, az kullanılan ödeme, şifre sıfırlama ve izin açıklama ekranlarıdır.

2. Predictive back varsayılan olarak etkinleşiyor

API 36'yı hedefleyen uygulamalarda Android 16 üzerinde predictive back animasyonları varsayılan olarak çalışır. Sistem artık klasik onBackPressed() çağrısını yapmaz ve KEYCODE_BACK olayını göndermez. Uygulama aşağıdaki yöntemlere dayanıyorsa navigasyon davranışı bozulabilir:

• onBackPressed() metodunun manuel override edilmesi
• Back tuşunun klavye olayı gibi ele alınması
• Özel native navigasyon katmanı
• WebView geçmişi için eski back handler uygulaması
• Activity ve Fragment geçişlerinin manuel yönetilmesi
• React Native içinde özel native back modülü

Geçici olarak aşağıdaki manifest ayarıyla predictive back davranışından çıkılabilir:

<application
android:enableOnBackInvokedCallback="false">
</application>

Bu seçenek kalıcı çözüm olarak görülmemelidir. Android'in yönü, uygulamaların desteklenen back navigation API'lerine taşınmasıdır.

Test edilmesi gereken geri dönüş senaryoları

• Ana ekrandan uygulamadan çıkış
• Activity geçişleri
• Fragment veya Compose navigation geçişleri
• Modal kapatma
• Drawer kapatma
• WebView geçmişi
• Ödeme ve form ekranında veri kaybı
• Deep link ile açılmış ekrandan geri dönüş

3. Büyük ekranlarda yön ve en-boy oranı kısıtlamaları yok sayılıyor

API 36'yı hedefleyen uygulamalarda en küçük genişliği en az 600 dp olan ekranlarda aşağıdaki kısıtlamalar varsayılan olarak etkisiz hale gelir:

• Sabit portrait veya landscape yönü
• resizeableActivity="false"
• Minimum ve maksimum en-boy oranı
• Çalışma zamanında yön kilitleme çağrıları

Bu değişiklik tablet, katlanabilir cihaz ve masaüstü pencere modunda, yalnızca telefon ekranı için tasarlanmış arayüzlerin gerilmesine veya ekran dışına taşmasına neden olabilir. Geçici çıkış özelliği bulunmaktadır:

<application>
<property
android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
android:value="true" />
</application>

Ancak Google, bu geçici çıkışın API level 37 hedeflendiğinde çalışmayacağını belirtiyor. Başka bir ifadeyle API 36, adaptif arayüze geçişin ertelenebildiği son ara dönemdir.

Kontrol edilmesi gereken büyük ekran sorunları

• Sabit genişlikli kartlar
• Tam ekran görseller
• Harita ve kamera bileşenleri
• İmza veya çizim alanları
• Grafik ve dashboard ekranları
• Yatay döndüğünde sıfırlanan form durumu
• İki sütuna geçmesi gereken liste ve detay ekranları
• Katlanabilir cihazlardaki ara boyutlar
• Split-screen ve desktop windowing

4. Sağlık ve sensör izinleri daha ayrıntılı hale geliyor

Android 16'yı hedefleyen uygulamalarda BODY_SENSORS ve BODY_SENSORS_BACKGROUND izinlerinin kapsadığı bazı sağlık verileri daha ayrıntılı android.permissions.health izinlerine taşınıyor. Örneğin kalp atış hızı için READ_HEART_RATE, arka planda sağlık verisi okumak için ise READ_HEALTH_DATA_IN_BACKGROUND gibi izinler kullanılmalıdır. Mobil uygulamaların ayrıca gizlilik politikasını gösterecek bir activity tanımlaması gerekir; gerekli gerekçe sağlanmazsa izin iptal edilebilir. Bu bölüm yalnızca sağlık, fitness, giyilebilir cihaz veya sensör verisi işleyen uygulamalar için acildir. Standart e-ticaret veya kurumsal uygulamalar açısından genel bir migration engeli değildir.

5. Sabit aralıklı zamanlayıcıların kaçırılan görev davranışı değişiyor

API 36'yı hedefleyen uygulamalarda scheduleAtFixedRate ile planlanan bir görev, süreç uygun durumda değilken birden fazla çalıştırmayı kaçırırsa uygulama geri döndüğünde kaçırılan bütün görevleri arka arkaya çalıştırmaz. En fazla bir kaçırılmış görev hemen yürütülür. Bu değişiklik aşağıdaki iş akışlarını etkileyebilir:

• Belirli aralıklarla veri senkronizasyonu
• Telemetri gönderimi
• Sayaç veya zamanlayıcı tabanlı iş mantığı
• Arka planda biriken görevleri sonradan tamamlayan sistemler
• Özel scheduled executor kullanan native modüller

Finansal veya operasyonel kayıtları zamanlayıcının kaç kez çalıştığına bağlayan bir uygulama, eksik işlemleri ayrıca hesaplamalıdır. “Kaçırılan her çalıştırma geri dönünce tetiklenir” varsayımı artık güvenli değildir.

Android 16 üzerinde bütün uygulamaları etkileyebilecek değişiklikler

targetSdk değerini henüz 36 yapmamış olsanız bile uygulamayı Android 16 üzerinde test etmelisiniz. Android 16'da bütün uygulamalara uygulanan değişiklikler arasında şunlar bulunuyor:

• WorkManager ve JobScheduler görev süresi kotalarındaki değişiklikler
• Farklı süreçlerdeki broadcast önceliklerinin artık global olarak garanti edilmemesi
• ART çalışma zamanı iç yapısına bağlı kütüphanelerde uyumluluk riski
• 4 KB hizalanmış native kütüphaneler için 16 KB sayfa uyumluluk modu
• Intent yönlendirme saldırılarına karşı varsayılan güvenlik sertleştirmeleri

Google, WorkManager kullanan uygulamalarda durdurulma nedenlerinin izlenmesini ve Android 16 cihazlarda gerçek arka plan görev testleri yapılmasını öneriyor. Bu nedenle yalnızca targetSdk = 36 sonrasında yapılan test yeterli değildir. İki ayrı test yapılmalıdır:

• Mevcut target seviyesiyle Android 16 üzerinde çalışma testi
• API 36 hedeflenerek Android 16 üzerinde davranış testi

React Native projeleri nasıl hazırlanmalı?

Android 16 ve API 36 desteği React Native çekirdeğine 0.81 sürümüyle eklendi. Bu sürümde target API seviyesi 36'ya taşındı, edge-to-edge ve predictive back uyumluluğu için gerekli değişiklikler yapıldı. React Native 0.81 artık desteklenen güncel sürüm değildir; 22 Temmuz 2026 itibarıyla en yeni kararlı React Native hattı 0.86'dır. Bu nedenle eski bir React Native projesinde yalnızca aşağıdaki değeri değiştirmek doğru yaklaşım değildir:

targetSdkVersion = 36

Önce şu sorular cevaplanmalıdır:

• React Native sürümü desteklenen bir hatta mı?
• Native navigation veya özel onBackPressed() kodu var mı?
• SafeAreaView veya eski güvenli alan yaklaşımı kullanılıyor mu?
• Üçüncü taraf native modüller API 36 ile derlenebiliyor mu?
• Native .so kütüphaneleri 16 KB sayfa boyutuyla uyumlu mu?
• Uygulama New Architecture üzerinde çalışıyor mu?
• Android Gradle Plugin ve Kotlin sürümleri uyumlu mu?

React Native 0.81'de yerleşik SafeAreaView bileşeni, Android edge-to-edge ihtiyaçlarını yeterli karşılamadığı için kullanımdan kaldırılma sürecine girdi. Güncel projelerde react-native-safe-area-context gibi uyumlu bir yaklaşım kullanılmalıdır.

React Native test alanları

• Navigation stack
• Android donanım veya gesture geri hareketi
• Status bar ve navigation bar inset'leri
• Modal ve bottom sheet'ler
• Klavye açıldığında ekran yerleşimi
• Tablet ve foldable tasarımı
• Push notification ile açılan deep link'ler
• Native modüllerin derlenmesi
• Release AAB üretimi

Expo projeleri nasıl hazırlanmalı?

22 Temmuz 2026 itibarıyla Expo'nun güncel SDK dokümantasyonu Expo SDK 57'nin React Native 0.86 kullandığını gösteriyor. Expo'nun expo-build-properties eklentisi üzerinden compileSdkVersion, targetSdkVersion ve buildToolsVersion değerleri açıkça 36 olarak ayarlanabiliyor. {

"expo": {
"plugins": [

[ "expo-build-properties", {

"android": {
"compileSdkVersion": 36,
"targetSdkVersion": 36,
"buildToolsVersion": "36.0.0"

} } ] ] } } Bu yapılandırma özellikle native proje dosyalarını Expo Prebuild ile üreten projeler içindir. Eklenti, native Android klasörünü manuel yöneten bare projelerde aynı şekilde kullanılmaz. Expo projesinde kontrol edilmesi gerekenler:

• Expo SDK sürümü
• React Native sürümü
• EAS Build imajı
• expo-build-properties yapılandırması
• Config plugin'lerin API 36 desteği
• Edge-to-edge görünüm
• Expo Router geri navigasyonu
• Native modül içeren paketler
• Development build ve production build farkları
• Play Console'a gönderilecek AAB'nin gerçek target seviyesi

Yalnızca Expo Go içinde test yapmak yeterli değildir. Production imza ve native yapılandırmayla üretilmiş development veya preview build üzerinde test yapılmalıdır.

Native Android, React Native ve Expo için karşılaştırmalı geçiş tablosu

Önerilen migration sırası

1. Mevcut durumu ölçün

Aşağıdaki bilgileri kaydedin:

• minSdk
• compileSdk
• targetSdk
• Android Gradle Plugin
• Gradle
• Kotlin
• React Native veya Expo sürümü
• Kullanılan native modüller
• Play Console'daki target API uyarısı
• Mevcut production AAB'nin hedef API seviyesi

2. Ayrı bir migration branch'i açın

Target API geçişini özellik geliştirmeleriyle aynı branch'e koymayın. Aksi halde mağaza zorunluluğundan kaynaklanan hata ile ürün değişikliğinden kaynaklanan hata birbirine karışır.

3. Derleme zincirini güncelleyin

Android Studio, Android SDK 36, Build Tools ve AGP uyumluluğunu sağlayın.

4. Önce compileSdk = 36 yapın

Bu aşamada hedef davranışları değiştirmeden:

• Derleme hatalarını
• Deprecated API'leri
• Manifest birleşim sorunlarını
• Native kütüphane problemlerini
• AndroidX uyumsuzluklarını

çözün.

5. Android 16 üzerinde mevcut target seviyesiyle test edin

Böylece bütün uygulamaları etkileyen Android 16 değişikliklerini izole edebilirsiniz.

6. targetSdk = 36 yapın

Bu aşamada edge-to-edge, predictive back ve büyük ekran değişiklikleri devreye girer.

7. Davranışları tek tek test edin

Google'ın App Compatibility Framework aracı, hedef seviyeyi değiştirmeden belirli davranış değişikliklerini ayrı ayrı etkinleştirip test etmeye yardımcı olur. Android 16 geliştirici sayfası, değişikliklerin çalışma zamanında açılıp kapatılarak izole edilmesini öneriyor.

8. Cihaz matrisi oluşturun

En az şu ortamlar test edilmelidir:

• Android 14 telefon
• Android 15 telefon
• Android 16 telefon
• Android 16 küçük ekran emulator
• Android 16 tablet veya sw600dp emulator
• Landscape ve portrait
• Gesture navigation
• Üç düğmeli navigasyon
• Düşük bellekli cihaz profili

9. Production AAB üretin

Debug APK'nın başarılı olması, Play Console gönderiminin başarılı olacağını göstermez. Release imzalı AAB üzerinde:

• R8/ProGuard
• Native symbol
• Manifest
• Split APK
• Target API
• 16 KB native kütüphane uyumluluğu

kontrol edilmelidir.

10. Kademeli yayın yapın

Yeni target seviyesi doğrudan yüzde 100 dağıtıma açılmamalıdır. Önce internal veya closed testing, ardından küçük oranlı staged rollout kullanılmalıdır.

Önerilen test matrisi

Aşağıdaki matris InoviqLab'ın teknik önerisidir:

Bu matris, bir hata bulunduğunda sorunun Android 16 platformundan mı yoksa target API değişikliğinden mi kaynaklandığını ayırmayı kolaylaştırır.

Kontrol listesi

Proje ve derleme

• Mevcut targetSdk doğrulandı mı?
• compileSdk 36 yapıldı mı?
• targetSdk 36 yapıldı mı?
• Android SDK Platform 36 kuruldu mu?
• Build Tools 36.x.x kuruldu mu?
• AGP ve Gradle sürümleri uyumlu mu?
• Release AAB üretilebiliyor mu?
• Play Console, paketi API 36 olarak görüyor mu?

Kullanıcı arayüzü

• Edge-to-edge bütün ana ekranlarda test edildi mi?
• Status bar ve navigation bar inset'leri doğru mu?
• Klavye açıldığında formlar kullanılabiliyor mu?
• Modal ve bottom sheet'ler sistem alanlarıyla çakışıyor mu?
• Tablet ve katlanabilir ekranlarda tasarım bozuluyor mu?
• Ekran döndüğünde kullanıcı durumu korunuyor mu?

Navigasyon

• Predictive back test edildi mi?
• onBackPressed() kullanan kodlar temizlendi mi?
• WebView geri geçmişi doğru çalışıyor mu?
• Deep link ile açılan ekranlardan dönüş doğru mu?
• Form verisi geri hareketinde yanlışlıkla kayboluyor mu?

İzin ve arka plan işlemleri

• Sağlık veya sensör izinleri kullanılıyor mu?
• WorkManager görevleri Android 16 üzerinde test edildi mi?
• Zamanlayıcılar kaçırılan çalıştırma varsayımına dayanıyor mu?
• Push notification ve background sync doğrulandı mı?
• Native kütüphaneler 16 KB sayfa boyutuyla uyumlu mu?

Yayın

• Internal testing tamamlandı mı?
• Closed testing tamamlandı mı?
• Crash ve ANR takibi hazır mı?
• Kademeli dağıtım oranı belirlendi mi?
• Geri alma planı var mı?
• Uzatma formunun gerekip gerekmediği belirlendi mi?

Hangi projelerde geçiş acildir?

Acil

• 31 Ağustos 2026'dan sonra güncelleme göndermesi gereken uygulamalar
• Sık güncellenen SaaS ve e-ticaret uygulamaları
• Ödeme veya rezervasyon akışı bulunan uygulamalar
• React Native 0.80 veya daha eski sürüm kullanan projeler
• Yıllardır framework güncellemesi almamış uygulamalar
• Çok sayıda native modül kullanan projeler
• Yalnızca portrait ekran için tasarlanmış uygulamalar
• Tabletlerde kullanılan operasyon uygulamaları
• Sağlık ve fitness uygulamaları

Planlanabilir

• API 36'yı zaten hedefleyen ve Android 16 testleri tamamlanmış projeler
• Yalnızca küçük içerik güncellemeleri alan, güncel bağımlılıklı uygulamalar
• Güncel Expo SDK veya React Native sürümü kullanan basit uygulamalar

Politika açısından istisna kapsamında olabilecekler

Belirli bir kuruluşun kullanıcılarıyla sınırlandırılmış ve yalnızca kurum içi dağıtılan kalıcı özel uygulamalar target API zorunluluğunun istisnaları arasında yer alabilir. İstisna, herkese açık standart Google Play uygulamaları için geçerli değildir.

Performans, güvenlik ve maliyet etkisi

Performans etkisi

API 36'ya geçmenin tek başına garantili bir performans kazancı yoktur. Android 16'nın çalışma zamanı ve görev planlama iyileştirmeleri bulunmakla birlikte, uygulamanın gerçek etkisi kullanılan kütüphanelere ve arka plan iş modeline göre değişir.

Güvenlik etkisi

Yeni target seviyesi, güncel platform güvenlik davranışlarını devreye alır. Intent işleme, sağlık izinleri ve veri parmak izi oluşturmayı zorlaştıran MediaStore değişiklikleri buna örnektir. Ancak targetSdk değerini yükseltmek, uygulama kodundaki güvenlik açıklarını otomatik olarak düzeltmez.

Maliyet etkisi

Doğrudan lisans maliyeti yoktur. Maliyet şuralardan oluşur:

• Framework ve bağımlılık yükseltmesi
• Native modül uyumluluğu
• Edge-to-edge arayüz düzeltmeleri
• Navigasyon migration'ı
• Tablet ve katlanabilir ekran testleri
• QA cihaz matrisi
• Play Console test ve yayın süreci

Basit ve güncel bir native Android uygulamasında geçiş sınırlı olabilir. Eski React Native, Expo veya Cordova projelerinde ise target API değişikliği, framework migration projesine dönüşebilir.

InoviqLab teknik değerlendirmesi

Bu bölüm InoviqLab'ın yorumudur; resmî Google dokümantasyonundaki doğrulanmış bilgilerden ayrıdır. Target API geçişlerinde en büyük hata, işin büyüklüğünü build.gradle dosyasındaki iki satıra bakarak tahmin etmek. Gerçek maliyeti target API seviyesi değil, uygulamanın son sistematik bakım tarihinden bu yana biriken teknik borç belirler. Altı ay önce güncellenmiş bir uygulamada API 36 geçişi olağan bakım olabilir. Üç yıldır framework yükseltmesi yapılmamış bir React Native projesinde ise aynı işlem; Gradle, Kotlin, React Native, navigation, native modüller ve kullanıcı arayüzünü kapsayan çok katmanlı bir migration'a dönüşür. İkinci kritik konu test sırasıdır. Uygulamayı doğrudan API 36'ya geçirip yalnızca Android 16 emulator üzerinde test etmek, hata kaynağını belirsiz hale getirir. Önce Android 16 ile mevcut target seviyesi, ardından Android 16 ile API 36 test edilmelidir. Bu iki aşama arasında ortaya çıkan fark, hedef API değişikliğinin gerçek etkisidir. Üçüncü konu büyük ekranlardır. Android 16'daki yön ve yeniden boyutlandırma değişikliği ilk bakışta yalnızca tablet uygulamalarını ilgilendiriyor gibi görünür. Ancak Google Play'deki standart telefon uygulamaları tablet, katlanabilir cihaz, Chromebook ve masaüstü pencere modunda da çalışabilir. “Bizim tablet uygulamamız yok” cümlesi artık büyük ekran testini atlamak için yeterli değildir. Son olarak, uzatma seçeneği geliştirme takviminde normal son tarih gibi kullanılmamalıdır. 1 Kasım uzatması test süresi kazandırabilir; ancak ürün ekibinin 31 Ağustos'a kadar hazır olmamasını varsayan ana plan haline gelirse, bir sonraki yıllık target API döngüsünde aynı teknik borç tekrar oluşur.

Sonuç

31 Ağustos 2026 Google Play target API zorunluluğu, standart Android uygulamalarında API 36'ya geçişi gerektiriyor. Fakat başarılı bir migration'ın ölçütü yalnızca Play Console'un paketi kabul etmesi değildir. Başarılı geçiş şu dört sonucu birlikte sağlamalıdır:

• Uygulama API 36 ile derlenmeli ve gönderilebilmelidir.
• Edge-to-edge ve predictive back davranışları doğru çalışmalıdır.
• Tablet ve katlanabilir cihazlarda arayüz kullanılabilir kalmalıdır.
• Production AAB, gerçek cihaz ve kademeli dağıtım testlerinden geçmelidir.

İlk adım targetSdk değerini değiştirmek değil, mevcut mobil teknoloji envanterini çıkarmaktır. Framework, native modül, derleme zinciri ve cihaz test kapsamı bilinmeden 31 Ağustos için güvenilir bir teslim tarihi verilemez.