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 (API na poziomie 37) lub nowszego otrzymują nową implementację bez blokad funkcji android.os.MessageQueue. 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 strategie ograniczania ryzyka, znajdziesz w przewodniku po zmianach w działaniu MessageQueue.

Statyczne pola końcowe są teraz niemodyfikowalne

Aplikacje działające na Androidzie 17 lub nowszym, które są kierowane na Androida 17 (API na poziomie 37) lub nowszego, nie mogą zmieniać pól static final. Jeśli aplikacja spróbuje zmienić pole static final za pomocą odbicia, spowoduje to IllegalAccessException. Próba zmodyfikowania jednego z tych pól za pomocą interfejsów API JNI (np. SetStaticLongField()) spowoduje awarię aplikacji.

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 za pomocą edytora IME

This feature introduces new AccessibilityEvent and TextAttribute APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME apps can now signal whether a text conversion candidate has been selected during text composition. Apps with edit fields can specify text change types when sending text changed accessibility events. For example, apps can specify that a text change occurred during text composition, or that a text change resulted from a commit. Doing this enables accessibility services such as screen readers to deliver more precise feedback based on the nature of the text modification.

App adoption

  • IME Apps: When setting composing text in edit fields, IMEs can use TextAttribute.Builder.setTextSuggestionSelected() to indicate whether a specific conversion candidate was selected.

  • Apps with Edit Fields: Apps that maintain a custom InputConnection can retrieve candidate selection data by calling TextAttribute.isTextSuggestionSelected(). These apps should then call AccessibilityEvent.setTextChangeTypes() when dispatching TYPE_VIEW_TEXT_CHANGED events. Apps targeting Android 17 (API level 37) that use the standard TextView will have this feature enabled by default. (That is, TextView will handle retrieving data from the IME and setting text change types when sending events to accessibility services).

  • Accessibility Services: Accessibility services that process TYPE_VIEW_TEXT_CHANGED events can call AccessibilityEvent.getTextChangeTypes() to identify the nature of the modification and adjust their feedback strategies accordingly.

Prywatność

W Androidzie 17 wprowadziliśmy te zmiany, aby zwiększyć prywatność użytkowników.

ECH (Encrypted Client Hello) włączone oportunistycznie

Android 17 wprowadza obsługę platformy dla rozszerzenia Encrypted Client Hello (ECH), które zwiększa prywatność użytkowników przez szyfrowanie wskaźnika nazwy serwera (SNI) podczas uzgadniania połączenia TLS. To szyfrowanie utrudnia obserwatorom sieci łatwe zidentyfikowanie konkretnej domeny, z którą łączy się Twoja aplikacja.

W przypadku aplikacji kierowanych na Androida 17 (API na poziomie 37) lub nowszego ECH jest używane w przypadku połączeń TLS. Rozszerzenie ECH jest aktywne tylko wtedy, gdy biblioteka sieciowa używana przez aplikację (np. HttpEngine, WebView lub OkHttp) ma zintegrowaną obsługę ECH, a serwer zdalny również obsługuje protokół ECH. Jeśli nie można uzgodnić ECH, połączenie automatycznie przełącza się na standardowy protokół TLS bez szyfrowania SNI.

Aby umożliwić aplikacjom dostosowywanie tego działania, Android 17 dodaje nowy element <domainEncryption> do pliku konfiguracji zabezpieczeń sieci. Deweloperzy mogą używać tagów <domainEncryption> w tagach <base-config> lub <domain-config>, aby wybrać tryb ECH (np. "opportunistic", "enabled" lub "disabled") globalnie lub w poszczególnych domenach.

Więcej informacji znajdziesz w dokumentacji Encrypted Client Hello.

Uprawnienia dostępu do sieci lokalnej wymagane w przypadku aplikacji kierowanych na Androida 17

Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission to protect users from unauthorized local network access. Because this falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions aren't prompted again. This new requirement prevents malicious apps from exploiting unrestricted local network access for covert user tracking and fingerprinting. By declaring and requesting this permission, your app can discover and connect to devices on the local area network (LAN), such as smart home devices or casting receivers.

Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.

For more information, see the Local network permission documentation.

Ukrywanie haseł na urządzeniach fizycznych

Jeśli aplikacja jest kierowana na Androida 17 (API na poziomie 37) lub nowszego, a użytkownik korzysta z fizycznego urządzenia wejściowego (np. zewnętrznej klawiatury), system operacyjny Android stosuje nowe ustawienie show_passwords_physical do wszystkich znaków w polu hasła. Domyślnie to ustawienie ukrywa wszystkie znaki hasła.

System Android wyświetla ostatni wpisany znak hasła, aby pomóc użytkownikowi sprawdzić, czy nie popełnił błędu. Jest to jednak znacznie mniej potrzebne w przypadku większych klawiatur zewnętrznych. Dodatkowo urządzenia z klawiaturami zewnętrznymi mają często większe wyświetlacze, co zwiększa ryzyko, że ktoś zobaczy wpisane hasło.

Jeśli użytkownik korzysta z ekranu dotykowego urządzenia, system zastosuje nowe ustawienieshow_passwords_touch.

Bezpieczeństwo

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

Bezpieczeństwo aktywności

