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ızın targetSdkVersion değerinden bağımsız olarak Android 10'da çalışırken uygulamanız için geçerlidir. Uygulamanızı test etmeniz ve bu değişiklikleri düzgün bir şekilde desteklemek için gerektiği şekilde değiştirmeniz gerekir.

Uygulamanızın targetSdkVersion değeri 29 veya daha yüksekse ek değişiklikleri de desteklemeniz gerekir. Ayrıntılar için Android 10'u (API düzeyi 29) hedefleyen uygulamalarda davranış değişiklikleri başlıklı makaleyi okuyun.

SDK olmayan arayüz kısıtlamaları

Platform, uygulama kararlılığını ve uyumluluğunu sağlamak 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ştiricileriyle yapılan ortak çalışmalar ve en son dahili testler doğrultusunda güncellenmiş kısıtlanmış SDK dışı arayüz listeleri içerir. SDK olmayan arayüzleri kısıtlamadan önce herkese açık alternatiflerin mevcut olduğundan emin olmak istiyoruz.

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ışı bir yöntem veya alan kullanmak her zaman uygulamanızın bozulmasıyla ilgili yüksek risk taşır.

Uygulamanızın SDK dışı arayüzler kullanıp kullanmadığından emin değilseniz öğrenmek için uygulamanızı test edebilirsiniz. Uygulamanız SDK olmayan arayüzleri kullanıyorsa SDK alternatiflerine geçiş planlamaya başlamalısınız. Bununla birlikte, bazı uygulamaların SDK dışı arayüzleri kullanmak için geçerli kullanım alanları olduğunu biliyoruz. Uygulamanızdaki bir özellik için SDK dışı arayüz kullanmaya alternatif bulamıyorsanız yeni bir herkese açık 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üzlerde kısıtlamalar başlıklı makaleleri inceleyin.

Hareketle Gezinme

Android 10'dan itibaren kullanıcılar cihaz genelinde hareketle gezinmeyi etkinleştirebilir. Kullanıcı, hareketle gezinmeyi etkinleştirirse bu durum, uygulamanın hedef 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 bölümleri için bu hareketi özellikle geçersiz kılıyorsa bu durum geçerli değildir.

Uygulamanızı hareketle gezinme ile uyumlu hale getirmek için uygulama içeriğini uçtan uca genişletmeniz ve çakışan hareketleri uygun şekilde işlemeniz gerekir. Bilgi için Hareketle gezinme belgelerine bakın.

NDK

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

Paylaşılan nesneler metin yer değiştirmeleri içeremez

Android 6.0 (API düzeyi 23), paylaşılan nesnelerde metin yer değiştirmelerinin 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ği iyileştirir.

SELinux, Android 10 veya sonraki sürümleri hedefleyen uygulamalarda bu kısıtlamayı uygular. Bu uygulamalar, metin yer değiştirmeleri içeren paylaşılan nesneleri kullanmaya devam ederse bozulma riski yüksektir.

Bionic kitaplıklarında ve dinamik bağlayıcı yollarında yapılan değişiklikler

Android 10'dan itibaren, normal dosyalar yerine sembolik bağlantılar olan çeşitli yollar vardır. Yolların normal dosyalar olmasına dayanan 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. 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 için bir sembolik bağlantıdır. Bu nedenle dlopen(“/system/lib/libc.so”) çalışmaya devam eder ancak uygulamalar, /proc/self/maps veya benzerini okuyarak yüklenen kitaplıkları incelemeye çalıştığında farkı görür. Bu durum normal olmasa da bazı uygulamaların bilgisayar korsanlığına karşı koruma sürecinin bir parçası olarak bunu yaptığını tespit ettik. Bu durumda, /apex/… yolları Bionic dosyaları için geçerli yollar olarak eklenmelidir.

Yalnızca yürütme belleğiyle 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 yalnızca yürütülebilir (okunamaz) belleğe eşlenir. Uygulamanız, salt yürütme olarak işaretlenmiş bellek segmentlerinde okuma işlemleri gerçekleştirirse (hata, güvenlik açığı veya kasıtlı Bellek Denetleyicisi nedeniyle) sistem, uygulamanıza SIGSEGV sinyali gönderir.

/data/tombstones/ dizinindeki ilgili tombstone dosyasını inceleyerek bu davranışın kilitlenmeye neden olup olmadığını belirleyebilirsiniz. Yalnızca yürütme ile ilgili bir kilitlenme, aşağıdaki iptal mesajını içerir:

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

Bellek Denetleyicisi gibi işlemleri gerçekleştirmek için bu sorunu geçici olarak çözmek amacıyla mprotect() işlevini çağırarak yalnızca 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 tekrar salt 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 etkin

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ıyı aşağıda bulabilirsiniz:

