Zmiany zachowania: aplikacje kierowane na Androida 16 lub nowszego

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Podobnie jak w przypadku poprzednich wersji, Android 16 zawiera zmiany zachowania, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany zachowania mają zastosowanie wyłącznie do aplikacji kierowanych na Androida 16 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 16 lub nowszego, w razie potrzeby zmodyfikuj ją, aby obsługiwała te funkcje.

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

Wrażenia użytkownika i interfejs systemu

Android 16 (poziom interfejsu API 36) zawiera te zmiany, które mają na celu zapewnienie bardziej spójnego i intuicyjnego interfejsu.

Odrzucenie wyświetlania bez ramki

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16 Beta 3, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

Wymagane przeprowadzenie migracji lub rezygnacja z funkcji przewidywania wstecz.

W przypadku aplikacji kierowanych na Androida 16 (poziom interfejsu API 36) lub nowszego i działających na urządzeniu z Androidem 16 lub nowszym domyślnie włączone są animowane systemowe animacje wstecz (powrót do ekranu głównego, przełączanie między zadaniami i aplikacją). Dodatkowo funkcja onBackPressed nie jest wywoływana, a zapytanie KeyEvent.KEYCODE_BACK nie jest już wysyłane.

Jeśli Twoja aplikacja przechwytuje zdarzenie wstecz i nie została jeszcze przekształcona w aplikację z przewidywanym wstecznym przechodzeniem, zaktualizuj ją, aby używała obsługiwanych interfejsów API nawigacji wstecz. Możesz też tymczasowo zrezygnować z tej funkcji, ustawiając atrybut android:enableOnBackInvokedCallback na false w tagu <application> lub <activity> pliku AndroidManifest.xml aplikacji.

Wycofanie i wyłączenie interfejsów API czcionek elegant

Aplikacje kierowane na Androida 15 (poziom API 35) mają atrybut elegantTextHeight TextView ustawiony domyślnie na true, co zastępuje czcionkę kompaktową czcionką znacznie łatwiejszą do odczytania. Możesz to zmienić, ustawiając atrybut elegantTextHeight na false.

W Androidzie 16 atrybut elegantTextHeight jest przestarzały. Gdy Twoja aplikacja będzie kierowana na Androida 16, atrybut ten zostanie zignorowany. Czcionki interfejsu kontrolowane przez te interfejsy API zostaną wycofane, dlatego należy dostosować wszelkie układy, aby zapewnić spójne i przyszłe renderowanie tekstu w języku arabskim, laotam, tamilskim, gudżarati, kannada, malajalam, orija, telugu i tajskim.

Główna funkcja

Android 16 (poziom interfejsu API 36) zawiera te zmiany, które modyfikują lub rozszerzają różne podstawowe funkcje systemu Android.

Optymalizacja harmonogramu pracy z ustaloną stawką

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

Formaty urządzeń

Android 16 (poziom interfejsu API 36) wprowadza te zmiany w aplikacjach wyświetlanych na urządzeniach z dużym ekranem.

Układy adaptacyjne

Aplikacje na Androida działają teraz na różnych urządzeniach (takich jak telefony, tablety, urządzenia składane, komputery, samochody i telewizory) oraz w różnych trybach okna na dużych ekranach (np. podzielony ekran i okno na komputerze). Deweloperzy powinni więc tworzyć aplikacje na Androida, które dostosowują się do dowolnego ekranu i rozmiaru okna niezależnie od orientacji urządzenia. W dzisiejszym świecie, w którym używa się wielu urządzeń, takie paradygmaty jak ograniczanie orientacji i możliwości zmiany rozmiaru są zbyt restrykcyjne.

zignoruj ograniczenia dotyczące orientacji, zmiany rozmiaru i formatu obrazu;

W przypadku aplikacji kierowanych na Androida 16 (poziom API 36) Android 16 zawiera zmiany dotyczące sposobu zarządzania przez system orientacją, zmianą rozmiaru i ograniczeniami dotyczącymi proporcji. Na wyświetlaczach o szerokości co najmniej 600 dp te ograniczenia nie obowiązują. Aplikacje wypełniają też całe okno wyświetlania niezależnie od współczynnika proporcji lub preferowanej orientacji użytkownika. Nie jest też używane pillarboxing.

Ta zmiana wprowadza nowe standardowe działanie platformy. Android przechodzi do modelu, w którym aplikacje mają się dostosowywać do różnych orientacji, rozmiarów ekranu i proporcji. Ograniczenia takie jak zablokowana orientacja lub ograniczona możliwość zmiany rozmiaru utrudniają dostosowanie aplikacji, dlatego zalecamy stworzenie adaptacyjnej wersji aplikacji, aby zapewnić użytkownikom jak najlepsze wrażenia.

