Davranış değişiklikleri: tüm uygulamalar

Android 10, uygulamanızı etkileyebilecek davranış değişiklikleri içerir. Bu sayfada listelenen değişiklikler, uygulamanın targetSdkVersion'ünden bağımsız olarak Android 10'da çalışırken uygulamanız için geçerlidir. Bu değişiklikleri düzgün bir şekilde desteklemek için uygulamanızı test etmeniz ve gerektiğinde değiştirmeniz gerekir.

Uygulamanızın targetSdkVersion özelliği 29 veya daha yeni bir sürümse ek değişiklikleri de desteklemeniz gerekir. Ayrıntılı bilgi için uygulamalar için davranış değişiklikleri 29'u okuduğunuzdan emin olun.

Not: Android 10, bu sayfada listelenen değişikliklere ek olarak aşağıdakiler de dahil olmak üzere çok sayıda gizlilik odaklı değişiklik ve kısıtlama sunar:

  • Cihaz konumuna arka planda erişim
  • Arka plan etkinliği başlar
  • Kişilerle ilgili yakınlık bilgileri
  • MAC adresi rastgele hale getirme
  • Kamera meta verileri
  • İzin modeli

Bu değişiklikler tüm uygulamaları etkiler ve kullanıcı gizliliğini artırır. Bu değişiklikleri nasıl destekleyeceğiniz hakkında daha fazla bilgi edinmek için Gizlilik değişiklikleri sayfasına bakın.

SDK olmayan arayüz kısıtlamaları

Platform, uygulama kararlılığını ve uyumluluğunu sağlamaya yardımcı olmak için uygulamanızın Android 9'da (API düzeyi 28) kullanabileceği SDK dışı arayüzleri kısıtlamaya başladı. Android 10, Android geliştiricilerle yapılan ortak çalışmalara 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 kullanıma sunulması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 kullanabilseniz de (uygulamanızın hedef API düzeyine bağlı olarak) SDK dışı herhangi bir yöntem veya alanı kullanmak her zaman uygulamanızın bozulma riskini artırır.

Uygulamanızın SDK dışı arayüz kullanıp kullanmadığından emin değilseniz bunu öğrenmek için uygulamanızı test edebilirsiniz. Uygulamanız SDK dışı arayüzlere dayanıyorsa SDK alternatiflerine geçiş planlamaya başlamanız gerekir. Bununla birlikte, bazı uygulamaların SDK dışı arayüzler için geçerli kullanım alanları olduğunun farkındayız. Uygulamanızdaki bir özellik için SDK dışı arayüz kullanmanın alternatifini bulamıyorsanız yeni bir herkese açık API isteğinde bulunmanız gerekir.

Daha fazla bilgi edinmek için Android 10'da SDK dışı arayüz kısıtlamalarıyla ilgili güncellemeler bölümünü ve SDK olmayan arayüzlerle ilgili kısıtlamalar bölümünü inceleyin.

Hareketle Gezinme

Android 10'dan itibaren kullanıcılar cihaz genelinde hareketle gezinmeyi etkinleştirebilir. Kullanıcı hareketle gezinmeyi etkinleştirirse bu, API düzeyi 29'u hedefleyip hedeflemediğine bakılmaksızın cihazdaki tüm uygulamaları etkiler. Örneğin, kullanıcı ekranın kenarından içeri doğru kaydırırsa sistem bu hareketi Geri gezinme olarak yorumlar. Ancak bir uygulama, ekranın belirli bölümleri için bu hareketi özel olarak geçersiz kılarsa sistem hareketi farklı şekilde yorumlar.

Uygulamanızın hareketle gezinmeyle uyumlu olması için uygulama içeriğini kenardan kenara genişletmeniz ve çakışan hareketleri uygun şekilde ele almanız gerekir. Bilgi için Hareketle gezinme dokümanlarına bakın.

NDK

Android 10, aşağıdaki NDK değişikliklerini içerir.

Paylaşılan nesneler metin taşıma içeremez

Android 6.0 (API düzeyi 23), paylaşılan nesnelerde metin taşıma işlemlerinin kullanımına izin vermez. Kod olduğu gibi yüklenmeli ve değiştirilmemelidir. Bu değişiklik, uygulama yükleme sürelerini ve güvenliğini iyileştirir.

