Zmiany w działaniu: wszystkie aplikacje

Platforma Android 12 zawiera zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wszystkich aplikacji, gdy działają one na Androidzie 12, niezależnie od targetSdkVersion. W razie potrzeby przetestuj aplikację i zmodyfikuj ją, aby prawidłowo obsługiwała te funkcje.

Zapoznaj się też z listą zmian w zachowaniu, które mają wpływ tylko na aplikacje kierowane na Androida 12.

Interfejs użytkownika

Efekt rozciągania podczas przewijania

Na urządzeniach z Androidem 12 lub nowszym zmienia się sposób działania wizualnego w przypadku zdarzeń przewijania poza zakres.

W Androidzie 11 i starszych wersjach zdarzenie przewijania powoduje, że elementy wizualne świecą, a w Androidzie 12 i nowszych wersjach rozciągają się i odbijają podczas przeciągania oraz rozciągają się i odbijają podczas szybkiego przesunięcia.

Więcej informacji znajdziesz w przewodniku po animowaniu gestów przewijania.

Ekrany powitalne aplikacji

Jeśli masz już wdrożony niestandardowy ekran powitalny na Androidzie 11 lub starszym, musisz przenieść aplikację do interfejsu SplashScreen API, aby mieć pewność, że będzie on prawidłowo wyświetlany od Androida 12. Nieprzeniesienie aplikacji spowoduje pogorszenie lub nieprawidłowe działanie aplikacji podczas uruchamiania.

Instrukcje znajdziesz w artykule Migracja istniejącej implementacji ekranu powitalnego do Androida 12.

Dodatkowo od Androida 12 system zawsze stosuje nowy domyślny ekran powitalny systemu Android podczas zimnego i ciepłego uruchamiania wszystkich aplikacji. Domyślnie ten ekran powitalny jest tworzony przy użyciu elementu ikony programu uruchamiającego aplikacji i windowBackground motywu (jeśli jest to jeden kolor).

Więcej informacji znajdziesz w przewodniku dla programistów dotyczącym ekranów powitalnych.

Rozpoznawanie intencji w internecie

Od Androida 12 (API na poziomie 31) ogólny zamiar internetowy jest rozpoznawany jako aktywność w aplikacji tylko wtedy, gdy aplikacja została zatwierdzona w przypadku konkretnej domeny zawartej w tym zamiarze internetowym. Jeśli aplikacja nie zostanie zatwierdzona w domenie, zamiast niej zostanie otwarta domyślna aplikacja przeglądarki użytkownika.

Aplikacje mogą uzyskać tę zgodę na jeden z tych sposobów:

Jeśli Twoja aplikacja wywołuje intencje internetowe, rozważ dodanie prośby lub okna dialogowego, w którym użytkownik będzie musiał potwierdzić działanie.

Ulepszenia trybu pełnoekranowego w przypadku nawigacji przy użyciu gestów

Android 12 ujednolica dotychczasowe działanie, aby ułatwić użytkownikom wykonywanie poleceń nawigacji gestami w trybie pełnoekranowym. Dodatkowo Android 12 zapewnia zgodność wsteczną w przypadku trybu pełnoekranowego.

Display#getRealSize i getRealMetrics: wycofanie i ograniczenia

Urządzenia z Androidem są dostępne w wielu różnych formatach, np. z dużym ekranem, jako tablety i urządzenia składane. Aby prawidłowo renderować treści na każdym urządzeniu, aplikacja musi określić rozmiar ekranu lub wyświetlacza. Z biegiem czasu Android udostępniał różne interfejsy API do pobierania tych informacji. W Androidzie 11 wprowadziliśmy interfejs WindowMetrics API i wycofaliśmy te metody:

W Androidzie 12 nadal zalecamy używanie metody WindowMetrics i wycofujemy te metody:

Aby ograniczyć działanie aplikacji, które używają interfejsów Display API do pobierania granic aplikacji, Android 12 ogranicza wartości zwracane przez interfejsy API w przypadku aplikacji, których rozmiaru nie można w pełni zmieniać. Może to mieć wpływ na aplikacje, które używają tych informacji z MediaProjection.

Aplikacje powinny używać interfejsów API WindowMetrics do wysyłania zapytań o granice okna i Configuration.densityDpi do wysyłania zapytań o aktualną gęstość.

Aby zapewnić szerszą zgodność ze starszymi wersjami Androida, możesz użyć biblioteki Jetpack WindowManager, która zawiera klasę WindowMetrics obsługującą Androida 4.0 (API na poziomie 14) i nowsze wersje.

