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
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()zwracaERROR_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
Od Androida 17, jeśli aplikacja poprosi o przechwycenie wskaźnika za pomocą
View.requestPointerCapture(), a użytkownik będzie korzystać z touchpada, system
rozpozna ruch wskaźnika i gesty przewijania wykonywane przez użytkownika i
zgłosi je aplikacji w taki sam sposób jak ruchy wskaźnika i kółka myszy
z przechwyconej myszy. W większości przypadków eliminuje to konieczność dodawania przez aplikacje obsługujące przechwycone myszy specjalnej logiki obsługi touchpadów. Więcej
informacji znajdziesz w dokumentacji View.POINTER_CAPTURE_MODE_RELATIVE.
Wcześniej system nie próbował rozpoznawać gestów z touchpada, ale przekazywał do aplikacji surowe, bezwzględne lokalizacje palców w formacie podobnym do dotknięć ekranu dotykowego. Jeśli aplikacja nadal wymaga tych danych bezwzględnych, powinna
zamiast tego wywołać nową metodę View.requestPointerCapture(int) z
View.POINTER_CAPTURE_MODE_ABSOLUTE.
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 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