SELinux, Android 10 veya sonraki sürümleri hedefleyen uygulamalarda bu kısıtlamayı uygular. Bu uygulamalar, metin taşıma işlemleri içeren ortak nesneleri kullanmaya devam ederse çalışmama riski yüksektir.

Bionic kitaplıkları ve dinamik bağlayıcı yollarındaki değişiklikler

Android 10'dan itibaren, çeşitli yollar normal dosyalar yerine sembolik bağlantılardır. Normal dosya olan yolları kullanan uygulamalar bozulabilir:

  • /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
  • /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
  • /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
  • /system/bin/linker -> /apex/com.android.runtime/bin/linker

Bu değişiklikler, dosyanın 64 bit varyantları için de geçerlidir. Bu varyantlarda lib/, lib64/ ile değiştirilir.

Uyumluluk için sembolik bağlantılar eski yollarda sağlanır. Örneğin, /system/lib/libc.so, /apex/com.android.runtime/lib/bionic/libc.so dosyasına giden bir kısayoldur. Bu nedenle dlopen(“/system/lib/libc.so”) çalışmaya devam eder ancak uygulamalar, /proc/self/maps veya benzeri bir yöntemle yüklü kitaplıkları incelemeye çalıştıklarında farkı fark ederler. Bu durum normal değildir ancak bazı uygulamaların, bilgisayar korsanlığı önleme süreci kapsamında bunu yaptığını tespit ettik. Bu durumda, /apex/… yolları Bionic dosyaları için geçerli yollar olarak eklenmelidir.

Yalnızca çalıştırılabilir bellekle eşlenen sistem ikili dosyaları/kitaplıkları

Android 10'dan itibaren, sistem ikili dosyalarının ve kitaplıklarının yürütülebilir segmentleri, kod yeniden kullanma saldırılarına karşı bir güçlendirme tekniği olarak bellekte salt yürütme (okunamaz) olarak eşlenir. Uygulamanız, hata, güvenlik açığı veya kasıtlı bellek denetimi nedeniyle salt yürütme olarak işaretlenmiş bellek segmentlerinde okuma işlemleri gerçekleştirirse sistem uygulamanıza bir SIGSEGV sinyali gönderir.

/data/tombstones/ içindeki ilgili tombstone dosyasını inceleyerek bu davranışın kilitlenmeye neden olup olmadığını belirleyebilirsiniz. Yalnızca yürütmeyle ilgili kilitlenmeler aşağıdaki iptal mesajını içerir:

Cause: execute-only (no-read) memory access error; likely due to data in .text.

Bellek denetimi gibi işlemleri gerçekleştirmek için bu sorunu gidermek amacıyla mprotect() çağrısı yaparak salt yürütme segmentlerini okuma+yürütme olarak işaretleyebilirsiniz. Ancak bu erişim izni ayarı, uygulamanız ve kullanıcılarınız için daha iyi koruma sağladığından, daha sonra yalnızca yürütme olarak ayarlamanızı önemle tavsiye ederiz.

Güvenlik

Android 10 aşağıdaki güvenlik değişikliklerini içerir.

TLS 1.3 varsayılan olarak etkindir

Android 10 ve sonraki sürümlerde TLS 1.3, tüm TLS bağlantıları için varsayılan olarak etkindir. TLS 1.3 uygulamamızla ilgili birkaç önemli ayrıntı aşağıda verilmiştir:

  • TLS 1.3 şifre paketleri özelleştirilemez. Desteklenen TLS 1.3 şifre paketleri, TLS 1.3 etkinleştirildiğinde her zaman etkindir. setEnabledCipherSuites() çağrısı yapılarak devre dışı bırakma girişimleri yoksayılır.
  • TLS 1.3 pazarlığı yapılırken oturum önbelleği oturumlara eklenmeden önce HandshakeCompletedListener nesneleri çağrılır. (TLS 1.2 ve önceki sürümlerde bu nesneler, oturumlar oturum önbelleğine eklendikten sonra çağrılır.)
  • SSLEngine örnekleri Android'in önceki sürümlerinde SSLHandshakeException hatası oluşturduğu bazı durumlarda, bu örnekler Android 10 ve sonraki sürümlerde bunun yerine SSLProtocolException hatası oluşturur.
  • 0-RTT modu desteklenmez.