• TLS 1.3 şifreleme paketleri özelleştirilemez. TLS 1.3 etkinleştirildiğinde, desteklenen TLS 1.3 şifreleme paketleri her zaman etkinleştirilir. setEnabledCipherSuites() yöntemini çağırarak bunları devre dışı bırakma girişimleri yoksayılır.
• TLS 1.3 üzerinde anlaşmaya varıldığında, oturumlar oturum önbelleğine eklenmeden önce HandshakeCompletedListener nesneleri çağrılır. (TLS 1.2 ve diğer önceki sürümlerde bu nesneler, oturumlar oturum önbelleğine eklendikten sonra çağrılır.)
• Android'in önceki sürümlerinde SSLEngine örneklerinin SSLHandshakeException hatası verdiği bazı durumlarda, bu örnekler Android 10 ve sonraki sürümlerde SSLProtocolException hatası verir.
• 0-RTT modu desteklenmez.

İsterseniz SSLContext.getInstance("TLSv1.2") çağrısı yaparak TLS 1.3'ün devre dışı bırakıldığı bir SSLContext elde edebilirsiniz. Ayrıca, uygun bir nesnede setEnabledProtocols() yöntemini çağırarak protokol sürümlerini bağlantı bazında etkinleştirebilir veya devre dışı bırakabilirsiniz.

SHA-1 ile imzalanmış sertifikalara TLS'de güvenilmez

Android 10'da, SHA-1 karma algoritmasını kullanan sertifikalar TLS bağlantılarında güvenilir olarak kabul edilmez. Kök CA'lar 2016'dan beri bu tür sertifikalar vermemektedir ve Chrome veya diğer önemli tarayıcılarda artık güvenilir olarak kabul edilmemektedir.

SHA-1 kullanan bir sertifika sunan siteye bağlanma 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 bir 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 sertifika seçme istemi göstermek için KeyChain.choosePrivateKeyAlias() yöntemini çağırırken verenleri ve anahtar spesifikasyon parametrelerini dikkate alır. Özellikle bu istem, sunucu spesifikasyonlarına 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çme istemi gösterilmez.

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

Diğer TLS ve kriptografi değişiklikleri

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

• AES/GCM/NoPadding ve ChaCha20/Poly1305/NoPadding şifreleri, getOutputSize() sınıfından daha doğru arabellek boyutları döndürür.
• TLS_FALLBACK_SCSV şifre paketi, maksimum protokolü TLS 1.2 veya daha yüksek olan bağlantı denemelerinden çıkarılır. TLS sunucu uygulamalarındaki iyileştirmeler nedeniyle TLS harici yedekleme denemenizi önermiyoruz. Bunun yerine TLS sürüm anlaşmasını kullanmanızı öneririz.
• ChaCha20-Poly1305, ChaCha20/Poly1305/NoPadding için bir takma addır.
• Sonunda nokta olan 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ı dikkate alınır.
• Android Keystore'dakiler gibi opak imzalama anahtarları, TLS'de RSA-PSS imzalarıyla kullanılabilir.

Kablosuz Doğrudan Bağlantı yayınları

Android 10'da, Wi-Fi Direct ile ilgili aşağıdaki yayınlar yapışkan değildir:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

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

Wi-Fi Aware özellikleri

Android 10, Wi-Fi Aware veri yollarını kullanarak TCP/UDP soketi oluşturmayı kolaylaştıran bir destek ekler. ServerSocket sunucusuna bağlanan bir TCP/UDP soketi oluşturmak için istemci cihazın sunucunun IPv6 adresini ve bağlantı noktasını bilmesi gerekir. Bu anahtarın daha önce bant dışı olarak (ör. BT veya Wi-Fi Aware katman 2 mesajlaşması kullanılarak) iletilmesi ya da mDNS gibi diğer protokoller kullanılarak bant içi olarak keşfedilmesi gerekiyordu. Android 10'da bu bilgiler ağ kurulumu sırasında iletilebilir.

Sunucu aşağıdakilerden birini yapabilir:

• ServerSocket başlatın ve kullanılacak bağlantı noktasını ayarlayın veya alın.
• Bağlantı noktası bilgilerini Wi-Fi Aware ağ isteğinin bir parçası olarak belirtin.

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

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()

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, IPv6'yı ve sunucu tarafından sağlanan bağlantı noktasını almak için bir Wi-Fi Aware ağ isteği gönderir:

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)

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 iznini alamaz. Bunun nedeni, pencere çiziminin aşırı bellek kullanmasıdır. Bu durum, özellikle düşük bellekli Android cihazların performansına zarar verir.

