Davranış değişiklikleri: API 29 veya sonraki sürümleri hedefleyen uygulamalar

Android 10, uygulamanızı etkileyebilecek güncellenmiş sistem davranış değişiklikleri içerir. Bu sayfada listelenen değişiklikler yalnızca API 29 veya sonraki sürümleri hedefleyen uygulamalar için geçerlidir. Uygulamanız targetSdkVersion değerini "29" veya daha yüksek bir değere ayarlıyorsa uygulamanızı, geçerli olduğu durumlarda bu davranışları düzgün şekilde destekleyecek şekilde değiştirmeniz gerekir.

Android 10'da çalışan tüm uygulamaları etkileyen davranış değişiklikleri listesini de incelemeyi unutmayın.

SDK olmayan arayüz kısıtlamalarıyla ilgili güncellemeler

Platform, uygulama kararlılığını ve uyumluluğunu sağlamak için Android 9'da (API düzeyi 28) uygulamanızın kullanabileceği SDK dışı arayüzleri kısıtlamaya başladı. Android 10, Android geliştiricilerle işbirliği ve en son dahili testlere dayalı olarak kısıtlanmış SDK dışı arayüzlerin güncellenmiş listelerini içerir. Hedefimiz, SDK dışı arayüzleri kısıtlamadan önce herkese açık alternatiflerin mevcut olmasını sağlamaktır.

Android 10'u (API düzeyi 29) hedeflemeyecekseniz bu değişikliklerin bazıları sizi hemen etkilemeyebilir. Ancak şu anda bazı SDK dışı arayüzleri (uygulamanızın hedef API düzeyine bağlı olarak) kullanabilseniz de herhangi bir SDK dışı yöntemi veya alanı kullanmak uygulamanızın bozulma riskini her zaman yüksek oranda artırır.

Uygulamanızın SDK dışı arayüzler kullanıp kullanmadığından emin değilseniz bunu öğrenmek için uygulamanızı test edebilirsiniz. Uygulamanız SDK dışı arayüzleri kullanıyorsa SDK alternatiflerine geçiş planlamaya başlamanız gerekir. Bununla birlikte, bazı uygulamaların SDK dışı arayüzleri kullanmak için geçerli kullanım alanları olduğunu anlıyoruz. Uygulamanızdaki bir özellik için SDK dışı arayüz kullanmaya alternatif bir çözüm bulamıyorsanız yeni bir genel API isteğinde bulunmanız gerekir.

Daha fazla bilgi edinmek için Android 10'daki SDK olmayan arayüz kısıtlamalarında yapılan güncellemeler ve SDK olmayan arayüzlerdeki kısıtlamalar başlıklı makaleleri inceleyin.

Paylaşılan anı

Ashmem, /proc/<pid>/maps konumundaki dalvik haritalarının biçimini değiştirdi. Bu durum, haritalar dosyasını doğrudan ayrıştıran uygulamaları etkiliyor. Uygulama geliştiriciler, Android 10 veya sonraki sürümlerin yüklü olduğu cihazlarda /proc/<pid>/maps biçimini test etmeli ve uygulama dalvik harita biçimlerine bağlıysa buna göre ayrıştırmalıdır.

Android 10'u hedefleyen uygulamalar, ashmem(/dev/ashmem) öğesini doğrudan kullanamaz. Bunun yerine, NDK'nın ASharedMemory sınıfı aracılığıyla paylaşılan belleğe erişmelidir. Ayrıca uygulamalar, mevcut ashmem dosya tanımlayıcılarına doğrudan IOCTL'ler yapamaz ve bunun yerine paylaşılan bellek bölgeleri oluşturmak için NDK'nın ASharedMemory sınıfını veya Android Java API'lerini kullanmalıdır. Bu değişiklik, paylaşılan bellek ile çalışırken güvenliği ve sağlamlığı artırarak Android'in genel performansını ve güvenliğini iyileştirir.

Uygulama ana dizini için yürütme izni kaldırıldı

Yazılabilir uygulama ana dizinindeki dosyaların yürütülmesi W^X ihlalidir. Uygulamalar yalnızca bir uygulamanın APK dosyasına yerleştirilmiş ikili kodu yüklemelidir.

Android 10'u hedefleyen güvenilmeyen uygulamalar, uygulamanın ana dizinindeki dosyalar üzerinde doğrudan execve() işlevini çağıramaz.

Ayrıca, Android 10'u hedefleyen uygulamalar, dlopen() ile açılan dosyalardaki yürütülebilir kodu bellek içi olarak değiştiremez ve bu değişikliklerin diske yazılmasını bekleyemez. Bunun nedeni, kitaplığın yazılabilir bir dosya tanımlayıcısı aracılığıyla PROT_EXEC olarak eşlenememesidir. Buna, metin yeniden konumlandırmaları içeren tüm paylaşılan nesne (.so) dosyaları dahildir.

Android çalışma zamanı yalnızca sistem tarafından oluşturulan OAT dosyalarını kabul eder