Możesz też przetestować to zachowanie, korzystając z platformy zgodności aplikacji i włączając flagę zgodności UNIVERSAL_RESIZABLE_BY_DEFAULT.

Typowe zmiany powodujące niezgodność

Ignorowanie ograniczeń dotyczących orientacji, możliwości zmiany rozmiaru i formatu obrazu może wpłynąć na interfejs aplikacji na niektórych urządzeniach, zwłaszcza na elementy zaprojektowane pod kątem małych układów blokowanych w orientacji pionowej. Mogą wystąpić problemy, takie jak rozciągnięte układy, animacje i elementy wykraczające poza ekran. Wszelkie założenia dotyczące proporcji lub orientacji mogą powodować problemy wizualne w aplikacji. Dowiedz się więcej, jak ich unikać i poprawić działanie aplikacji w trybie dostosowywania.

Zezwalanie na rotację urządzenia powoduje ponowne tworzenie aktywności, co może spowodować utratę stanu użytkownika, jeśli nie zostanie on prawidłowo zachowany. Dowiedz się, jak prawidłowo zapisywać stan interfejsu użytkownika w artykule Zapisywanie stanów interfejsu użytkownika.

Szczegóły implementacji

Na urządzeniach z dużym ekranem w trybie pełnoekranowym i wielozadaniowość są ignorowane następujące atrybuty pliku manifestu i interfejsy API w czasie wykonywania:

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

Te wartości parametrów screenOrientation, setRequestedOrientation() i getRequestedOrientation() są ignorowane:

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

Jeśli chodzi o możliwość zmiany rozmiaru wyświetlacza, opcje android:resizeableActivity="false", android:minAspectRatio i android:maxAspectRatio nie mają wpływu.

W przypadku aplikacji kierowanych na Androida 16 (poziom interfejsu API 36) ograniczenia dotyczące orientacji, zmiany rozmiaru i formatu obrazu są domyślnie ignorowane na dużych ekranach, ale każda aplikacja, która nie jest w pełni gotowa, może tymczasowo zastąpić to zachowanie, rezygnując z tego działania (co spowoduje, że aplikacja będzie działać w trybie zgodności).

Wyjątki

Ograniczenia dotyczące orientacji, zmiany rozmiaru i formatu obrazu w Androidzie 16 nie obowiązują w tych sytuacjach:

• Gry (na podstawie flagi android:appCategory)
• użytkownicy wyraźnie wyrażają zgodę na domyślne zachowanie aplikacji w ustawieniach proporcji obrazu na urządzeniu;
• Ekrany mniejsze niż sw600dp

Tymczasowe wyłączenie

Aby zrezygnować z określonej aktywności, zadeklaruj PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITYwłaściwość pliku manifestu:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

Jeśli zbyt wiele części Twojej aplikacji nie jest gotowych na Androida 16, możesz całkowicie zrezygnować z użycia tej właściwości na poziomie aplikacji:

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

Zdrowie i fitness

Android 16 (poziom interfejsu API 36) zawiera te zmiany dotyczące danych o zdrowiu i aktywności fizycznej:

Uprawnienia dotyczące zdrowia i fitnessu

W przypadku aplikacji kierowanych na Androida 16 (poziom API 36) lub nowszego uprawnienia BODY_SENSORS są zastępowane bardziej szczegółowymi uprawnieniami android.permissions.health, które są też używane na platformie Health Connect. Interfejsy API, które wcześniej wymagały uprawnień BODY_SENSORS lub BODY_SENSORS_BACKGROUND, wymagają teraz odpowiednich uprawnień android.permissions.health. Ma to wpływ na te typy danych, interfejsy API i typy usług działających na pierwszym planie:

• HEART_RATE_BPM z Wear Health Services
• Sensor.TYPE_HEART_RATE z Menedżera czujników Androida
• heartRateAccuracy i heartRateBpm z Wear ProtoLayout
• FOREGROUND_SERVICE_TYPE_HEALTH, gdzie zamiast BODY_SENSORS wymagane jest odpowiednie uprawnienie android.permission.health

Jeśli Twoja aplikacja korzysta z tych interfejsów API, powinna teraz poprosić o odpowiednie szczegółowe uprawnienia:

• Aby monitorować tętno, SpO2 lub temperaturę skóry podczas używania: poproś o szczegółowe uprawnienia w sekcji android.permissions.health, np. READ_HEART_RATE zamiast BODY_SENSORS.
• Dostęp do czujnika w tle: poproś o READ_HEALTH_DATA_IN_BACKGROUND zamiast o BODY_SENSORS_BACKGROUND.

Są to te same uprawnienia, które chronią dostęp do odczytu danych z Health Connect, czyli bazy danych Androida zawierającej dane o zdrowiu, kondycji i samopoczuciu.

