Google Play İzin Politikası 2027: Rehber, Konum, SMS Geçişi

Google Play izin politikası 2027'ye doğru köklü bir revizyondan geçiyor: rehber erişimi geniş izinden picker tabanlı modele kayıyor, hassas konum için "location button" minimum kapsam öneriliyor, telefon doğrulamada çağrı kaydı izni devre dışı kalıyor. Bu geçişin takvimini, kod seviyesinde ne değiştiğini ve Play Console'da neyi kontrol etmen gerektiğini aşağıda tek yerde bulacaksın.

💡 Pro Tip: Değişikliklerin çoğu 27 Ocak 2027'de yürürlüğe giriyor ama Play Console'daki ön-inceleme uyarıları 27 Ekim 2026'dan itibaren görünmeye başlıyor — kodu Ekim'e kadar hazırlamak, enforcement gününde sürpriz red almanı engeller.

İçindekiler

• 2026-2027 uyum takvimi tek tabloda
• 30 Eylül 2026 iki ayrı katman getiriyor
• 27 Ocak 2027'de yürürlüğe giren dört madde
• Neden bu takvimi şimdi öğrenmelisin
• Rehber erişimi: geniş izinden picker'a geçiş
• Aşamalı izin isteme neden hâlâ merkezde
• Konum kapsamının daraltılması
• Location button ile mevcut runtime akışının farkı
• Telefon doğrulamada çağrı kaydı yerine alternatifler
• Arka plan konumu ve foreground service gerekçeleri
• Reddedilme senaryoları ve itiraz süreci
• Uyum kontrol listesi
• SSS
• Play Console kayıt son tarihi ne zaman?
• Hangi izinler 2027'de daraltılıyor?
• Geniş izin yerine hangi picker API'leri kullanılmalı?
• Declaration formunu doldurmazsam ne olur?
• Pre-review uyarıları ne zaman başlıyor?
• Bu değişiklikler Android Geliştirici Doğrulaması ile aynı şey mi?
• Sonuç
• Kaynaklar

2026-2027 uyum takvimi tek tabloda

Google, Android geliştirici doğrulaması ile izin politikası değişikliklerini aynı dönemde yürütüyor; ikisini karıştırmamak önemli çünkü kapsamları ve tarihleri farklı.

30 Eylül 2026 iki ayrı katman getiriyor

Geliştirici doğrulaması genel kaydı Mart 2026'da tüm geliştiricilere açıldı. 30 Eylül 2026 ise iki ayrı şeyi aynı anda getiriyor ve bunları karıştırmak pahalıya patlıyor.

Birinci katman küresel: Play Console kaydı. Play'de dağıttığın uygulamaları Play Console'da kayıtlı tutmak zorundasın ve bu kuralın coğrafi sınırı yok. Politika sayfasındaki 30 Eylül 2026 tarihli "Play Console Requirements" satırı birebir şöyle diyor: "To meet Android developer verification requirements and Play Console requirements, you must register your Play apps in Play Console." Aynı satır, uygulamaların %99'unun Play'de otomatik olarak kaydedildiğini, kalanları için Play Console Home sayfasını kontrol edip kaydı elle tamamlaman gerektiğini, aksi halde "global removal from Google Play" riskinin doğduğunu söylüyor. Yani Türkiye'de olman seni bu tarihten muaf tutmuyor.

İkinci katman bölgesel: dört ülkede cihaz-tarafı yeni-kurulum engeli. Aynı tarihte Brezilya, Endonezya, Singapur ve Tayland'da sertifikalı Android cihazlarda kayıtsız geliştiricilerin uygulamaları normal kurulum akışıyla yüklenemiyor; adb üzerinden kurulum bu gereksinimden bağımsız kalıyor, kayıtsız uygulamalar için ayrı bir "advanced flow" sideload yolu bulunuyor. Cihaz-tarafı korumanın küresel genişlemesi 2027'ye planlı. Bu katmanın ayrıntılarını geliştirici doğrulaması ve sideload yazımızda tek tek ele aldık.

27 Ocak 2027'de yürürlüğe giren dört madde

İzin politikası tarafında dört değişiklik 27 Ocak 2027'de aynı anda yürürlüğe giriyor:

Play Console'da pre-review kontrolleri 27 Ekim 2026'dan itibaren devreye giriyor; duyurunun ifadesiyle bu kontroller "potential contacts or location permissions policy issues" işaretliyor — yani kapsam rehber ve konum izinleriyle sınırlı, SMS/çağrı kaydı ile foreground service maddeleri pre-review kapsamında değil. Yine de enforcement tarihinden üç ay önce, rehber ve konum akışların için gönderim sırasında uyarı görmeye başlayacaksın.

Neden bu takvimi şimdi öğrenmelisin

Dört değişikliğin hepsi aynı gün (27 Ocak 2027) yürürlüğe girse de, kod tarafındaki iş üç ayrı ekibi (rehber, konum, kimlik doğrulama) ilgilendiriyor ve her biri kendi test döngüsünü gerektiriyor. Declaration formunun Ekim 2026'dan önce açılması, Google'ın bu geçişi tek seferlik bir "flag kapat" değil, gözden geçirme gerektiren bir süreç olarak kurguladığını gösteriyor — form üzerinden sunduğun gerekçe incelemeye tabi tutuluyor, bu da başvuru-inceleme-onay döngüsünün zaman alabileceği anlamına geliyor. Pre-review uyarılarının enforcement'tan üç ay önce başlaması da aynı mantığın parçası: Google, geliştiricilere kodu düzeltmeleri için görünür bir erken-uyarı penceresi tanıyor.

Rehber erişimi: geniş izinden picker'a geçiş

Mevcut politika zaten izinleri bağlam içinde ve aşamalı istemeni, verinin ilk toplandığı amacın dışında kullanmak için kullanıcıdan yeniden onay almanı şart koşuyor. 27 Ocak 2027'de buna eklenen katman şu: Android 17 ve üzerini hedefleyen uygulamalarda, uygulamanın rehberdeki tüm kişilere sürekli erişim ihtiyacı Android Contact Picker yetersiz kaldığında gerekçelendirilmek zorunda — bu gerekçe Play Console'daki Play Developer Declaration formu ile sunuluyor.

Contact Picker'da kullanıcı hangi kişiyi paylaşacağına kendisi karar veriyor; geliştirici yalnızca ihtiyaç duyduğu alanları (telefon, e-posta vb.) belirtiyor, READ_CONTACTS izni hiç istenmiyor. Dokümantasyon bu entegrasyonu ContactsPickerSessionContract.ACTION_PICK_CONTACTS intent'i üzerinden tarif ediyor; istenen alanlar EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS extra'sına ContactsContract.CommonDataKinds MIME tiplerinden oluşan bir ArrayList<String> olarak veriliyor. Rehber verisi tek yol değil: Play'in kısıtlı izinler politikası "System pickers and alternatives like Sharesheet are designed to support a privacy-oriented path for developers" diyerek Sharesheet'i de gizlilik odaklı alternatifler arasında sayıyor.

Kod öncesi — geniş izinle rehber listesi çekme:

1// Android 17 öncesi yaygın desen: tüm rehbere erişim isteniyor
2if (ContextCompat.checkSelfPermission(
3        context, Manifest.permission.READ_CONTACTS
4    ) != PackageManager.PERMISSION_GRANTED
5) {
6    ActivityCompat.requestPermissions(
7        activity, arrayOf(Manifest.permission.READ_CONTACTS), REQUEST_CODE
8    )
9}
10// İzin verilirse ContentResolver ile tüm rehber sorgulanır

Kod sonrası — Contact Picker ile alan-bazlı seçim (Android 17 / API 37):

