Android Uygulamada 16 KB Bellek Sayfası Uyumu Nasıl Test Edilir?

Android uygulamada 16 KB bellek sayfası uyumu, yalnızca bir mağaza uyarısını kapatma işi değildir. Uygulamanın paketlediği yerel kütüphaneleri bulmak, doğru hizalamayla yeniden derlemek ve gerçekten 16 KB ortamında görev akışlarını çalıştırmak gerekir. Java veya Kotlin ağırlıklı görünen bir projede bile üçüncü taraf SDK yerel kod taşıyabilir. Bu nedenle ilk soru “hangi Android sürümünü hedefliyoruz?” kadar “pakette hangi ikili dosyalar var?” olmalıdır.

Google'ın Android geliştirici rehberi, 16 KB sayfa boyutunu desteklemeyen güncellemeler için Play uyumluluk gereksinimini açıklar. Rehber 16 Eylül 2026'da güncellenmiştir; mağaza koşulları değişebileceğinden yayın gününde Play Console uyarısını da kontrol edin. Bu yazı, test sırasını anlamak için bir çalışma planıdır. Belirli bir uygulamaya bakmadan “uyumlu” ya da “uyumsuz” kararı vermek doğru olmaz.

Önce gerçek paket içeriğini çıkarın

Kaynak kodda doğrudan C veya C++ görmemeniz yeterli kanıt değildir. Harita, görüntü işleme, ödeme ya da analiz SDK'sı paket içinde yerel kütüphane taşıyabilir. Üretime göndereceğiniz dosyayı esas alın; geliştirme bilgisayarındaki bağımlılık listesi ile nihai APK veya AAB'nin içeriği aynı kontrol noktası değildir. Android dokümanı APK Analyzer içindeki lib klasöründe paylaşılan kütüphaneleri incelemeyi öneriyor. Burada .so dosyası varsa hangi bağımlılıktan geldiğini ve kimin güncelleyeceğini kaydedin.

Kütüphane envanterini küçük bir tabloyla tutun: dosya adı, sağlayıcı, sürüm, projedeki kullanım yeri, yükseltme olanağı ve test sonucu. Hazır bir SDK'nın sürümünü geliştiricinin keyfî olarak yeniden derleyemeyebileceğini hesaba katın. Sağlayıcının uyumluluk açıklaması ile elinizdeki paket sürümünü karşılaştırın. Uygulama yalnızca Java/Kotlin ve aynı tür kütüphanelerden oluşuyorsa Google rehberi varsayılan uyumluluktan söz eder; yine de çalışma davranışını test etmeyi önerir. “Varsayılan” ifadesini test muafiyeti sanmayın.

Derleme ve hizalama kontrolünü ayırın

Bir kütüphanenin 16 KB uyumlu derlenmiş olması ile uygulama paketindeki yerleşimin doğru olması ilişkili ama farklı kontrollerdir. Derleme ayarları, yerel bağımlılıklar ve paketleme biçimi beraber incelenmelidir. Android'in güncel yönergesi, uygun araç sürümlerini ve 16 KB uyumlu hazır bağımlılıkları kullanmanın işi kolaylaştırdığını; eski veya özel yerel kodda ise ayrıca düzeltme gerekebileceğini belirtiyor. Sürüm numaralarını ezberleyip körlemesine değiştirmeyin; projenin diğer bağımlılıklarını ve desteklenen Android sürümlerini de doğrulayın.

Kodu güncelledikten sonra teslim edeceğiniz AAB ve ondan üretilen APK üzerinde kontrolleri tekrarlayın. Test edilen artefakt ile mağazaya gönderilen artefakt farklıysa başarılı sonuç geçerli değildir. CI sürecine aynı kontrolün eklenmesi, yeni bir SDK güncellemesinin eski sorunu geri getirmesini yakalamaya yardımcı olabilir. Çıktıda uyarı gördüğünüzde yalnızca derleme komutunu tekrar çalıştırmayın; hangi paylaşılan kütüphanenin hizalama sorununa yol açtığını belirleyin.

Gerçek 16 KB çalışma ortamını doğrulayın