Przykłady użycia WindowMetrics

Najpierw upewnij się, że aktywności w Twojej aplikacji są w pełni zmienne.

W przypadku wszelkich działań związanych z interfejsem, zwłaszcza WindowManager.getCurrentWindowMetrics() lub WindowMetricsCalculator.computeCurrentWindowMetrics() z Jetpacka, działanie powinno korzystać z WindowMetrics z kontekstu działania.

Jeśli aplikacja tworzy MediaProjection, granice muszą mieć odpowiedni rozmiar, ponieważ projekcja obejmuje partycję wyświetlacza, w której działa aplikacja projektora.

Jeśli aplikacja ma możliwość pełnej zmiany rozmiaru, kontekst aktywności zwraca prawidłowe granice, np.:

Kotlin

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Java

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

Jeśli aplikacja nie jest w pełni skalowalna, musi wysyłać zapytania do instancji WindowContext i pobierać WindowMetrics granic aktywności za pomocą WindowManager.getMaximumWindowMetrics() lub metody Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().

Kotlin

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Java

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

Wszystkie aplikacje w trybie wielu okien

W Androidzie 12 tryb wielu okien jest standardowym zachowaniem.

Na dużych ekranach (sw >= 600 dp) platforma obsługuje wszystkie aplikacje w trybie wielu okien niezależnie od konfiguracji aplikacji. Jeśli resizeableActivity="false", aplikacja jest w razie potrzeby przełączana w tryb zgodności, aby dostosować się do wymiarów ekranu.

Na małych ekranach (sw < 600 dp) system sprawdza wartości minWidth i minHeight aktywności, aby określić, czy może ona działać w trybie wielu okien. Jeśli resizeableActivity="false", aplikacja nie może działać w trybie wielu okien niezależnie od minimalnej szerokości i wysokości.

Więcej informacji znajdziesz w artykule Obsługa wielu okien.

Podgląd z kamery na dużych ekranach

Aplikacje aparatu zwykle zakładają stałą zależność między orientacją urządzenia a formatem podglądu z kamery. Jednak urządzenia z dużym ekranem, takie jak urządzenia składane, oraz tryby wyświetlania, takie jak wielookienkowy i wielomonitorowy, podważają to założenie.

Na Androidzie 12 aplikacje aparatu, które wymagają określonej orientacji ekranu i nie można ich zmieniać (resizeableActivity="false"), automatycznie przechodzą w tryb pionowy z wcięciem, co zapewnia prawidłową orientację i proporcje podglądu z aparatu. Na urządzeniach składanych i innych urządzeniach z warstwą abstrakcji sprzętu aparatu (HAL) do wyjścia z aparatu stosowane jest dodatkowe obracanie, aby skompensować orientację czujnika aparatu, a wyjście z aparatu jest przycinane w celu dopasowania do proporcji podglądu z aparatu w aplikacji. Przycinanie i dodatkowe obracanie zapewniają prawidłowe wyświetlanie podglądu z kamery niezależnie od orientacji urządzenia oraz tego, czy jest ono złożone czy rozłożone.

Opóźnienie UX w przypadku powiadomień o usługach działających na pierwszym planie

Aby zapewnić płynne działanie usług działających na pierwszym planie, urządzenia z Androidem 12 lub nowszym mogą opóźniać wyświetlanie powiadomień o usługach działających na pierwszym planie o 10 sekund, z kilkoma wyjątkami. Dzięki tej zmianie krótkotrwałe zadania będą mogły się zakończyć, zanim pojawią się powiadomienia.

Wydajność

Aplikacje w trybie czuwania z ograniczeniami

W Androidzie 11 (poziom API 30) wprowadzono ograniczony przedział jako przedział gotowości aplikacji. Od Androida 12 ten zasobnik jest domyślnie aktywny. Ograniczony koszyk ma najniższy priorytet (i największe ograniczenia) ze wszystkich koszyków. Koszty są uporządkowane według priorytetu od najwyższego do najniższego:

  1. Aktywna: aplikacja jest obecnie używana lub była używana niedawno.
  2. Zestaw roboczy: aplikacja jest regularnie używana.
  3. Często: aplikacja jest często używana, ale nie codziennie.
  4. Rzadko: aplikacja nie jest często używana.
  5. Ograniczone: aplikacja zużywa dużo zasobów systemowych lub może wykazywać niepożądane działanie.

