Verhaltensänderungen: alle Apps

Die Android 17-Plattform enthält Verhaltensänderungen, die sich auf deine App auswirken können. Die folgenden Verhaltensänderungen gelten für alle Apps , wenn sie unter Android 17 ausgeführt werden, unabhängig von targetSdkVersion. Du solltest deine App testen und sie dann gegebenenfalls an diese Änderungen anpassen.

Sieh dir auch die Liste der Verhaltensänderungen an, die sich nur auf Apps auswirken, die auf Android 17 ausgerichtet sind.

Hauptfunktion

Android 17 (API-Level 37) enthält die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems ändern oder erweitern.

App-Arbeitsspeicherlimits

Android 17 引入了基于设备总 RAM 的应用内存限制，旨在为您的应用和 Android 用户打造更稳定、更具确定性的环境。这些限制侧重于在内存泄漏和其他异常值触发系统范围的不稳定性（导致界面卡顿、电池耗电量增加和应用被终止）之前，对其进行限制。虽然我们预计对绝大多数应用会话的影响很小，但我们建议您遵循以下内存最佳实践，包括建立内存基准。

您可以在 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

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

Datenschutz

Android 17 enthält die folgenden Änderungen, um den Datenschutz für Nutzer zu verbessern.

SMS-OTP-Schutz

从 Android 17 开始，Android 将扩大对包含一次性密码 (OTP) 的短信的保护范围。

在之前的 Android 版本中，此保护主要侧重于 SMS Retriever 格式。对于大多数应用，包含 SMS Retriever 哈希的消息的递送延迟了 3 小时。不过，某些应用（例如默认短信处理程序）不受此延迟的影响，拥有哈希的应用也不受此延迟的影响。

从 Android 17 开始，此保护也适用于 WebOTP 格式的消息。如果应用有权读取短信，但不是 WebOTP 消息的预期接收者（由网域验证确定），则该应用在收到消息后 3 小时内无法访问该消息。此变更旨在提高用户安全性，确保只有与消息中提及的网域关联的应用才能以编程方式读取验证码。

在这 3 小时的延迟期间，系统会保留 SMS_RECEIVED_ACTION 广播，并过滤 短信提供商 数据库查询。延迟结束后，这些应用即可使用短信。此变更适用于 所有应用，无论其目标 API 级别如何。

某些应用（例如默认短信助理应用、关联设备配套应用等）不受此延迟的影响。所有依赖于读取短信 来提取 OTP 的应用都应过渡到使用 SMS Retriever 或 SMS User Consent API，以确保功能持续可用。

Sicherheit

Android 17 enthält die folgenden Verbesserungen für die Geräte- und App-Sicherheit.

Einstellungszeitplan für usesClearTraffic

我们计划在未来的版本中弃用 usesCleartextTraffic 元素。需要建立未加密 (HTTP) 连接的应用应迁移为使用网络安全配置文件，该文件可让您指定应用需要与哪些网域建立明文连接。

请注意，网络安全配置文件仅在 API 级别 24 及更高版本中受支持。如果您的应用的最低 API 级别低于 24，您应执行以下两项操作：

  • 将 usesCleartextTraffic 属性设置为 true
  • 使用网络配置文件

如果应用的最低 API 级别为 24 或更高，您可以使用网络配置文件，而无需设置 usesCleartextTraffic。

Implizite URI-Berechtigungen einschränken

Wenn eine App derzeit einen Intent mit einem URI startet, der die Aktion ACTION_SEND, ACTION_SEND_MULTIPLE oder ACTION_IMAGE_CAPTURE hat, gewährt das System der Ziel-App automatisch die Lese- und Schreib-URI-Berechtigungen. Ab Android 18 gewährt das System diese Berechtigungen nicht mehr automatisch. Aus diesem Grund empfehlen wir, dass Apps die relevanten URI-Berechtigungen explizit gewähren, anstatt sich darauf zu verlassen, dass das System sie gewährt.

