Google Play Hedef API Seviyesi Şartı: Uygulamanız Neden Uyarı Aldı?

Bu sayfaya büyük olasılıkla Play Console'da ya da e-posta kutunuzda hedef API seviyesiyle ilgili bir uyarı gördükten sonra geldiniz. Panik yapmanıza gerek yok; uygulamanız şu an yayından kalkmış değil. Önce şu adımları atın:

1. Play Console'da uygulamanızın Politika durumu sayfasını açın ve uyarının ayrıntısını okuyun.
2. Uygulamanızın şu an hangi hedef API seviyesini kullandığını not edin.
3. Resmi yardım sayfasından güncel eşiği ve son tarihi kontrol edin.
4. Kaynak koduna ve geliştiricinize erişiminiz olup olmadığını netleştirin.
5. Süre yetmeyecekse uzatma talebi seçeneğinin açık olup olmadığına bakın.

Talha Aslan ve ekibi olarak bu yazıda kuralın mantığını, uyarının ne anlattığını ve güncellemenin getirdiği gerçek işi anlatıyoruz. Kuralın ayrıntısını Play Console Yardım'daki hedef API seviyesi gereksinimleri sayfasından doğruladık. Eşikler her yıl değiştiği için güncel değeri her zaman bu resmi sayfadan kontrol edin.

Hedef API seviyesi tam olarak neyi ifade eder?

Her Android sürümünün bir API seviyesi numarası vardır. Hedef API seviyesi (targetSdkVersion, yani uygulamanın hangi Android sürümüne göre test edildiğini bildiren ayar) uygulamanızın derleme dosyasında yazan bir değerdir. Bu değer, uygulamanızın hangi Android sürümünün kurallarına göre davrandığını sisteme söyler.

Burada sık karışan iki kavram var. Birincisi minimum seviye (minSdkVersion); uygulamanızın kurulabileceği en eski Android sürümünü belirler. İkincisi hedef seviye; uygulamanın hangi yeni davranışları kabul ettiğini belirler. Dolayısıyla hedef seviyeyi yükseltmek eski telefonları dışarıda bırakmaz. Uygulamanız eski cihazlarda çalışmaya devam eder.

Peki Android neden böyle bir ayara ihtiyaç duyuyor? Android Developers belgesine göre bazı yeni davranışlar yalnız o sürümü açıkça hedefleyen uygulamalarda devreye giriyor. Böylece eski uygulamalar bir gecede bozulmuyor. Ancak bu esneklik, gizlilik ve güvenlik iyileştirmelerinin kullanıcıya ulaşmasını da geciktiriyor. Google Play bu yüzden hedef seviye için bir alt sınır koyuyor.

Kısacası hedef API seviyesi, uygulamanızın güncelliğini gösteren teknik bir beyandır. Değeri değiştirmek kolaydır; asıl iş, uygulamanın yeni kurallar altında doğru çalıştığından emin olmaktır.

Google Play hedef API seviyesi kuralı nasıl işliyor?

Kısaca Google Play hedef API seviyesi kuralı iki parçalı bir zaman penceresine dayanıyor. Google Play'in hedef API seviyesi politikası yeni uygulamaların ve güncellemelerin, en son büyük Android sürümünün çıkışından itibaren bir yıl içindeki bir API seviyesini hedeflemesini istiyor. Bu şartı karşılamayan gönderimleri Play Console kabul etmiyor.

Mevcut uygulamalar için pencere daha geniş. Politikaya göre güncellenmeyen ve en son büyük Android sürümünden itibaren iki yıl içindeki bir seviyeyi hedeflemeyen uygulamalar, yeni Android sürümlerini kullanan yeni kullanıcılara sunulmuyor. Yani uygulamanız mağazada kalır, ama yeni telefon alan kişi onu bulamaz.

Bu pencere sabit bir rakam değil, kayan bir çizgi. Her yıl yeni bir Android sürümü çıktıkça eşik de bir basamak yukarı çıkıyor. Google bu güncellemeyi duyurularında düzenli yıllık güncelleme olarak tanımlıyor. Bu nedenle bu yıl şartı karşılayan bir uygulama, hiç dokunulmazsa ertesi yıl yeniden uyarı alır.

