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 działających na Androidzie 12, niezależnie od targetSdkVersion. Przetestuj aplikację i w razie potrzeby 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ą tylko na aplikacje kierowane na Androida 12.
Interfejs użytkownika
Efekt rozciągania przewijania
Na urządzeniach z Androidem 12 lub nowszym zmienia się sposób wyświetlania zdarzeń przewijania poza zakres.
Na Androidzie 11 i starszych zdarzenie overscroll powoduje, że elementy wizualne świecą. Na Androidzie 12 i nowszych elementy wizualne rozciągają się i odbijają przy zdarzeniu przeciągnięcia, a przy zdarzeniu szybkiego przewijania są szybko przewijane i odbijają się.
Więcej informacji znajdziesz w przewodniku na temat animowania gestów przewijania.
Ekrany powitalne aplikacji
Jeśli masz już niestandardowy ekran powitalny w Androidzie 11 lub starszym, musisz przenieść aplikację do interfejsu API SplashScreen, aby mieć pewność, że będzie się prawidłowo wyświetlać w Androidzie 12. Jeśli nie przeniesiesz aplikacji, jej uruchamianie może być utrudnione lub nieprawidłowe.
Instrukcje znajdziesz w artykule Migracja istniejącej implementacji ekranu powitalnego na Androida 12.
Dodatkowo od Androida 12 system zawsze stosuje nowy domyślny ekran powitalny systemu Android podczas uruchamiania na zimno i uruchamiania na ciepło wszystkich aplikacji.
Domyślnie ten domyślny ekran powitalny systemu 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
Począwszy od Androida 12 (API na poziomie 31), ogólna intencja internetowa jest rozpoznawana jako aktywność w aplikacji tylko wtedy, gdy aplikacja jest zatwierdzona dla konkretnej domeny zawartej w tej intencji. Jeśli Twoja aplikacja nie zostanie zatwierdzona dla domeny, intencja internetowa zostanie przekierowana do przeglądarki domyślnej użytkownika.
Aplikacje mogą uzyskać tę zgodę na jeden z tych sposobów:
Zweryfikuj domenę za pomocą linków do aplikacji na Androida.
W przypadku aplikacji kierowanych na Androida 12 lub nowszego system zmienia sposób automatycznej weryfikacji linków do aplikacji na Androida. Sprawdź, czy w filtrach intencji aplikacji uwzględniasz kategorię
BROWSABLEi obsługujesz schemathttps.Na Androidzie 12 lub nowszym możesz ręcznie zweryfikować linki do aplikacji na Androida, aby sprawdzić, jak ta zaktualizowana logika wpływa na Twoją aplikację.
Poproś użytkownika o powiązanie aplikacji z domeną w ustawieniach systemu.
Jeśli aplikacja wywołuje intencje internetowe, rozważ dodanie prośby lub okna z prośbą o potwierdzenie działania przez użytkownika.
Ulepszenia trybu imersji w nawigacji przy użyciu gestów
Android 12 konsoliduje dotychczasowe zachowanie, aby ułatwić użytkownikom wykonywanie poleceń nawigacji przy użyciu gestów w trybie pojemnym. Dodatkowo Android 12 zapewnia zgodność wsteczną w przypadku trybu imersji.
Display#getRealSize i getRealMetrics: wycofanie i ograniczenia
Urządzenia z Androidem są dostępne w wielu różnych formatach, takich jak duże ekrany, 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 czasem Android udostępnił różne interfejsy API do pobierania tych informacji. W Androidzie 11 wprowadziliśmy interfejs API WindowMetrics i wycofaliśmy te metody:
W Androidzie 12 nadal zalecamy używanie WindowMetrics i wycofujemy te metody:
Aby ograniczyć zachowanie 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 zmienić. Może to mieć wpływ na aplikacje, które używają tych informacji w MediaProjection.
Aplikacje powinny używać interfejsów API WindowMetrics do wysyłania zapytań o granice okna oraz Configuration.densityDpi do wysyłania zapytań o bieżącą gęstość.
Aby zapewnić większą zgodność ze starszymi wersjami Androida, możesz użyć biblioteki Jetpack WindowManager, która zawiera klasę WindowMetrics obsługującą Androida 4.0 (poziom interfejsu API 14) i nowsze wersje.
Przykłady użycia WindowMetrics
Najpierw upewnij się, że aktywności w aplikacji mają pełną możliwość zmiany rozmiaru.
W przypadku wszelkich działań związanych z interfejsem, zwłaszcza WindowManager.getCurrentWindowMetrics() lub WindowMetricsCalculator.computeCurrentWindowMetrics() Jetpacka, aktywność powinna opierać się na WindowMetrics z kontekstu aktywności.
Jeśli aplikacja tworzy obiekt MediaProjection, granice muszą mieć prawidłowy rozmiar, ponieważ projekcja rejestruje partycję wyświetlacza, na której działa aplikacja projektora.
Jeśli rozmiar aplikacji można w pełni zmienić, kontekst aktywności zwraca prawidłowe granice, na przykład:
Kotlin
val projectionMetrics: WindowMetrics = activityContext .getSystemService(WindowManager::class.java).maximumWindowMetrics
Java
WindowMetrics projectionMetrics = activityContext .getSystemService(WindowManager.class).getMaximumWindowMetrics();
Jeśli rozmiaru aplikacji nie można w pełni zmienić, musi ona wysłać zapytanie z instancji WindowContext i pobrać 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 wyświetlacza.
Na małych ekranach (sw < 600 dp) system sprawdza właściwości aktywności
minWidth
i
minHeight,
aby określić, czy aktywność może 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 aparatu na dużych ekranach
Aplikacje do obsługi aparatu zwykle zakładają stałą zależność między orientacją urządzenia a formatem obrazu podglądu z aparatu. Jednak urządzenia z dużym ekranem, takie jak urządzenia składane, oraz tryby wyświetlania, takie jak tryb wielu okien i wielu wyświetlaczy, podważają to założenie.
Na Androidzie 12 aplikacje aparatu, które wymagają określonej orientacji ekranu i nie można zmienić ich rozmiaru (resizeableActivity="false"), automatycznie przechodzą w tryb portretowy, co zapewnia prawidłową orientację i format obrazu podglądu aparatu. Na urządzeniach składanych i innych urządzeniach, które mają warstwę abstrakcji sprzętowej (HAL) aparatu, do obrazu z aparatu stosowany jest dodatkowy obrót, aby skompensować orientację czujnika aparatu, a obraz z aparatu jest przycinany, aby pasował do formatu obrazu podglądu aparatu w aplikacji. Przycinanie i dodatkowe obracanie zapewniają prawidłowe wyświetlanie podglądu z aparatu niezależnie od orientacji urządzenia oraz jego stanu złożenia lub rozłożenia.
Opóźnienie UX w przypadku powiadomień o usługach działających na pierwszym planie
Aby zapewnić płynne działanie krótko działających usług na pierwszym planie, urządzenia z Androidem 12 lub nowszym mogą opóźniać wyświetlanie powiadomień o usługach na pierwszym planie o 10 sekund, z kilkoma wyjątkami. Dzięki tej zmianie krótkotrwałe zadania mogą zostać ukończone, zanim pojawią się powiadomienia.
Wydajność
Zasobnik czuwania aplikacji z ograniczeniami
W Androidzie 11 (poziom API 30) wprowadzono zasobnik z ograniczeniami jako zasobnik czuwania aplikacji. Od Androida 12 ten zasobnik jest domyślnie aktywny. Zasobnik z ograniczeniami ma najniższy priorytet (i największe ograniczenia) ze wszystkich zasobników. Kategorie w kolejności od najwyższego do najniższego priorytetu:
- Aktywna: aplikacja jest obecnie używana lub była używana niedawno.
- Zestaw roboczy: aplikacja jest regularnie używana.
- Często: aplikacja jest używana często, ale nie codziennie.
- Rzadko: aplikacja nie jest często używana.
- Ograniczone: aplikacja zużywa dużo zasobów systemowych lub może wykazywać niepożądane zachowanie.
Aby zdecydować, czy umieścić aplikację w zasobniku z ograniczeniami, system bierze pod uwagę jej zachowanie oraz wzorce użytkowania.
Jeśli aplikacja będzie bardziej odpowiedzialnie korzystać z zasobów systemowych, prawdopodobieństwo, że zostanie umieszczona w zasobniku z ograniczeniami, będzie mniejsze. System umieszcza też aplikację w mniej restrykcyjnym zasobniku, jeśli użytkownik wchodzi z nią w bezpośrednią interakcję.
Sprawdzanie, czy aplikacja znajduje się w zasobniku z ograniczeniami
Aby sprawdzić, czy system umieścił aplikację w zasobniku z ograniczeniami, wywołaj getAppStandbyBucket().
Jeśli ta metoda zwraca wartość STANDBY_BUCKET_RESTRICTED, aplikacja znajduje się w zasobniku z ograniczeniami.
Testowanie działania zasobnika z ograniczeniami
Aby sprawdzić, jak zachowuje się aplikacja, gdy system umieści ją w zasobniku z ograniczeniami, możesz ręcznie przenieść ją do tego zasobnika. Aby to zrobić, uruchom w oknie terminala to polecenie:
adb shell am set-standby-bucket PACKAGE_NAME restricted
Lokalizacja na pierwszym planie i Oszczędzanie baterii
Począwszy od Androida 12, lokalizacja na pierwszym planie (w tym z usługi działającej na pierwszym planie) może być nadal dostarczana, gdy oszczędzanie baterii jest aktywne, nawet przy wyłączonym ekranie.
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 oszczędzania baterii, aby zapewnić dostarczanie lokalizacji.
Aplikacje, które żądają dostępu do lokalizacji za pomocą usługi działającej na pierwszym planie, powinny wykonać te czynności:
- Wywołaj
getLocationPowerSaverMode(), aby sprawdzić, jak zachowują się funkcje lokalizacji urządzenia, gdy oszczędzanie baterii jest aktywne. - Jeśli zwróci wartość
LOCATION_MODE_FOREGROUND_ONLY, aplikacja będzie nadal otrzymywać informacje o zmianie lokalizacji, gdy będzie działać na pierwszym planie lub gdy będzie uruchomiona usługa (działająca) na pierwszym planie, gdy Oszczędzanie baterii będzie włączone, a ekran wyłączony.
Prywatność i bezpieczeństwo
Przybliżona lokalizacja
Na urządzeniach z Androidem 12 lub nowszym użytkownicy mogą zażądać, aby aplikacja miała dostęp tylko do przybliżonej lokalizacji.
Jeśli aplikacja prosi o uprawnienia ACCESS_FINE_LOCATION w czasie działania, powinna też poprosić o uprawnienia ACCESS_COARSE_LOCATION, aby obsłużyć przypadek, w którym użytkownik przyznaje jej dostęp do przybliżonej lokalizacji. Oba uprawnienia powinny być uwzględnione w jednym żądaniu w czasie działania.
Okno uprawnień systemowych zawiera te opcje dla użytkownika, jak pokazano na rysunku 1:
- Dokładna: zapewnia dostęp do dokładnych informacji o lokalizacji.
- Przybliżona: zapewnia dostęp tylko do informacji o przybliżonej lokalizacji.
Przełączniki mikrofonu i aparatu
Obsługiwane urządzenia z Androidem 12 lub nowszym umożliwiają użytkownikom włączanie i wyłączanie dostępu do aparatu i mikrofonu we wszystkich aplikacjach na urządzeniu za pomocą jednego przełącznika. Użytkownicy mogą uzyskać dostęp do opcji przełączania 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
Na urządzeniach z Androidem 12 lub nowszym, gdy aplikacja korzysta z 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.
Uprawnienia do wyświetlania pakietów
Na urządzeniach z Androidem 12 lub nowszym aplikacje kierowane na Androida 11 (poziom API 30) lub nowszego, które wywołują jedną z poniższych metod, otrzymują przefiltrowany zestaw wyników na podstawie widoczności pakietu aplikacji w innych aplikacjach:
Usunięto implementację 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 dotyczy Twojej aplikacji, jeśli spełniony jest którykolwiek 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 logiczne kryptografii aplikacji, aby używać różnych rozmiarów kluczy.
Twoja aplikacja używa nieprawidłowych rozmiarów kluczy w
KeyGenerator. ImplementacjaKeyGeneratorw Conscrypt przeprowadza dodatkową weryfikację parametrów klucza w porównaniu z 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.BouncyCastle umożliwia generowanie kluczy o nieprawidłowych rozmiarach, ale później kończy się niepowodzeniem, jeśli te klucze są używane z
Cipher. Conscrypt kończy się niepowodzeniem wcześniej.Inicjujesz szyfry Galois/Counter Mode (GCM) przy użyciu rozmiaru innego niż 12 bajtów. Implementacja
GcmParameterSpecw Conscrypt wymaga inicjalizacji 12 bajtów, co jest zalecane przez NIST.
Powiadomienia o dostępie do schowka
Na urządzeniach z Androidem 12 lub nowszym, gdy aplikacja po raz pierwszy wywołuje getPrimaryClip(), aby uzyskać dostęp do danych klipu z innej aplikacji, użytkownik otrzymuje powiadomienie o dostępie do schowka.
Tekst w komunikacie wyskakującym ma ten format:
APP pasted from your clipboard.
Informacje o tekście w opisie klipu
Na Androidzie 12 i nowszych getPrimaryClipDescription() może wykrywać te informacje:
- Stylizowany tekst, używający
isStyledText(). - różne klasyfikacje tekstu, np. adresy URL, za pomocą
getConfidenceScore().
Aplikacje nie mogą zamykać okien systemowych
Aby zwiększyć kontrolę użytkownika podczas interakcji z aplikacjami i systemem, od Androida 12 działanie intencji ACTION_CLOSE_SYSTEM_DIALOGS jest wycofane. Z wyjątkiem kilku szczególnych przypadków, gdy aplikacja próbuje wywołać intencję zawierającą to działanie, system wykonuje jedną z tych czynności w zależności od docelowej wersji pakietu SDK aplikacji:
- Jeśli aplikacja jest kierowana na Androida 12 lub nowszego, występuje błąd
SecurityException. Jeśli 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 przeprowadza test z instrumentacją.
Twoja aplikacja jest kierowana na Androida 11 lub starszego i wyświetla okno nad obszarem powiadomień.
Twoja aplikacja jest kierowana na Androida 11 lub starszego. Dodatkowo użytkownik wszedł w interakcję z powiadomieniem, np. używając przycisków poleceń, a aplikacja przetwarza usługę lub odbiornik komunikatów w odpowiedzi na 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 kierowana na Androida 12 i chcesz zamknąć pasek powiadomień, użyj działania ułatwień dostępu
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.
Niezaufane zdarzenia dotknięcia są blokowane
Aby zapewnić bezpieczeństwo systemu i wygodę użytkowników, Android 12 uniemożliwia aplikacjom wykorzystywanie zdarzeń dotknięcia, gdy nakładka zasłania aplikację w niebezpieczny sposób. Innymi słowy, system blokuje dotknięcia, które przechodzą przez niektóre okna, z kilkoma wyjątkami.
Aplikacje, w których wystąpiła awaria
Ta zmiana dotyczy aplikacji, które zezwalają na przekazywanie dotknięć przez okna, na przykład za pomocą flagi FLAG_NOT_TOUCHABLE. Oto kilka przykładów:
- Nakładki, które wymagają uprawnienia
SYSTEM_ALERT_WINDOW, takie jak okna korzystające zTYPE_APPLICATION_OVERLAYi używające flagiFLAG_NOT_TOUCHABLE. - Okna aktywności, które używają flagi
FLAG_NOT_TOUCHABLE.
Wyjątki
W tych przypadkach dozwolone są dotknięcia „przekazywane”:
- Interakcje w aplikacji. Aplikacja wyświetla nakładkę, która pojawia się tylko wtedy, gdy użytkownik wchodzi w interakcję z aplikacją.
Zaufane okna Te okna to m.in.:
Całkowicie przezroczyste okna. Właściwość
alphama wartość 0,0 dla okna.Wystarczająco przezroczyste okna alertów systemowych. System uznaje zestaw okien alertów systemowych za wystarczająco przezroczysty, gdy łączna przezroczystość jest mniejsza lub równa maksymalnej przezroczystości systemu w przypadku dotknięć. W Androidzie 12 domyślna maksymalna nieprzezroczystość wynosi 0, 8.
Wykrywanie blokowania niezaufanego dotknięcia
Jeśli działanie dotykowe zostanie zablokowane przez system, Logcat zarejestruje ten komunikat:
Untrusted touch due to occlusion by PACKAGE_NAME
Testowanie zmiany
Na urządzeniach z Androidem 12 lub nowszym niezaufane dotknięcia są domyślnie blokowane. 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
Aktywności w głównym menu z aplikacjami nie są już zamykane po naciśnięciu przycisku Wstecz.
Android 12 zmienia domyślną obsługę naciśnięcia przycisku Wstecz w aktywnościach programu uruchamiającego, które są głównymi aktywnościami w zadaniach. W poprzednich wersjach system kończył te aktywności po naciśnięciu przycisku Wstecz. W Androidzie 12 system przenosi aktywność i jej zadanie do tła, zamiast ją kończyć. Nowe zachowanie jest zgodne z obecnym zachowaniem 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 ze stanu ciepłego, zamiast całkowicie uruchamiać ją ponownie ze stanu zimnego.
Zalecamy przetestowanie aplikacji pod kątem tej zmiany. Jeśli aplikacja obecnie zastępuje metodę onBackPressed(), aby obsługiwać przechodzenie wstecz i kończyć działanie Activity, zaktualizuj implementację, aby wywoływać metodę super.onBackPressed() zamiast kończyć działanie. Wywołanie metody super.onBackPressed() przenosi aktywność i jej zadanie do tła, gdy jest to konieczne, i zapewnia użytkownikom bardziej spójne działanie nawigacji w aplikacjach.
Pamiętaj też, że ogólnie zalecamy używanie interfejsów API aktywności AndroidX do zapewniania niestandardowego przechodzenia wstecz, a nie zastępowania metody onBackPressed(). Interfejsy AndroidX Activity API automatycznie odwołują się do odpowiedniego działania 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 na nową częstotliwość odświeżania. Płynne przejście to takie, które nie powoduje żadnych zakłóceń wizualnych, takich jak czarny ekran przez sekundę lub dwie. Wcześniej, jeśli wyświetlacz nie obsługiwał płynnego przejścia, po wywołaniu setFrameRate() zwykle nadal używał tej samej częstotliwości odświeżania. Możesz wcześniej określić, czy przejście na nową częstotliwość odświeżania będzie płynne, wywołując funkcję 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 niepłynnego przejścia.
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);
Połączenia
Aktualizacje Passpoint
W Androidzie 12 dodano te interfejsy API:
isPasspointTermsAndConditionsSupported(): Warunki korzystania z usługi to funkcja Passpoint, która umożliwia zastąpienie niezabezpieczonych portali przechwytujących, które korzystają z sieci otwartych, bezpieczną siecią Passpoint. Gdy wymagane jest zaakceptowanie warunków korzystania z usługi, użytkownikowi wyświetla się powiadomienie. Aplikacje, które sugerują sieci Passpoint ograniczone warunkami korzystania z usługi, 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ą i należy zaproponować sieć alternatywną lub starszego typu.isDecoratedIdentitySupported(): podczas uwierzytelniania w sieciach z prefiksem dekoracji prefiks dekoracji tożsamości umożliwia operatorom sieci aktualizowanie identyfikatora dostępu do sieci (NAI) w celu wykonywania jawnego routingu przez wiele serwerów proxy w sieci AAA (więcej informacji znajdziesz w dokumencie RFC 7542).Android 12 implementuje tę funkcję, aby zapewnić zgodność 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 udekorowana, 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 Wi-Fi Alliance.
Więcej informacji znajdziesz w artykule Interfejs Wi-Fi Suggestion API do połączeń z internetem.
Zaktualizowane ograniczenia interfejsów innych niż SDK
Android 12 zawiera zaktualizowane listy ograniczonych interfejsów spoza pakietu SDK, które powstały we współpracy z programistami aplikacji na Androida i na podstawie najnowszych testów wewnętrznych. Zanim ograniczymy dostęp do interfejsów innych niż SDK, staramy się zapewnić 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 pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale użycie dowolnej metody lub pola spoza pakietu SDK zawsze wiąże się z dużym ryzykiem uszkodzenia aplikacji.
Jeśli nie masz pewności, czy Twoja aplikacja używa interfejsów innych niż SDK, możesz ją przetestować, aby to sprawdzić. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych rozwiązań SDK. Rozumiemy jednak, że niektóre aplikacje mają uzasadnione przypadki użycia interfejsów spoza pakietu SDK. Jeśli nie możesz znaleźć alternatywy dla interfejsu spoza pakietu 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 spoza pakietu SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów spoza pakietu SDK.