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.

Bezpieczeństwo

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

Harmonogram wycofywania atrybutu usesCleartextTraffic

W przyszłej wersji planujemy wycofać element usesCleartextTraffic. Aplikacje, które muszą nawiązywać połączenia nieszyfrowane (HTTP), powinny przejść na korzystanie z pliku konfiguracji zabezpieczeń sieciowych, który umożliwia określenie, z jakimi domenami aplikacja musi nawiązywać połączenia nieszyfrowane.

Pamiętaj, że pliki konfiguracyjne zabezpieczeń sieci są obsługiwane tylko na poziomach interfejsu API 24 i wyższych. Jeśli minimalny poziom interfejsu API aplikacji jest niższy niż 24, musisz wykonać oba te działania:

  • Ustaw atrybut usesCleartextTraffic na true
  • Używanie pliku konfiguracji sieci

Jeśli minimalny poziom interfejsu API aplikacji to 24 lub wyższy, możesz użyć pliku konfiguracji sieci i nie musisz ustawiać wartości 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 do 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

Od Androida 17, jeśli aplikacja zażąda przechwytywania wskaźnika za pomocą funkcji View.requestPointerCapture(), a użytkownik będzie korzystać z touchpada, system będzie rozpoznawać ruch wskaźnika i gesty przewijania wykonywane przez użytkownika i przekazywać je do aplikacji w taki sam sposób jak ruchy wskaźnika i kółka 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 szczegółów znajdziesz w dokumentacji View.POINTER_CAPTURE_MODE_RELATIVE.

Wcześniej system nie próbował rozpoznawać gestów wykonywanych na touchpadzie, tylko 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 wywołać nową metodę View.requestPointerCapture(int) z parametrem 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 sparować 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.
  • Zmodyfikowany czas intencji: intencja ACTION_KEY_MISSING jest teraz wysyłana tylko wtedy, gdy nie uda się automatyczna próba ponownego parowania. 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