Wear OS, Android TV, Android Automotive OS ve Android XR gibi platformların eşikleri ise telefon uygulamalarından farklı olabiliyor. Ayrıca yalnız belirli bir kuruluşun çalışanlarına özel, kalıcı olarak gizli dağıtılan uygulamalar resmi sayfada istisna olarak geçiyor. Hangi gruba girdiğinizi yardım sayfasındaki tablodan kontrol edin.

Yeni uygulama, güncelleme ve mevcut uygulama için fark nedir?

Uyarıyı doğru okumak için uygulamanızın hangi durumda olduğunu bilmeniz gerekiyor. Aynı kural üç farklı duruma farklı sonuç doğuruyor. Aşağıdaki tablo, resmi politikanın genel çerçevesini özetliyor; kesin API numarasını ve tarihi her zaman resmi sayfadan alın.

Tablodaki en sinsi satır ikincisi. Birçok işletme uygulamasının yıllarca güncelleme almadan çalıştığını görüyoruz. Ardından acil bir hata çıkıyor, ekip düzeltmeyi hazırlıyor ve yükleme anında Play Console reddediyor. Böylece beş dakikalık bir düzeltme, haftalar süren bir uyumluluk projesine dönüşüyor.

Öte yandan üçüncü satır sessiz bir kayıp yaratır. Mevcut kullanıcılarınız fark etmez; ancak yeni müşteri kazanımı her ay biraz daha azalır.

Uyarı e-postası ve Play Console bildirimi size ne anlatıyor?

Resmi yardım sayfasına göre yalnız şartı karşılamayan uygulamalar Play Console'da politika uyarısı ve bildirim alıyor. Yani uyarıyı gördüyseniz uygulamanız gerçekten risk grubunda. Uyarı size Play Console bildirimi olarak ya da hesabınıza bağlı e-posta adresine gelen benzeri bir mesaj olarak ulaşabilir.

Uyarıda genellikle şu bilgileri ararsınız:

• Hangi uygulamanın ya da hangi paket adının etkilendiği.
• Uygulamanın şu an hangi hedef seviyeyi kullandığı.
• Ulaşmanız gereken eşik ve son tarih.
• Uzatma talebi seçeneğinin olup olmadığı.

Bu bilgileri en güvenilir biçimde Play Console'daki Politika durumu sayfasında bulursunuz. Politika durumunu anlatan yardım sayfası, uygulamanızın politika açısından sorunlarını ve aktif yaptırımları bu ekranda gösterdiğini açıklıyor. E-postadaki bağlantıya tıklamak yerine Play Console'a kendiniz giriş yapıp bu sayfayı açmanızı öneriyoruz. Çünkü Google'ı taklit eden sahte e-postalar da dolaşıyor.

Ayrıca uyarıyı yalnız geliştiriciye iletmekle yetinmeyin. Hesap sahibi olarak siz de son tarihi takviminize yazın. Böylece süreç bir kişinin unutkanlığına bağlı kalmaz.

Şartı karşılamazsanız uygulamanıza tam olarak ne olur?

En sık duyduğumuz korku, uygulamanın bir sabah mağazadan silinmesi. Gerçek tablo farklı. Hedef seviye şartını kaçıran mevcut bir uygulama Google Play'den kaldırılmıyor; ancak görünürlüğü daralıyor.

Resmi sayfaya göre eski seviyeyi hedefleyen uygulama, yalnız işletim sistemi sürümü uygulamanın hedef seviyesine eşit ya da daha düşük olan cihazlarda kullanılabilir kalıyor. Dolayısıyla yeni Android sürümüne geçmiş bir kullanıcı uygulamanızı aradığında onu bulamıyor. Daha önce yükleyen kullanıcılar ise uygulamayı yeniden yükleyip kullanmaya devam edebiliyor.

Bu durumun iş tarafındaki etkisini küçümsemeyin. Örnek senaryo: bir kuaför zinciri randevu uygulamasını yeni müşterilerine mağaza üzerinden tanıtıyor. Yeni telefonlar her ay pazara giriyor ve bu telefonlar en yeni Android sürümüyle geliyor. Sonuç olarak uygulamanın erişebildiği yeni kullanıcı havuzu zaman içinde sessizce küçülüyor; reklam bütçesi aynı kalsa bile yükleme sayısı düşüyor.