Android rehberi 16 KB tabanlı emülatör görüntüsü veya uygun cihaz üzerinde test yapılmasını anlatıyor. Test cihazının gerçekten o modda olduğunu adb shell getconf PAGE_SIZE komutuyla doğrulayın; beklenen değer 16384 olmalıdır. Emülatörü kurmuş olmak tek başına doğru görüntüyle açtığınızı kanıtlamaz. Cihaz veya emülatör, test raporunda model ve sistem görüntüsü bilgisiyle yer almalı. Böylece bir sonraki sürümde aynı ortam yeniden oluşturulabilir.

Uygulamayı sadece açıp kapatmak yetersizdir. Giriş, oturum yenileme, görsel yükleme, kamera, çevrimdışı veri, harita, bildirim ve ödeme gibi projenin gerçekten kullandığı işlevleri çalıştırın. Yerel kütüphanenin çağrılmadığı bir başlangıç ekranı hatayı saklayabilir. Çökme kayıtlarını ve ilgili günlükleri test adımıyla eşleyin. Arka plan görevleri de varsa uygulama ön planda değilken tetiklenen akışı ayrıca sınayın. Bir özellik üçüncü taraf SDK'ya bağlıysa sağlayıcı sürümünü test notunda saklayın.

Geriye uyumluluk yanıltmasın

Bazı cihazlarda uyumluluk modu bir uygulamanın açılmasına yardımcı olabilir. Bu, aynı uygulamanın doğrudan 16 KB uyumlu olduğu veya her cihazda sorunsuz davranacağı anlamına gelmez. Test koşulunu açıkça yazın: gerçek destek mi, geçici uyumluluk davranışı mı? Mağaza kabulü ile kullanıcı deneyimini iki ayrı sonuç olarak raporlayın. Yayın kapısını yalnızca “uyarı görünmedi” biçiminde tanımlarsanız, uygulama içindeki kırık bir özelliği kaçırabilirsiniz.

Testin sonunda eksikleri önem derecesine ayırın. Uygulama hiç açılmıyorsa yayın durdurulmalı. Sadece belirli bir özellik bozuluyorsa o özelliğin kullanıcı yolundaki etkisini değerlendirin. Sorun bir SDK'daysa sağlayıcı güncellemesinin bekleme süresi, alternatif kütüphane ve geçici ürün kararı birlikte ele alınmalı. Bir geçici çözüm kullanılacaksa kullanıcıya etkisi ve geri alma koşulu yazılı olmalı. Kontrol listesi, ekipteki başka bir kişinin aynı kararı yeniden üretebilmesini sağlamalıdır.

Çok modüllü bir uygulamada her ekibin kendi modülünü ayrı doğrulaması faydalıdır; yine de son karar tek birleştirilmiş paket üzerinden verilmelidir. Aynı SDK'nın farklı modüllerde farklı sürümleri bulunuyorsa hangi sürümün nihai pakete girdiğini kontrol edin. Hata kaydı paylaşırken kullanıcı verisini ayıklayın ve yalnızca teknik teşhis için gerekli izleri saklayın. Yayından sonra yeni cihazlardan gelen çökme raporlarını önceki test raporuyla karşılaştırmak da önemlidir. Laboratuvar testi riski azaltır, gerçek kullanımın tamamını temsil etmez. Bir sonraki sürümün kabul koşullarını yalnızca bugünkü emülatör sonucuna bağlamayın.

Sürüm öncesi karar kaydı

Son raporda hedeflenen Android sürümü, Play Console uyarısı, nihai paket kimliği, yerel kütüphane listesi, hizalama sonucu, 16 KB ortamının kanıtı ve tamamlanan görev testleri bulunsun. “Test edildi” yerine hangi senaryonun hangi sonuçla bittiğini belirtin. Uyumluluk gereksinimi hakkında Play Console teknik kalite sayfasını de yayın öncesi yeniden okuyun. Politika metni ile uygulamanızın gerçek paket verisi beraber değerlendirilmeden teslim tarihi taahhüt etmeyin.

Webinle'nin mobil uygulama geliştirme hizmeti, sürüm planı ile doğrulama senaryolarını aynı kapsamda ele almak isteyen ekipler içindir. Paket kimliği ve mağaza sorumluluğu üzerine ayrı bir karar vermeniz gerekiyorsa Android paket adı doğrulama rehberimize bakabilirsiniz. Mevcut uygulamanızın teknoloji yığınını ve Play Console uyarısını teklif formunda paylaşın; önce hangi kanıtların eksik olduğunu birlikte belirleyelim.