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
usesCleartextTrafficattribute totrue - 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
Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.
If an app attempts to create keys beyond the limit, the creation fails with a
KeyStoreException. The exception's message string contains information
about the key limit. If the app calls getNumericErrorCode() on the
exception, the return value depends on what API level the app targets:
- Apps targeting Android 17 (API level 37) or higher:
getNumericErrorCode()returns the newERROR_TOO_MANY_KEYSvalue. - All other apps:
getNumericErrorCode()returnsERROR_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
Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.
If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:
- Set the
android:windowSoftInputModeattribute tostateAlwaysVisible. - Programmatically request the soft keyboard in your activity's
onCreate()method, or add theonConfigurationChanged()method.
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
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ść
W Androidzie 17 wprowadziliśmy te zmiany, aby zwiększyć łą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_REQUESTzawiera teraz dodatkowy elementEXTRA_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_MISSINGjest 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