1// ContactPickerActivity.kt
2import android.app.Activity
3import android.content.Intent
4import android.net.Uri
5import android.os.Bundle
6import android.provider.ContactsContract
7import android.provider.ContactsContract.CommonDataKinds.Email
8import android.provider.ContactsContract.CommonDataKinds.Phone
9import android.provider.ContactsPickerSessionContract.ACTION_PICK_CONTACTS
10import android.provider.ContactsPickerSessionContract.EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS
11import android.util.Log
12import androidx.activity.ComponentActivity
13import androidx.activity.result.contract.ActivityResultContracts.StartActivityForResult
14 
15class ContactPickerActivity : ComponentActivity() {
16 
17    // Picker tek bir Session Uri döndürür; kişi başına ayrı Uri sorgusu gerekmez.
18    private val pickContacts =
19        registerForActivityResult(StartActivityForResult()) { result ->
20            if (result.resultCode != Activity.RESULT_OK) return@registerForActivityResult
21            val sessionUri: Uri = result.data?.data ?: return@registerForActivityResult
22            readSelectedContacts(sessionUri)
23        }
24 
25    override fun onCreate(savedInstanceState: Bundle?) {
26        super.onCreate(savedInstanceState)
27        // READ_CONTACTS izni hiç istenmiyor; yalnız ihtiyaç duyulan alanlar bildiriliyor.
28        val requestedFields = arrayListOf(
29            Phone.CONTENT_ITEM_TYPE,
30            Email.CONTENT_ITEM_TYPE
31        )
32        val pickIntent = Intent(ACTION_PICK_CONTACTS).apply {
33            putStringArrayListExtra(
34                EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS,
35                requestedFields
36            )
37        }
38        pickContacts.launch(pickIntent)
39    }
40 
41    private fun readSelectedContacts(sessionUri: Uri) {
42        val projection = arrayOf(
43            ContactsContract.Contacts.DISPLAY_NAME_PRIMARY,
44            ContactsContract.Data.MIMETYPE,
45            ContactsContract.Data.DATA1
46        )
47        // Session Uri özel selection/selectionArgs desteklemez; doğrudan sorgulanır.
48        contentResolver.query(sessionUri, projection, null, null, null)?.use { cursor ->
49            val nameIdx = cursor.getColumnIndex(ContactsContract.Contacts.DISPLAY_NAME_PRIMARY)
50            val mimeIdx = cursor.getColumnIndex(ContactsContract.Data.MIMETYPE)
51            val dataIdx = cursor.getColumnIndex(ContactsContract.Data.DATA1)
52            while (cursor.moveToNext()) {
53                val name = cursor.getString(nameIdx).orEmpty()
54                val mimeType = cursor.getString(mimeIdx).orEmpty()
55                val value = cursor.getString(dataIdx).orEmpty()
56                // value yalnızca kullanıcının paylaşmayı seçtiği alanı içerir
57                when (mimeType) {
58                    Phone.CONTENT_ITEM_TYPE -> Log.d("picker", "$name phone: $value")
59                    Email.CONTENT_ITEM_TYPE -> Log.d("picker", "$name email: $value")
60                    else -> Unit
61                }
62            }
63        }
64    }
65}

Uygulamanın gerçekten sürekli, geniş rehber erişimine ihtiyacı varsa (örneğin bir yedekleme veya CRM uygulamasıysa), bu ihtiyacı Play Developer Declaration formunda gerekçelendirmen gerekiyor; form Ekim 2026'dan önce Play Console'da kullanıma açılıyor.

Aşamalı izin isteme neden hâlâ merkezde

Mevcut politika, izinleri kullanıcıya "neden istediğini" bağlam içinde gösterecek şekilde, aşamalı olarak istemeni bekliyor — yani uygulama açılır açılmaz tüm izinleri art arda sormak yerine, kullanıcı o izni gerektiren özelliğe dokunduğunda isteği tetiklemek gerekiyor. Contact Picker'a geçiş bu felsefeyle örtüşüyor: kullanıcı "kişi paylaş" butonuna bastığında picker açılıyor, izin isteği diye ayrı bir adım bile kalmıyor. Eğer uygulaman rehber verisini topladıktan sonra farklı bir amaç için (örneğin pazarlama analizi) kullanmak isterse, bunun için kullanıcıdan ayrıca ve açıkça onay alman gerektiğini unutma — bu kural yeni değil, mevcut politikanın bir parçası ve Contact Picker'a geçiş bu yükümlülüğü ortadan kaldırmıyor.

