Zmiany w działaniu: wszystkie aplikacje

Platforma Android 17 zawiera zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wszystkich aplikacji działających na Androidzie 17, niezależnie od targetSdkVersion. Przetestuj aplikację, a następnie w razie potrzeby zmodyfikuj ją, aby obsługiwała te zmiany.

Zapoznaj się też z listą zmian w działaniu, które wpływają tylko na aplikacje kierowane na Androida 17.

Główna funkcjonalność

Android 17 (API na poziomie 37) zawiera te zmiany, które modyfikują lub rozszerzają różne podstawowe funkcje systemu Android.

Limity pamięci aplikacji

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

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

Prywatność

Android 17 zawiera te zmiany, które zwiększają prywatność użytkowników.

Ochrona przed SMS-ami z kodami jednorazowymi

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.

Bezpieczeństwo

Android 17 zawiera te ulepszenia, które zwiększają bezpieczeństwo urządzeń i aplikacji.

Harmonogram wycofywania atrybutu usesCleartextTraffic

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

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

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

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

Ograniczanie niejawnych uprawnień do identyfikatorów URI

Obecnie, jeśli aplikacja uruchamia intencję z URI, która ma działanie ACTION_SEND, ACTION_SEND_MULTIPLE lub ACTION_IMAGE_CAPTURE, system automatycznie przyznaje aplikacji docelowej uprawnienia do odczytu i zapisu URI. Od Androida 18 system nie będzie już automatycznie przyznawać tych uprawnień. Z tego powodu zalecamy, aby aplikacje wyraźnie przyznawały odpowiednie uprawnienia dotyczące identyfikatora URI, zamiast polegać na systemie.

Aby wykryć użycie tych intencji w aplikacji, użyj StrictMode z detectImplicitUriPermissionGrant(), aby wywołać naruszenie:

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

Możesz też monitorować zalogowane wyjątki zawierające komunikat Please set the grant explicitly in the app, który pojawia się, gdy system niejawnie ustawia uprawnienia. Możesz monitorować te logi za pomocą tego polecenia: adb

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

Aby wyraźnie przyznać niezbędne uprawnienia, dodaj flagę FLAG_GRANT_READ_URI_PERMISSION do intencji ACTION_SEND i ACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Uwzględnij flagi FLAG_GRANT_READ_URI_PERMISSION i FLAG_GRANT_WRITE_URI_PERMISSION w przypadku intencji ACTION_IMAGE_CAPTURE:

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

Limity magazynu kluczy poszczególnych aplikacji

应用应避免在 Android 密钥库中创建过多的密钥，因为它是设备上所有应用的共享资源。从 Android 17 开始，系统会强制限制应用可拥有的密钥数量。对于以 Android 17（API 级别 37）或更高版本为目标平台的非系统应用，密钥数量上限为 50,000 个；对于所有其他应用，密钥数量上限为 200,000 个。无论系统应用以哪个 API 级别为目标，其密钥数量上限均为 20 万。

如果应用尝试创建超出限制的密钥，则创建会失败并显示 KeyStoreException。异常的消息字符串包含有关密钥限制的信息。如果应用针对异常调用 getNumericErrorCode()，则返回值取决于应用的目标 API 级别：

  • 如果应用以 Android 17（API 级别 37）或更高版本为目标平台，getNumericErrorCode() 会返回新的 ERROR_TOO_MANY_KEYS 值。
  • 所有其他应用：getNumericErrorCode() 返回 ERROR_INCORRECT_USAGE。

Blokowanie ruchu zwrotnego między profilami połączonymi

Od Androida 17 ruch zwrotny między profilami nie jest już domyślnie dozwolony. Nie ma to wpływu na ruch zwrotny w ramach tego samego profilu. Ta zmiana dotyczy wszystkich aplikacji działających na Androidzie 17 lub nowszym, niezależnie od docelowego poziomu interfejsu API.

Wygoda użytkowania i interfejs systemu

Android 17 zawiera te zmiany, które mają na celu zapewnienie bardziej spójnego i intuicyjnego interfejsu użytkownika.

Przywracanie domyślnej widoczności IME po obróceniu ekranu

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

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

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

Dane wejściowe od człowieka

Android 17 zawiera te zmiany, które wpływają na sposób, w jaki aplikacje wchodzą w interakcję z urządzeniami wejściowymi, takimi jak klawiatury i touchpady.

Touchpady domyślnie dostarczają zdarzenia względne podczas przechwytywania wskaźnika

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

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

Multimedia

Android 17 zawiera te zmiany w działaniu multimediów.

Wzmacnianie zabezpieczeń dźwięku w tle

Od Androida 17 framework audio wymusza ograniczenia dotyczące interakcji audio w tle, w tym odtwarzania dźwięku, żądań aktywności audio i interfejsów API do zmiany głośności, aby mieć pewność, że te zmiany są inicjowane przez użytkownika.

Jeśli aplikacja spróbuje wywołać interfejsy API audio, gdy nie jest w prawidłowym cyklu życia, interfejsy API do odtwarzania dźwięku i zmiany głośności nie powiedzą się bez zgłaszania wyjątku ani wyświetlania komunikatu o błędzie. Interfejs API aktywności audio nie powiedzie się z kodem wyniku AUDIOFOCUS_REQUEST_FAILED.

Więcej informacji, w tym o strategiach ograniczania ryzyka, znajdziesz w artykule Wzmacnianie zabezpieczeń dźwięku w tle .

Łączność

Android 17 zawiera te zmiany, które zwiększają łączność urządzeń.

Autonomiczne ponowne parowanie w przypadku utraty połączenia Bluetooth

Android 17 introduces autonomous re-pairing, a system-level enhancement designed to automatically resolve Bluetooth bond loss.

Previously, if a bond was lost, users had to manually navigate to Settings to unpair and then re-pair the peripheral. This feature builds upon the security improvement of Android 16 by allowing the system to re-establish bonds in the background without requiring users to manually navigate to Settings to unpair and re-pair peripherals.

While most apps will not require code changes, developers should be aware of the following behavior changes in Bluetooth stack:

  • New pairing context: The ACTION_PAIRING_REQUEST now includes the EXTRA_PAIRING_CONTEXT extra which allows apps to distinguish between a standard pairing request and an autonomous system-initiated re-pairing attempt.
  • Conditional key updates: Existing security keys will only be replaced if the re-pairing is successful and new connection meets or exceeds the security level of the previous bond.
  • Modified intent timing: The ACTION_KEY_MISSING intent is now broadcast only if the autonomous re-pairing attempt fails. This reduces unnecessary error handling in the app if the system successfully recovers the bond in the background.
  • User notification: The system manages re-pairing via new UI notifications and dialogs. Users will be prompted to confirm the re-pairing attempt to ensure they are aware of the reconnection.

Peripheral device manufacturers and companion app developers should verify that hardware and app gracefully handle bond transitions. To test this behavior, simulate a remote bond loss using either of the following methods:

  • Manually remove the bond information from the peripheral device
  • Manually unpair the device in: Settings > Connected devices