Android 9 veya önceki bir sürümün yüklü olduğu Go sürümü cihazda çalışan bir uygulama SYSTEM_ALERT_WINDOW iznini alırsa cihaz Android 10'a yükseltilse bile uygulama bu izni korur. Ancak bu izne sahip olmayan uygulamalara, cihaz yeni sürüme geçirildikten sonra izin verilemez.

Go cihazındaki bir uygulama ACTION_MANAGE_OVERLAY_PERMISSION işlemiyle bir intent gönderirse sistem isteği otomatik olarak reddeder ve kullanıcıyı, iznin cihazı yavaşlattığı için verilmediğini belirten bir Ayarlar ekranına yönlendirir. Go cihazındaki bir uygulama Settings.canDrawOverlays() yöntemini çağırırsa yöntem her zaman false 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.

Android'in eski 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 daha eski 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 uygulamanın izinlerini ayarlama fırsatı da verilir.

Google Play'in hedef API şartları nedeniyle kullanıcılar bu uyarıları yalnızca yakın zamanda güncellenmemiş bir uygulamayı çalıştırdıklarında görürler. Diğer mağazalar üzerinden dağıtılan uygulamalar için benzer hedef API şartları 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 kapsamını genişletme başlıklı makaleyi inceleyin.

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

Aşağıdaki SHA-2 CBC şifreleme 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 şifreleme paketleri, GCM kullanan benzer şifreleme paketlerine göre daha az güvenlidir ve çoğu sunucu, bu şifreleme paketlerinin hem GCM hem de CBC varyantlarını destekler veya hiçbirini desteklemez.

Uygulama kullanımı

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

• UsageStats uygulama kullanımı iyileştirmeleri - Android 10, uygulamalar bölünmüş ekran veya pencere içinde pencere modunda kullanıldığında UsageStats ile uygulama kullanımını doğru bir şekilde izler. Ayrıca Android 10, hazır uygulama kullanımını doğru şekilde izler.

• Uygulama bazında gri tonlama - Android 10, uygulama bazında gri tonlamalı ekran modu ayarlayabilir.

• Uygulama bazında dikkat dağıtma durumu - Android 10, uygulamaları seçerek "dikkat dağıtma durumuna" ayarlayabilir. Bu durumda uygulamaların bildirimleri bastırılır ve önerilen uygulamalar olarak görünmezler.

• Askıya alma ve oynatma - Android 10'da askıya alınan uygulamalar ses çalamaz.

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

Android 10 çalıştıran bir uygulama null değerini setSSLSocketFactory() yöntemine iletirse IllegalArgumentException hatası oluşur. Önceki sürümlerde, null değerini setSSLSocketFactory() yöntemine iletmek, geçerli varsayılan fabrikayı iletmekle aynı etkiye sahipti.

android.preference kitaplığı kullanımdan kaldırıldı

android.preference kitaplığının desteği Android 10 itibarıyla sonlandırılmıştır. Geliştiriciler bunun yerine Android Jetpack'in bir parçası olan AndroidX tercih kitaplığını kullanmalıdır. Taşıma ve geliştirme sürecinde yardımcı olacak ek kaynaklar için güncellenmiş Ayarlar Kılavuzu'nun yanı sıra herkese açık örnek uygulamamızı ve referans belgelerimizi inceleyin.

ZIP dosyası yardımcı program kitaplığı değişiklikleri

Android 10, ZIP dosyalarını işleyen java.util.zip paketindeki sınıflarda aşağıdaki değişiklikleri yapar. 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 pompası

Önceki sürümlerde, Inflater sınıfındaki bazı yöntemler end() çağrısından sonra çağrıldığında IllegalStateException hatası veriyordu. Android 10'da bu yöntemler bunun yerine NullPointerException hatası verir.

ZipFile

Android 10 ve sonraki sürümlerde, File, int ve Charset türünde bağımsız değişkenler alan ZipFile için oluşturucu, sağlanan ZIP dosyası herhangi bir dosya içermiyorsa ZipException hatası vermez.

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ışırsa ZipException hatası vermez.

Kamera değişiklikleri

Kamera kullanan birçok uygulama, cihaz dikey yapılandırmadaysa fiziksel cihazın da dikey yönde olduğunu varsayar. Bu durum, Kamera yönü bölümünde açıklanmıştır. 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) neden olabilir.

API düzeyi 24 veya üstünü hedefleyen uygulamalar, android:resizeableActivity özelliğini açıkça ayarlamalı ve çok pencereli işlemi gerçekleştirmek için gerekli işlevleri sağlamalıdır.

Pil kullanımı takibi