Aplikacjach mobilnych

Aplikacje mobilne, które przechodzą na korzystanie z uprawnień READ_HEART_RATE i innych szczegółowych uprawnień, muszą też deklarować aktywność, aby wyświetlać politykę prywatności aplikacji. To ten sam wymóg co w Health Connect.

Łączność

Android 16 (poziom interfejsu API 36) zawiera te zmiany w pakiecie Bluetooth, które poprawiają łączność z urządzeniami peryferyjnymi:

Nowe intencje do obsługi utraty powiązania i zmian szyfrowania

W ramach ulepszonej obsługi utraty połączenia Android 16 wprowadza 2 nowe intencje, które zwiększają świadomość aplikacji na temat utraty połączenia i zmian szyfrowania.

Aplikacje kierowane na Androida 16 mogą teraz:

• Otrzymywać intencję ACTION_KEY_MISSING, gdy wykryto utratę połączenia z urządzeniem zdalnym, co pozwala im udzielać bardziej szczegółowych opinii użytkowników i podejmować odpowiednie działania.
• Otrzymywać intencję ACTION_ENCRYPTION_CHANGE za każdym razem, gdy zmienia się stan szyfrowania linku. Obejmuje to zmianę stanu szyfrowania, zmianę algorytmu szyfrowania i zmianę rozmiaru klucza szyfrowania. Aplikacje muszą uznać, że połączenie zostało przywrócone, jeśli link zostanie zaszyfrowany po otrzymaniu intencji ACTION_ENCRYPTION_CHANGE.

Jeśli Twoja aplikacja obecnie korzysta z niestandardowych mechanizmów obsługi utraty połączenia, zmień ją na nowy zamiar ACTION_KEY_MISSING, aby wykrywać zdarzenia utraty połączenia i zarządzać nimi. Zalecamy, aby aplikacja informowała użytkownika, że urządzenie zdalne jest w zasięgu, zanim rozpocznie się zapominanie urządzenia i ponowne parowanie.

Jeśli urządzenie rozłączy się po otrzymaniu intencji ACTION_KEY_MISSING, aplikacja powinna zachować ostrożność podczas ponownego łączenia się z nim, ponieważ może ono nie być już połączone z systemem.

Bezpieczeństwo

Android 16 (poziom API 36) zawiera te zmiany dotyczące zabezpieczeń:

Blokada wersji MediaStore

W przypadku aplikacji kierowanych na Androida 16 lub nowszego ciąg MediaStore#getVersion() będzie teraz niepowtarzalny dla każdej aplikacji. Pozwoli to wyeliminować z ciągu wersji właściwości identyfikujące, aby zapobiec nadużyciom i użyciu w ramach technik odciskania palca. Aplikacje nie powinny zakładać niczego w stosunku do formatu tej wersji. Aplikacje powinny już obsługiwać zmiany wersji podczas korzystania z tego interfejsu API i w większości przypadków nie trzeba zmieniać ich bieżącego działania, chyba że deweloper próbował wywnioskować dodatkowe informacje wykraczające poza zamierzony zakres tego interfejsu API.

Bezpieczniejsze intencje

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

More on the supported flags:

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

Prywatność

Android 16 (poziom API 36) zawiera te zmiany dotyczące prywatności:

Dostęp do sieci lokalnej

Do urządzeń w sieci LAN można uzyskać dostęp z dowolnej aplikacji, która ma uprawnienia INTERNET. Ułatwia to aplikacjom nawiązywanie połączeń z urządzeniami lokalnymi, ale ma też konsekwencje dla prywatności, takie jak tworzenie odcisku palca użytkownika i uzyskiwanie dostępu do lokalizacji.

Projekt „Ochrona sieci lokalnej” ma na celu ochronę prywatności użytkownika przez ograniczenie dostępu do sieci lokalnej za pomocą nowego uprawnienia w czasie wykonywania.

Plan wydania

Ta zmiana zostanie wdrożona między 2 wersjami: 25Q2 i TBD. Deweloperzy muszą przestrzegać tych wskazówek dotyczących 25Q2 i przekazywać opinie, ponieważ te zabezpieczenia zostaną wprowadzone w późniejszej wersji Androida. Ponadto deweloperzy będą musieli zaktualizować scenariusze, które zależą od domyślnego dostępu do sieci lokalnej, korzystając z tych wskazówek, oraz przygotować się na odrzucenie przez użytkownika nowego uprawnienia i jego cofnięcie.

Wpływ

Obecnie jest to funkcja opcjonalna, co oznacza, że dotyczy ona tylko aplikacji, które ją włączą. Celem fazy zgód jest umożliwienie deweloperom aplikacji zrozumienia, które części ich aplikacji są zależne od domyślnego dostępu do sieci lokalnej, aby mogli przygotować się do wprowadzenia ochrony uprawnień w przyszłej wersji.

