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

Android 17 platformu, uygulamanızı etkileyebilecek davranış değişiklikleri içerir. Aşağıdaki davranış değişiklikleri, targetSdkVersion değerinden bağımsız olarak Android 17'de çalışan tüm uygulamalar için geçerlidir. Uygulamanızı test etmeli ve uygun olduğu durumlarda bu değişiklikleri desteklemek için uygulamanızı gerektiği şekilde değiştirmelisiniz.

Yalnızca Android 17'yi hedefleyen uygulamaları etkileyen davranış değişiklikleri listesini de incelemeyi unutmayın.

Temel işlevler

Android 17 (API düzeyi 37), Android sisteminin çeşitli temel özelliklerini değiştiren veya genişleten aşağıdaki değişiklikleri içerir.

Uygulama bellek sınırları

Android 17, uygulamalarınız ve Android kullanıcıları için daha kararlı ve deterministik bir ortam oluşturmak amacıyla cihazın toplam RAM'ine göre uygulama bellek sınırları getiriyor. Bu sınırlar, bellek sızıntılarına ve diğer aykırı değerlere odaklanarak sistem genelinde kararsızlığa yol açıp kullanıcı arayüzünün titremesine, pilin daha hızlı tükenmesine ve uygulamaların kapatılmasına neden olmalarını engeller. Uygulama oturumlarının büyük çoğunluğunun bu durumdan en az düzeyde etkileneceğini tahmin etsek de bellek için bir temel oluşturmak da dahil olmak üzere aşağıdaki en iyi bellek uygulamalarını kullanmanızı öneririz.

Uygulama oturumunuzun etkilenip etkilenmediğini ApplicationExitInfo içinde getDescription işlevini çağırarak belirleyebilirsiniz. Uygulamanız etkilenmişse çıkış nedeni REASON_OTHER olur ve açıklamada "MemoryLimiter:AnonSwap" dizesiyle birlikte diğer bilgiler yer alır. Bellek sınırı aşıldığında toplanan yığın dökümlerini almak için TRIGGER_TYPE_ANOMALY ile tetikleyici tabanlı profil oluşturma özelliğini de kullanabilirsiniz.

Uygulamanızın belleğini yönetme dokümanında, uygulamanızın bellek sorunlarını teşhis etmenize ve kaynak tüketimini optimize etmenize yardımcı olacak bilgiler yer alır.

Uygulamanızın bellek kısıtlamaları altındaki davranışını test etme

Bellek sınırlarını uygulayan cihazlarda bu sınırları ayarlamak veya devre dışı bırakmak için Android Debug Bridge'i (adb) kullanabilirsiniz. Kabuk komutu am bellek sınırlarını ayarlamak için üç alt komut sağlar. (Bu komutlar, bellek sınırı olmayan cihazlarda etkili olmaz.)

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

Bellek sınırlayıcıya bazı veya tüm işlemleri yoksayma talimatı verir. UID (Android Kullanıcı Kimliği) iletildiğinde bellek sınırlayıcı, bu UID ile ilişkili tüm işlemler için zorlamayı yoksayma talimatı alır. Ayrıca all (tüm uygulamaları yoksay) veya none (hiçbir uygulamayı yoksayma) değerini de iletebilirsiniz. none değerinin iletilmesi, am memory-limiter ignore için yapılan önceki tüm çağrıları geçersiz kılar.

Bellek sınırlayıcıya bir UID'yi yoksayma talimatı verirseniz am memory-limiter manual işlevini çağırarak uygulama içindeki bir işleme manuel bellek sınırı uygulayabilirsiniz.

manual

Sisteme, belirtilen PID (işlem kimliği) ile işleme bellek kısıtlaması uygulama talimatı verir. Bellek kısıtlaması MB cinsinden bir tam sayı olarak belirtilir. Örneğin, 30 iletildiğinde işlemin 30 MB bellek ile sınırlandırıldığı belirtilir. max iletildiğinde bu işlemle ilgili tüm bellek sınırlamaları kaldırılır. none iletildiğinde, süreçte belirlenen tüm manuel sınırlar kaldırılır ve sistemin varsayılan sınırı (varsa) geri yüklenir.

status

Bellek sınırlayıcının mevcut durumunu bildirir. Durum, görünür ve görünür olmayan işlemlere uygulanan bellek sınırlarını içerir.

Gizlilik

Android 17, kullanıcı gizliliğini iyileştirmek için aşağıdaki değişiklikleri içerir.