System bierze pod uwagę zachowanie aplikacji oraz wzorce użytkowania, aby zdecydować, czy umieścić ją w grupie ograniczonej.

Jeśli Twoja aplikacja będzie w odpowiedzialny sposób korzystać z zasobów systemowych, jest mniejsze prawdopodobieństwo, że trafi do grupy ograniczonej. Jeśli użytkownik wchodzi w bezpośrednią interakcję z aplikacją, system umieszcza ją w mniej restrykcyjnej kategorii.

Sprawdzanie, czy aplikacja znajduje się w zasobniku z ograniczeniami

Aby sprawdzić, czy system umieścił Twoją aplikację w zasobniku z ograniczeniami, wywołaj funkcję getAppStandbyBucket(). Jeśli ta metoda zwraca wartość STANDBY_BUCKET_RESTRICTED, oznacza to, że Twoja aplikacja znajduje się w grupie ograniczonej.

Testowanie działania zasobnika z ograniczeniami

Aby sprawdzić, jak aplikacja zachowuje się, gdy system umieści ją w grupie z ograniczeniami, możesz ręcznie przenieść ją do tej grupy. Aby to zrobić, uruchom to polecenie w oknie terminala:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Lokalizacja na pierwszym planie i Oszczędzanie baterii

Od Androida 12 lokalizacja na pierwszym planie (w tym z usługi działającej na pierwszym planie) może być nadal dostarczana, gdy tryb oszczędzania baterii jest aktywny, nawet gdy ekran jest wyłączony.

Wcześniej tryb oszczędzania baterii zatrzymywał aktualizacje lokalizacji, gdy ekran był wyłączony. Ta zmiana wydłuża czas pracy na baterii i oznacza, że deweloperzy nie muszą prosić użytkowników o wyłączenie trybu oszczędzania baterii, aby zapewnić dostarczanie informacji o lokalizacji.

Aplikacje, które proszą o dostęp do lokalizacji za pomocą usługi działającej na pierwszym planie, powinny wykonać te czynności:

  1. Zadzwoń getLocationPowerSaverMode() i sprawdź, jak działają funkcje lokalizacji urządzenia, gdy aktywne jest oszczędzanie baterii.
  2. Jeśli ta funkcja zwróci wartość LOCATION_MODE_FOREGROUND_ONLY, aplikacja będzie nadal otrzymywać aktualizacje lokalizacji, gdy jest na pierwszym planie lub gdy działa jako usługa na pierwszym planie, a tryb oszczędzania baterii jest włączony i ekran jest wyłączony.

Prywatność i bezpieczeństwo

Przybliżona lokalizacja

Okno dialogowe ma 2 zestawy opcji, jeden nad drugim.
Rysunek 1. Okno dialogowe uprawnień systemowych, które umożliwia użytkownikowi przyznanie dostępu do przybliżonych informacji o lokalizacji.

Na urządzeniach z Androidem 12 lub nowszym użytkownicy mogą poprosić, aby Twoja aplikacja miała dostęp tylko do przybliżonych informacji o lokalizacji.

Jeśli aplikacja prosi o uprawnienie na czas działania ACCESS_FINE_LOCATION, powinna też prosić o uprawnienie ACCESS_COARSE_LOCATION, aby obsługiwać sytuację, w której użytkownik przyznaje aplikacji dostęp do przybliżonej lokalizacji. Oba uprawnienia powinny być zawarte w jednej prośbie o przyznanie uprawnień w czasie działania.

Okno uprawnień systemowych zawiera te opcje dla użytkownika (rysunek 1):

  • Dokładna: zapewnia dostęp do dokładnych informacji o lokalizacji.
  • Przybliżona: zapewnia dostęp tylko do przybliżonych informacji o lokalizacji.

Przełączniki mikrofonu i aparatu

Na obsługiwanych urządzeniach z Androidem 12 lub nowszym użytkownicy mogą włączać i wyłączać dostęp do kamery i mikrofonu dla wszystkich aplikacji na urządzeniu, naciskając jeden przełącznik. Użytkownicy mogą uzyskać dostęp do opcji, które można włączać i wyłączać, w Szybkich ustawieniach, jak pokazano na rysunku 1, lub na ekranie Prywatność w ustawieniach systemu.

Dowiedz się więcej o tych przełącznikach i o tym, jak sprawdzić, czy Twoja aplikacja jest zgodna ze sprawdzonymi metodami dotyczącymi uprawnień CAMERA i RECORD_AUDIO.

Wskaźniki mikrofonu i aparatu

