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 potem 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 funkcja

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

Limity pamięci aplikacji

Android 17 wprowadza limity pamięci aplikacji oparte na całkowitej pamięci RAM urządzenia, aby zapewnić bardziej stabilne i deterministyczne środowisko dla aplikacji i użytkowników Androida. W Androidzie 17 limity są ustawione w sposób konserwatywny, aby ustalić wartości bazowe systemu. Ma to na celu wykrywanie ekstremalnych wycieków pamięci i innych wartości odstających, zanim spowodują one niestabilność całego systemu, co może prowadzić do przeskoków interfejsu, szybkiego zużycia baterii i zamykania aplikacji. Spodziewamy się, że w przypadku większości sesji w aplikacjach wpływ będzie minimalny, ale zalecamy stosowanie tych sprawdzonych metod dotyczących pamięci, w tym ustalenie wartości bazowej pamięci.

Aby sprawdzić, czy sesja aplikacji została objęta tym problemem, wywołaj funkcję getDescription w ApplicationExitInfo. Jeśli aplikacja została objęta tym problemem, powód zakończenia sesji będzie mieć wartość REASON_OTHER, a opis będzie zawierać ciąg znaków "MemoryLimiter:AnonSwap" wraz z innymi informacjami. Możesz też użyć profilowania opartego na aktywatorach z TRIGGER_TYPE_ANOMALY, aby uzyskać zrzuty stosu zbierane po osiągnięciu limitu pamięci.

Aby ułatwić Ci znajdowanie wycieków pamięci, Android Studio Panda dodaje integrację z LeakCanary bezpośrednio w profilerze Android Studio jako dedykowane zadanie, które jest kontekstowe w środowisku IDE i w pełni zintegrowane z kodem źródłowym.

Bezpieczeństwo

Android 17 zawiera te ulepszenia zabezpieczeń urządzenia i aplikacji:

Harmonogram wycofywania atrybutu usesCleartextTraffic

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.

Ograniczanie niejawnych uprawnień do identyfikatorów URI

Obecnie, jeśli aplikacja uruchamia intencję z identyfikatorem URI, który ma działanie Send, SendMultiple lub ImageCapture, system automatycznie przyznaje aplikacji docelowej uprawnienia do odczytu i zapisu identyfikatora URI. Planujemy zmienić to zachowanie w Androidzie 18. Z tego powodu zalecamy, aby aplikacje wyraźnie przyznawały odpowiednie uprawnienia dotyczące identyfikatora URI, zamiast polegać na systemie.

Limity magazynu kluczy poszczególnych aplikacji

Aplikacje powinny unikać tworzenia nadmiernej liczby kluczy w magazynie kluczy Androida, ponieważ jest to zasób współdzielony przez wszystkie aplikacje na urządzeniu. Od Androida 17 system egzekwuje limit liczby kluczy, które może posiadać aplikacja. Limit wynosi 50 tys. kluczy w przypadku aplikacji innych niż systemowe, które są kierowane na Androida 17 (poziom interfejsu API 37) lub nowszego, oraz 200 tys. kluczy w przypadku wszystkich innych aplikacji. Aplikacje systemowe mają limit 200 tys. kluczy niezależnie od poziomu interfejsu API, na który są kierowane.

Jeśli aplikacja spróbuje utworzyć klucze ponad limit, utworzenie nie powiedzie się i zostanie zgłoszony wyjątek a KeyStoreException. Ciąg komunikatu wyjątku zawiera informacje o limicie kluczy. Jeśli aplikacja wywoła getNumericErrorCode() w przypadku wyjątku, wartość zwracana zależy od poziomu interfejsu API, na który jest kierowana:

• Aplikacje kierowane na Androida 17 (poziom interfejsu API 37) lub nowszego: getNumericErrorCode() zwraca nową wartość ERROR_TOO_MANY_KEYS.
• Wszystkie inne aplikacje: getNumericErrorCode() zwraca ERROR_INCORRECT_USAGE.

Wrażenia użytkowników i interfejs systemu

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

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

Od Androida 17, gdy konfiguracja urządzenia ulegnie zmianie (np. w wyniku obrócenia ekranu), a aplikacja nie obsłuży tej zmiany, poprzednia widoczność IME nie zostanie przywrócona.

Jeśli w aplikacji nastąpi zmiana konfiguracji, której nie obsługuje, a po zmianie klawiatura musi być widoczna, musisz wyraźnie o to poprosić. Możesz przesłać prośbę na jeden z tych sposobów:

• Ustaw atrybut android:windowSoftInputMode na stateAlwaysVisible.
• Programowo poproś o wyświetlenie klawiatury ekranowej w metodzie onCreate() aktywności lub dodaj metodę onConfigurationChanged().

Dane wejściowe od człowieka

Android 17 zawiera te zmiany, które wpływają na sposób interakcji aplikacji z urządzeniami wejściowymi, takimi jak klawiatury i touchpady.

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

Beginning with Android 17, if an app requests pointer capture using View.requestPointerCapture() and the user uses a touchpad, the system recognizes pointer movement and scrolling gestures from the user's touches and reports them to the app in the same way as pointer and scroll wheel movements from a captured mouse. In most cases, this removes the need for apps that support captured mice to add special handling logic for touchpads. For more details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.

Previously, the system did not attempt to recognize gestures from the touchpad, and instead delivered the raw, absolute finger locations to the app in a similar format to touchscreen touches. If an app still requires this absolute data, it should call the new View.requestPointerCapture(int) method with View.POINTER_CAPTURE_MODE_ABSOLUTE instead.

Multimedia

W Androidzie 17 wprowadziliśmy te zmiany w działaniu multimediów.

Wzmacnianie zabezpieczeń dźwięku w tle

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.

Łączność

W Androidzie 17 wprowadziliśmy te zmiany, aby zwiększyć łą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