Dotyczy to aplikacji, które uzyskują dostęp do sieci lokalnej użytkownika za pomocą:

• bezpośrednie lub biblioteczne korzystanie z setek surowych na adresy sieci lokalnej (np. protokół wykrywania usług mDNS lub SSDP);
• Używanie klas na poziomie frameworku, które uzyskują dostęp do sieci lokalnej (np.NsdManager).

Ruch do i z adresu sieci lokalnej wymaga uprawnień dostępu do sieci lokalnej. W tabeli poniżej znajdziesz kilka typowych przypadków:

Te ograniczenia są wdrażane głęboko w składniku sieciowym, dlatego dotyczą wszystkich interfejsów API sieciowych. Dotyczy to gniazd utworzonych w kodzie natywnym lub zarządzanym, bibliotek sieciowych, takich jak Cronet i OkHttp, oraz interfejsów API zaimplementowanych na ich podstawie. Próba rozwiązania usług w sieci lokalnej (czyli usług z przyrostkiem .local) wymaga uprawnień do sieci lokalnej.

Wyjątki od powyższych zasad:

• Jeśli serwer DNS urządzenia znajduje się w sieci lokalnej, ruch do niego i z niego (na porcie 53) nie wymaga uprawnień dostępu do sieci lokalnej.
• Aplikacje korzystające z przełącznika wyjścia jako selektora w aplikacji nie będą wymagać uprawnień do sieci lokalnej (więcej wskazówek pojawi się w IV kwartale 2025 r.).

Wskazówki dla programistów (włączanie opcji)

Aby włączyć ograniczenia sieci lokalnej, wykonaj te czynności:

1. Flashowanie urządzenia do wersji 25Q2 Beta 3 lub nowszej.
2. Zainstaluj aplikację, którą chcesz przetestować.

3. Przełącz flagę Appcompat w adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Uruchom ponownie urządzenie

Teraz dostęp aplikacji do sieci lokalnej jest ograniczony, a próba uzyskania dostępu do sieci lokalnej spowoduje błąd gniazda. Jeśli używasz interfejsów API, które wykonują operacje sieci lokalnej poza procesem aplikacji (np. NsdManager), nie będą one miały wpływu na fazę zgłaszania.

Aby przywrócić dostęp, musisz przyznać aplikacji uprawnienia do NEARBY_WIFI_DEVICES.

1. Upewnij się, że aplikacja deklaruje uprawnienie NEARBY_WIFI_DEVICES w pliku manifestu.
2. Kliknij Ustawienia > Aplikacje > [Nazwa aplikacji] > Uprawnienia > Urządzenia w pobliżu > Zezwalaj.

Teraz dostęp aplikacji do sieci lokalnej powinien zostać przywrócony, a wszystkie scenariusze powinny działać tak samo jak przed włączeniem aplikacji.

Gdy zaczniemy egzekwować ochronę sieci lokalnej, w ten sposób wpłynie to na ruch w sieci aplikacji:

Aby wyłączyć flagę zgodności aplikacji, użyj tego polecenia:

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Błędy

Błędy wynikające z tych ograniczeń będą zwracane do wywołującego gniazda, gdy wywoła on metodę send lub jej wariant na potrzeby wysyłania do lokalnego adresu sieci.

Przykładowe błędy:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definicja sieci lokalnej

Sieć lokalna w tym projekcie to sieć IP, która korzysta z interfejsu sieciowego obsługującego transmisję, np. Wi-Fi lub Ethernet, ale wyklucza połączenia komórkowe (WWAN) i VPN.

Do sieci lokalnych zaliczamy:

IPv4:

• 169.254.0.0/16 // Link Local
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

• Link-local
• Trasy połączone bezpośrednio
• siecie typu stub, takie jak Thread;
• Wiele podsieci (TBD)

Dodatkowo zarówno adresy multicast (224.0.0.0/4, ff00::/8), jak i adres rozgłoszeniowy IPv4 (255.255.255.255) są klasyfikowane jako adresy sieci lokalnej.

Zdjęcia należące do aplikacji

Gdy aplikacja kierowana na pakiet SDK 36 lub nowszy na urządzeniach z Androidem 16 lub nowszym poprosi o uprawnienia do zdjęć i filmów, użytkownicy, którzy zdecydują się na ograniczenie dostępu do wybranych multimediów, zobaczą wszystkie zdjęcia należące do aplikacji wstępnie wybrane w selektorze zdjęć. Użytkownicy mogą odznaczyć dowolne z tych wstępnie wybranych elementów, co spowoduje cofnięcie dostępu aplikacji do tych zdjęć i filmów.