Gdy aplikacja na urządzeniu z Androidem 12 lub nowszym uzyskuje dostęp do mikrofonu lub aparatu, na pasku stanu pojawia się ikona.

Dowiedz się więcej o tych wskaźnikach i o tym, jak sprawdzić, czy Twoja aplikacja jest zgodna ze sprawdzonymi metodami dotyczącymi uprawnień CAMERA i RECORD_AUDIO.

Kafelki szybkich ustawień mają etykiety „Dostęp do aparatu” i „Dostęp do mikrofonu”.
Rysunek 2. przełączniki mikrofonu i kamery w Szybkich ustawieniach
.
Zaokrąglony prostokąt w prawym górnym rogu, który zawiera ikonę aparatu i ikonę mikrofonu.
Rysunek 3. wskaźniki mikrofonu i aparatu, które pokazują
ostatni dostęp do danych;

Widoczność pakietu uprawnień

Na urządzeniach z Androidem 12 lub nowszym aplikacje, które są kierowane na Androida 11 (API na poziomie 30) lub nowszego i wywołują jedną z tych metod, otrzymują filtrowany zestaw wyników na podstawie widoczności pakietu aplikacji w innych aplikacjach:

Usunięcie implementacji BouncyCastle

Android 12 usuwa wiele implementacji BouncyCastle algorytmów kryptograficznych, które zostały wcześniej wycofane, w tym wszystkie algorytmy AES. Zamiast tego system używa implementacji Conscrypt tych algorytmów.

Ta zmiana ma wpływ na Twoją aplikację, jeśli spełniony jest jeden z tych warunków:

  • Twoja aplikacja używa kluczy o rozmiarze 512 bitów. Conscrypt nie obsługuje tego rozmiaru klucza. W razie potrzeby zaktualizuj mechanizmy kryptograficzne aplikacji, aby używać różnych rozmiarów kluczy.

  • Aplikacja używa nieprawidłowych rozmiarów kluczy w przypadku KeyGenerator. Implementacja biblioteki Conscrypt w przypadku KeyGenerator przeprowadza dodatkową weryfikację parametrów klucza w porównaniu z biblioteką BouncyCastle. Na przykład Conscrypt nie pozwala aplikacji na wygenerowanie 64-bitowego klucza AES, ponieważ AES obsługuje tylko klucze 128-, 192- i 256-bitowe.

    Biblioteka BouncyCastle umożliwia generowanie kluczy o nieprawidłowych rozmiarach, ale później nie działa, jeśli te klucze są używane z Cipher. Conscrypt wcześniej zgłasza błąd.

  • Szyfry w trybie Galois/Counter Mode (GCM) inicjujesz przy użyciu rozmiaru innego niż 12 bajtów. Implementacja GcmParameterSpec w bibliotece Conscrypt wymaga inicjalizacji 12 bajtów, co zaleca NIST.

Powiadomienia o dostępie do schowka

Gdy na urządzeniu z Androidem 12 lub nowszym aplikacja po raz pierwszy wywoła getPrimaryClip(), aby uzyskać dostęp do danych schowka z innej aplikacji, pojawi się komunikat informujący użytkownika o tym dostępie.

Tekst w wyskakującym powiadomieniu ma ten format:APP pasted from your clipboard.

Informacje o tekście w opisie klipu

Na Androidzie 12 i nowszym getPrimaryClipDescription() może wykrywać te szczegóły:

Aplikacje nie mogą zamykać okien systemowych

Aby zwiększyć kontrolę użytkowników nad interakcjami z aplikacjami i systemem, działanie intencji ACTION_CLOSE_SYSTEM_DIALOGS zostało wycofane w Androidzie 12. Z wyjątkiem kilku szczególnych przypadków, gdy aplikacja próbuje wywołać intencję zawierającą tę czynność, system wykonuje jedną z tych czynności w zależności od docelowej wersji pakietu SDK aplikacji:

  • Jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego, wystąpi błąd SecurityException.

  • Jeśli Twoja aplikacja jest kierowana na Androida 11 (poziom interfejsu API 30) lub starszego, intencja nie zostanie wykonana, a w Logcat pojawi się ten komunikat:

    E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.

Wyjątki