Wenn Sie die Verwendung dieser Intents in Ihrer App erkennen möchten, verwenden Sie StrictMode mit detectImplicitUriPermissionGrant(), um einen Verstoß auszulösen:

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

Alternativ können Sie nach protokollierten Ausnahmen mit der Meldung Please set the grant explicitly in the app suchen, die angezeigt wird, wenn das System die Erteilung implizit festlegt. Sie können diese Logs mit dem folgenden adb-Befehl überwachen:

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

Wenn Sie die erforderlichen Berechtigungen explizit gewähren möchten, fügen Sie das Flag FLAG_GRANT_READ_URI_PERMISSION den Intents ACTION_SEND und ACTION_SEND_MULTIPLE hinzu:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Fügen Sie sowohl das Flag FLAG_GRANT_READ_URI_PERMISSION als auch das Flag FLAG_GRANT_WRITE_URI_PERMISSION für ACTION_IMAGE_CAPTURE-Intents ein:

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

Keystore-Limits pro App

Apps sollten nicht zu viele Schlüssel im Android-Keystore erstellen, da es sich um eine gemeinsam genutzte Ressource für alle Apps auf dem Gerät handelt. Ab Android 17 erzwingt das System ein Limit für die Anzahl der Schlüssel, die einer App gehören können. Das Limit liegt bei 50.000 Schlüsseln für Nicht-System-Apps, die auf Android 17 (API-Level 37) oder höher ausgerichtet sind, und bei 200.000 Schlüsseln für alle anderen Apps. System-Apps haben ein Limit von 200.000 Schlüsseln,unabhängig davon, auf welche API-Ebene sie ausgerichtet sind.

Wenn eine App versucht, über das Limit hinaus Schlüssel zu erstellen, schlägt die Erstellung mit dem Fehler KeyStoreException fehl. Der Meldungsstring der Ausnahme enthält Informationen zum Schlüssellimit. Wenn die App getNumericErrorCode() für die Ausnahme aufruft, hängt der Rückgabewert davon ab, auf welches API-Level die App ausgerichtet ist:

  • Apps, die auf Android 17 (API‑Level 37) oder höher ausgerichtet sind: getNumericErrorCode() gibt den neuen ERROR_TOO_MANY_KEYS-Wert zurück.
  • Alle anderen Apps: getNumericErrorCode() gibt ERROR_INCORRECT_USAGE zurück.

Profilübergreifenden Loopback-Traffic blockieren

从 Android 17 开始，默认情况下不再允许跨个人资料环回流量。同一个人资料内的环回流量不受影响。 此项变更适用于在 Android 17 或更高版本上运行的所有应用，无论应用以哪个 API 级别为目标平台。

Nutzererfahrung und System-UI

Android 17 enthält die folgenden Änderungen, die eine einheitlichere und intuitivere Nutzererfahrung schaffen sollen.

Standardmäßige IME-Sichtbarkeit nach Drehung wiederherstellen

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

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

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

Menschliche Eingabe

Android 17 enthält die folgenden Änderungen, die sich auf die Interaktion von Apps mit Eingabegeräten wie Tastaturen und Touchpads auswirken.

Touchpads liefern bei der Zeigererfassung standardmäßig relative Ereignisse

从 Android 17 开始，如果应用使用 View.requestPointerCapture() 请求捕获指针，并且用户使用触控板，系统会识别用户触摸操作产生的指针移动和滚动手势，并以与捕获的鼠标产生的指针和滚轮移动相同的方式将这些信息报告给应用。在大多数情况下，这使得支持捕获鼠标的应用无需为触控板添加特殊的处理逻辑。如需了解详情，请参阅 View.POINTER_CAPTURE_MODE_RELATIVE 的文档。

之前，系统不会尝试识别触控板的手势，而是以类似于触摸屏触摸的格式将原始的绝对手指位置传递给应用。如果应用仍需要此绝对数据，则应改为使用 View.POINTER_CAPTURE_MODE_ABSOLUTE 调用新的 View.requestPointerCapture(int) 方法。

Medien

