Platforma Android 12 zawiera zmiany zachowania, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany zachowania dotyczą wszystkich aplikacji, które działają na Androidzie 12, niezależnie od targetSdkVersion. Przetestuj aplikację, a następnie w razie potrzeby zmodyfikuj ją, aby obsługiwała te funkcje.
Sprawdź też listę zmian zachowania, które mają wpływ tylko na aplikacje kierowane na Androida 12.
Interfejs użytkownika
Efekt rozciągania przy przewijaniu
Na urządzeniach z Androidem 12 lub nowszym zmienia się zachowanie wizualne zdarzeń przesunięcia ponad krawędź.
W Androidzie 11 i starszych zdarzenia przewijania do końca powodują, że elementy wizualne zaczynają się świecić. W Androidzie 12 i nowszych elementy wizualne rozciągają się i powracają po zdarzeniu przeciągania oraz przesuwają się i powracają po zdarzeniu przesuwania.
Więcej informacji znajdziesz w przewodniku po animacji gestów przewijania.
Ekrany powitalne aplikacji
Jeśli w Androidzie 11 lub starszym masz zaimplementowany niestandardowy ekran powitalny, musisz przenieść aplikację do interfejsu API SplashScreen, aby zapewnić prawidłowe wyświetlanie od wersji Androida 12. Nieprzeprowadzenie migracji aplikacji spowoduje pogorszenie jej działania lub niezamierzone uruchomienie.
Instrukcje znajdziesz w artykule Migracja obecnego ekranu powitalnego do Androida 12.
Dodatkowo od Androida 12 system zawsze stosuje nowy domyślny ekran powitalny systemu Android podczas uruchamiania „na zimno” i „na ciepło” wszystkich aplikacji.
Domyślny ekran powitalny systemu jest domyślnie tworzony na podstawie elementu ikony w aplikacji i windowBackground motywu (jeśli jest w jednym kolorze).
Więcej informacji znajdziesz w przewodniku dla programistów dotyczącym ekranów powitalnych.
Rozwiązywanie intencji w internecie
Od Androida 12 (poziom interfejsu API 31) ogólny zamiar internetowy jest przekształcany w działanie w aplikacji tylko wtedy, gdy aplikacja została zatwierdzona dla konkretnej domeny zawartej w tym zamiarze. Jeśli aplikacja nie jest zatwierdzona w przypadku domeny, intencja przeglądarki internetowej zostanie przekierowana do domyślnej przeglądarki użytkownika.
Aplikacje mogą uzyskać tę zgodę, wykonując jedną z tych czynności:
Potwierdź 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 w Twojej aplikacji. W filtrach intencji aplikacji sprawdź, czy uwzględniasz kategorię
BROWSABLEi obsługujesz schemathttps.W Androidzie 12 lub nowszym możesz ręcznie zweryfikować linki do aplikacji na Androida, aby sprawdzić, jak zaktualizowana logika wpływa na Twoją aplikację.
Poproś użytkownika o powiązanie aplikacji z domeną w ustawieniach systemu.
Jeśli Twoja aplikacja wywołuje intencje internetowe, rozważ dodanie promptu lub okna dialogowego z prośbą o potwierdzenie działania.
Ulepszenia trybu pełnoekranowego w przypadku nawigacji za pomocą gestów
Android 12 konsoliduje dotychczasowe zachowanie, aby ułatwić użytkownikom wykonywanie poleceń nawigacji za pomocą gestów w trybie pełnoekranowym. Android 12 zapewnia też zgodność wsteczną w trybie pojemnym.
Display#getRealSize i getRealMetrics: wycofanie i ograniczenia
Urządzenia z Androidem są dostępne w wielu różnych formatach, np. jako duże ekrany, tablety i urządzenia składane. Aby renderować treści w odpowiednich rozmiarach na poszczególnych urządzeniach, aplikacja musi określić rozmiar ekranu lub wyświetlacza. Z czasem Android udostępniał 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, a te metody są wycofywane:
Aby ograniczyć działanie aplikacji korzystających z interfejsów Display API do pobierania granic aplikacji, Android 12 ogranicza wartości zwracane przez interfejsy API w przypadku aplikacji, których rozmiar nie można w pełni zmieniać. Może to mieć wpływ na działanie aplikacji, które korzystają z tych informacji w ramach usługi MediaProjection.
Aplikacje powinny korzystać z interfejsów API WindowMetrics, aby pobierać informacje o granicach okna, oraz z interfejsu Configuration.densityDpi, aby pobierać informacje o bieżącej gęstości.
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 nowszego.
Przykłady korzystania z WindowMetrics
Przede wszystkim upewnij się, że działania w aplikacji można w pełni zmienić.
Aktywność powinna wykorzystywać WindowMetrics z kontekstu aktywności do wszelkich prac związanych z interfejsem użytkownika, zwłaszcza WindowManager.getCurrentWindowMetrics() lub Jetpacka WindowMetricsCalculator.computeCurrentWindowMetrics().
Jeśli aplikacja tworzy MediaProjection, granice muszą być poprawnie dopasowane, ponieważ rzutowanie przechwytuje partycję wyświetlacza, na której działa aplikacja projektora.
Jeśli aplikacja ma pełną możliwość zmiany rozmiaru, kontekst aktywności zwraca prawidłowe granice:
Kotlin
val projectionMetrics: WindowMetrics = activityContext .getSystemService(WindowManager::class.java).maximumWindowMetrics
Java
WindowMetrics projectionMetrics = activityContext .getSystemService(WindowManager.class).getMaximumWindowMetrics();
Jeśli rozmiar aplikacji nie może być zmieniany, musi ona wysłać zapytanie z poziomu instancji WindowContext i pobrać WindowMetricsgranic działania 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
Android 12 wprowadza tryb wielu okien jako standardowe zachowanie.
Na dużych ekranach (sw >= 600 dp) platforma obsługuje wszystkie aplikacje w trybie wielookiennym niezależnie od ich konfiguracji. Jeśli jest to resizeableActivity="false", aplikacja jest w razie potrzeby przełączana w tryb zgodności, aby obsługiwać wymiary displayowe.
Na małych ekranach (sw < 600 dp) system sprawdza minWidth i minHeight aktywności, aby określić, czy aktywność może zostać uruchomiona w trybie wielu okien. Jeśli resizeableActivity="false", aplikacja nie może działać w trybie wielookiennym 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 do obsługi aparatu zazwyczaj zakładają stały związek między orientacją urządzenia a formatem podglądu aparatu. Jednak duże ekrany, takie jak składane urządzenia, oraz tryby wyświetlania, takie jak tryb wielookienkowy i wielomonitorowy, podważają to założenie.
Aplikacje z aparatem na Androidzie 12, które wymagają określonej orientacji ekranu i nie można zmienić rozmiaru (resizeableActivity="false"), automatycznie włączają tryb wstawki, który zapewnia prawidłową orientację i współczynnik proporcji podglądu z aparatu. Na urządzeniach składanych i innych urządzeniach z poziomem abstrakcji sprzętowej aparatu (HAL) dodatkowe obracanie jest stosowane do sygnału wyjściowego aparatu w celu zrekompensowania orientacji czujnika aparatu, a sygnał wyjściowy aparatu jest przycinany, aby dopasować go do formatu wyjściowego podglądu aparatu w aplikacji. Przycinanie i dodatkowe obracanie zapewniają prawidłową prezentację podglądu aparatu niezależnie od orientacji urządzenia i stanu (złożonego lub rozłożonego).
Opóźnienie w UX w przypadku powiadomień usługi 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óźnić wyświetlanie powiadomień o 10 sekundach (z kilkoma wyjątkami). Ta zmiana daje szansę na wykonanie krótkotrwałych zadań, zanim wyświetlą się powiadomienia.
Wydajność
Grupa aplikacji w trybie czuwania z ograniczeniami
W Androidzie 11 (poziom interfejsu API 30) wprowadzono zasobnik z ograniczonym dostępem jako zasobnik gotowości aplikacji. Od Androida 12 ten zasobnik jest domyślnie aktywny. Zbiory o ograniczonym dostępie mają najniższy priorytet (i największe ograniczenia) spośród wszystkich zbiorów. Zasobniki w kolejności od najwyższego do najniższego to:
- Aktywna: aplikacja jest obecnie używana lub była używana bardzo 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.
- Ograniczona: aplikacja zużywa bardzo dużo zasobów systemu lub może zachowywać się w niewłaściwy sposób.
System bierze pod uwagę zachowanie aplikacji oraz wzorce użytkowania, aby zdecydować, czy umieścić aplikację w grupie ograniczonej.
Aplikacja rzadziej trafi do puli ograniczonej, jeśli korzysta z zasobów systemowych w bardziej odpowiedzialny sposób. System umieszcza też Twoją aplikację w mniej restrykcyjnej grupie, jeśli użytkownik wejdzie w interakcję bezpośrednio z nią.
Sprawdzanie, czy aplikacja znajduje się w zasobniku z ograniczeniami
Aby sprawdzić, czy system umieścił Twoją aplikację w grupie ograniczonej, zadzwoń pod numer getAppStandbyBucket().
Jeśli zwracana wartość tej metody to STANDBY_BUCKET_RESTRICTED, oznacza to, że aplikacja znajduje się w grupie ograniczonej.
Testowanie zachowania puli z ograniczeniami
Aby sprawdzić, jak aplikacja zachowuje się, gdy system umieszcza ją w grupie ograniczonej, możesz ręcznie przenieść ją do tej grupy. Aby to zrobić, uruchom w oknie terminala to polecenie:
adb shell am set-standby-bucket PACKAGE_NAME restricted
Prywatność i bezpieczeństwo
Przybliżona lokalizacja
Na urządzeniach z Androidem 12 lub nowszym użytkownicy mogą poprosić o dostęp tylko do informacji o przybliżonej lokalizacji.
Jeśli Twoja aplikacja prosi o uprawnienie środowiska wykonawczego ACCESS_FINE_LOCATION, poproś też o uprawnienia ACCESS_COARSE_LOCATION w przypadku, gdy użytkownik przyzna jej dostęp do przybliżonej lokalizacji. Obydwa te uprawnienia należy uwzględnić w jednym żądaniu środowiska wykonawczego.
Jak widać na rysunku 1, w oknie uprawnień systemowych użytkownik ma do wyboru te opcje:
- Dokładna: zapewnia dostęp do dokładnych informacji o lokalizacji.
- W przybliżeniu: zapewnia dostęp tylko do przybliżonych informacji o lokalizacji.
Przełączniki mikrofonu i aparatu
Użytkownicy obsługiwanych urządzeń z Androidem 12 lub nowszym 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 przełączania w Szybkich ustawieniach (patrz rys. 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 stosuje się do sprawdzonych metod dotyczących uprawnień CAMERA i RECORD_AUDIO.
Widoczność pakietu uprawnień
Na urządzeniach z Androidem 12 lub nowszym aplikacje, które są kierowane na Androida 11 (poziom interfejsu API 30) lub nowszego i wywołują jedną z tych metod, otrzymują odfiltrowany zestaw wyników na podstawie widoczności pakietu w innych aplikacjach:
Usunięto implementację BouncyCastle
Android 12 usuwa wiele implementacji algorytmów kryptograficznych BouncyCastle, które zostały wcześniej wycofane, w tym wszystkie algorytmy AES. Zamiast tego system używa implementacji tych algorytmów w Conscrypt.
Ta zmiana ma wpływ na Twoją aplikację, jeśli:
- Twoja aplikacja używa kluczy o długości 512 bitów. Serwer Conscrypt nie obsługuje tego rozmiaru klucza. W razie potrzeby zaktualizuj logikę kryptograficzną aplikacji, aby użyć różnych rozmiarów kluczy.
Twoja aplikacja używa nieprawidłowych rozmiarów kluczy w przypadku
KeyGenerator. ImplementacjaKeyGeneratorw Conscrypt wykonuje dodatkową weryfikację kluczowych parametrów w porównaniu z BouncyCastle. Na przykład Conscrypt nie zezwala 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 nie działa, jeśli te klucze są używane z
Cipher. Conscrypt nie działa wcześniej.Inicjujesz szyfry Galois/Counter Mode (GCM) za pomocą rozmiaru innego niż 12 bajtów. Implementacja
GcmParameterSpecw Conscrypt wymaga zainicjowania 12 bajtów, zgodnie z zaleceniami NIST.
Powiadomienia o dostępie do schowka
Na Androidzie 12 i nowszych, gdy aplikacja po raz pierwszy wywoła metodę getPrimaryClip() w celu uzyskania dostępu do danych klipu z innej aplikacji, użytkownik otrzyma powiadomienie o dostępie do schowka.
Tekst w powiadomieniu toast zawiera następujący format:
APP pasted from your clipboard.
Informacje o tekście w opisie klipu
Na Androidzie 12 i nowszych getPrimaryClipDescription() może wykryć te informacje:
- Stylizowany tekst za pomocą
isStyledText(). - Różne klasyfikacje tekstu, takie jak adresy URL, za pomocą właściwości
getConfidenceScore().
Aplikacje nie mogą zamykać okien systemowych
Aby zwiększyć kontrolę użytkownika podczas interakcji z aplikacją i systemem, od Androida 12 nie obsługujemy już działania ACTION_CLOSE_SYSTEM_DIALOGS. 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 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 niższego, intencja nie zostanie wykonana, a w Logcat pojawi się 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 wykonuje test instrumentacji.
Twoja aplikacja jest kierowana na Androida 11 lub starszego i wyświetla okno na wierzchu schowka powiadomień.
Twoja aplikacja jest kierowana na Androida 11 lub starszego. Oprócz tego użytkownik wszedł w interakcję z powiadomieniem, prawdopodobnie używając przycisków działania powiadomienia, a aplikacja przetwarza usługę lub odbiornik w odpowiedzi na to działanie.
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 chce zamknąć pasek powiadomień, użyj zamiast tego akcji dostępności
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.
Niezaufane zdarzenia dotyku są blokowane
Aby zapewnić bezpieczeństwo systemu i dobre wrażenia użytkownika, Android 12 uniemożliwia aplikacjom korzystanie z wydarzeń dotyku, gdy nakładka zasłania aplikację w niebezpieczny sposób. Inaczej mówiąc, 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 pozwalają na przepuszczanie dotyku przez okna, na przykład za pomocą flagi FLAG_NOT_TOUCHABLE. Oto kilka przykładów:
- Nakładki, które wymagają uprawnień
SYSTEM_ALERT_WINDOW, np. okna, które korzystają z flagiTYPE_APPLICATION_OVERLAYiFLAG_NOT_TOUCHABLE. - okna aktywności, które korzystają z flagi
FLAG_NOT_TOUCHABLE.
Wyjątki
W tych przypadkach dozwolone są „przepuszczane” dotknięcia:
- Interakcje w aplikacji. Aplikacja wyświetla nakładkę, która pojawia się tylko wtedy, gdy użytkownik wchodzi w interakcję z aplikacją.
Zaufane okna Okna te to między innymi:
Pełna przejrzystość okien. Właściwość
alphama wartość 0,0 w ramach tego okna.wystarczająco przezroczyste okna z alertami systemowymi. System uznaje, że zestaw okien alertów systemu jest wystarczająco przezroczysty, gdy łączna przezroczystość jest mniejsza lub równa maksymalnej przezroczystości dla dotyku. W Androidzie 12 domyślna maksymalna krycie wynosi 0, 8.
Wykrywanie zablokowania nieznanego dotyku
Jeśli działanie dotykowe zostanie zablokowane przez system, Logcat zarejestruje ten komunikat:
Untrusted touch due to occlusion by PACKAGE_NAME
Testowanie zmiany
Domyślnie niezaufane dotknięcia są blokowane na urządzeniach z Androidem 12 lub nowszym. Aby zezwolić na niezaufane dotknięcia, uruchom to polecenie ADB w oknie terminala:
# 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ć działanie do wartości domyślnych (niezaufane dotknięcia są blokowane), 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 działania
Działania z Menu z aplikacjami głównymi nie są już wykonywane po naciśnięciu Wstecz
Android 12 zmienia domyślną obsługę systemu Naciśnij Wstecz w programie uruchamiającym, które znajdują się w głównej części zadań. W poprzednich wersjach system kończył te czynności po naciśnięciu przycisku Wstecz. W Androidzie 12 system przenosi aktywność i jej zadanie do tła, zamiast kończyć aktywność. Nowe zachowanie jest takie samo jak obecne 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 zamknąć aplikację, mogą szybciej wrócić do niej z poziomu ciepłego, zamiast uruchamiać ją od nowa z poziomu zimnego.
Zalecamy przetestowanie aplikacji z tą zmianą. Jeśli Twoja aplikacja zastępuje obecnie instancję onBackPressed() w celu obsługi nawigacji wstecz i dokończenie zadania Activity, zaktualizuj implementację, aby wywoływała funkcję super.onBackPressed(), zamiast ją kończyć. Wywołanie funkcji super.onBackPressed() przenosi aktywność i jej zadanie do tła, gdy jest to odpowiednie, oraz zapewnia użytkownikom bardziej spójne wrażenia podczas nawigacji w różnych aplikacjach.
Pamiętaj też, że ogólnie zalecamy używanie interfejsów Activity API w AndroidX do zapewniania niestandardowej nawigacji wstecz zamiast zastępowania interfejsu onBackPressed(). Interfejsy API aktywności AndroidX automatycznie przekazują sterowanie do odpowiedniego zachowania systemu, jeśli nie ma żadnych 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ąpić 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 przerw w wyświetlaniu, takich jak czarny ekran na 1–2 sekundy. Wcześniej, jeśli wyświetlacz nie obsługiwał płynnego przejścia, zwykle po wywołaniu funkcji setFrameRate() z reguły korzystał z tej samej częstotliwości odświeżania. Z wyprzedzeniem możesz ustalić, czy przejście na nowe odświeżanie będzie przebiegać bezproblemowo, wywołując metodę getAlternativeRefreshRates().
Zazwyczaj funkcja wywołania zwrotnego onDisplayChanged() jest wywoływana po zakończeniu zmiany częstotliwości odświeżania, ale w przypadku niektórych wyświetlaczy podłączonych z zewnątrz jest wywoływana podczas niepłynnego przejścia.
Oto przykładowy sposób implementacji:
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 dodano te interfejsy API:
isPasspointTermsAndConditionsSupported(): Warunki to funkcja Passpoint, która umożliwia zastąpienie niepewnych portali przechwytujących, korzystających z otwartych sieci, bezpieczną siecią Passpoint. Gdy użytkownik musi zaakceptować warunki, wyświetla się powiadomienie. Aplikacje, które sugerują sieci Passpoint, które są ograniczone przez warunki 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 można się połączyć z tą siecią. W takim przypadku należy zaproponować sieć alternatywną lub starszą.isDecoratedIdentitySupported(): podczas uwierzytelniania w sieciach z ozdobą prefiksu operatorzy sieci mogą aktualizować identyfikator dostępu do sieci (NAI), aby przeprowadzić jawne kierowanie przez wiele serwerów proxy w ramach sieci AAA (więcej informacji znajdziesz w RFC 7542).Android 12 wdraża tę funkcję zgodnie ze specyfikacją WBA dotyczącą rozszerzeń PPS-MO. Aplikacje, które sugerują sieci Passpoint wymagające oznakowanej 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 udać.
Aby tworzyć sugestie dotyczące 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 API sugestii dotyczącej sieci Wi-Fi na potrzeby łączenia się z internetem.
Zaktualizowane ograniczenia interfejsu innego niż SDK
Android 12 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK na podstawie współpracy z deweloperami Androida i najnowszych testów wewnętrznych. W miarę możliwości dbamy o to, aby dostępne były publiczne alternatywy, zanim ograniczymy dostęp do interfejsów innych niż SDK.
Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą nie od razu Cię dotyczyć. Mimo że obecnie można korzystać z niektórych interfejsów innych niż SDK (w zależności od docelowego poziomu interfejsu API aplikacji), 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 przetestować ją, aby się tego dowiedzieć. Jeśli Twoja aplikacja korzysta z interfejsów spoza pakietu SDK, zaplanuj migrację do alternatywnych pakietów SDK. Zdajemy sobie jednak sprawę, że w niektórych przypadkach interfejsy inne niż SDK mogą być przydatne. Jeśli nie możesz znaleźć alternatywy dla interfejsu spoza pakietu SDK, który jest używany w funkcji Twojej aplikacji, poproś o nowy publiczny interfejs API.
Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Zmiany ograniczeń interfejsu niebędącego interfejsem SDK w Androidzie 12. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK.