Google Play Politika Uyumu: Data Safety, İzinler ve Red

Google Play'de bir güncelleme gönderip "Rejected" e-postası aldığında saat genelde geriye işlemeye başlar: hangi politika, hangi ekran, hangi form alanı. Bu rehber Data Safety formunu alan alan doğru doldurmayı, hassas izin beyanlarını, hesap/veri silme zorunluluğunu ve abonelik şeffaflığı kurallarını Google'ın resmi Play Console Help sayfalarındaki birebir ifadelerle anlatıyor; amaç bir sonraki gönderiminde aynı ihlali tekrarlamaman.

💡 Pro Tip: Data Safety formunu her sürüm göndermeden önce değil, veri toplama davranışını değiştiren her değişiklikte (yeni SDK, yeni izin, yeni analytics eklentisi) güncelle — form ile gerçek davranış arasındaki uyumsuzluk, tek başına red nedenidir.

İçindekiler

• Play Politika Ekosistemi: Nereden Başlamalı
• Data Safety Formu: Alan Alan Doğru Doldurma
• Hassas İzinler ve Restricted Permissions Beyanı
• Hesap ve Veri Silme Zorunluluğu
• Abonelik ve Faturalandırma Politikaları
• Sık Görülen İhlal Örnekleri ve Düzeltmeleri
• Reddedilen Uygulamayı Yeniden Gönderme (Resubmit) Süreci
• Yayın Öncesi Uyum Kontrol Listesi
• SSS
• Data Safety formu nasıl doğru doldurulur?
• Google Play'de uygulamam neden reddedildi?
• Hassas izin (SMS, konum, erişilebilirlik) beyanı nasıl yapılır?
• Hesap silme zorunluluğu kimleri kapsıyor?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Play Politika Ekosistemi: Nereden Başlamalı

Google Play politikaları tek bir doküman değil, birbirine bağlı birkaç katmandan oluşur: Developer Program Policies (genel çerçeve), Data Safety gereksinimleri, Permissions politikası, User Data politikası ve kategori-özel kurallar (finans, sağlık, çocuklar). Bir uygulama genellikle birden fazla katmana aynı anda tabidir; örneğin hassas izin isteyen bir uygulama hem Permissions politikasına hem User Data politikasına hem de Data Safety formuna uymak zorundadır.

Geliştiriciler için pratik sonuç şu: politika ihlali genellikle tek bir kuralın değil, iki katman arasındaki tutarsızlığın sonucudur. Store listing sayfasında beyan ettiğin özellik ile uygulamanın gerçekte istediği izin örtüşmüyorsa, Data Safety formunda "toplamıyorum" dediğin bir veri türünü bir SDK arka planda gönderiyorsa, red gelir.

Bu tutarsızlığı gönderim öncesi yakalamanın en ucuz yolu, bağımlılık listeni elle gözden geçirmek yerine komut satırından çıkarmaktır. Aşağıdaki komut, projendeki tüm transitive bağımlılıkları listeler; her satırı SDK'nın kendi gizlilik dokümantasyonuyla eşleştirip Data Safety formuna aktarman gerekir.

1# Tüm release bağımlılıklarını (transitive dahil) tek dosyaya çıkar
2./gradlew app:dependencies --configuration releaseRuntimeClasspath > deps-release.txt
3 
4# Reklam/analytics/crash-reporting gibi veri toplama ihtimali yüksek SDK'ları filtrele
5grep -Ei 'ads|analytics|crashlytics|firebase|facebook|adjust|appsflyer' deps-release.txt

Bu listeyi Data Safety formunu doldurmadan önce çıkarmak, formu ikinci kez düzeltme ihtiyacını büyük ölçüde azaltır — çünkü her SDK'nın veri toplama davranışını tek tek unutmak yerine, somut bir kontrol listesinden çalışırsın.

Data Safety Formu: Alan Alan Doğru Doldurma

Data Safety formu, internal testing track'inde aktif olan uygulamalar hariç tüm yayın track'lerinde zorunludur. Google'ın kendi ifadesiyle: "Apps that are active on internal testing tracks are exempt from inclusion in the data safety section." Yani closed/open testing veya production'a çıkan her sürüm formu doldurmak zorundadır.