SMS OTP koruması

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

Güvenlik

Android 17, cihaz ve uygulama güvenliğiyle ilgili aşağıdaki iyileştirmeleri içerir.

usesClearTraffic desteğini sonlandırma planı

In a future release, we plan to deprecate the usesCleartextTraffic element. Apps that need to make unencrypted (HTTP) connections should migrate to using a network security configuration file, which lets you specify which domains your app needs to make cleartext connections to.

Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:

  • Set the usesCleartextTraffic attribute to true
  • Use a network configuration file

If your app's minimum API level is 24 or higher, you can use a network configuration file and you don't need to set usesCleartextTraffic.

Örtülü URI izinlerini kısıtlama

Currently, if an app launches an intent with a URI that has the action ACTION_SEND, ACTION_SEND_MULTIPLE, or ACTION_IMAGE_CAPTURE, the system automatically grants the read and write URI permissions to the target app. Starting in Android 18, the system will no longer automatically grant these permissions. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

To detect the usage of these intents in your app, use StrictMode with detectImplicitUriPermissionGrant() to trigger a violation:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

Alternatively, you can monitor for logged exceptions containing the message Please set the grant explicitly in the app that appears when system implicitly sets the grant. You can monitor for these logs using the following adb command:

adb logcat | grep "Please set the grant explicitly in the app"

To explicitly grant the necessary permissions, add the FLAG_GRANT_READ_URI_PERMISSION flag to ACTION_SEND and ACTION_SEND_MULTIPLE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Include both FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags for ACTION_IMAGE_CAPTURE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Uygulama başına anahtar deposu sınırları

Uygulamalar, cihazdaki tüm uygulamalar için paylaşılan bir kaynak olduğundan Android anahtar deposunda çok sayıda anahtar oluşturmaktan kaçınmalıdır. Android 17'den itibaren sistem, bir uygulamanın sahip olabileceği anahtar sayısını sınırlamaktadır. Android 17 (API düzeyi 37) veya sonraki sürümleri hedefleyen sistem dışı uygulamalar için sınır 50.000 anahtar, diğer tüm uygulamalar için ise 200.000 anahtardır. Sistem uygulamaları, hangi API düzeyini hedeflediklerinden bağımsız olarak 200.000 anahtarla sınırlıdır.

Bir uygulama sınırın üzerinde anahtar oluşturmaya çalışırsa oluşturma işlemi KeyStoreException ile başarısız olur. İstisnanın ileti dizesinde anahtar sınırı hakkında bilgiler yer alır. Uygulama, istisna durumunda getNumericErrorCode() çağrısı yaparsa döndürülen değer, uygulamanın hedeflediği API düzeyine bağlıdır:

  • Android 17'yi (API düzeyi 37) veya sonraki sürümleri hedefleyen uygulamalar: getNumericErrorCode() yeni ERROR_TOO_MANY_KEYS değerini döndürür.
  • Diğer tüm uygulamalar: getNumericErrorCode() döndürür ERROR_INCORRECT_USAGE.

Profiller arası geri döngü trafiğini engelleme

Android 17'den itibaren, profiller arası geri döngü trafiğine varsayılan olarak izin verilmemektedir. Aynı profil içindeki geri döngü trafiği etkilenmez. Bu değişiklik, uygulamanın hedeflediği API düzeyinden bağımsız olarak Android 17 veya sonraki sürümlerde çalışan tüm uygulamalar için geçerlidir.

Kullanıcı deneyimi ve sistem arayüzü

Android 17, daha tutarlı ve sezgisel bir kullanıcı deneyimi oluşturmak için aşağıdaki değişiklikleri içerir.

Döndürme işleminden sonra varsayılan IME görünürlüğünü geri yükleme

从 Android 17 开始，当设备的配置发生变化（例如，通过旋转）且应用本身未处理此变化时，系统不会恢复之前的 IME 可见性。

如果应用经历了它无法处理的配置更改，并且应用需要在更改后显示键盘，您必须明确请求此行为。您可以通过以下方式之一提出此要求：

  • 将 android:windowSoftInputMode 属性设置为 stateAlwaysVisible。
  • 在 activity 的 onCreate() 方法中以编程方式请求显示软键盘，或添加 onConfigurationChanged() 方法。

İnsan girdisi

Android 17, uygulamaların klavye ve dokunmatik yüzey gibi insan giriş cihazlarıyla etkileşimini etkileyen aşağıdaki değişiklikleri içerir.

Dokunmatik alanlar, işaretçi yakalama sırasında varsayılan olarak göreli etkinlikler sunar.

Android 17'den itibaren bir uygulama View.requestPointerCapture() kullanarak işaretçi yakalama isteğinde bulunursa ve kullanıcı dokunmatik yüzey kullanırsa sistem, kullanıcının dokunuşlarından işaretçi hareketini ve kaydırma hareketlerini tanır ve bunları, yakalanan bir fareden gelen işaretçi ve kaydırma tekerleği hareketleriyle aynı şekilde uygulamaya bildirir. Çoğu durumda bu, yakalanan fareleri destekleyen uygulamaların dokunmatik yüzeyler için özel işleme mantığı eklemesini gerektirmez. Daha fazla bilgi için View.POINTER_CAPTURE_MODE_RELATIVE dokümanlarına bakın.

Daha önce sistem, dokunma yüzeyindeki hareketleri tanımaya çalışmıyordu. Bunun yerine, parmakların ham ve mutlak konumlarını dokunmatik ekran dokunuşlarına benzer bir biçimde uygulamaya iletiyordu. Bir uygulama hâlâ bu mutlak verileri gerektiriyorsa bunun yerine View.requestPointerCapture(int) yöntemini View.POINTER_CAPTURE_MODE_ABSOLUTE ile çağırmalıdır.

Medya

Android 17, medya davranışıyla ilgili aşağıdaki değişiklikleri içerir.

Arka planda ses sağlamlaştırma

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

For more information, including mitigation strategies, see Background audio hardening.

Bağlantı

Android 17, cihaz bağlantısını geliştirmek için aşağıdaki değişiklikleri içerir.

Bluetooth bağlantı kaybı durumunda otomatik olarak yeniden eşleme

Android 17, Bluetooth bağlantı kaybını otomatik olarak çözmek için tasarlanmış sistem düzeyinde bir geliştirme olan bağımsız yeniden eşlemeyi sunar.

Daha önce, bir bağlantı kaybolduğunda kullanıcıların çevre biriminin eşlemesini kaldırmak ve ardından yeniden eşlemek için Ayarlar'a manuel olarak gitmesi gerekiyordu. Bu özellik, Android 16'daki güvenlik iyileştirmesini temel alır. Kullanıcıların çevre birimlerinin eşlemesini kaldırmak ve yeniden eşlemek için Ayarlar'a manuel olarak gitmesini gerektirmeden sistemin arka planda bağları yeniden kurmasına olanak tanır.

Çoğu uygulama için kod değişikliği gerekmez ancak geliştiricilerin Bluetooth yığınındaki aşağıdaki davranış değişikliklerinden haberdar olması gerekir:

  • Yeni eşleme bağlamı: ACTION_PAIRING_REQUEST artık EXTRA_PAIRING_CONTEXT ekstrasını içeriyor. Bu ekstra, uygulamaların standart bir eşleme isteği ile otonom sistem tarafından başlatılan yeniden eşleme girişimi arasında ayrım yapmasına olanak tanır.
  • Koşullu anahtar güncellemeleri: Mevcut güvenlik anahtarları yalnızca yeniden eşleme başarılı olursa ve yeni bağlantı, önceki bağlantının güvenlik düzeyini karşılarsa veya aşarsa değiştirilir.
  • Değiştirilmiş amaç zamanlaması: ACTION_KEY_MISSING amacı artık yalnızca bağımsız yeniden eşleme girişimi başarısız olursa yayınlanır. Bu, sistem arka planda bağı başarıyla kurtarırsa uygulamadaki gereksiz hata işlemeyi azaltır.
  • Kullanıcı bildirimi: Sistem, yeni kullanıcı arayüzü bildirimleri ve iletişim kutuları aracılığıyla yeniden eşlemeyi yönetir. Kullanıcılardan, yeniden eşleme girişimini onaylamaları istenir. Böylece yeniden bağlantı kurulduğundan haberdar olurlar.

Çevre birimi üreticileri ve yardımcı uygulama geliştiricileri, donanım ve uygulamanın bağ geçişlerini sorunsuz bir şekilde gerçekleştirdiğini doğrulamalıdır. Bu davranışı test etmek için aşağıdaki yöntemlerden birini kullanarak uzaktan bağlantı kaybını simüle edin:

  • Bağlantı bilgilerini çevre biriminden manuel olarak kaldırma
  • Cihazın eşlemesini manuel olarak kaldırın: Ayarlar > Bağlı cihazlar