Konum kapsamının daraltılması

Konum tarafında da aynı mantık işliyor: geniş, sürekli izin yerine dar kapsamlı, bağlama özel erişim. Google, hassas konum için location button'ı önerilen minimum kapsam olarak tanımlıyor. Dokümandaki tanım birebir şu: "a customizable system UI element designed to simplify how you request session-scoped precise location access" — yani kullanıcı düğmeye bastığında uygulama oturum kapsamlı (session-scoped) hassas konum alıyor, sürekli arka plan erişimi gerekmiyor.

Manifest tarafında üç satır birden gerekiyor; onlyForLocationButton bayrağı bunlardan yalnızca biri ve dokümanda "Optional" olarak işaretli. Düğmenin ekrana çizilebilmesi için gereken USE_LOCATION_BUTTON ise "CRITICAL: Required system permission for rendering the LocationButton" notuyla veriliyor:

1<!-- AndroidManifest.xml -->
2<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
3 
4<!-- Optional: yalnızca location button ile hassas konum alıyorsan -->
5<uses-permission
6    android:name="android.permission.ACCESS_FINE_LOCATION"
7    android:usesPermissionFlags="onlyForLocationButton" />
8 
9<!-- CRITICAL: LocationButton'ın render edilebilmesi için zorunlu -->
10<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

Düğmenin kendisini elle çizmiyorsun: doküman entegrasyonu androidx.core.locationbutton Jetpack kütüphanesi üzerinden tarif ediyor ve bu kütüphanenin deneysel (experimental) olduğunu, değişebileceğini açıkça yazıyor. Yani bir test build'inde denerken API yüzeyinin sürüm atlarında kayabileceğini hesaba kat.

Uygulamanın gerçekten sürekli veya arka planda hassas konuma ihtiyacı varsa — örneğin bir navigasyon veya filo takip uygulamasıysa — bunu da Play Developer Declaration formunda gerekçelendirmen gerekiyor; aksi halde onlyForLocationButton yeterli görülmeyen kapsam olarak işaretlenebilir. Android 11'den beri var olan "Only this time" (yalnızca bu sefer) seçeneği de aynı felsefenin runtime karşılığı: kullanıcı konumu tek seferlik verir, erişim uygulama arka plana geçtikten kısa bir süre sonra sona erer; activity görünürken bir foreground service başlattıysan, uygulama arka plana geçtikten sonra da erişim o servis durana kadar sürer; kullanıcı ayarlardan iptal ederse erişim derhal kesilir ve uygulama süreci sonlandırılır.

Location button ile mevcut runtime akışının farkı

Bugüne kadar hassas konum isteme akışın muhtemelen ACCESS_FINE_LOCATION iznini doğrudan requestPermissions() ile istemek şeklindeydi; kullanıcı "Only this time", "While using the app" veya "Deny" arasında seçim yapıyordu. Location button bu akışı tersine çeviriyor: erişim, kullanıcının uygulama arayüzündeki sistem düğmesine tıklamasıyla, doğrudan kullanıcı eylemiyle başlatılıyor ve oturum kapsamıyla sınırlı kalıyor. Dokümanın ifadesiyle bu yaklaşım, "only this time" tipi geçici izinlerde tipik olarak karşılaşılan tekrarlayan izin diyaloglarının sürtünmesini azaltıyor. Bu, hem kullanıcı deneyimini kısaltıyor hem de Google'ın "yalnızca gerektiği anda, gerektiği kadar" ilkesini kod seviyesinde zorunlu kılıyor. Sürekli arka plan takibi gerçekten gerekiyorsa (teslimat, filo yönetimi gibi), bu istisnai ihtiyacı ayrıca gerekçelendirmen bekleniyor.