Dilerseniz SSLContext.getInstance("TLSv1.2") numaralı telefonu arayarak TLS 1.3'ün devre dışı bırakıldığı bir SSLContext alabilirsiniz. Ayrıca, uygun bir nesnede setEnabledProtocols() işlevini çağırarak protokol sürümlerini bağlantı bazında etkinleştirebilir veya devre dışı bırakabilirsiniz.

SHA-1 ile imzalanan sertifikalara TLS'de güvenilmez

Android 10'da, SHA-1 karma algoritmasını kullanan sertifikalara TLS bağlantılarında güvenilmez. Kök CA'lar 2016'dan beri bu tür sertifika yayınlamıyor ve Chrome'da veya diğer büyük tarayıcılarda artık bunlara güvenilmiyor.

Bağlantı, SHA-1 kullanan bir sertifika sunan bir siteye ise bağlantı kurma girişimleri başarısız olur.

KeyChain davranışı değişiklikleri ve iyileştirmeleri

Google Chrome gibi bazı tarayıcılar, bir TLS sunucusu TLS el sıkışmasının parçası olarak sertifika isteği mesajı gönderdiğinde kullanıcıların sertifika seçmesine olanak tanır. Android 10'dan itibaren KeyChain nesneleri, kullanıcılara bir sertifika seçim istemi göstermek için KeyChain.choosePrivateKeyAlias() çağrısı yapıldığında kartı verenleri ve anahtar spesifikasyonu parametrelerini dikkate alır. Özellikle bu istem, sunucu özelliklerine uymayan seçenekler içermez.

Kullanıcı tarafından seçilebilecek sertifika yoksa (ör. sunucu spesifikasyonuyla eşleşen sertifika yoksa veya cihazda yüklü sertifika yoksa) sertifika seçim istemi hiç gösterilmez.

Ayrıca, Android 10 veya sonraki sürümlerde anahtarları ya da CA sertifikalarını bir KeyChain nesnesine içe aktarmak için cihaz ekran kilidinin olması gerekmez.

Diğer TLS ve kriptografi değişiklikleri

TLS ve kriptografi kitaplıklarında, Android 10'da geçerli olacak birkaç küçük değişiklik yapılmıştır.

  • AES/GCM/NoPadding ve ChaCha20/Poly1305/NoPadding şifreleri, getOutputSize()'ten daha doğru arabellek boyutları döndürür.
  • TLS_FALLBACK_SCSV şifre paketi, maksimum protokolü TLS 1.2 veya sonraki sürümler olan bağlantı denemelerinden çıkarılır. TLS sunucu uygulamalarında yapılan iyileştirmeler nedeniyle, TLS harici yedekleme denemelerini önermiyoruz. Bunun yerine, TLS sürüm iletişiminin kullanılmasını öneririz.
  • ChaCha20-Poly1305, ChaCha20/Poly1305/NoPadding için bir takma addır.
  • Sonunda nokta bulunan ana makine adları geçerli SNI ana makine adları olarak kabul edilmez.
  • Sertifika yanıtları için imzalama anahtarı seçilirken CertificateRequest içindeki supported_signature_algorithms uzantısına uyulur.
  • Android Anahtar Deposu'ndakiler gibi opak imzalama anahtarları, TLS'de RSA-PSS imzalarıyla kullanılabilir.

Kablosuz doğrudan yayınlar

Android 10'da Kablosuz Direkt ile ilgili aşağıdaki yayınlar kalıcı değildir:

Uygulamanız, yapışkan oldukları için bu yayınları kayıt sırasında alıyorduysa bilgileri almak için başlatma sırasında uygun get() yöntemini kullanın.

Kablosuz duyarlılığı özellikleri

Android 10, Wi-Fi Aware veri yollarını kullanarak TCP/UDP Yuvası oluşturma işlemini kolaylaştırmak için destek ekler. ServerSocket adresine bağlanan bir TCP/UDP soketi oluşturmak için istemci cihazın sunucunun IPv6 adresini ve bağlantı noktasını bilmesi gerekir. Daha önce bu bilgilerin bant dışı olarak (ör. BT veya Wi-Fi Aware katman 2 mesajları kullanılarak) iletilmesi veya mDNS gibi diğer protokoller kullanılarak bant içinde keşfedilmesi gerekiyordu. Android 10'da bilgiler, ağ kurulumunun bir parçası olarak iletilebilir.