Üstelik güncelleme kapısı da kapanıyor. Ödeme altyapınız değişirse, bir güvenlik açığı çıkarsa ya da kampanya ekranı eklemek isterseniz önce hedef seviyeyi yükseltmeniz gerekiyor. Yani asıl kayıp, acil anda hareket edememek.

Uygulamanızın hedef API seviyesini nasıl öğrenirsiniz?

Bunun için kodu açmanız şart değil. Play Console'da uygulamanızın yüklü sürümlerine ait ayrıntılar, her paketin hedef SDK bilgisini gösterir. Panelde ilgili bölümün adı zaman içinde değişebileceği için uygulama paketleri ya da sürüm ayrıntıları ekranına bakmanız yeterli. Ayrıca Politika durumu sayfasındaki uyarı da mevcut değeri çoğu zaman belirtir.

Kaynak koduna erişiminiz varsa değer, modül düzeyindeki derleme dosyasında yer alır. Resmi Android belgesi değeri derleme yapılandırmasında ya da manifest dosyasındaki ilgili öznitelikte tanımlayabileceğinizi söylüyor. Geliştiricinizden bu değeri ve en son derleme tarihini yazılı olarak isteyin.

Bu noktada sık gördüğümüz bir sorunu da belirtelim. Bazı işletmeler kaynak kodunun nerede olduğunu bilmiyor. Proje eski bir serbest çalışanın bilgisayarında kalmış olabilir. Bu durumda hedef seviyeyi öğrenmek kolay, değiştirmek ise zordur. Önce koda ve imzalama anahtarına kimin sahip olduğunu netleştirin; bu konuya aşağıda ayrı bir başlıkta değiniyoruz.

Kısacası ilk gün yapacağınız iş basit: mevcut değeri, istenen eşiği ve son tarihi tek bir notta toplayın. Planın geri kalanı bu üç bilgiye dayanır.

Google Play hedef API seviyesi için süre uzatma talebi nasıl yapılır?

Google, eşiğin yükseldiği dönemlerde süre yetmeyen geliştiricilere genellikle sınırlı bir uzatma imkânı tanıyor. Resmi yardım sayfasına göre uzatma formuna Play Console'daki Politika durumu sayfasında, uyarının ya da sorunun ayrıntı ekranından ulaşıyorsunuz. Etkilenen uygulamalar form bağlantısını Play Console bildirimleri üzerinden de alıyor.

Uzatma talebi için şu sırayı izleyin:

1. Play Console'a giriş yapın ve etkilenen uygulamayı seçin.
2. Politika durumu sayfasında hedef API seviyesiyle ilgili uyarıyı açın.
3. Ayrıntı ekranında uzatma formu bağlantısı varsa formu açın.
4. Gerekçenizi kısa ve dürüst yazın; örneğin üçüncü taraf bir kütüphanenin güncellemesini beklediğinizi belirtin.
5. Onay gelirse yeni son tarihi takviminize ekleyin ve güncelleme planını hemen başlatın.

Burada iki şeyi bilmeniz gerekiyor. Birincisi, uzatma bir hak değil ve süresi sınırlı; güncel uzatma tarihini resmi sayfadan kontrol edin. İkincisi, uzatma işi ortadan kaldırmıyor, yalnız erteliyor. Bu yüzden uzatma süresini bekleme süresi değil, çalışma süresi olarak kullanın.

Formu doldururken gerçeğe aykırı gerekçe yazmayın. Google'a yanlış beyan, ileride hesabınızı etkileyebilecek bir risk yaratır.

Güncellemeyi ertelemenin gizli maliyeti nedir?

Hedef seviye uyarısı çoğu işletmeye "sonra bakarız" türünden bir iş gibi geliyor. Ancak erteleme süresi uzadıkça önünüzdeki iş katlanıyor. Nedeni basit: aradaki her Android sürümü kendi davranış değişikliklerini getiriyor ve bunların hepsini tek seferde ele almak zorunda kalıyorsunuz.

Örnek senaryo olarak iki işletmeyi düşünün. Birincisi uygulamasını her yıl düzenli olarak bir basamak yükseltiyor; her seferinde birkaç ekranı ve izni gözden geçiriyor. İkincisi üç yıl hiç dokunmuyor. İkinci işletme sonunda birden fazla Android sürümünün değişikliklerini, eskimiş kütüphaneleri ve derleme araçlarındaki kırılmaları aynı anda çözmek zorunda kalıyor.