Hiç veri toplamayan bir uygulama bile bu yükümlülükten muaf değildir. Google açıkça şunu belirtiyor: "Even developers with apps that do not collect any user data must complete this form and provide a link to their privacy policy." Formu boş bırakmak veya atlamak seçenek değildir; "veri toplamıyorum" seçeneğini işaretleyip gizlilik politikası linkini yine de eklemen gerekir.

Formu doldururken en çok atlanan nokta üçüncü taraf SDK'lardır. Google'ın politikası net: "This includes data collected and handled through any third-party libraries or SDKs used in their apps." Reklam SDK'sı, crash reporting aracı, analytics kütüphanesi — hepsi senin beyanına dahildir, "ben o veriyi toplamıyorum, SDK topluyor" savunması geçerli değildir.

Neyin "toplama" sayılmadığını bilmek de en az neyin sayıldığını bilmek kadar önemli. Üç istisna var:

• Yalnızca cihaz-üstü işleme: "User data accessed by your app that is only processed locally on the user's device and not sent off device does not need to be disclosed."
• Uçtan uca şifreleme: "User data that is sent off device, but that is unreadable by you or anyone other than the sender and recipient as a result of end-to-end encryption does not need to be disclosed."
• Service provider transferi: Veriyi senin adına işleyen bir "service provider"a aktarım, paylaşım (sharing) olarak sayılmaz.

Bir veri türünü "optional" (isteğe bağlı) olarak işaretleyebilmen için tek şart, cihaz veya bölge farkı gözetmeksizin tüm kullanıcıların ya bilgiyi isteğe bağlı sağlayabilmesi, ya opt-out ya da opt-in yapabilmesidir. Yalnızca belirli bir ülkedeki kullanıcılara opt-out veriyorsan, formda bunu "optional" olarak işaretleyemezsin.

Data Safety formunda alan alan doğru sınıflandırma şu tabloya göre yapılabilir:

Uygulama bağımsız bir güvenlik incelemesi (MASA — Mobile Application Security Assessment) rozeti de alabilir; bu isteğe bağlıdır ve geliştirici tarafından finanse edilir: "This is an optional review undertaken and paid for by developers. Through MASA (Mobile Application Security Assessment) developers can work directly with a Google Authorized Lab." Zorunlu değildir ama hassas veri işleyen finans/sağlık uygulamalarında güven sinyali olarak işe yarar.

Hassas İzinler ve Restricted Permissions Beyanı

Google Play, kalıcı cihaz kimlikleriyle (IMEI, IMSI, SIM seri numarası) kişisel/hassas kullanıcı verisi veya sıfırlanabilir reklam kimliklerinin eşleştirilmesini yasaklar: "Google Play prohibits linking persistent device identifiers (such as IMEI, IMSI, or SIM Serial #) to personal and sensitive user data or resettable device identifiers." Kalıcı kimliğe dayanan eski entegrasyon desenleri bu maddeye takılır.

Hassas kullanıcı verisi kapsamı geniştir ve Google'ın tanımına göre şunları içerir: "personally identifiable information, financial and payment information, authentication information, phonebook, contacts, device location, SMS and call-related data, health data…" Bu kategorilerden birine erişen her izin, Restricted Permissions politikasına tabidir.

Restricted Permissions için iki temel kural var. Birincisi, izin kullanımı store listing'de tanıtılan mevcut bir özelliğe bağlı ve "in-context" olmalı: "You may only request permissions and APIs that access sensitive information that are necessary to implement current features or services in your app that are promoted in your Google Play listing." İkincisi, kullanıcı reddi manipülasyonla aşılamaz: "Respect users' decisions if they decline a request for a Restricted Permission, and users may not be manipulated or forced into consenting to any non-critical permission."

In-context izin isteğini pratikte şöyle kurarsın: kullanıcı ilgili özelliğe dokunmadan izin diyaloğu açılmaz.

1// Kullanıcı "Konumu Paylaş" butonuna bastığında izin iste — uygulama açılışında DEĞİL
2button.setOnClickListener {
3    when {
4        ContextCompat.checkSelfPermission(
5            context, Manifest.permission.ACCESS_FINE_LOCATION
6        ) == PackageManager.PERMISSION_GRANTED -> {
7            shareCurrentLocation()
8        }
9        else -> {
10            requestPermissionLauncher.launch(Manifest.permission.ACCESS_FINE_LOCATION)
11        }
12    }
13}

Bu desen iki şeyi aynı anda çözer: hem "in-context" gereksinimini karşılar hem de Data Safety formundaki "konum toplama amacı" alanını (ör. "App functionality") somut ve savunulabilir kılar — çünkü izin isteği ile özelliğin kullanımı zaman içinde birebir örtüşür.

