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 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your applications and Android users. In Android 17, limits are set conservatively to establish system baselines, targeting extreme memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory.

You can determine if your app session was impacted by calling getDescription in ApplicationExitInfo; if your app was affected, the exit reason will be REASON_OTHER and the description will contain the string "MemoryLimiter:AnonSwap" along with other information. You can also use trigger-based profiling with TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the memory limit is hit.

The Manage your app's memory documentation gives information to help you diagnose your app's memory issues and optimize its resource consumption.

Test your app's behavior under the memory constraints

You can use Android Debug Bridge (adb) to adjust or disable the memory limits on any device that imposes them. The shell command am provides three subcommands to adjust the memory limits. (These commands have no effect on a device which does not impose memory limits.)

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

Instructs the memory limiter to ignore some or all processes. Passing a UID instructs the memory limiter to ignore all processes associated with that UID. You can also pass all (ignore all processes) or none (do not ignore any processes). Passing none overrides any previous calls to am memory-limiter ignore.

If you instruct the memory limiter to ignore a process, you can still apply a manual memory limit to the process by calling am memory-limiter manual.

manual

Instructs the system to impose a memory constraint on the process with the specified PID. The memory constraint is specified as an integer number of MB; for example, passing 30 specifies that the process is limited to 30 MB of memory. Passing max removes all memory limits on that process. Passing none removes any manual limits set on the process, restoring the system's default limit (if any).

status

Reports the current status of the memory limiter. The status includes the memory limits imposed on visible and non-visible processes.

Prywatność

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

Ochrona przed SMS-ami z kodami jednorazowymi

Od Androida 17 Android rozszerza ochronę wiadomości SMS zawierających hasła jednorazowe (OTP).

W poprzednich wersjach Androida ta ochrona była skoncentrowana głównie na formacie SMS Retriever. Dostarczanie wiadomości zawierających hasz SMS Retriever było opóźniane o 3 godziny w przypadku większości aplikacji. Jednak niektóre aplikacje (np. domyślna aplikacja do obsługi SMS-ów) były zwolnione z tego opóźnienia, podobnie jak aplikacja, która była właścicielem haszu.

Od Androida 17 ochrona obejmuje też wiadomości w formacie WebOTP. Jeśli aplikacja ma uprawnienia do odczytywania wiadomości SMS, ale nie jest zamierzonym odbiorcą wiadomości WebOTP (co jest ustalane na podstawie weryfikacji domeny), nie będzie miała dostępu do wiadomości przez 3 godziny od jej otrzymania. Ta zmiana ma na celu zwiększenie bezpieczeństwa użytkowników przez zapewnienie, że tylko aplikacje powiązane z domeną wymienioną w wiadomości mogą programowo odczytać kod weryfikacyjny.

Podczas tego 3-godzinnego opóźnienia wstrzymywane jest nadawanie komunikatu SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtrowane. Po upływie tego czasu wiadomość SMS jest dostępna dla tych aplikacji. Ta zmiana dotyczy wszystkich aplikacji, niezależnie od poziomu interfejsu API, na który są kierowane.

Niektóre aplikacje, takie jak domyślna aplikacja asystenta SMS-ów czy aplikacje towarzyszące połączonym urządzeniom, są zwolnione z tego opóźnienia. Aby zapewnić dalsze działanie, wszystkie aplikacje, które polegają na odczytywaniu wiadomości SMS w celu wyodrębnienia haseł jednorazowych, powinny przejść na korzystanie z interfejsów API SMS Retriever lub SMS User Consent.

Bezpieczeństwo

Android 17 zawiera te ulepszenia, które zwiększają bezpieczeństwo urządzeń 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

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

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.

Blokowanie ruchu zwrotnego między profilami połączonymi

Beginning with Android 17, cross-profile loopback traffic is no longer permitted by default. Loopback traffic within the same profile is not affected. This change applies to all apps running on Android 17 or higher, regardless of what API level the app targets.

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

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, 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

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

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 wprowadza autonomiczne ponowne parowanie, czyli ulepszenie na poziomie systemu, które automatycznie rozwiązuje problem z utratą połączenia Bluetooth.

Wcześniej, jeśli połączenie zostało utracone, użytkownicy musieli ręcznie przejść do Ustawień, aby odłączyć, a następnie ponownie połączyć urządzenie peryferyjne. Ta funkcja opiera się na ulepszeniach zabezpieczeń wprowadzonych w Androidzie 16, ponieważ umożliwia systemowi ponowne nawiązywanie połączeń w tle bez konieczności ręcznego przechodzenia przez użytkowników do Ustawień w celu rozparowania i ponownego sparowania urządzeń peryferyjnych.

Większość aplikacji nie będzie wymagać zmian w kodzie, ale deweloperzy powinni pamiętać o tych zmianach w działaniu stosu Bluetooth:

  • Nowy kontekst parowania: ACTION_PAIRING_REQUEST zawiera teraz dodatkowy element EXTRA_PAIRING_CONTEXT, który umożliwia aplikacjom odróżnienie standardowego żądania parowania od próby ponownego parowania zainicjowanej przez autonomiczny system.
  • Warunkowe aktualizacje kluczy: istniejące klucze bezpieczeństwa zostaną zastąpione tylko wtedy, gdy ponowne parowanie się powiedzie, a nowe połączenie osiągnie poziom bezpieczeństwa poprzedniego połączenia lub go przekroczy.
  • Zmiana czasu działania intencji: intencja ACTION_KEY_MISSING jest teraz wysyłana tylko wtedy, gdy nie uda się automatyczne ponowne parowanie. Dzięki temu w aplikacji nie będzie konieczne niepotrzebne obsługiwanie błędów, jeśli systemowi uda się odzyskać połączenie w tle.
  • Powiadomienie użytkownika: system zarządza ponownym parowaniem za pomocą nowych powiadomień interfejsu i okien dialogowych. Użytkownicy zostaną poproszeni o potwierdzenie próby ponownego sparowania, aby mieć pewność, że wiedzą o ponownym połączeniu.

Producenci urządzeń peryferyjnych i deweloperzy aplikacji towarzyszących powinni sprawdzić, czy sprzęt i aplikacja prawidłowo obsługują przejścia między stanami połączenia. Aby przetestować to zachowanie, zasymuluj utratę połączenia zdalnego za pomocą jednej z tych metod:

  • Ręczne usuwanie informacji o powiązaniu z urządzenia peryferyjnego
  • Ręcznie odłącz urządzenie: Ustawienia > Połączone urządzenia