Platforma Android 12 wprowadza zmiany zachowania, które mogą mieć wpływ na Twoją aplikację. Te zmiany zachowania dotyczą wszystkich aplikacji, gdy działają na Androidzie 12, niezależnie od targetSdkVersion. Należy przetestować aplikację, a w razie potrzeby zmodyfikować ją tak, aby spełniała te wymagania.
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 zdarzenie przewijania do końca powoduje, ż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 podczas uruchamiania „na zimno” i „na ciepło” wszystkich aplikacji.
Domyślny ekran powitalny systemu jest domyślnie tworzony na podstawie elementu ikony w ekranie Launchera 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 internetowym. 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 weryfikować 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 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. Ponadto Android 12 zapewnia zachowanie zgodności wstecznej w przypadku trybu przylegającego i trybu pełnoekranowego.
Display#getRealSize i getRealMetrics: wycofanie i ograniczenia
Urządzenia z Androidem są dostępne w różnych formatach, takich jak 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 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 użycia WindowMetrics
Najpierw sprawdź, czy rozmiary aktywności w aplikacji można w pełni zmieniać.
Aktywność powinna opierać się na WindowMetrics z kontekstu aktywności w przypadku wszelkich działań związanych z interfejsem użytkownika, zwłaszcza WindowManager.getCurrentWindowMetrics() lub Jetpacka WindowMetricsCalculator.computeCurrentWindowMetrics().
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ć 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
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 resizeableActivity="false", aplikacja przechodzi w tryb zgodności, aby dostosować się do wymiarów ekranu.
Na małych ekranach (sw < 600 dp) system sprawdza, czy aktywność:
minWidth
minHeight
może działać w trybie wielookiennym. 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.
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. Na urządzeniach składanych i innych urządzeniach z urządzeniem do przetwarzania obrazu (HAL) dodatkowe obracanie jest stosowane do sygnału z aparatu, aby zrekompensować orientację czujnika aparatu, a sygnał z aparatu jest przycinany, aby dopasować go do formatu obrazu 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 krótkim zadaniom szansę na ukończenie przed wyświetleniem powiadomień.
Wydajność
Grupa aplikacji w trybie czuwania z ograniczeniami
Android 11 (poziom API 30) wprowadził kategorię ograniczoną jako kategorię w trybie w oczekywaniu. Od Androida 12 ten zasób jest domyślnie aktywny. Zbiory o ograniczonym dostępie mają najniższy priorytet (i największe ograniczenia) spośród wszystkich zbioró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 często używana, ale nie codziennie.
- Rzadko: aplikacja jest rzadko używana.
- Ograniczona: aplikacja zużywa dużo zasobów systemowych lub może zachowywać się niepożądany 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 Twoją aplikacją.
Sprawdzanie, czy aplikacja znajduje się w zasośniku z ograniczonym dostępem
Aby sprawdzić, czy system umieścił Twoją aplikację w grupie ograniczonej, zadzwoń pod numer getAppStandbyBucket().
Jeśli zwrócona 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 aplikacji 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.
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 stosuje się do sprawdzonych metod dotyczących 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 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ż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 zainicjowania 12 bajtów, zgodnie z zaleceniami 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, wyświetla się komunikat wyskakujący z informacją o tym dostępie.
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, np. adresy URL, za pomocą atrybutu
getConfidenceScore().
Aplikacje nie mogą zamykać okien systemowych
Aby zwiększyć kontrolę użytkownika podczas interakcji z aplikacją i systemem, w Androidzie 12 wycofujemy działanie 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 poniższych przypadkach aplikacja może nadal zamykać okna dialogowe systemu 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 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 używają 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 z nią w interakcję.
Zaufane okna Te okna to m.in.:
Pełna przejrzystość okien. Właściwość
alphama wartość 0,0 w tym oknie.Okna alertów systemowych są wystarczająco przezroczyste. System uznaje, że zestaw okien alertów jest wystarczająco przezroczysty, gdy łączna przezroczystość jest mniejsza lub równa maksymalnej przezroczystości dla dotyku. W Androidzie 12 domyślna maksymalna przezroczystość wynosi 0, 8.
Wykrywanie zablokowania nieznanego dotyku
Jeśli działanie dotykowe zostanie zablokowane przez system, Logcat zapisze w dzienniku 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ć domyślne działanie (blokowanie nieznanych 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 działania
Aktywności root launcher nie są już kończyć się po naciśnięciu przycisku Wstecz
Android 12 zmienia domyślne obsługiwanie naciśnięcia przycisku Wstecz w systemie w przypadku aktywności w uruchomiku, które są źródłem 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 całkowicie ją uruchamiać od stanu zimnego.
Zalecamy przetestowanie aplikacji z tą zmianą. 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 przekierowują 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, po wywołaniu funkcji setFrameRate() nadal używał 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().
Zazwyczaj 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 z zewnątrz jest wywoływane 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, które korzystają 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 połączyć się z taką siecią. W takiej sytuacji należy zaproponować alternatywną sieć lub sieć starszego typu.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 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ż interfejsy SDK na podstawie współpracy z deweloperami 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. Obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z metod lub pól spoza pakietu 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 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 interfejsów innych niż SDK.