Android 10'dan itibaren SystemHealthManager, büyük bir şarj etkinliğinden sonra cihazın fişi her çekildiğinde pil kullanım istatistiklerini sıfırlar. Genel olarak, önemli bir şarj etkinliği şunlardan biridir: Cihaz tamamen şarj edilmiştir veya cihazın şarjı çoğunlukla boşken çoğunlukla dolu hale gelmiştir.

Android 10'dan önce, pil seviyesinde ne kadar az değişiklik olursa olsun cihazın fişi her çekildiğinde pil kullanım istatistikleri sıfırlanırdı.

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

Android 10'da, Near Field Communication (NFC) aracılığıyla cihazlar arasında veri paylaşımı başlatmaya yönelik eski bir özellik olan Android Beam'i resmi olarak kullanımdan kaldırıyoruz. Ayrıca ilgili NFC API'lerinden bazılarını da kullanımdan kaldırıyoruz. Android Beam, kullanmak isteyen cihaz üreticisi iş ortakları için isteğe bağlı olarak kullanılabilir ancak artık etkin geliştirme aşamasında değildir. Ancak Android, diğer NFC özelliklerini ve API'lerini desteklemeye devam edecek. Etiketlerden okuma ve ödeme gibi kullanım alanları da beklendiği gibi çalışmaya devam edecek.

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

BigDecimal.stripTrailingZeros(), giriş değeri sıfırsa özel bir durum olarak sondaki sıfırları artık korumaz.

java.util.regex.Matcher ve Pattern davranış değişiklikleri

split() işlevinin sonucu, girişin başında sıfır genişlikli bir eşleşme olduğunda artık boş bir String ("") ile başlamayacak şekilde değiştirildi. Bu durum String.split() için de geçerlidir. Örneğin, "x".split("") artık {"x"} değerini döndürürken Android'in eski sürümlerinde {"", "x"} değerini 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), değiştirme String geçersiz bir şekilde tek bir ters eğik çizgiyle bitiyorsa artık IndexOutOfBoundsException yerine IllegalArgumentException hatası veriyor. Değiştirme String, $ ile biterse de aynı istisna oluşturulur. Daha önce bu senaryoda istisna oluşturulmuyordu.
• replaceFirst(null), NullPointerException hatası verirse artık Matcher üzerinde reset() yöntemini çağırmaz. NullPointerException artık eşleşme olmadığında da oluşturulur. Daha önce yalnızca eşleşme olduğunda oluşturuluyordu.
• start(int group), end(int group) ve group(int group), grup dizini sınırların dışındaysa artık daha genel bir IndexOutOfBoundsException hatası veriyor. Bu yöntemler daha önce ArrayIndexOutOfBoundsException hatası veriyordu.

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

Android 10'da, XML'de bir GradientDrawable tanımlar ve açı ölçümü sağlamazsanız gradyan yönü varsayılan olarak TOP_BOTTOM olur. Bu, varsayılan değerin LEFT_RIGHT olduğu önceki Android sürümlerine göre bir değişikliktir.

Geçici bir çö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) ile birlikte 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, bir uygulama API düzeyi 23 veya daha düşük bir sürümü hedefliyorsa ve eski, yanlış, varsayılan serialVersionUID değerini kullanıyorsa sistem bir uyarı kaydeder ve kod düzeltmesi önerir.

Özellikle, aşağıdaki koşulların tümü karşılanıyorsa sistem bir uyarı kaydeder:

• Uygulama, API düzeyi 23 veya daha altını hedefliyor.
• Bir sınıf serileştirilir.
• Serileştirilmiş sınıf, açıkça bir serialVersionUID ayarlamak yerine varsayılan serialVersionUID değerini kullanıyor.
• Varsayılan serialVersionUID, uygulamanın hedef API düzeyi 24 veya daha yüksek bir sürümü hedeflemesi durumunda geçerli olacak serialVersionUID değerinden farklıdır.

Bu uyarı, etkilenen her sınıf için bir kez günlüğe kaydedilir. Uyarı mesajında, uygulamanın hedef API düzeyi 24 veya daha yüksek bir sürümü hedeflemesi durumunda hesaplanacak varsayılan değere serialVersionUID değerini açıkça ayarlamak olan önerilen bir düzeltme yer alır. Bu düzeltmeyi kullanarak, API düzeyi 23 veya daha düşük bir sürümü hedefleyen bir uygulamada bu sınıftan bir nesne serileştirilirse nesnenin, 24 veya daha yüksek bir sürümü hedefleyen uygulamalar tarafından doğru şekilde okunmasını sağlayabilirsiniz. Bu durum, tam tersi için de geçerlidir.

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

Android 10'dan itibaren FileChannel.map(), truncate() kullanılarak boyutu 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'yu yutuyordu ancak Android 10 bir IOException hatası veriyor. Eski davranışa ihtiyacınız varsa yerel kod kullanmanız gerekir.