Zmiany zachowania: aplikacje kierowane na Androida 16 lub nowszego

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 użytkownikom bardziej spójnego i intuicyjnego działania.

Odrzucenie wyświetlania bez ramki

Android 15 wymusza wyświetlanie bez ramki w przypadku aplikacji kierowanych na Androida 15 (poziom API 35), ale Twoja aplikacja może z tego zrezygnować, ustawiając wartość R.attr#windowOptOutEdgeToEdgeEnforcement na true. W przypadku aplikacji kierowanych na Androida 16 atrybut R.attr#windowOptOutEdgeToEdgeEnforcement jest wycofany i wyłączony, a aplikacja nie może zrezygnować z wyświetlania bez ramki.

Jeśli chcesz przeprowadzić testy na Androidzie 16 w wersji beta 2, upewnij się, że Twoja aplikacja obsługuje wyświetlanie obrazu od krawędzi do krawędzi, i usuń wszystkie odwołania do R.attr#windowOptOutEdgeToEdgeEnforcement. Aby uzyskać informacje o obsługiwaniu formatu edge-to-edge, zapoznaj się z artykułem Tworzenie wiadomości i Widok. Poinformuj nas o problemach w naszym narzędziu do zgłaszania błędów na stronie opinii.

Wymagane przeprowadzenie migracji lub rezygnacja z funkcji przewidywania wstecz

W przypadku aplikacji kierowanych na Androida 16 lub nowszego i uruchamianych na urządzeniu z Androidem 16 lub nowszym animacje systemowe przewidywanego przejścia wstecz (powrotu do ekranu głównego, przełączania zadań i przełączania działań) są domyślnie włączone. 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 przeniesiona na przewidywane wsteczne przechodzenie, zaktualizuj ją, aby używała obsługiwanych interfejsów API do nawigacji wstecz, lub tymczasowo wyłącz tę funkcję, ustawiając atrybut android:enableOnBackInvokedCallback na false w tagu <application> lub <activity> w pliku AndroidManifest.xml aplikacji.

Animacja przewidywanego powrotu do domu.
Przewidowana animacja aktywności.
Animacja przewidywania zadań.

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

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.

elegantTextHeightzachowanie w przypadku aplikacji kierowanych na Androida 14 (poziom API 34) lub niższego albo aplikacji kierowanych na Androida 15 (poziom API 35), które zastąpiły ustawienie domyślne przez ustawienie atrybutu elegantTextHeight na false.
elegantTextHeight zachowanie w przypadku aplikacji kierowanych na Androida 16 lub na Androida 15 (poziom API 35), które nie zastąpiły wartości domyślnej przez ustawienie atrybutu elegantTextHeight na false.

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ą

Przed kierowaniem na Androida 16, gdy scheduleAtFixedRate nie udało się wykonać zadania, ponieważ nie było ono dostępne w ramach prawidłowego cyklu życia procesu, wszystkie niewykonane zadania są natychmiast wykonywane, gdy aplikacja wraca do prawidłowego cyklu życia.

W przypadku kierowania na Androida 16 maksymalnie 1 niewykonany wcześniej element scheduleAtFixedRate jest natychmiast wykonywany, gdy aplikacja wraca do prawidłowego cyklu życia. Ta zmiana zachowania powinna poprawić działanie aplikacji. Przetestuj to zachowanie w aplikacji, aby sprawdzić, czy na nią wpływa. Możesz też przeprowadzić testy za pomocą ramy kompatybilności aplikacji i włączenia flagi zgodności STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

Formaty urządzeń

Android 16 (poziom interfejsu API 36) wprowadza te zmiany w przypadku aplikacji 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;

Aplikacje kierowane na Androida 16 będą musiały uwzględniać zmiany w zarządzaniu orientacją, zmianą rozmiaru i ograniczeniami dotyczącymi proporcji. Na wyświetlaczach o szerokości ≥ 600 dp te ograniczenia nie obowiązują. Aplikacje wypełniają też cały ekran niezależnie od proporcji i preferowanej orientacji użytkownika. Nie stosuje się też formatu pillarbox.

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 aplikacji, aby zapewnić użytkownikom jak najlepsze wrażenia.

Możesz też przetestować to zachowanie, korzystając z [ramy aplikacji zgodnościowej][a16-kilo-14] i włączając flagę kompatybilnoś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 poziomej. 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 obracanie urządzenia powoduje ponowne tworzenie większej liczby działań, co może spowodować utratę stanu użytkownika, jeśli nie zostanie on odpowiednio 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:

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 na dużych ekranach domyślnie ignorowane są ograniczenia dotyczące orientacji, zmiany rozmiaru i proporcji, 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 korzystania z tej funkcji, stosując tę samą właściwość 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 lub nowszego uprawnienia BODY_SENSORS są zastępowane bardziej szczegółowymi uprawnieniami android.permissions.health, które są też używane przez 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:

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

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 mają na celu poprawę łączności z urządzeniami peryferyjnymi:

Nowe intencje do obsługi utraty połączenia 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.