Hesap ve Veri Silme Zorunluluğu

Uygulama içi hesap oluşturma sunan her uygulama için Google iki ayrı yol tanımlıyor: "If your app enables account creation, you must: provide users with an in-app path to delete their app accounts and associated data; and provide a web link resource where users can request app account deletion and associated data deletion." Yani tek bir web formu yeterli değildir — uygulama içinde de bir silme yolu olmak zorunda.

Google'ın ilan ettiği takvimde Data deletion sorularının tamamlanması için son tarih 7 Aralık 2023'tü; Play Console üzerinden uzatma talep edenler için bu süre 31 Mayıs 2024'e kadar uzuyordu. Bu makalenin yayın tarihi olan 2025-02-10 itibarıyla zorunluluk tüm hesap-oluşturan uygulamalar için tam yürürlüktedir. Pratikte iki ayrı akış kurman gerekir: biri Play Store listing sayfasında linklenen bir web sayfası (uygulamayı silmeden de erişilebilir), diğeri uygulama ayarları içinde "Hesabımı Sil" gibi bir menü öğesi.

Abonelik ve Faturalandırma Politikaları

Google Play, abonelik teklifinde şeffaflığı zorunlu tutar: "You must be transparent about your offer. This includes clearly and explicitly disclosing your offer terms, the cost of your subscription, the frequency of your billing cycle, the automatic renewal terms, whether a subscription is required to use the app, and any other material information about the subscription." Politikanın saydığı kalemler (teklif koşulları, abonelik ücreti, faturalama sıklığı, otomatik yenileme koşulları, uygulamayı kullanmak için aboneliğin şart olup olmadığı ve aboneliğe dair diğer esaslı bilgiler) satın alma akışının kullanıcı tarafından ek işlem gerektirmeden görülebileceği bir yerde durmalı.

Aynı politika, abonelik modelinin ne sunması gerektiğini de tanımlar: "Subscriptions must provide sustained or recurring value to users throughout the life of the subscription, and may not be used to offer what are effectively one-time benefits to users (for example, SKUs that provide lump sum in-app credits/currency, or single-use game boosters)." Tek seferlik bir dijital ürünü (örneğin tek bir PDF rapor) abonelik olarak paketlemek bu maddeyi ihlal eder.

Deneme veya tanıtım fiyatlandırması sunuyorsan, dönemin sonunda otomatik ücretli aboneliğe geçileceğini açıkça belirtmemek ihlal örneği olarak sayılıyor: "Offers that do not clearly explain that the user will be automatically enrolled in a paid subscription at the end of the offer period." Deneme süresi biten kullanıcı satın alma ekranına dönmeden önce, o ekranda bu bilgi zaten net biçimde yazmalı — dipnot veya küçük harf yeterli değildir.

Satın alma ekranında gösterilmesi gereken minimum şeffaflık setini şöyle modelleyebilirsin:

1{
2  "offerTitle": "Aylık Plan",
3  "price": "₺149,99 / ay",
4  "billingCycle": "Her ay otomatik yenilenir",
5  "trialPeriod": "7 gün ücretsiz, sonra otomatik ücretli aboneliğe geçer",
6  "cancelInfo": "Play Store > Abonelikler'den istediğin an iptal edebilirsin"
7}

Sık Görülen İhlal Örnekleri ve Düzeltmeleri

Google'ın politika sayfalarında numaralandırılmış tek bir "en sık red nedenleri" listesi yok; her politika kendi ihlal örneklerini kendi sayfasında tanımlıyor. Aşağıdaki tablo, Data Safety, User Data ve Subscriptions politikalarında geçen somut ihlal örneklerini ve karşılık gelen düzeltmeyi bir araya getiriyor — istatistik değil, doğrudan politika metninden alınmış örnekler.

Reklam varlığını yanlış beyan etmenin sonucu ciddi: "If you misrepresent the presence of ads in your app(s), it's considered a violation of the Google Play policies and may result in your app(s) being suspended." Bu madde özellikle "Contains ads" etiketini bilinçli olarak atlayan uygulamalar için askıya alma riskini açıkça belirtiyor.

Reddedilen Uygulamayı Yeniden Gönderme (Resubmit) Süreci