In Android 17, the platform continues its shift toward a "secure-by-default" architecture, introducing a suite of enhancements designed to mitigate high-severity exploits such as phishing, interaction hijacking, and confused deputy attacks. This update requires developers to explicitly opt in to new security standards to maintain app compatibility and user protection.

Key impacts for developers include:

  • BAL hardening & improved opt-in: We are refining Background Activity Launch (BAL) restrictions by extending protections to IntentSender. Developers must migrate away from the legacy MODE_BACKGROUND_ACTIVITY_START_ALLOWED constant. Instead, you should adopt granular controls like MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, which restricts activity starts to scenarios where the calling app is visible, significantly reducing the attack surface.
  • Adoption tools: Developers should utilize strict mode and updated lint checks to identify legacy patterns and ensure readiness for future target SDK requirements.

Domyślne włączanie CT

If an app targets Android 17 (API level 37) or higher, certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)

Safer Native DCL-C

Jeśli Twoja aplikacja jest kierowana na Androida 17 (poziom interfejsu API 37) lub nowszego, ochrona Safer Dynamic Code Loading (DCL) wprowadzona w Androidzie 14 w przypadku plików DEX i JAR obejmuje teraz również 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.

Ograniczanie pól umożliwiających identyfikację osób w widoku danych CP2

W przypadku aplikacji kierowanych na Androida 17 (poziom API 37) i nowsze wersje dostawca kontaktów 2 (CP2) ogranicza dostęp do niektórych kolumn zawierających informacje umożliwiające identyfikację. Gdy ta zmiana zostanie włączona, te kolumny zostaną usunięte z widoku danych, aby zwiększyć prywatność użytkowników. Ograniczone kolumny:

Aplikacje, które używają tych kolumn z ContactsContract.Data mogą je zamiast tego wyodrębniać z ContactsContract.RawContacts , łącząc się z RAW_CONTACT_ID.

Wymuszanie rygorystycznych kontroli SQL w CP2

W przypadku aplikacji kierowanych na Androida 17 (interfejs API na poziomie 37) i nowsze wersje dostawca kontaktów 2 (CP2) wymusza ścisłą weryfikację zapytań SQL, gdy uzyskiwany jest dostęp do tabeli ContactsContract.Data bez uprawnienia READ_CONTACTS.

Po wprowadzeniu tej zmiany, jeśli aplikacja nie ma uprawnień READ_CONTACTS, podczas wysyłania zapytań do tabeli ContactsContract.Data ustawiane są opcje StrictColumns i StrictGrammar. Jeśli zapytanie używa wzorca, który nie jest z nimi zgodny, zostanie odrzucone i spowoduje zgłoszenie wyjątku.

Multimedia

W Androidzie 17 wprowadziliśmy te zmiany w działaniu multimediów.

Wzmacnianie zabezpieczeń dźwięku w tle

Od Androida 17 platforma audio wymusza ograniczenia dotyczące interakcji audio w tle, w tym odtwarzania dźwięku, żądań aktywności audio i interfejsów API zmiany głośności, aby mieć pewność, że te zmiany są inicjowane celowo przez użytkownika.

Niektóre ograniczenia dotyczące dźwięku obowiązują w przypadku wszystkich aplikacji. Jeśli jednak aplikacja jest kierowana na Androida 17 (API na poziomie 37), ograniczenia są bardziej rygorystyczne. Jeśli jedna z tych aplikacji wchodzi w interakcję z dźwiękiem w tle, musi mieć uruchomioną usługę na pierwszym planie. Dodatkowo aplikacja musi spełniać co najmniej jedno z tych wymagań:

  • Usługa na pierwszym planie musi mieć funkcje obowiązujące podczas używania.
  • Aplikacja musi mieć uprawnienie alarm precyzyjny i korzystać ze strumieni audio USAGE_ALARM.

Więcej informacji, w tym strategie ograniczania ryzyka, znajdziesz w artykule Wzmacnianie zabezpieczeń dźwięku w tle.

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 (interfejs API na poziomie 37) lub nowszy.

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

Łączność

Android 17 wprowadza następującą zmianę, aby zwiększyć spójność i dostosować działanie gniazd RFCOMM Bluetooth do standardowego zachowania InputStream w języku Java.

Spójne działanie funkcji BluetoothSocket read() w przypadku RFCOMM

W przypadku aplikacji kierowanych na Androida 17 (poziom interfejsu API 37) metoda read() klasy InputStream uzyskana z klasy BluetoothSocket opartej na RFCOMM zwraca teraz wartość -1, gdy gniazdo jest zamknięte lub połączenie zostało przerwane.

Ta zmiana sprawia, że działanie gniazda RFCOMM jest zgodne z działaniem gniazd LE CoC i jest zgodna ze standardową InputStream.read() dokumentacją, która stwierdza, że -1 jest zwracana po osiągnięciu końca strumienia

Aplikacje, które polegają wyłącznie na przechwytywaniu IOException w celu przerwania pętli odczytu, mogą zostać dotknięte tą zmianą i powinny zaktualizować pętle odczytu BluetoothSocket, aby wyraźnie sprawdzać wartość zwracaną -1. Dzięki temu pętla zostanie prawidłowo zakończona, gdy urządzenie zdalne się rozłączy lub gniazdo zostanie zamknięte. Przykład zalecanej implementacji znajdziesz we fragmencie kodu w przewodniku Przesyłanie danych przez Bluetooth.