Sunucu aşağıdakilerden birini yapabilir:

  • Bir ServerSocket başlatın ve kullanılacak bağlantı noktasını ayarlayın veya edinin.
  • Wi-Fi Aware ağ isteği kapsamında bağlantı noktası bilgilerini belirtin.

Aşağıdaki kod örneğinde, ağ isteğinin bir parçası olarak bağlantı noktası bilgilerinin nasıl belirtileceği gösterilmektedir:

Kotlin

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

Java

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

Ardından istemci, sunucu tarafından sağlanan IPv6 ve bağlantı noktasını almak için bir Wi-Fi Aware ağ isteği gerçekleştirir:

Kotlin

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

Java

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

Go cihazlarda SYSTEM_ALERT_WINDOW

Android 10 (Go sürümü) cihazlarda çalışan uygulamalar SYSTEM_ALERT_WINDOW iznine sahip olamaz. Bunun nedeni, yer paylaşımlı pencerelerin çiziminde aşırı bellek kullanılmasıdır. Bu, özellikle düşük belleğe sahip Android cihazların performansına zarar verir.

Android 9 veya daha eski bir sürümü çalıştıran Go sürümü bir cihazda çalışan bir uygulama SYSTEM_ALERT_WINDOW izni alırsa cihaz Android 10'a yükseltilse bile uygulama iznini korur. Ancak, bu izni henüz almamış uygulamalara cihaz yükseltildikten sonra izin verilemez.

Go cihazlarındaki bir uygulama ACTION_MANAGE_OVERLAY_PERMISSION işlemiyle birlikte bir intent gönderirse sistem, isteği otomatik olarak reddeder ve kullanıcıyı Ayarlar ekranına yönlendirir. Bu ekran, cihazı yavaşlattığı için iznin verilmediğini belirtir. Go cihazındaki bir uygulama Settings.canDrawOverlays() çağrısı yaparsa yöntem her zaman yanlış değerini döndürür. Bu kısıtlamalar, cihaz Android 10'a yükseltilmeden önce SYSTEM_ALERT_WINDOW izni alan uygulamalar için geçerli değildir.

Eski Android sürümlerini hedefleyen uygulamalarla ilgili uyarılar

Android 10 veya sonraki sürümleri çalıştıran cihazlar, Android 5.1 (API düzeyi 22) veya önceki sürümleri hedefleyen bir uygulamayı ilk kez çalıştırdıklarında kullanıcıları uyarır. Uygulama, kullanıcının izin vermesini gerektiriyorsa uygulamanın ilk kez çalıştırılmasına izin verilmeden önce kullanıcıya uygulama izinlerini düzenleme fırsatı da verilir.

Google Play'in hedef API koşulları nedeniyle kullanıcılar bu uyarıları yalnızca yakın zamanda güncellenmemiş bir uygulamayı çalıştırdıklarında görür. Diğer mağazalar üzerinden dağıtılan uygulamalar için benzer hedef API gereksinimleri 2019'da yürürlüğe girecektir. Bu şartlar hakkında daha fazla bilgi için 2019'da hedef API düzeyi şartlarının genişletilmesi bölümüne bakın.

SHA-2 CBC şifre paketleri kaldırıldı

Aşağıdaki SHA-2 CBC şifre paketleri platformdan kaldırıldı:

  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Bu şifre paketleri, GCM kullanan benzer şifre paketlerine kıyasla daha az güvenlidir ve çoğu sunucu bu şifre paketlerinin GCM ve CBC varyantlarını ya destekler ya da hiçbirini desteklemez.

Uygulama kullanımı

Android 10, uygulama kullanımıyla ilgili aşağıdaki davranış değişikliklerini sunar:

  • Ayrıca Android 10, hazır uygulama kullanımını doğru şekilde izler.

HTTPS bağlantısı değişiklikleri

Android 10 çalıştıran bir uygulama null öğesini setSSLSocketFactory()'ye aktarırsa IllegalArgumentException meydana gelir. Önceki sürümlerde null öğesinin setSSLSocketFactory() öğesine geçirilmesi, mevcut varsayılan fabrika ayarını iletmeyle aynı etkiye sahipti.

