Zmiany w działaniu: aplikacje kierowane na Androida 17 lub nowszego

Podobnie jak w przypadku poprzednich wersji Androida, w Androidzie 17 wprowadziliśmy zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wyłącznie aplikacji kierowanych na Androida 17 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 17 lub nowszego, zmodyfikuj ją, aby w odpowiednich przypadkach obsługiwała te działania.

Zapoznaj się też z listą zmian w działaniu, które wpływają na wszystkie aplikacje działające na Androidzie 17 niezależnie od targetSdkVersion aplikacji.

Główna funkcja

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

Nowa implementacja MessageQueue bez blokad

Od Androida 17 aplikacje kierowane na Androida 17 lub nowszego otrzymują nową implementację android.os.MessageQueue bez blokad. Nowa implementacja zwiększa wydajność i zmniejsza liczbę pominiętych klatek, ale może powodować awarie klientów, którzy korzystają z pól i metod prywatnych MessageQueue.

Więcej informacji, w tym strategii ograniczania ryzyka, znajdziesz w przewodniku po zmianach w działaniu MessageQueue.

Ułatwienia dostępu

W Androidzie 17 wprowadziliśmy te zmiany, aby poprawić dostępność.

Ułatwienia dostępu do złożonego pisania na klawiaturze fizycznej IME

Ta funkcja wprowadza nowe interfejsy API AccessibilityEventTextAttribute, które ulepszają odczytywanie przez czytnik ekranu komunikatów głosowych w przypadku wprowadzania tekstu w językach CJKV. Aplikacje CJKV IME mogą teraz sygnalizować, czy podczas tworzenia tekstu wybrano kandydata do konwersji tekstu. Aplikacje z polami edycji mogą określać rodzaje zmian tekstu podczas wysyłania zdarzeń dostępności związanych ze zmianą tekstu. Aplikacje mogą na przykład określać, że zmiana tekstu nastąpiła podczas pisania lub że wynikała z zatwierdzenia. Dzięki temu usługi ułatwień dostępu, takie jak czytniki ekranu, mogą przekazywać bardziej precyzyjne informacje zwrotne na podstawie charakteru modyfikacji tekstu.

Popularność aplikacji

  • Aplikacje IME: podczas ustawiania tekstu w polach edycji aplikacje IME mogą używać znaku TextAttribute.Builder.setTextSuggestionSelected(), aby wskazać, czy wybrano konkretną propozycję konwersji.

  • Aplikacje z uprawnieniami do edytowania pól: aplikacje, które obsługują niestandardowy interfejs InputConnection, mogą pobierać dane o wyborze kandydatów, wywołując interfejs TextAttribute.isTextSuggestionSelected(). Aplikacje te powinny następnie wywoływać AccessibilityEvent.setTextChangeTypes() podczas wysyłania TYPE_VIEW_TEXT_CHANGED zdarzeń. Aplikacje kierowane na Androida 17, które używają standardowego TextView, będą miały tę funkcję domyślnie włączoną. (Oznacza to, że TextView będzie pobierać dane z edytora IME i ustawiać typy zmian tekstu podczas wysyłania zdarzeń do usług ułatwień dostępu).

  • Usługi ułatwień dostępu: usługi ułatwień dostępu, które przetwarzają zdarzenia TYPE_VIEW_TEXT_CHANGED, mogą wywoływać AccessibilityEvent.getTextChangeTypes(), aby określić charakter modyfikacji i odpowiednio dostosować strategie przekazywania informacji zwrotnych.

Bezpieczeństwo

Android 17 wprowadza te ulepszenia zabezpieczeń urządzeń i aplikacji:

Bezpieczeństwo aktywności

W Androidzie 17 platforma kontynuuje przejście na architekturę „bezpieczną domyślnie”, wprowadzając zestaw ulepszeń zaprojektowanych w celu ograniczenia poważnych exploitów, takich jak wyłudzanie informacji, przejmowanie interakcji i ataki typu „confused deputy”. Ta aktualizacja wymaga od deweloperów wyraźnego zaakceptowania nowych standardów bezpieczeństwa, aby zachować zgodność aplikacji i ochronę użytkowników.

Najważniejsze zmiany dla programistów:

  • Wzmocnienie BAL i ulepszone wyrażanie zgody: udoskonalamy ograniczenia dotyczące uruchamiania aktywności w tle (BAL), rozszerzając ochronę na IntentSender. Deweloperzy muszą zrezygnować ze stałej MODE_BACKGROUND_ACTIVITY_START_ALLOWED starszego typu. Zamiast tego używaj szczegółowych elementów sterujących, takich jak MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, które ograniczają uruchamianie aktywności do sytuacji, w których aplikacja wywołująca jest widoczna, co znacznie zmniejsza obszar ataku.
  • Narzędzia do wdrażania: deweloperzy powinni korzystać z trybu ścisłego i zaktualizowanych kontroli lint, aby identyfikować starsze wzorce i zapewnić gotowość na przyszłe wymagania dotyczące docelowego pakietu SDK.