Telefon doğrulamada çağrı kaydı yerine alternatifler

SMS ve Çağrı Kaydı (Call Log) izinlerine dair politika hâlihazırda katı: bu izinleri istemeden önce uygulamanın SMS, Telefon veya Asistan için aktif olarak varsayılan (default) handler olarak kayıtlı olması şart. 27 Ocak 2027'den itibaren buna yeni bir kısıtlama ekleniyor — READ_CALL_LOG izni artık telefon araması üzerinden hesap doğrulama amacıyla kullanılamayacak.

Google bu kullanım senaryosu için iki alternatif gösteriyor: Digital Credentials API ve SMS Retriever API. SMS Retriever API, kullanıcıdan SMS okuma izni istemeden, gelen doğrulama SMS'ini otomatik yakalayıp koddan okumanı sağlıyor:

1val client = SmsRetriever.getClient(context)
2client.startSmsRetriever().addOnSuccessListener {
3    // SMS izni istenmeden, retriever broadcast'ini dinlemeye başla
4}
5 
6val smsVerifyReceiver = object : BroadcastReceiver() {
7    override fun onReceive(context: Context, intent: Intent) {
8        if (SmsRetriever.SMS_RETRIEVED_ACTION == intent.action) {
9            val extras = intent.extras
10            val status = extras?.get(SmsRetriever.EXTRA_STATUS) as? Status
11            if (status?.statusCode == CommonStatusCodes.SUCCESS) {
12                val message = extras.getString(SmsRetriever.EXTRA_SMS_MESSAGE)
13                // Mesajdan doğrulama kodunu ayıkla
14            }
15        }
16    }
17}

Kısıtlı bir izin (ör. Call Log) kullanıcı tarafından reddedildiğinde, mevcut politika uygulamanın makul bir alternatif sunmasını da şart koşuyor — örneğin kullanıcının telefon numarasını elle girebilmesi gibi. Bu gereklilik 2027 değişikliğiyle değil, hâlihazırdaki politika ile geçerli; yeni kural yalnızca "çağrı kaydı = doğrulama yöntemi" eşleşmesini kapatıyor.

Arka plan konumu ve foreground service gerekçeleri

Foreground service kullanımı için politika, servisi başlatma gerekçesinin kullanıcıya görünür ve tutarlı olmasını istiyor. 27 Ocak 2027'den itibaren geofencing artık foreground service için onaylı bir kullanım senaryosu değil — yani "kullanıcı belirli bir bölgeye girdiğinde/çıktığında bildirim göster" gibi bir akışı foreground service üzerinden değil, platformun kendi Geofence API'si üzerinden kurman gerekiyor.

Bunun pratik anlamı şu: eğer uygulaman şu an bir foreground service içinde konum dinleyip kendi geofence mantığını (koordinat karşılaştırma, mesafe hesabı) elle yazıyorsa, bu yaklaşım 2027'den sonra reddedilme riski taşıyor. Geofence API, aynı işlevi sistem seviyesinde, pil dostu ve foreground service gerektirmeden sağlıyor — geçiş, hem politika uyumu hem de pil tüketimi açısından kazançlı.

Reddedilme senaryoları ve itiraz süreci

Politika koşullarını karşılamayan veya gerekli Declaration formunu sunmayan uygulamalar Google Play'den kaldırılabiliyor. Bu, tek seferlik bir red değil — mevcut politika metni bunu net biçimde söylüyor: "Apps that fail to meet policy requirements or lack a Permissions Declaration Form may be removed from Google Play."

Kendini bu riskten korumak için üç noktaya dikkat et:

• Declaration formunu erken doldur. Form Ekim 2026'dan önce Play Console'da açılıyor; enforcement tarihini (27 Ocak 2027) beklemeden, ihtiyacını gerekçelendiren başvuruyu erken göndermek red riskini azaltır.
• Runtime rationale'ı eksiksiz göster. Kısıtlı izin isteklerinde (READ_CALENDAR gibi örnekler dahil) açık bir gerekçe sunman ve kullanıcıyı manipüle etmemen gerekiyor; shouldShowRequestPermissionRationale() akışını atlamak politika ihlali sayılabilir.
• Alternatif akışı unutma. Kullanıcı izni reddettiğinde uygulaman çökmemeli veya işlevsiz kalmamalı — manuel giriş gibi makul bir düşüş (fallback) senaryosu sunman bekleniyor.

Red aldığında Play Console'daki politika ihlali bildirimi genellikle hangi maddenin tetiklendiğini belirtir; itiraz etmeden önce Play Console bildirimlerini ve e-postanı, hangi politikanın ihlal edildiğini öğrenmek için kontrol et; ardından "File an appeal" formuyla itirazını gönder (her kaldırma, askıya alma veya yaptırım için tek bir itiraz hakkın var) ve Declaration formunda belirttiğin gerekçeyle tutarlı bir açıklama sun.

Uyum kontrol listesi

Yukarıdaki dört politika maddesini tek tek ele almak yerine, Ekim-Ocak penceresini tek bir sıralı akış olarak yönetmek daha az hataya yol açıyor. Aşağıdaki liste, önce mevcut durumu doğrulamayı, sonra kod değişikliklerini, en son da Play Console süreçlerini kapatmayı öneriyor — sıralama önemli çünkü Declaration formunu doldurmadan önce hangi akışların gerçekten gerekçe gerektirdiğini kod tarafında netleştirmiş olman gerekiyor.

Ekim-Ocak arasındaki hazırlık penceresinde sırayla kontrol etmen gerekenler:

SSS

Play Console kayıt son tarihi ne zaman?

30 Eylül 2026, Play Console kaydı için küresel son tarih: Play'de dağıttığın uygulamaları Play Console'da kayıtlı tutman gerekiyor, aksi halde politika sayfasının ifadesiyle "global removal from Google Play" riski doğuyor. Play, uygulamaların %99'unun otomatik kaydedildiğini söylüyor; kalan istisnaya girip girmediğini Play Console Home sayfasından doğrula. Aynı tarihte ikinci ve ayrı bir katman daha başlıyor: Brezilya, Endonezya, Singapur ve Tayland'da sertifikalı cihazlarda kayıtsız geliştiricilerin uygulamaları normal kurulum akışıyla yüklenemiyor; adb üzerinden kurulum bu gereksinimden bağımsız kalıyor, kayıtsız uygulamalar için ayrı bir "advanced flow" sideload yolu açık kalıyor. Cihaz-tarafı korumanın küresel genişlemesi 2027'ye planlı.

Hangi izinler 2027'de daraltılıyor?

27 Ocak 2027'de dört değişiklik birlikte yürürlüğe giriyor: Android 17+ hedefleyen uygulamalarda geniş READ_CONTACTS yerine Contact Picker zorunluluğu, hassas konum için location button'ın (onlyForLocationButton) önerilen minimum kapsam olması, READ_CALL_LOG ile telefon doğrulamanın kaldırılması ve foreground service'te geofencing'in onaylı kullanım senaryosu olmaktan çıkması.

Geniş izin yerine hangi picker API'leri kullanılmalı?

Rehber verisi için Android'in yerleşik Contact Picker'ı (ContactsPickerSessionContract.ACTION_PICK_CONTACTS) ya da Sharesheet gibi gizlilik odaklı alternatifler, hassas konum için USE_LOCATION_BUTTON ile render edilen ve onlyForLocationButton bayrağıyla kapsamı daraltılan location button, telefon doğrulama için ise Digital Credentials API veya SMS Retriever API kullanılmalı.

Declaration formunu doldurmazsam ne olur?