android.preference kitaplığının desteği sonlandırıldı

android.preference kitaplığının desteği Android 10'dan itibaren sonlandırıldı. Geliştiriciler bunun yerine Android Jetpack'in bir parçası olan AndroidX tercih kitaplığını kullanmalıdır. Taşıma ve geliştirmeye yardımcı olacak ek kaynaklar için güncellenmiş Ayarlar Kılavuzu'nun yanı sıra herkese açık örnek uygulamamız ve referans dokümanlarımıza göz atın.

ZIP dosyası yardımcı programı kitaplığındaki değişiklikler

Android 10, ZIP dosyalarını işleyen java.util.zip paketindeki sınıflarda aşağıdaki değişiklikleri sunar. Bu değişiklikler, kitaplığın davranışını Android ile java.util.zip kullanan diğer platformlar arasında daha tutarlı hale getirir.

Şişirme

Önceki sürümlerde, Inflater sınıfındaki bazı yöntemler end() çağrısından sonra çağrılırsa IllegalStateException hatası fırlatıyordu. Android 10'da bu yöntemler bunun yerine NullPointerException oluşturur.

ZipFile

Android 10 ve sonraki sürümlerde, File, int ve Charset türündeki bağımsız değişkenleri alan ZipFile sınıfının kurucusu, sağlanan ZIP dosyası dosya içermiyorsa ZipException hatası atmaz.

ZipOutputStream

Android 10 ve sonraki sürümlerde, ZipOutputStream içindeki finish() yöntemi dosya içermeyen bir ZIP dosyası için çıkış akışı yazmaya çalıştığında ZipException atmaz.

Kamera değişiklikleri

Kamera kullanan çoğu uygulama, cihaz dikey yapılandırmadaysa fiziksel cihazın da Kamera yönü bölümünde açıklandığı gibi dikey yönde olduğunu varsayar. Bu, geçmişte güvenli bir varsayımdı ancak katlanabilir cihazlar gibi mevcut form faktörlerinin genişlemesiyle bu durum değişti. Bu cihazlardaki bu varsayım, kamera vizörünün yanlış döndürülmesine veya ölçeklendirilmesine (ya da her ikisine birden) yol açabilir.

API düzeyi 24 veya üstünü hedefleyen uygulamalar, android:resizeableActivity değerini açıkça ayarlamalı ve çoklu pencere işlevini yönetmek için gerekli işlevleri sağlamalıdır.

Pil kullanımı takibi

Android 10'dan itibaren SystemHealthManager, önemli bir şarj işleminden sonra cihazın fişi çekildiğinde pil kullanımı istatistiklerini sıfırlar. Genel olarak, önemli bir şarj etkinliği şu durumlarda gerçekleşir: Cihaz tamamen şarj olmuştur veya cihazın şarjı çoğunlukla bitmişken çoğunlukla şarj olmuştur.

Android 10'dan önce, pil seviyesinde ne kadar az değişiklik olursa olsun, cihaz fişe takılıyken pil kullanımı istatistikleri sıfırlanıyordu.

Android Beam'in kullanımdan kaldırılması

Android 10'da, Near Field Communication (NFC) üzerinden cihazlar arasında veri paylaşımı başlatmak için kullanılan eski bir özellik olan Android Beam'i kullanımdan kaldırıyoruz. Ayrıca, ilgili NFC API'lerinden birkaçını da kullanımdan kaldırıyoruz. Android Beam, kullanmak isteyen cihaz üreticisi iş ortakları tarafından isteğe bağlı olarak kullanılabilir ancak artık etkin olarak geliştirilmemektedir. Bununla birlikte Android, diğer NFC özelliklerini ve API'lerini desteklemeye devam edecek. Etiketlerden veri okuma ve ödeme gibi kullanım alanları da beklendiği gibi çalışmaya devam edecektir.

java.math.BigDecimal.stripTrailingZeros() davranışında değişiklik

BigDecimal.stripTrailingZeros() artık giriş değeri sıfır ise sonundaki sıfırları özel durum olarak korumaz.

java.util.regex.Matcher ve Pattern davranışında yapılan değişiklikler