Bir güncelleme reddedildiğinde veya uygulama kaldırıldığında panik yapmana gerek yok — Google'ın kendi ifadesiyle süreç destek ekibiyle iletişime geçmeden de tamamlanabilir: "If your update is rejected or your app is removed, please follow the instructions below to resubmit your app for review. You can complete these steps without contacting or waiting for a reply from the policy support team." Yani destek talebi açıp yanıt beklemek zorunda değilsin; ihlali düzeltip doğrudan yeniden gönderebilirsin.

Pratikte adımlar şöyle işler: önce Play Console'daki red e-postasında veya Policy Center panelinde hangi politikanın ihlal edildiği belirtilir, sonra ilgili değişikliği yapıp (Data Safety formu güncelleme, izin kaldırma, gizlilik politikası linki ekleme gibi) yeni bir sürüm olarak gönderirsin. Google, yeniden inceleme için ilan edilmiş bir süre taahhüdü yayınlamıyor; başvurunun durumunu Play Console'daki Policy Center panelinden takip edersin.

Bir politika ihlali çoğu zaman birden fazla politika sayfasını aynı anda ilgilendirir; yalnızca red e-postasında belirtilen tek maddeyi düzeltip göndermek bu yüzden yetmeyebilir — örneğin hatalı bir izin beyanı hem Restricted Permissions politikasını hem de Data Safety formunu aynı anda ihlal ediyor olabilir. Yeniden gönderim öncesi tüm ilgili politika sayfalarını (Permissions, Data Safety, User Data) tek tek gözden geçirmek, ikinci bir red turunu önler.

Gizlilik politikası zorunluluğu iki ayrı senaryoda devreye girer. Hassas izin veya veri isteyen uygulamalar için: "For apps that request access to sensitive permissions or data... You must link to a privacy policy on your app's store listing page and within your app." Çocuklara yönelik uygulamalar için ise hassas veri erişimi olmasa bile zorunluluk aynen geçerli: "For apps that target children: You must link to a privacy policy... regardless of your app's access to sensitive permissions or data."

Yayın Öncesi Uyum Kontrol Listesi

Yukarıdaki ödül listesi PLAYPOLICY7 ile açılan detaylı versiyondu; burada aynı kontrolün özet sıralaması var, gönderim öncesi hızlı tarama için:

1. Data Safety formu güncel mi (SDK/izin değişikliğinden sonra)
2. Gizlilik politikası linki hem store listing'de hem uygulama içinde mi
3. Hassas izinler yalnızca tanıtılan özellik için mi isteniyor
4. Hesap/veri silme yolu hem uygulama içi hem web'de mi
5. Abonelik ekranı fiyat + yenileme + iptal bilgisini gösteriyor mu
6. Reklam beyanı ("Contains ads") doğru mu

SSS

Data Safety formu nasıl doğru doldurulur?

Formu doldururken tek bir kural yeterli: uygulamanın ve içindeki tüm üçüncü taraf SDK'ların cihaz-dışına gönderdiği her veri türünü beyan et. Google'ın kendi ifadesiyle "This includes data collected and handled through any third-party libraries or SDKs used in their apps" — yani reklam, analytics, crash reporting kütüphaneleri de senin beyanına dahil. Yalnızca cihaz-üstünde kalan veya uçtan uca şifrelenmiş veri beyandan muaf.

Google Play'de uygulamam neden reddedildi?

Play Console'daki red e-postası veya Policy Center paneli hangi politikanın ihlal edildiğini belirtir; politika metinlerinde açıkça ihlal örneği olarak sayılanlar arasında Data Safety formu ile gerçek SDK davranışının uyuşmaması, hassas iznin store listing'de tanıtılmayan bir özellik için istenmesi ve abonelik şeffaflığı eksiklikleri var. Google numaralandırılmış bir "en sık red nedenleri" listesi yayınlamıyor; düzeltme, ihlali giderip Google'ın kendi ifadesiyle "without contacting or waiting for a reply from the policy support team" yeniden göndermekle başlıyor.

Hassas izin (SMS, konum, erişilebilirlik) beyanı nasıl yapılır?

Hassas izni yalnızca store listing'de tanıtılan mevcut bir özellik için, izin diyaloğunu o özelliğe dokunulduğunda açarak (in-context) iste. Kullanıcı izni reddederse bu kararı manipülasyonla aşmaya çalışma — Google bunu açıkça yasaklıyor. İznin eriştiği veri türü aynı zamanda Data Safety formunda da beyan edilmeli.