Politika gereksinimlerini karşılamayan veya gerekli Permissions Declaration Formu bulunmayan uygulamalar Google Play'den kaldırılabiliyor. Geniş rehber erişimi veya sürekli hassas konum gibi ihtiyaçların varsa, bu formu doldurup gerekçeni sunmadan enforcement tarihine girmemelisin.

Pre-review uyarıları ne zaman başlıyor?

Play Console'daki pre-review kontrolleri 27 Ekim 2026'dan itibaren devreye giriyor — yani 27 Ocak 2027 enforcement tarihinden üç ay önce. Duyuru bu kontrollerin kapsamını "potential contacts or location permissions policy issues" olarak tanımlıyor; yani uyarılar rehber ve konum izinleri için geliyor, SMS/çağrı kaydı ve foreground service maddeleri pre-review kapsamında değil.

Bu değişiklikler Android Geliştirici Doğrulaması ile aynı şey mi?

Hayır. Android Geliştirici Doğrulaması, uygulamaları imzalayan geliştiricinin kimliğini doğrulamakla ilgili; 30 Eylül 2026'da hem küresel Play Console kayıt zorunluluğu hem de dört ülkedeki cihaz-tarafı kurulum kısıtı olarak devreye giriyor. Bu makaledeki izin politikası değişiklikleri (rehber, konum, SMS/çağrı kaydı, foreground service) ise ayrı bir politika seti ve 27 Ocak 2027'de yürürlüğe giriyor.

Sonuç

2027'ye geçiş tek bir büyük değişiklik değil, dört ayrı politika maddesinin aynı tarihte (27 Ocak 2027) birleşmesi. Kod tarafında en büyük iş rehber erişimini Contact Picker'a taşımak ve telefon doğrulamasını SMS Retriever veya Digital Credentials API'ye geçirmek; süreç tarafında en kritik adım ise Declaration formunu enforcement'tan aylar önce doldurmak. Android 17 (API 37) uygulamanı kıracak diğer değişiklikler için rehberimize göz atabilir, Google Play API 36 son tarihini kaçıranlar için hazırladığımız yazıyı okuyabilirsin. Geliştirici doğrulamasının sideload'a etkisini merak ediyorsan ayrı bir yazıda bunu detaylı ele aldık; Android 15 döneminin Privacy Sandbox ve foreground service değişiklikleri için ise önceki rehberimiz hâlâ güncel bir zemin sunuyor. Abonelik tarafında izin politikasından bağımsız ama aynı dönemde geçerli bir başka konu için Google Play Billing v7 rehberimize bakabilirsin.

Kaynaklar

• Google Play Console Yardım — Politika Güncellemeleri — 2027-01-27 tarihli contacts, location ve SMS/call log/foreground service değişikliklerinin resmi listesi.
• Google Play Console Yardım — Contacts Permissions Politikası — Contact Picker zorunluluğu ve bağlam içi izin isteme kuralları.
• Google Play Console Yardım — SMS ve Çağrı Kaydı İzinleri Politikası — READ_CALL_LOG ile doğrulamanın kaldırılması ve default handler şartı.
• Google Play Console Yardım — Kısıtlı İzinler Genel Politikası — runtime rationale ve alternatif akış gereklilikleri.
• Android Developers Blog — Giving Users a Clearer Choice — Contact Picker, location button ve Declaration formu duyurusu.
• Android Developers — Runtime İzin İsteme Rehberi — checkSelfPermission / shouldShowRequestPermissionRationale akışı ve "Only this time" davranışı.
• Android 17 — Contact picker — ACTION_PICK_CONTACTS, istenen alan MIME tipleri ve Session URI'nin sorgulanması.
• Android Developers — Location button — session-scoped tanımı, USE_LOCATION_BUTTON zorunluluğu ve deneysel Jetpack kütüphanesi.
• Play Console Yardım — Uygulamam Google Play'den kaldırıldı — ihlal bildirimi, 'File an appeal' formu ve yaptırım başına tek itiraz kuralı.