W tych przypadkach aplikacja może nadal zamykać okna systemowe na Androidzie 12 lub nowszym:

  • Aplikacja uruchamia test instrumentacji.

  • Twoja aplikacja jest kierowana na Androida 11 lub starszego i wyświetla okno na panelu powiadomień.

  • Twoja aplikacja jest kierowana na Androida 11 lub starszego. Dodatkowo użytkownik wszedł w interakcję z powiadomieniem, być może używając przycisków działania powiadomienia, a aplikacja przetwarza usługę lub odbiornik transmisji w odpowiedzi na to działanie użytkownika.

  • Twoja aplikacja jest kierowana na Androida 11 lub starszego i ma aktywną usługę ułatwień dostępu. Jeśli Twoja aplikacja jest przeznaczona na Androida 12 i chcesz zamknąć pasek powiadomień, użyj działania ułatwień dostępu GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.

Niezaufane zdarzenia dotyku są blokowane

Aby zachować bezpieczeństwo systemu i zapewnić użytkownikom wygodę, Android 12 uniemożliwia aplikacjom korzystanie z zdarzeń dotykowych, gdy nakładka zasłania aplikację w niebezpieczny sposób. Innymi słowy, system blokuje dotknięcia, które przechodzą przez określone okna, z kilkoma wyjątkami.

Aplikacje, w których wystąpiła awaria

Ta zmiana dotyczy aplikacji, które umożliwiają przekazywanie dotknięć przez swoje okna, np. za pomocą flagi FLAG_NOT_TOUCHABLE. Oto kilka przykładów:

Wyjątki

W tych przypadkach zezwalamy na przekazywanie dotknięć:

  • Interakcje w aplikacji: aplikacja wyświetla nakładkę, która pojawia się tylko wtedy, gdy użytkownik wchodzi z nią w interakcję.

  • Zaufane okna. Obejmują one m.in.:

  • Niewidoczne okna. Widok główny okna to GONE lub INVISIBLE.

  • Całkowicie przezroczyste okna. Właściwość alpha okna ma wartość 0,0.

  • Okna alertów systemowych są wystarczająco przezroczyste. System uznaje zestaw okien alertów systemowych za wystarczająco przezroczysty, gdy łączna nieprzezroczystość jest mniejsza lub równa maksymalnej nieprzezroczystości zasłaniania dotyku w systemie. W Androidzie 12 domyślna maksymalna nieprzezroczystość wynosi 0, 8.

Wykrywanie zablokowania niezaufanego dotyku

Jeśli działanie dotykowe zostanie zablokowane przez system, w Logcat pojawi się ten komunikat:

Untrusted touch due to occlusion by PACKAGE_NAME

Testowanie zmiany

Niezaufane dotknięcia są domyślnie blokowane na urządzeniach z Androidem 12 lub nowszym. Aby zezwolić na niezaufane dotknięcia, uruchom w oknie terminala to polecenie ADB:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

Aby przywrócić domyślne działanie (blokowanie niezaufanych dotknięć), uruchom to polecenie:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Cykl życia aktywności

Działania programu uruchamiającego głównego nie są już kończone po naciśnięciu przycisku Wstecz

Android 12 zmienia domyślne działanie systemowego przycisku Wstecz w aktywnościach launchera, które są u podstawy swoich zadań. W poprzednich wersjach system kończył te działania po naciśnięciu przycisku Wstecz. W Androidzie 12 system przenosi aktywność i jej zadanie w tle zamiast kończyć aktywność. Nowe działanie jest zgodne z obecnym działaniem podczas opuszczania aplikacji za pomocą przycisku ekranu głównego lub gestu.

W przypadku większości aplikacji ta zmiana oznacza, że użytkownicy, którzy używają przycisku Wstecz, aby wyjść z aplikacji, mogą szybciej wznowić jej działanie w stanie ciepłym, zamiast całkowicie uruchamiać ją ponownie w stanie zimnym.

Zalecamy przetestowanie aplikacji po wprowadzeniu tej zmiany. Jeśli Twoja aplikacja obecnie zastępuje onBackPressed(), aby obsługiwać nawigację wstecz i kończyć Activity, zaktualizuj implementację, aby wywoływać super.onBackPressed() zamiast kończyć. Wywoływaniesuper.onBackPressed() przenosi aktywność i jej zadanie w odpowiednich przypadkach w tle i zapewnia użytkownikom spójniejsze wrażenia podczas poruszania się po aplikacjach.

Pamiętaj też, że do zapewniania niestandardowej nawigacji wstecz zalecamy używanie interfejsów AndroidX Activity API, a nie zastępowanie metody onBackPressed(). Interfejsy API AndroidX Activity automatycznie przekierowują do odpowiedniego zachowania systemu, jeśli nie ma komponentów przechwytujących naciśnięcie przycisku Wstecz.