Ochrona localhosta

Aby zwiększyć bezpieczeństwo platformy i prywatność użytkowników, Android 17 wprowadza nowe uprawnienie przyznawane w momencie instalacji – USE_LOOPBACK_INTERFACE. Ta zmiana ogranicza komunikację między aplikacjami i profilami przez interfejs sprzężenia zwrotnego (np. 127.0.0.1 lub ::1), która była wcześniej niejawnie dozwolona w ramach uprawnienia INTERNET. W przypadku aplikacji kierowanych na Androida 17 lub nowszego obowiązują te reguły:

  • Wymagana wzajemna zgoda: komunikacja między aplikacjami i profilami jest teraz domyślnie blokowana. Aby połączenie zostało nawiązane, zarówno aplikacja wysyłająca, jak i odbierająca muszą wyraźnie zadeklarować uprawnienie USE_LOOPBACK_INTERFACE w swoich plikach manifestu.
  • Ruch w aplikacji jest wyłączony: komunikacja zwrotna w ramach tej samej aplikacji (komunikacja wewnątrz aplikacji) pozostaje bez zmian i nie wymaga tego nowego uprawnienia.
  • Działanie docelowego pakietu SDK:
    • Aplikacja jest kierowana na Androida 17 lub nowszego: uprawnienie musi być wyraźnie wymagane. Jeśli go brakuje, operacje na gniazdach (takie jak połączenie TCP lub wysyłanie UDP) kończą się niepowodzeniem, zwykle zwracając błąd EPERM(operacja niedozwolona).
    • Aplikacja jest kierowana na poziom API 36 lub niższy: uprawnienie jest traktowane jako podzielone uprawnienie na urządzeniach z Androidem INTERNET. Aplikacje kierowane na niższe poziomy interfejsu API otrzymują to uprawnienie automatycznie, jeśli mają uprawnienie INTERNET.
  • Ostrzeżenie dotyczące zgodności: jeśli aplikacja odbierająca zaktualizuje docelowy poziom interfejsu API do Androida 17, ale nie poprosi o to uprawnienie, połączenia przychodzące z innych aplikacji będą odrzucane, nawet jeśli aplikacja wysyłająca jest kierowana na niższy poziom interfejsu API.

Domyślne włączanie CT

Jeśli aplikacja jest kierowana na Androida 17 lub nowszego, protokół Certificate Transparency (CT) jest domyślnie włączony. (Na Androidzie 16 CT jest dostępny, ale aplikacje musiały wyrazić zgodę na jego używanie).

Bezpieczniejsza natywna DCL-C

Jeśli Twoja aplikacja jest kierowana na Androida 17 lub nowszego, bezpieczniejsza ochrona dynamicznego ładowania kodu (DCL) wprowadzona w Androidzie 14 w przypadku plików DEX i JAR obejmuje teraz biblioteki natywne.

Wszystkie pliki natywne wczytane za pomocą funkcji System.load() muszą być oznaczone jako tylko do odczytu. W przeciwnym razie system zgłasza wyjątek UnsatisfiedLinkError.

Zalecamy, aby aplikacje w miarę możliwości unikały dynamicznego wczytywania kodu, ponieważ znacznie zwiększa to ryzyko naruszenia bezpieczeństwa aplikacji przez wstrzyknięcie lub zmodyfikowanie kodu.

Formaty urządzeń

Android 17 wprowadza te zmiany, aby poprawić komfort użytkowania na urządzeniach o różnych rozmiarach i formach.

Zmiany w interfejsie Platform API, które powodują ignorowanie ograniczeń dotyczących orientacji, możliwości zmiany rozmiaru i formatu obrazu na dużych ekranach (sw>=600dp)

W Androidzie 16 wprowadziliśmy zmiany w interfejsie Platform API, aby ignorować ograniczenia dotyczące orientacji, formatu obrazu i możliwości zmiany rozmiaru na dużych ekranach (sw >= 600 dp) w przypadku aplikacji korzystających z API na poziomie 36 lub nowszym. Deweloperzy mogą zrezygnować z tych zmian w przypadku pakietu SDK 36, ale ta opcja nie będzie już dostępna w przypadku aplikacji, których docelowy poziom to Android 17 lub nowszy.

Więcej informacji znajdziesz w artykule Ograniczenia dotyczące orientacji i możliwości zmiany rozmiaru są ignorowane.