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. Należy przetestować aplikację, a następnie zmodyfikować ją w taki sposób, aby w odpowiednich przypadkach zapewniała prawidłowe działanie tych funkcji.
Sprawdź też listę zmian zachowania, które mają wpływ tylko na aplikacje kierowane na Androida 12.
Interfejs użytkownika
Efekt rozciągania dalekiego przewijania
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 wcześniej zaimplementowałeś niestandardowy ekran powitalny w Androidzie 11 lub niższym, musisz przenieść aplikację do interfejsu SplashScreen API, aby wyświetlała się prawidłowo od Androida 12. Nieprzeprowadzenie migracji aplikacji spowoduje pogorszenie jej działania lub niezamierzone uruchomienie.
Instrukcje znajdziesz w artykule Migracja dotychczasowej implementacji ekranu powitalnego na Androida 12.
Dodatkowo od Androida 12 system zawsze stosuje nowy domyślny ekran powitalny systemu Android w przypadku wszystkich aplikacji „na zimno” i uruchomienia „na zimno”.
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ązanie 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 Twoja aplikacja nie zostanie zatwierdzona w domenie, intencja internetowa będzie otwierana w domyślnej przeglądarce 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 aplikacjach kierowanych na Androida 12 lub nowszego system zmienia sposób automatycznej weryfikacji linków aplikacji na Androida. W filtrach intencji aplikacji sprawdź, czy uwzględniasz kategorię
BROWSABLEi obsługujesz schemathttps.Na Androidzie 12 lub nowszym możesz ręcznie zweryfikować linki aplikacji na Androida, aby sprawdzić, jak ta aktualizacja 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 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ę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 korzystanie z metody WindowMetrics i wycofujemy te metody:
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 używać interfejsów API WindowMetrics do wysyłania zapytań dotyczących granic okna oraz Configuration.densityDpi do wysyłania zapytań dotyczących 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 użycia WindowMetrics
Przede wszystkim upewnij się, że działania w aplikacji można w pełni zmienić.
Podczas wykonywania działań związanych z interfejsem użytkownika aktywność powinna opierać się na WindowMetrics z kontekstu działania, zwłaszcza w przypadku WindowManager.getCurrentWindowMetrics() czy usługi WindowMetricsCalculator.computeCurrentWindowMetrics() Jetpack.
Jeśli Twoja aplikacja tworzy MediaProjection, jej granice muszą mieć prawidłowe wymiary, ponieważ projekcja obejmuje obszar wyświetlacza, w którym 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 standardowo działa w trybie wielu okien.
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, czy aktywność:
minWidth
minHeight
może działać w trybie wielookiennym. W polu 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 do obsługi aparatu zazwyczaj zakładają stały związek między orientacją urządzenia a formatem podglądu aparatu. Jednak urządzenia z dużym ekranem, np. urządzenia składane i tryby wyświetlania, takie jak wiele okien i różnych wyświetlaczy, podważają to założenie.
Na Androidzie 12 aplikacje aparatu, które wymagają określonej orientacji ekranu i nie można ich skalować (resizeableActivity="false"), automatycznie przechodzą w tryb w orientacji pionowej, co zapewnia prawidłową orientację i proporcje podglądu aparatu. W przypadku urządzeń składanych i innych z warstwą abstrakcji obrazu z aparatu (HAL) wyjścia kamery są dodatkowo obrócone, aby skompensować orientację jej czujnika. Obraz z kamery jest przycinany tak, aby pasował do formatu obrazu w podglądzie z 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 UX w powiadomieniach usługi na pierwszym planie
Aby usprawnić 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ń usługi na pierwszym planie o 10 sekund (z kilkoma wyjątkami). Ta zmiana daje krótkim zadaniom szansę na ukończenie przed wyświetleniem powiadomień.
Wydajność
Zasobnik gotowości aplikacji z ograniczonym dostępem
Android 11 (poziom API 30) wprowadził kategorię ograniczoną jako kategorię w trybie gotowości aplikacji. Od Androida 12 ten zasób jest domyślnie aktywny. Zasobnik z ograniczeniami ma najniższy priorytet (i najwyższe ograniczenia) ze wszystkich zasobników. Grupy według priorytetu od najwyższego do najniższego:
- 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 dużo zasobów systemowych lub może zachowywać się niepoprawnie.
Aby zdecydować, czy umieścić aplikację w zasobniku z ograniczeniami, system bierze pod uwagę nie tylko wzorce użytkowania, ale też zachowanie aplikacji.
Jeśli aplikacja będzie korzystać z zasobów systemowych w sposób bardziej odpowiedzialny, prawdopodobieństwo umieszczenia aplikacji w zasobniku z ograniczeniami jest mniejsze. 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 ta metoda zwraca wartość STANDBY_BUCKET_RESTRICTED, Twoja aplikacja znajduje się w zasobniku z ograniczeniami.
Testowanie zachowania puli z ograniczeniami
Aby sprawdzić, jak zachowuje się Twoja aplikacja, gdy system umieszcza ją w zasobniku z ograniczeniami, możesz ręcznie przenieść ją do tego zasobnika. Aby to zrobić, uruchom to polecenie w oknie terminala:
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 aplikacja prosi o uprawnienia w czasie działaniaACCESS_FINE_LOCATION, należy również poprosić o uprawnieniaACCESS_COARSE_LOCATION, aby obsłużyć przypadek, gdy użytkownik przyzna aplikacji dostęp do przybliżonej lokalizacji. Oba uprawnienia należy uwzględnić w jednym zapytaniu o uprawnienia w czasie działania.
Okno uprawnień systemowych zawiera te opcje użytkownika, tak jak na ilustracji 1:
- 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
Obsługiwane urządzenia z Androidem 12 lub nowszym pozwalają użytkownikom włączać i wyłączać dostęp do aparatu i mikrofonu we wszystkich aplikacjach na urządzeniu. Wystarczy nacisnąć jeden przełącznik. Użytkownicy mają dostęp do opcji, które można przełączać, w Szybkich ustawieniach (jak pokazano na ilustracji 1) lub na ekranie prywatności w ustawieniach systemowych.
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 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.
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:
- Aplikacja używa 512-bitowych rozmiarów kluczy. Conscrypt nie obsługuje tego rozmiaru klucza. W razie potrzeby zaktualizuj logikę kryptograficzną aplikacji, aby używać 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 inicjowania 12 bajtów, co zaleca NIST.
Powiadomienia o dostępie do schowka
W Androidzie 12 i nowszych, gdy aplikacja wywołuje funkcję getPrimaryClip(), aby po raz pierwszy uzyskać dostęp do danych z innej aplikacji, użytkownik otrzymuje powiadomienie o dostępie do schowka.
Tekst w wyświetlanej wiadomości ma 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ą właściwości
isStyledText()). - Różne klasyfikacje tekstu, takie jak adresy URL, za pomocą właściwości
getConfidenceScore().
Aplikacje nie mogą zamykać okien systemowych
Aby zapewnić użytkownikom większą kontrolę podczas interakcji z aplikacjami i systemem, w Androidzie 12 wycofaliśmy działanie związane z zamiarem 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ższym, intencja nie jest wykonywana, a w Logcat pojawia 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 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. Użytkownik wchodzi w interakcję z powiadomieniem, prawdopodobnie korzystając z przycisków akcji powiadomienia, a Twoja aplikacja przetwarza usługę lub odbiornik transmisji danych 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 kierowana na Androida 12 i chce zamknąć pasek powiadomień, zamiast tego użyj działania ułatwień dostępu
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.
Zdarzenia niezaufanego dotknięcia 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. Innymi słowy, system blokuje dotknięcia przechodzące 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
„Przekazywanie” jest dozwolone w tych przypadkach:
- 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:
Całkowicie przezroczyste okna. Właściwość
alphama wartość 0,0 w ramach tego okna.wystarczająco przezroczyste okna z alertami systemowymi. System uznaje zestaw okien alertów systemowych za wystarczająco przezroczysty, gdy łączna przezroczystość jest mniejsza od maksymalnej przezroczystości systemu zasłoniętej lub równa maksymalnej przezroczystości systemu po dotknięciu. W Androidzie 12 maksymalne przezroczystość wynosi domyślnie 0, 8.
Wykrywanie zablokowania nieznanego dotyku
Jeśli system zablokuje kliknięcie dotykiem, Logcat rejestruje 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 niesprawdzone 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ć 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 działania naciśnięciem przycisku wstecz. W Androidzie 12 system przenosi aktywność i zadanie w tle, zamiast ją dokończyć. Nowy sposób działania odpowiada aktualnemu działaniu, które występuje podczas opuszczania aplikacji za pomocą przycisku lub gestu ekranu głównego.
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 po wprowadzeniu tej zmiany. Jeśli Twoja aplikacja obecnie zastępuje onBackPressed(), aby obsłużyć funkcję Wstecz i zakończyć działanie Activity, zaktualizuj implementację, aby wywołać super.onBackPressed() zamiast kończyć działanie. 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 grafika
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. Aby sprawdzić, czy przejście na nową wersję będzie płynne, możesz wcześniej zadzwonić pod numer getAlternativeRefreshRates().
Wywołanie zwrotne onDisplayChanged() jest zwykle wywoływane po wyłączeniu przełącznika częstotliwości odświeżania, ale w przypadku niektórych wyświetlaczy połączonych zewnętrznie jest wywoływane w przypadku pł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 korzystania z usługi to funkcja punktu dostępu, która umożliwia wdrożeniam sieciowym zastąpienie niezabezpieczonych portali przechwytujących, które korzystają z sieci otwartych, bezpieczną siecią Passpoint. Gdy użytkownik musi zaakceptować warunki, wyświetla się powiadomienie. Aplikacje sugerujące sieci Passpoint, które są objęte 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 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 sugerujące sieci Passpoint, które wymagają ozdobnej 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 można było 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 sekcji Interfejs API sugestii Wi-Fi na potrzeby połączeń z internetem.
Zaktualizowane ograniczenia interfejsu innego niż SDK
Android 12 zawiera zaktualizowane listy ograniczonych interfejsów spoza pakietu SDK utworzone na podstawie współpracy z deweloperami aplikacji na Androida i najnowszych testów wewnętrznych. Zawsze, gdy to możliwe, sprawdzamy, czy dostępne są publiczne alternatywy, zanim zaczniemy ograniczać interfejsy inne niż SDK.
Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą nie mieć na Ciebie natychmiastowego wpływu. 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 korzysta z interfejsów innych niż SDK, możesz to przetestować. Jeśli Twoja aplikacja korzysta z interfejsów spoza pakietu SDK, zacznij planować migrację do alternatyw dla pakietu SDK. Zdajemy sobie jednak sprawę, że w niektórych przypadkach interfejsy inne niż SDK mogą być przydatne. Jeśli nie możesz znaleźć w swojej aplikacji interfejsu innego niż interfejs SDK, musisz poprosić 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.