Ertelemenin bir diğer maliyeti de bilgi kaybı. Uygulamayı yazan geliştirici başka projelere geçiyor, belgeler eskiyor, test cihazları kayboluyor. Dolayısıyla yeni ekip, kodu anlamak için ek zaman harcıyor.

Son olarak fırsat maliyetini unutmayın. Güncelleme kapısı kapalıyken yeni özellik çıkaramazsınız. Rakibiniz yeni bir kampanya ekranı yayınlarken siz derleme hatalarıyla uğraşırsınız. Bu yüzden biz hedef seviye yükseltmesini yıllık bakım takviminin sabit bir maddesi olarak görüyoruz.

Hedef seviyeyi yükseltmek neden tek satırlık iş değildir?

Teknik olarak hedef seviye bir sayıdır ve onu değiştirmek bir dakika sürer. Asıl iş o sayı değiştikten sonra başlar. Çünkü yeni hedef seviye, uygulamanızın yeni Android kurallarını kabul ettiği anlamına gelir.

Sayıyı yükselttiğinizde genellikle üç tür sorunla karşılaşırsınız:

• Derleme sorunları: Derleme araçlarını, eklentileri ve kütüphaneleri güncel sürüme taşımanız gerekebilir.
• Davranış sorunları: Uygulama derlenir ama bazı ekranlar, izinler ya da arka plan görevleri farklı çalışır.
• Görünüm sorunları: Yeni sistem çubukları, ekran kenarları ya da büyük ekran kuralları arayüzünüzü bozabilir.

Örneğin derleme sorunları hemen göze çarpar, çünkü derleyici hemen hata verir. Davranış sorunları ise daha tehlikelidir. Uygulama mağazaya çıkar ve ilk günlerde sorunsuz çalışır; ardından bildirimlerin gitmediğini ya da uygulamanın konum iznini hiç istemediğini fark edersiniz.

Bu nedenle hedef seviye güncellemesini her zaman bir test turuyla birlikte planlayın. Yükseltmeden sonra çökme oranını da yakından izleyin; mağazanın çökme eşiklerini uygulama çökme oranı ve mağaza eşikleri yazımızda ayrıca anlattık.

Son Android sürümlerinde hangi değişiklikler sorun çıkarıyor?

Google her Android sürümünün davranış değişiklikleri listesini resmi belgede ayrıca yayımlıyor. Biz her yükseltmede bu listeyi satır satır okuyup uygulamaya karşılık gelen maddeleri işaretliyoruz. Son sürümlerden birkaç örnek, işin kapsamını anlamanıza yardım eder:

• Android 15'i hedefleyen uygulamalarda kenardan kenara (edge-to-edge) görünüm varsayılan hale geldi; içerik durum çubuğunun ve gezinme çubuğunun arkasına taşabiliyor.
• Android 15 ile bazı ön plan hizmeti türleri için çalışma süresi sınırı geldi.
• Kenardan kenara görünümden, Android 16'yı hedefleyen uygulamalar artık çıkamıyor.
• Tahmine dayalı geri hareketi (predictive back) animasyonları Android 16'da varsayılan olarak açık geliyor.
• Android 16'da sistem, geniş ekranlı cihazlarda yön ve yeniden boyutlandırma kısıtlamalarını yok sayıyor; tablet görünümünüz değişebiliyor.

Bu maddeler hangi sürümü hedeflediğinize göre değişir. Yani sizin listeniz, mevcut seviyenizle hedeflediğiniz seviye arasındaki tüm sürümlerin toplamıdır. Ayrıca Android 12 öncesinden gelen uygulamalarda dışa açık bileşenlerin açıkça işaretlenmesi ve bekleyen niyet nesnelerinin değiştirilebilirlik bilgisi gibi eski değişiklikler de devreye girer.

Kısacası değişiklik listesi teknik bir belge gibi görünse de doğrudan kullanıcı deneyimine dokunur. Bu yüzden listeyi tasarım ekibiyle birlikte okuyun.

Üçüncü taraf SDK'lar güncellemeyi nasıl engeller?

SDK (yazılım geliştirme kiti), uygulamanıza başka bir firmanın eklediği hazır kod parçasıdır. Ödeme, harita, analiz, reklam ve bildirim gibi özelliklerin çoğu bu kitlerle gelir. Hedef seviyeyi yükselttiğinizde bu kitlerin de yeni sürümle uyumlu olması gerekir.