Android 17 enthält die folgenden Änderungen am Medienverhalten.

Härtung von Audio im Hintergrund

Ab Android 17 erzwingt das Audio-Framework Einschränkungen für Audiointeraktionen im Hintergrund, einschließlich Audiowiedergabe, Audiofokus-Anfragen und APIs zur Lautstärkeänderung. So soll sichergestellt werden, dass diese Änderungen vom Nutzer beabsichtigt sind.

Wenn die App versucht, Audio-APIs aufzurufen, während sie sich nicht in einem gültigen Lebenszyklus befindet, schlagen die APIs für die Audiowiedergabe und die Lautstärkeänderung im Hintergrund fehl, ohne eine Ausnahme auszulösen oder eine Fehlermeldung zu liefern. Die Audiofokus-API schlägt mit dem Ergebniscode AUDIOFOCUS_REQUEST_FAILED fehl.

Weitere Informationen, einschließlich Strategien zur Risikominderung, finden Sie unter Background audio hardening (Härtung von Audio im Hintergrund).

Konnektivität

Android 17 enthält die folgenden Änderungen, um die Gerätekonnektivität zu verbessern.

Autonome Neuverknüpfung bei Verlust der Bluetooth-Verbindung

Mit Android 17 wird die autonome Neuverknüpfung eingeführt, eine Verbesserung auf Systemebene, die darauf ausgelegt ist, den Verlust von Bluetooth-Verknüpfungen automatisch zu beheben.

Bisher mussten Nutzer bei einem Verlust der Verknüpfung manuell die Einstellungen aufrufen, um die Verknüpfung mit dem Peripheriegerät aufzuheben und es dann neu zu verknüpfen. Diese Funktion baut auf der Sicherheitsverbesserung von Android 16 auf, indem sie es dem System ermöglicht, Verknüpfungen im Hintergrund wiederherzustellen, ohne dass Nutzer manuell die Einstellungen aufrufen müssen, um die Verknüpfung mit Peripheriegeräten aufzuheben und sie neu zu verknüpfen.

Bei den meisten Apps sind keine Codeänderungen erforderlich. Entwickler sollten jedoch die folgenden Verhaltensänderungen im Bluetooth-Stack beachten:

  • Neuer Verknüpfungskontext: Die ACTION_PAIRING_REQUEST enthält jetzt die EXTRA_PAIRING_CONTEXT zusätzliche, mit der Apps zwischen einer Standardverknüpfungsanfrage und einem autonomen, vom System initiierten Neuverknüpfungsversuch unterscheiden können.
  • Bedingte Schlüsselaktualisierungen:Vorhandene Sicherheitsschlüssel werden nur ersetzt, wenn die Neuverknüpfung erfolgreich ist und die neue Verbindung das Sicherheitsniveau der vorherigen Verknüpfung erfüllt oder übertrifft.
  • Geänderter Intent-Zeitpunkt:Der Intent ACTION_KEY_MISSING wird jetzt nur gesendet, wenn der autonome Neuverknüpfungsversuch fehlschlägt. Dadurch wird die unnötige Fehlerbehandlung in der App reduziert, wenn das System die Verknüpfung im Hintergrund erfolgreich wiederherstellt.
  • Benachrichtigung für Nutzer:Die Neuverknüpfung wird vom System über neue UI-Benachrichtigungen und Dialogfelder verwaltet. Nutzer werden aufgefordert, den Neuverknüpfungsversuch zu bestätigen, damit sie über die Wiederverbindung informiert sind.

Hersteller von Peripheriegeräten und Entwickler von Begleit-Apps sollten prüfen, ob Hardware und App Verknüpfungsübergänge ordnungsgemäß verarbeiten. Um dieses Verhalten zu testen, simulieren Sie einen Verlust der Remote-Verknüpfung mit einer der folgenden Methoden:

  • Entfernen Sie die Verknüpfungsinformationen manuell vom Peripheriegerät.
  • Heben Sie die Verknüpfung mit dem Gerät manuell auf: Einstellungen > Verbundene Geräte