Girişin başında sıfır genişlikli bir eşleşme olduğunda split() işlevinin sonucu, artık boş bir String ("") ile başlamayacak şekilde değiştirildi. Bu durum String.split()'ü de etkiler. Örneğin, "x".split("") artık {"x"} döndürüyor. Android'in eski sürümlerinde ise {"", "x"} döndürüyordu. "aardvark".split("(?=a)" artık {"", "a", "ardv", "ark"} yerine {"a", "ardv", "ark"} döndürüyor.

Geçersiz bağımsız değişkenler için istisna davranışı da iyileştirildi:

  • appendReplacement(StringBuffer, String) artık String yerine IndexOutOfBoundsException yerine IllegalArgumentException atıyor. Değişim String $ ile bitiyorsa artık aynı istisna atılır. Daha önce bu senaryoda istisna atılmamıştı.
  • replaceFirst(null), NullPointerException hatası verirse artık Matcher üzerinde reset()'ı çağırmıyor. NullPointerException artık eşleşme olmadığında da atılır. Daha önce yalnızca eşleşme olduğunda atılıyordu.
  • start(int group), end(int group) ve group(int group), grup dizini sınırları dışındaysa artık daha genel bir IndexOutOfBoundsException hatası veriyor. Daha önce bu yöntemler ArrayIndexOutOfBoundsException hatası veriyordu.

GradientDrawable için varsayılan açı artık TOP_BOTTOM

Android 10'da XML'de bir GradientDrawable tanımlarsanız ve açı ölçümü sağlamazsanız degrade yönü varsayılan olarak TOP_BOTTOM olur. Bu, varsayılan olarak LEFT_RIGHT olan Android'in önceki sürümlerinden farklıdır.

Geçici çözüm olarak, AAPT2'nin en son sürümüne güncellerseniz araç, açı ölçümü belirtilmemişse eski uygulamalar için 0 açı ölçümü ayarlar.

Varsayılan SUID kullanılarak serileştirilmiş nesneler için günlük kaydı

Android 7.0 (API düzeyi 24) sürümünden itibaren platform, serileştirilebilir nesneler için varsayılan serialVersionUID değerinde bir düzeltme yaptı. Bu düzeltme, API düzeyi 23 veya daha düşük olan uygulamaları etkilemedi.

Android 10'dan itibaren, API düzeyi 23 veya altını hedefleyen ve eski, yanlış, varsayılan serialVersionUID değerini kullanan uygulamalarda sistem bir uyarı günlüğe kaydeder ve kod düzeltmesi önerir.

Sistem, aşağıdaki koşulların tümü geçerliyse uyarı günlüğe kaydeder:

  • Uygulama, API düzeyi 23 veya altını hedefliyor.
  • Sınıf serileştirilir.
  • Serileştirilmiş sınıf, açıkça bir serialVersionUID ayarlamak yerine varsayılan serialVersionUID kullanır.
  • Uygulama, API düzeyi 24 veya üstünü hedefliyorsa varsayılan serialVersionUID, serialVersionUID değerinden farklıdır.

Bu uyarı, etkilenen her sınıf için bir kez kaydedilir. Uyarı mesajı, önerilen bir düzeltmeyi içerir. Bu düzeltme, uygulama API düzeyi 24 veya sonraki sürümleri hedeflediğinde hesaplanacak varsayılan değere açık bir şekilde serialVersionUID ayarlanmasını sağlar. Bu düzeltmeyi kullanarak, sınıftaki bir nesnenin API düzeyi 23 veya daha düşük bir uygulamada serileştirilmesi durumunda nesnenin 24 veya daha yüksek API düzeylerini hedefleyen uygulamalar tarafından doğru şekilde okunmasını ve bunun tam tersinin de geçerli olmasını sağlayabilirsiniz.

java.io.FileChannel.map() değişiklikleri

FileChannel.map(), Android 10'dan itibaren boyutu truncate() ile değiştirilemeyen /dev/zero gibi standart olmayan dosyalar için desteklenmez. Android'in önceki sürümleri, truncate() tarafından döndürülen errno değerini yutuyordu ancak Android 10 bir IOException atıyor. Eski davranışa ihtiyacınız varsa yerel kod kullanmanız gerekir.