Resmi Android belgesi, yükseltme öncesinde üçüncü taraf kitlerin yeni seviyeyi destekleyip desteklemediğini kontrol etmeyi açıkça öneriyor. Sahada en sık yaşadığımız tıkanma da burada. Örneğin yerel bir ödeme kuruluşunun eski kiti yeni seviyede derlenmiyor ve kuruluş güncel sürümü yayımlamamış oluyor.

Bu durumda üç seçeneğiniz vardır:

1. Kitin güncel sürümünü bekleyip bu arada uzatma talep etmek.
2. Aynı işi yapan ve güncel tutulan başka bir kite geçmek.
3. Özelliği geçici olarak web görünümüne taşımak.

Hangisinin doğru olduğu kitin işlevine ve sözleşmenize bağlı. Ancak her durumda kit listesini önceden çıkarın. Ayrıca kitlerin topladığı verileri değiştirirseniz Google Play veri güvenliği formunu da güncellemeniz gerekebilir. Aksi halde güncelleme başka bir nedenle takılır.

React Native veya Flutter uygulamalarında süreç farklı mı?

Kural aynı, ama yol biraz farklı. Çapraz platform çatıları, yani tek kod tabanından hem iOS hem Android uygulaması üreten araçlar, hedef seviyeyi kendi şablonlarında ve sürümlerinde yönetir. Bu yüzden önce çatının kendisini güncel bir sürüme taşımanız gerekebilir.

Örneğin React Native ile yazılmış eski bir projede hedef seviyeyi yükseltmek çoğu zaman çatı sürümünü de birkaç basamak yükseltmek demektir. Bu da her eklentinin yeni sürümle uyumunu kontrol etmenizi gerektirir. Flutter tarafında da benzer bir tablo vardır; Flutter'ın işletme uygulamalarına uygunluğunu Flutter rehberimizde ayrıca ele aldık.

Çapraz platform projelerinin bir avantajı da var. Toplulukta yaygın kullanılan eklentiler genellikle yeni Android sürümlerine hızla uyum sağlar. Ancak az kullanılan ya da bakımı durmuş eklentiler ciddi bir engel olabilir.

Bu yüzden çatı ne olursa olsun önce eklenti envanteri çıkarıyoruz. Bakımı durmuş eklentiyi değiştirmek, hedef seviye işinin en çok zaman alan parçası olabiliyor. Ayrıca aynı güncelleme turunda iOS tarafındaki bekleyen işleri de toplamak mantıklı olur.

Adım adım hedef seviye güncelleme planı

Bir hedef seviye uyarısını ekibimizle ele alırken izlediğimiz sıra aşağıda. Kendi geliştiricinizle çalışıyorsanız bu listeyi bir yol haritası olarak kullanabilirsiniz.

1. Envanter: Mevcut hedef seviyeyi, çatı sürümünü, kütüphaneleri ve kitleri listeleyin.
2. Fark analizi: Mevcut seviyenizle hedef arasındaki her Android sürümünün davranış değişikliklerini okuyun.
3. Derleme ortamı: Derleme araçlarını ve eklentileri güncel sürüme taşıyın.
4. Kod uyarlaması: İzin, bildirim, arka plan görevi ve ekran düzeni değişikliklerini uygulayın.
5. Test: Hem eski hem en yeni Android sürümünde ana akışları deneyin.
6. Kapalı yayın: Sürümü önce dahili ya da kapalı test kanalında yayınlayın.
7. Kademeli yayın: Üretime küçük bir kullanıcı yüzdesiyle başlayın ve çökme oranını izleyin.
8. Kapanış: Uyarının Politika durumu sayfasından kalktığını doğrulayın.

Bu planın en çok atlanan adımı ikincisi. Fark analizini yapmadan derlemeye geçen ekipler, sorunları ancak kullanıcı şikâyetiyle öğrenir.

Kademeli yayın sırasında eski sürümdeki kullanıcıları güncellemeye yönlendirmek isteyebilirsiniz. Bu ihtiyaç için zorunlu uygulama güncellemesi yazımız uygun ekran ve kurgu seçeneklerini anlatıyor.

Test aşamasında hangi noktaları kontrol etmelisiniz?

Hedef seviye güncellemesinde test, sıradan bir sürüm testinden farklıdır. Çünkü yeni kod yazmasanız bile sistem uygulamanıza farklı davranır. Bu yüzden aşağıdaki listeyi en az bir eski ve bir güncel Android cihazında tek tek deneyin:

• Uygulama ilk açılışta hangi izinleri istiyor, reddedince ne oluyor?
• Bildirimler hem uygulama açıkken hem kapalıyken ulaşıyor mu?
• Konum, kamera ve galeri erişimi beklendiği gibi çalışıyor mu?
• Ekran içerikleri durum çubuğunun ya da gezinme çubuğunun altında kalıyor mu?
• Geri hareketi ve geri tuşu doğru ekrana dönüyor mu?
• Tablet ya da katlanabilir cihazda düzen bozuluyor mu?
• Ödeme, giriş ve randevu gibi para ya da veri içeren akışlar sorunsuz mu?

Ayrıca izin reddi, pil tasarrufu modu ve uygulamanın arka planda uzun süre beklemesi gibi senaryoları da deneyin. Resmi belge de test sırasında izin reddini ve güç yönetimi modlarını kontrol etmeyi öneriyor.

Testi bitirince sonuçları kısa bir notla kayda geçirin. Böylece bir sonraki yıl aynı listeyi yeniden kullanırsınız ve işin süresi kısalır.

Örnek senaryo: eski bir randevu uygulaması nasıl güncellenir?

Gerçek bir müşteri vakası değil, sık karşılaştığımız tabloyu yansıtan bir örnek senaryo anlatalım. Bir diş kliniği zinciri yıllar önce bir randevu uygulaması yaptırmış. Uygulama çalışıyor, ancak birkaç yıldır güncelleme almamış. Klinik yeni bir şube ekranı eklemek istediğinde Play Console yüklemeyi kabul etmiyor.

İlk incelemede üç sorun çıkıyor. Birincisi, uygulamanın hedef seviyesi birden fazla sürüm geride kalmış. İkincisi, kullanılan bildirim kiti yeni sürümde derlenmiyor. Üçüncüsü, randevu hatırlatmaları arka plan görevine dayanıyor ve yeni kurallarda zamanlaması değişiyor.

Böyle bir senaryoda biz işi iki dalgaya bölüyoruz. İlk dalgada yalnız uyumluluk çalışması yapıyoruz: derleme ortamı, kitler, izinler ve görünüm. İkinci dalgada yeni şube ekranını ekliyoruz. Ardından kademeli yayınla üretime çıkıyoruz.

Bu ayrımın nedeni şu: uyumluluk ile yeni özelliği aynı sürüme koyarsanız, bir hata çıktığında kaynağını bulmak zorlaşır. Dolayısıyla iki ayrı sürüm biraz daha uzun sürer, ama riski belirgin biçimde azaltır.

Bakım sözleşmesi bu sorunu neden baştan çözer?

Hedef seviye uyarısı, mobil uygulamaların "bir kere yapılıp biten" bir iş olmadığını gösteren en net örnek. Android her yıl yeni sürüm çıkarıyor, Google Play her yıl eşiği yükseltiyor. Bu takvim değişmeyecek. Dolayısıyla uygulamanızın da yıllık bir bakım ritmine ihtiyacı var.

İyi bir bakım sözleşmesinde aradığımız maddeler şunlar:

• Yıllık hedef seviye yükseltmesinin kapsamda olduğu açıkça yazmalı.
• Geliştirici kitleri ve kütüphaneleri belirli bir ritimle güncellemeli.
• Sözleşme, politika uyarılarına kaç iş günü içinde döneceğinizi yazmalı.
• Kaynak kodu, imzalama anahtarı ve mağaza hesabı erişiminin işletmede kalacağı netleşmeli.
• Geliştirici her güncellemeden sonra kısa bir test raporu teslim etmeli.

Uygulamanızı biz geliştirir ve mağazaya biz çıkarırız; ardından bu bakım ritmini de üstleniriz. Mevcut uygulamanız için hedef seviye güncellemesine ya da yeni bir proje için teklif almak isterseniz mobil uygulama geliştirme hizmetimizin sayfasından bize ulaşabilirsiniz.

Bakım sözleşmesi olmayan uygulamalarda uyarı her yıl sürpriz olarak gelir. Sözleşmeli uygulamalarda ise bir takvim maddesine dönüşür.

Geliştiriciniz ortada yoksa ne yapmalısınız?

Hedef seviye uyarısını alan işletmelerin önemli bir kısmı, uygulamayı yazan kişiye ya da firmaya artık ulaşamıyor. Bu durumda ilk soru kaynak kodunun nerede olduğu. Kod olmadan hedef seviyeyi yükseltemezsiniz; uygulamayı yeniden yazmanız gerekir.

Ardından imzalama anahtarı gelir. Google Play uygulama imzalama hizmetini kullanıyorsanız, Google uygulama imzalama anahtarını saklar ve siz yalnız yükleme anahtarıyla çalışırsınız. Yükleme anahtarı kaybolursa Play Console üzerinden sıfırlama talebi oluşturabilirsiniz. Ancak eski bir projede bu yapı kurulmamışsa süreç zorlaşır.

Bu noktada kurallara aykırı kestirmelere karşı uyaralım. Mevcut uygulamayı silip başka bir paket adıyla yeni uygulama açmak, kullanıcılarınızı ve yorumlarınızı kaybettirir. Başkasının geliştirici hesabını kullanmak ise Google'ın kurallarına aykırıdır ve hesabınızı riske atar.

Uygulamanız kaldırma ya da askıya alma gibi bir yaptırımla karşılaştıysa durum farklıdır. Bu senaryo için Google Play uygulama kaldırıldı ve itiraz yazımız daha uygun bir başlangıç noktası olur.

Yayından önce son kontrol listesi

Yeni sürümü üretime göndermeden önce aşağıdaki maddelerin hepsini işaretleyin. Bu liste, ilk yüklemenin reddedilme riskini azaltır.

1. Hedef seviye, resmi sayfadaki güncel eşiği karşılıyor.
2. Uygulama en az bir eski ve bir güncel cihazda ana akışları geçti.
3. Tüm kitler yeni seviyeyle uyumlu sürümde.
4. İzin açıklamaları ve gizlilik politikası güncel.
5. Veri güvenliği bölümü yeni kitlerin topladığı verilerle örtüşüyor.
6. Mağaza açıklaması ve ekran görüntüleri yeni arayüzü yansıtıyor.
7. Kademeli yayın yüzdesi ve geri alma planı hazır.

Mağaza incelemesi hedef seviye dışında başka nedenlerle de takılabilir. Yükleme sonrası bir ret gelirse uygulama red nedenleri yazımız en sık karşılaşılan sorunları sıralıyor. Böylece aynı hatayı ikinci kez yaşamazsınız.

Ayrıca yayından sonraki ilk haftada çökme raporlarını ve kullanıcı yorumlarını her gün kontrol edin. Hedef seviye değişikliğinin yan etkileri çoğunlukla bu ilk haftada görünür.

Google Play hedef API seviyesi uyarısında hangi adımı ne zaman atarsınız?

Google Play hedef API seviyesi uyarısı bir ceza değil, bir hatırlatmadır. Doğru zamanda harekete geçerseniz uygulamanız kesintisiz yayında kalır. Özetle zaman çizelgeniz şöyle görünmeli:

• Uyarının geldiği hafta: mevcut seviyeyi, eşiği ve son tarihi not edin; kod ve hesap erişimini teyit edin.
• İlk ay: envanter ve fark analizini tamamlayın, kit sorunlarını belirleyin.
• Son tarihten önce: güncellemeyi test edip kademeli yayına çıkarın.
• Süre yetmiyorsa: uzatma formu açıksa talep edin ve çalışmayı sürdürün.
• Her yıl: bir sonraki Android sürümünü bekleyerek yükseltmeyi bakım takviminize ekleyin.

Bu işi tek seferlik bir yangın söndürme olarak değil, düzenli bir bakım rutini olarak görürseniz uyarılar sizi bir daha şaşırtmaz. Ekibimiz uyumluluk güncellemesini, test turunu ve mağaza yayınını sizin için baştan sona yürütebilir. Uygulamanızın durumunu birlikte değerlendirmek ve teklif almak için mobil uygulama geliştirme sayfamızdaki formu doldurmanız yeterli.

Son olarak bir hatırlatma: bu yazıdaki eşik pencereleri resmi politikanın genel çerçevesidir. Güncel API numarasını ve tarihi uygulamanızda değişiklik yapmadan önce mutlaka Play Console Yardım'dan kontrol edin.