Android çalışma zamanı (ART) artık uygulama sürecinden dex2oat işlevini çağırmıyor. Bu değişiklik, ART'nin yalnızca sistem tarafından oluşturulan OAT dosyalarını kabul edeceği anlamına gelir.

ART'de AOT doğruluğunu zorunlu kılma

Geçmişte, Android Runtime (ART) tarafından gerçekleştirilen önceden derleme (AOT), derleme zamanında ve çalışma zamanında sınıf yolu ortamı aynı değilse çalışma zamanı çökmelerine neden olabiliyordu. Android 10 ve sonraki sürümlerde bu ortam bağlamlarının her zaman aynı olması gerekir. Bu durum, davranışta aşağıdaki değişikliklere neden olur:

• Özel sınıf yükleyiciler (yani dalvik.system paketindeki sınıf yükleyicilerden farklı olarak uygulamalar tarafından yazılan sınıf yükleyiciler) AOT ile derlenmez. Bunun nedeni, ART'nin çalışma zamanında özelleştirilmiş sınıf arama uygulaması hakkında bilgi sahibi olamamasıdır.
• İkincil DEX dosyaları (yani birincil APK'da bulunmayan uygulamalar tarafından manuel olarak yüklenen DEX dosyaları) arka planda AOT ile derlenir. Bunun nedeni, ilk kullanım derlemesinin çok maliyetli olabilmesi ve yürütmeden önce istenmeyen gecikmeye yol açabilmesidir. Uygulamalar için bölmeleri kullanmanın ve ikincil dex dosyalarından uzaklaşmanın önerildiğini unutmayın.
• Android'deki paylaşılan kitaplıklar (Android manifest dosyasındaki <library> ve <uses-library> girişleri), platformun önceki sürümlerinde kullanılan sınıf yükleyici hiyerarşisinden farklı bir sınıf yükleyici hiyerarşisi kullanılarak uygulanır.

Tam ekran intent'lerle ilgili izin değişiklikleri

Android 10 veya sonraki sürümleri hedefleyen ve tam ekran intent'leri içeren bildirimler kullanan uygulamalar, uygulama manifest dosyalarında USE_FULL_SCREEN_INTENT iznini istemelidir. Bu, normal bir izin olduğundan sistem, bu izni isteyen uygulamaya otomatik olarak verir.

Android 10 veya sonraki sürümleri hedefleyen bir uygulama, gerekli izni istemeden tam ekran intent ile bildirim oluşturmaya çalışırsa sistem tam ekran intent'i yoksayar ve aşağıdaki günlük mesajını verir:

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

Katlanabilir cihazlar için destek

Android 10, katlanabilir cihazları ve büyük ekranlı cihazları destekleyen değişiklikler içerir.

Bir uygulama Android 10'da çalışırken onResume() ve onPause() yöntemleri farklı şekilde çalışır. Çoklu pencere veya çoklu ekran modunda aynı anda birden fazla uygulama göründüğünde, görünür yığınlardaki odaklanılabilir tüm üst etkinlikler devam ettirilen durumda olur ancak bunlardan yalnızca biri (en üstte devam ettirilen etkinlik) gerçekten odaklanmıştır. Android 10'dan önceki sürümlerde çalışırken sistemdeki yalnızca tek bir etkinlik aynı anda devam ettirilebilir, diğer tüm görünür etkinlikler duraklatılır.

"Odaklanma" ile "en üstte devam ettirilen" etkinliği karıştırmayın. Sistem, kullanıcının en son etkileşimde bulunduğu etkinliklere daha yüksek öncelik vermek için etkinliklere z-sırasına göre öncelik atar. Bir etkinlik, en üstte devam ettirilebilir ancak odaklanılamaz (örneğin, bildirim gölgesi genişletilmişse).

Android 10 (API düzeyi 29) ve sonraki sürümlerde, etkinliğiniz en üstteki devam ettirilen konumu kazandığında veya kaybettiğinde bildirim almak için onTopResumedActivityChanged() geri çağırma işlemine abone olabilirsiniz. Bu, Android 10'dan önceki devam ettirilen duruma eşdeğerdir ve uygulamanızın diğer uygulamalarla paylaşılması gerekebilecek özel veya tekil kaynaklar kullanması durumunda ipucu olarak faydalı olabilir.

resizeableActivity manifest özelliğinin davranışı da değişti. Bir uygulama Android 10 (API düzeyi 29) veya sonraki sürümlerde resizeableActivity=false olarak ayarlanırsa kullanılabilir ekran boyutu değiştiğinde ya da uygulama bir ekrandan diğerine taşındığında uyumluluk moduna alınabilir.

Uygulamalar, Android 10'da kullanıma sunulan android:minAspectRatio özelliğini kullanarak uygulamanızın desteklediği ekran en-boy oranlarını belirtebilir.

Android Studio'nun emülatör aracı, 3.5 sürümünden itibaren kodunuzu daha büyük ekranlarda test etmek için 7,3 inç ve 8 inçlik sanal cihazlar içerir.

Daha fazla bilgi için Katlanabilir cihazlar için uygulamalarınızı tasarlama başlıklı makaleyi inceleyin.