Grafika i obrazy

Ulepszone przełączanie częstotliwości odświeżania

W Androidzie 12 zmiany częstotliwości odświeżania za pomocą setFrameRate() mogą następować niezależnie od tego, czy wyświetlacz obsługuje płynne przejście do nowej częstotliwości odświeżania. Płynne przejście to takie, które nie powoduje żadnych zakłóceń wizualnych, np. czarnego ekranu przez sekundę lub dwie. Wcześniej, jeśli wyświetlacz nie obsługiwał płynnego przejścia, po wywołaniu funkcji setFrameRate() zwykle nadal używał tej samej częstotliwości odświeżania. Zanim przejdziesz na nowy sposób odświeżania, możesz sprawdzić, czy będzie to bezproblemowe, dzwoniąc pod numer getAlternativeRefreshRates(). Zwykle wywołanie zwrotne onDisplayChanged() jest wywoływane po zakończeniu zmiany częstotliwości odświeżania, ale w przypadku niektórych wyświetlaczy podłączonych zewnętrznie jest wywoływane podczas przejścia bez płynnej zmiany.

Oto przykład, jak możesz to zrobić:

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Java

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Łączność

Aktualizacje Passpoint

W Androidzie 12 dodaliśmy te interfejsy API:

  • isPasspointTermsAndConditionsSupported():Warunki to funkcja Passpoint, która umożliwia zastąpienie niezabezpieczonych portali przechwytujących, które korzystają z otwartych sieci, bezpieczną siecią Passpoint. Gdy wymagane jest zaakceptowanie warunków, użytkownikowi wyświetla się powiadomienie. Aplikacje, które sugerują sieci Passpoint z warunkami, muszą najpierw wywołać ten interfejs API, aby upewnić się, że urządzenie obsługuje tę funkcję. Jeśli urządzenie nie obsługuje tej funkcji, nie będzie mogło połączyć się z tą siecią. W takim przypadku należy zaproponować sieć alternatywną lub starszą.

  • isDecoratedIdentitySupported(): podczas uwierzytelniania w sieciach z dekoracją prefiksu udekorowany prefiks tożsamości umożliwia operatorom sieci aktualizowanie identyfikatora NAI w celu wykonywania jawnego routingu przez wiele serwerów proxy w sieci AAA (więcej informacji znajdziesz w RFC 7542).

    Android 12 implementuje tę funkcję zgodnie ze specyfikacją WBA dotyczącą rozszerzeń PPS-MO. Aplikacje, które sugerują sieci Passpoint wymagające udekorowanej tożsamości, muszą najpierw wywołać ten interfejs API, aby upewnić się, że urządzenie obsługuje tę funkcję. Jeśli urządzenie nie obsługuje tej funkcji, tożsamość nie zostanie ozdobiona, a uwierzytelnianie w sieci może się nie powieść.

Aby utworzyć sugestię Passpoint, aplikacje muszą używać klas PasspointConfiguration, Credential i HomeSp. Te klasy opisują profil Passpoint, który jest zdefiniowany w specyfikacji Passpoint organizacji Wi-Fi Alliance.

Więcej informacji znajdziesz w artykule Interfejs Wi-Fi suggestion API do łączenia się z internetem.

Zaktualizowane ograniczenia dotyczące interfejsów innych niż SDK

Android 12 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK, które powstały na podstawie współpracy z programistami Androida i najnowszych testów wewnętrznych. W miarę możliwości przed ograniczeniem interfejsów innych niż SDK udostępniamy publiczne alternatywy.

Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą nie mieć na nią natychmiastowego wpływu. Obecnie możesz używać niektórych interfejsów spoza SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z dowolnej metody lub pola spoza SDK zawsze wiąże się z wysokim ryzykiem awarii aplikacji.

Jeśli nie masz pewności, czy Twoja aplikacja używa interfejsów innych niż SDK, możesz to sprawdzić, testując ją. Jeśli Twoja aplikacja korzysta z interfejsów spoza SDK, zacznij planować migrację na alternatywne rozwiązania SDK. Rozumiemy jednak, że w przypadku niektórych aplikacji używanie interfejsów innych niż SDK jest uzasadnione. Jeśli nie możesz znaleźć alternatywy dla używania interfejsu innego niż SDK w przypadku funkcji w aplikacji, poproś o nowy publiczny interfejs API.

Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Aktualizacje ograniczeń interfejsów innych niż SDK w Androidzie 12. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK.