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 gibi 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 引入了基于设备总 RAM 的应用内存限制，以便为您的应用和 Android 用户打造更稳定、更确定的环境。在 Android 17 中，系统会保守地设置限制，以建立系统基准，在极端内存泄漏和其他异常情况导致系统范围内的不稳定（导致界面卡顿、耗电过快和应用被终止）之前，针对这些情况采取措施。虽然我们预计此变化对绝大多数应用会话的影响微乎其微，但我们建议您遵循以下内存最佳实践，包括建立内存基准。

您可以通过在 ApplicationExitInfo 中调用 getDescription 来确定应用会话是否受到影响；如果应用受到影响，退出原因将为 REASON_OTHER，说明将包含字符串 "MemoryLimiter:AnonSwap" 以及其他信息。您还可以将 TRIGGER_TYPE_ANOMALY 与基于触发器的分析搭配使用，以获取在达到内存限制时收集的堆转储。

管理应用的内存文档提供的信息可帮助您诊断应用的内存问题并优化其资源消耗。

在内存受限的情况下测试应用的运行情况

您可以使用 Android 调试桥 (adb) 调整或停用任何施加内存限制的设备上的内存限制。shell 命令 am 提供了三个用于调整内存限制的子命令。（这些命令对未施加内存限制的设备没有影响。）

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

指示内存限制器忽略部分或全部进程。传递 UID（Android 用户 ID）会指示内存限制器忽略对与该 UID 相关联的所有进程的强制执行。您还可以传递 all（忽略所有应用）或 none（不忽略任何应用）。传递 none 会替换之前对 am memory-limiter ignore 的任何调用。

如果您指示内存限制器忽略某个 UID，您仍然可以通过调用 am memory-limiter manual 为应用内的进程应用手动内存限制。

manual

指示系统对具有指定 PID（进程 ID）的进程施加内存限制。内存限制以整数形式的 MB 数指定；例如，传递 30 指定进程的内存限制为 30 MB。传递 max 会移除相应进程的所有内存限制。 传递 none 会移除对进程设置的所有手动限制，从而恢复系统的默认限制（如果有）。

status

报告内存限制器的当前状态。该状态包括对可见进程和非可见进程施加的内存限制。

Gizlilik

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

SMS OTP koruması

Android 17'den itibaren Android, tek kullanımlık şifre (OTP) içeren SMS mesajları için korumasını genişletiyor.

Android'in önceki sürümlerinde bu koruma öncelikle SMS Retriever biçimine odaklanıyordu. SMS alıcı karması içeren mesajların teslimi, çoğu uygulamada üç saat gecikiyordu. Ancak belirli uygulamalar (ör. varsayılan SMS işleyici) gecikmeden muaf tutulmuştu ve karma değerin sahibi olan uygulama da muaf tutulmuştu.

Android 17'den itibaren koruma, WebOTP biçimli mesajlara da uygulanır. Bir uygulamanın SMS mesajlarını okuma izni varsa ancak alan doğrulamasıyla belirlendiği üzere WebOTP mesajının amaçlanan alıcısı değilse mesaj, alındıktan üç saat sonrasına kadar uygulamaya erişilemez. Bu değişiklik, yalnızca mesajda belirtilen alanla ilişkili uygulamaların doğrulama kodunu programatik olarak okuyabilmesini sağlayarak kullanıcı güvenliğini artırmayı amaçlamaktadır.

Bu üç saatlik gecikme süresinde SMS_RECEIVED_ACTION yayını engellenir ve SMS sağlayıcı veritabanı sorguları filtrelenir. SMS mesajı, gecikme süresinden sonra bu uygulamalarda kullanılabilir. Bu değişiklik, hedef API seviyelerinden bağımsız olarak tüm uygulamalar için geçerlidir.

Varsayılan SMS asistanı uygulaması ve bağlı cihaz yardımcı uygulamaları gibi belirli uygulamalar bu gecikmeden muaftır. OTP çıkarma için SMS mesajlarını okumaya dayalı tüm uygulamalar, işlevselliğin devam etmesini sağlamak için SMS Retriever veya SMS User Consent API'lerini kullanmaya geçmelidir.

Güvenlik

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

usesClearTraffic desteğini sonlandırma planı

Gelecekteki bir sürümde usesCleartextTraffic öğesinin desteğini sonlandırmayı planlıyoruz. Şifrelenmemiş (HTTP) bağlantılar oluşturması gereken uygulamalar, ağ güvenlik yapılandırması dosyası kullanmaya geçmelidir. Bu dosya, uygulamanızın hangi alan adlarına şifresiz metin bağlantıları oluşturması gerektiğini belirtmenize olanak tanır.

Ağ güvenlik yapılandırma dosyalarının yalnızca API seviyesi 24 ve sonraki sürümlerde desteklendiğini unutmayın. Uygulamanızın minimum API düzeyi 24'ten düşükse aşağıdakilerin ikisini de yapmanız gerekir:

  • usesCleartextTraffic özelliğini true olarak ayarlayın.
  • Ağ yapılandırma dosyası kullanma

Uygulamanızın minimum API düzeyi 24 veya daha yüksekse ağ yapılandırma dosyası kullanabilirsiniz ve usesCleartextTraffic şeklinde ayarlamanız gerekmez.

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

目前，如果应用启动的 intent 具有 URI，且该 URI 具有操作 ACTION_SEND、ACTION_SEND_MULTIPLE或 ACTION_IMAGE_CAPTURE，则系统会自动向目标应用授予读取和 写入 URI 权限。从 Android 18 开始，系统将 不再自动授予这些权限。因此，我们建议应用明确授予相关 URI 权限，而不是依赖系统授予这些权限。

如需检测应用中这些 intent 的使用情况，请将 StrictMode 与 detectImplicitUriPermissionGrant() 结合使用，以触发违规行为：

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

或者，您也可以监控包含消息 Please set the grant explicitly in the app 的已记录异常，该消息会在系统隐式设置授予时显示。您可以使用以下 adb 命令监控这些日志：

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

如需明确授予必要的权限，请将 FLAG_GRANT_READ_URI_PERMISSION标志添加到ACTION_SEND和 ACTION_SEND_MULTIPLEintent：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

对于 ACTION_IMAGE_CAPTURE intent，请同时添加FLAG_GRANT_READ_URI_PERMISSION 和 FLAG_GRANT_WRITE_URI_PERMISSION 标志：

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'den itibaren, cihazın yapılandırması değiştiğinde (ör. döndürme yoluyla) ve bu değişiklik uygulamanın kendisi tarafından işlenmediğinde önceki IME görünürlüğü geri yüklenmez.

Uygulamanızın, işlemeyeceği bir yapılandırma değişikliğine uğraması ve değişiklikten sonra klavyenin görünür olması gerekiyorsa bunu açıkça istemeniz gerekir. Bu isteği aşağıdaki yöntemlerden biriyle yapabilirsiniz:

  • android:windowSoftInputMode özelliğini stateAlwaysVisible olarak ayarlayın.
  • Etkinliğinizin onCreate() yönteminde programatik olarak dokunmatik klavye isteğinde bulunun veya onConfigurationChanged() yöntemini ekleyin.

İ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

Android 17'den itibaren ses çerçevesi, bu değişikliklerin kullanıcı tarafından kasıtlı olarak başlatılmasını sağlamak için ses çalma, ses odağı istekleri ve ses seviyesi değişikliği API'leri dahil olmak üzere arka plandaki ses etkileşimleriyle ilgili kısıtlamalar uygular.

Uygulama geçerli bir yaşam döngüsünde değilken ses API'lerini çağırmaya çalışırsa ses çalma ve ses seviyesi değiştirme API'leri, istisna oluşturmadan veya hata mesajı vermeden sessizce başarısız olur. Ses odağı API'si, AUDIOFOCUS_REQUEST_FAILED sonuç koduyla başarısız oluyor.

Azaltma stratejileri de dahil olmak üzere daha fazla bilgi için Arka planda ses sağlamlaştırma başlıklı makaleyi inceleyin.

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