Hesap silme zorunluluğu kimleri kapsıyor?

Uygulama içinde hesap oluşturma sunan her uygulamayı kapsıyor. Bu uygulamalar hem uygulama içinde bir silme yolu hem de uygulama yüklü olmadan da erişilebilen bir web linki sağlamak zorunda; ikisi de eksiksiz olmalı, yalnız web linki yeterli değil.

Güncelleme (Eylül 2026)

Bu makalenin gövdesi 2025-02-10 tarihindeki politika durumunu yansıtıyor. O tarihten bugüne (2026-09-24) Google Play politikalarında, Data Safety ve izin beyanı konusuyla doğrudan ilgili şu değişiklikler duyuruldu:

• Duyuru 2025-03-05: Health Connect üzerinden erişilen hassas sağlık verisi kuralları sıkılaştırıldı (support.google.com/googleplay/android-developer/answer/15931464).
• Duyuru 2025-10-30: Yaş kısıtlamalı içerik (dating/gambling/matchmaking kategorileri) için yeni Age-Restricted Content and Functionality politikası duyuruldu; geliştiricilere uyum için duyurudan itibaren 30 gün tanındı (support.google.com/googleplay/android-developer/answer/16550159).
• Yürürlük 2026-01-01 (duyuru 19 Kas 2025): Age Signals API için veri kullanım kısıtları başlıyor (support.google.com/googleplay/android-developer/answer/16706838).
• Uyum son tarihi 2026-01-28 (duyuru 9 Ara 2025): ABD'de alternatif faturalandırma ve harici içerik linkleri için uyum gereksinimleri güncellendi (support.google.com/googleplay/android-developer/answer/16671517).
• Yürürlük 2026-09-30: Android geliştirici doğrulaması kapsamında Play uygulamalarını Play Console'a kaydetme zorunluluğu geliyor; kaydı yapılmayan uygulamalar Google Play'den kaldırılabilir (support.google.com/googleplay/android-developer/answer/10788890).

Bu değişikliklerin hiçbiri makalenin gövdesindeki Data Safety formu, Restricted Permissions veya hesap silme kurallarının temel mantığını değiştirmedi — mevcut süreç hâlâ geçerli. Geliştirici doğrulaması ve Health Connect kısıtları gibi kalemler ayrı, kategori-özel gereksinimler olarak üstüne eklendi.

Sonuç

Google Play politika uyumu tek seferlik bir kontrol değil, her SDK güncellemesinde, her yeni izin ekleyişinde tekrarlanması gereken bir disiplin. Data Safety formunu davranışla senkron tut, hassas izinleri yalnızca tanıtılan özellik için ve in-context iste, hesap oluşturan uygulamalarda hem uygulama içi hem web silme yolu sağla, abonelik ekranında fiyat ve yenileme koşulunu gizleme.

İlgili konularda derinleşmek istersen: abonelik altyapısını server tarafında doğrulamak için sunucu taraflı makbuz doğrulama rehberi makalesine, Play Billing v7 geçişi için Google Play Billing v7 abonelik rehberi makalesine, Android 15'in gizlilik değişiklikleri için Android 15 gizlilik ve Privacy Sandbox rehberi makalesine, Health Connect entegrasyonu için Health Connect Android entegrasyon rehberi makalesine ve production Android mimarisi için Jetpack Compose 1.7 performans rehberi makalesine göz atabilirsin.

Kaynaklar

• Provide information for Google Play's Data safety section - Play Console Help — Data Safety formu alan tanımları, muafiyetler ve zorunluluk kapsamı.
• User Data - Play Console Help — Hassas kullanıcı verisi kapsamı ve cihaz kimliği eşleştirme yasağı.
• Permissions and APIs that Access Sensitive Information - Play Console Help — Restricted Permissions ve in-context izin isteme kuralları.
• Account and data deletion - Play Console Help — Uygulama içi hesap oluşturan uygulamalar için silme yolu zorunluluğu.
• Subscriptions policy - Play Console Help — Abonelik şeffaflığı ve süregelen değer gereksinimleri.
• Prepare your app for review - Play Console Help — Resubmit süreci, gizlilik politikası linki zorunluluğu ve reklam beyanı.
• Request runtime permissions - Android Developers — Hassas izinleri kullanıcıya in-context (özelliğe dokunulduğunda) isteme yöntemi.