Platforma Androida 12 uwzględnia zmiany w działaniu, które mogą wpłynąć na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wszystkich aplikacji działających na Androidzie 12 (niezależnie od ustawień targetSdkVersion). Przetestuj aplikację, a potem w razie potrzeby zmodyfikuj ją, aby prawidłowo je obsługuje.
Zapoznaj się też z listą zmian w działaniu, które mają wpływ tylko na aplikacje kierowane na Androida 12.
Z perspektywy użytkownika
Efekt nadmiernego przewijania
Na urządzeniach z Androidem 12 lub nowszym wygląd zdarzeń nadmiernych przewijania zmienia się.
W Androidzie 11 i starszych z wykorzystaniem zdarzenia nadmiernego przewijania sprawia, że elementy wizualne zyskują poświatę, a na Androidzie 12 i nowszych elementy wizualne rozciągają się i odbijają podczas przeciągania, a potem przeskakują i odbijają się w wyniku krótkiego przewinięcia.
Więcej informacji znajdziesz w przewodniku po animowaniu gestów przewijania.
Ekrany powitalne aplikacji
Jeśli masz już wdrożony niestandardowy ekran powitalny w Androidzie 11 lub starszym, musisz przenieść swoją aplikację do interfejsu SplashScreen API, aby mieć pewność, że będzie się prawidłowo wyświetlać począwszy od Androida 12. Jeśli nie przeniesiesz swojej aplikacji, jej uruchamianie się pogorszy lub będzie niezamierzone.
Instrukcje znajdziesz w artykule Migracja obecnej implementacji ekranu powitalnego do Androida 12.
Dodatkowo, począwszy od Androida 12, w przypadku wszystkich aplikacji system zawsze stosuje nowy domyślny ekran powitalny przy uruchamianiu „na zimno” i z pamięci.
Domyślnie ten domyślny ekran powitalny jest tworzony z elementu ikony programu uruchamiającego aplikację oraz windowBackground motywu (jeśli jest on w jednym kolorze).
Więcej informacji znajdziesz w przewodniku dla programistów dotyczącym ekranów powitalnych.
Rozwiązanie intencji internetowej
Od Androida 12 (poziom interfejsu API 31) ogólna intencja internetowa skutkuje działaniem w aplikacji tylko wtedy, gdy jest zatwierdzona w konkretnej domenie zawartej w tej intencji internetowej. Jeśli Twoja aplikacja nie zostanie zatwierdzona w danej domenie, intencja internetowa zostanie otwarta w domyślnej przeglądarce użytkownika.
Aplikacje mogą uzyskać to zatwierdzenie, wykonując jedną z tych czynności:
Potwierdź własność domeny za pomocą linków 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.W Androidzie 12 i nowszych 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 aplikacja wywołuje intencje internetowe, warto dodać prompt lub okno z prośbą o potwierdzenie działania.
Ulepszenia trybu interaktywnego w nawigacji przy użyciu gestów
Android 12 łączy dotychczasowe działanie, aby ułatwić użytkownikom wykonywanie poleceń nawigacyjnych przy użyciu gestów w trybie pojemnym. Dodatkowo Android 12 umożliwia zgodność wsteczną w trybie przyklejonego elementu pełnoekranowego.
Display#getRealSize i getRealMetrics: wycofanie i ograniczenia
Urządzenia z Androidem są dostępne w wielu różnych formatach, np. dużych ekranach, tabletach czy urządzeniach składanych. Aby odpowiednio renderować treści 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 korzystanie z WindowMetrics i wycofujemy te metody:
Aby ograniczyć działanie aplikacji, które korzystają z interfejsów Display API do pobierania granic aplikacji, Android 12 ogranicza wartości zwracane przez interfejsy API w przypadku aplikacji, których nie można w pełni zmienić. Może to mieć wpływ na aplikacje, które używają tych informacji za pomocą funkcji MediaProjection.
Aplikacje powinny używać interfejsów API WindowMetrics do wysyłania zapytań dotyczących granic swojego okna i 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 nowsze wersje.
Przykłady korzystania z WindowMetrics
Przede wszystkim upewnij się, że możesz w pełni zmieniać rozmiar aktywności w aplikacji.
W przypadku każdej pracy związanej z interfejsem działanie powinno polegać na obiekcie WindowMetrics w kontekście aktywności, szczególnie w WindowManager.getCurrentWindowMetrics() lub WindowMetricsCalculator.computeCurrentWindowMetrics() Jetpack.
Jeśli aplikacja tworzy MediaProjection, progi muszą mieć odpowiedni rozmiar, ponieważ projekcja rejestruje partycję ekranu, na której działa aplikacja projektora.
Jeśli można w pełni zmienić rozmiar aplikacji, kontekst aktywności zwraca prawidłowe progi:
Kotlin
val projectionMetrics: WindowMetrics = activityContext
.getSystemService(WindowManager::class.java).maximumWindowMetrics
Java
WindowMetrics projectionMetrics = activityContext
.getSystemService(WindowManager.class).getMaximumWindowMetrics();
Jeśli aplikacji nie można w pełni zmienić rozmiaru, musi ona wysyłać zapytanie z instancji WindowContext i pobierać WindowMetrics granic aktywności za pomocą WindowManager.getMaximumWindowMetrics() lub metody Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().
Kotlin
val windowContext = context.createWindowContext(mContext.display!!,
WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
.maximumWindowMetrics
Java
Context windowContext = context.createWindowContext(mContext.getDisplay(),
WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
.getMaximumWindowMetrics();
Wszystkie aplikacje w trybie wielu okien
Android 12 umożliwia standardowe działanie trybu wielu okien.
W przypadku dużych ekranów (sw >= 600 dp) platforma obsługuje wszystkie aplikacje w trybie wielu okien niezależnie od ich konfiguracji. W przypadku zdarzeń resizeableActivity="false" aplikacja przełącza się w tryb zgodności, gdy jest to konieczne do obsługi wymiarów związanych z reklamami displayowymi.
Na małych ekranach (o parametrach < 600 dp) system sprawdza minWidth i minHeight aktywności, aby ustalić, czy może ona działać w trybie wielu okien. W przypadku wartości 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 aparatu domyślnie zakładają stały związek między orientacją urządzenia a formatem obrazu podglądu aparatu. Jednak korzystanie z dużych ekranów, np. urządzeń składanych, i trybów wyświetlania (np. trybu wielu okien i wielu wyświetlaczy) kwestionuje to założenia.
Na Androidzie 12 aplikacje aparatu, które proszą o określoną orientację ekranu i nie mają możliwości zmiany rozmiaru (resizeableActivity="false"), automatycznie wchodzą w tryb w pionie, który zapewnia prawidłową orientację i współczynnik proporcji podglądu aparatu. W przypadku urządzeń składanych i innych urządzeń wyposażonych w warstwę abstrakcji sprzętu kamery (HAL) obraz wyjściowy jest dodatkowo obracany, aby skompensować orientację czujnika kamery, a obraz z aparatu jest przycinany do formatu obrazu na podglądzie z aparatu w aplikacji. Przycinanie i dodatkowy obrót sprawiają, że podgląd z aparatu jest dobrze widoczny niezależnie od orientacji urządzenia oraz jego złożenia lub rozłożenia.
Opóźnienie UX dla powiadomień dotyczących 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ń o takiej usłudze o 10 sekund (z kilkoma wyjątkami). Dzięki tej zmianie możliwe jest wykonanie krótkotrwałych zadań, zanim pojawią się powiadomienia.
Wyniki
Zasobnik ograniczonej gotowości aplikacji z ograniczonym dostępem
W Androidzie 11 (poziom interfejsu API 30) wprowadzono ograniczony zasobnik jako zasobnik gotowości aplikacji. Od Androida 12 ten zasobnik jest domyślnie aktywny. Zasobnik z ograniczonym dostępem ma najniższy priorytet (i najwyższe ograniczenia) spośród wszystkich zasobników. Zasobniki pogrupowane według priorytetu (od największego do niskiego) to:
- Aktywna: aplikacja jest obecnie używana lub była używana niedawno.
- Zestaw roboczy: aplikacja jest regularnie używana.
- Częste: aplikacja jest często używana, ale nie codziennie.
- Rzadkie: aplikacja nie jest często używana.
- Ograniczone: aplikacja zużywa wiele zasobów systemowych lub może działać w niepożądany sposób.
Aby zdecydować, czy umieścić aplikację w zasobniku z ograniczonym dostępem, system uwzględnia jej zachowanie i wzorce wykorzystania.
Jest mniej prawdopodobne, że aplikacja zostanie umieszczona w zasobniku z ograniczonym dostępem, jeśli będzie bardziej odpowiedzialnie korzystać z zasobów systemowych. Poza tym system umieszcza aplikację w mniej restrykcyjnym zasobniku, jeśli użytkownik wchodzi z nią bezpośrednio w interakcję.
Sprawdź, czy Twoja aplikacja znajduje się w zasobniku z ograniczonym dostępem
Aby sprawdzić, czy system umieścił Twoją aplikację w zasobniku z ograniczonym dostępem, wywołaj metodę getAppStandbyBucket().
Jeśli wartość zwracana przez tę metodę to STANDBY_BUCKET_RESTRICTED, aplikacja znajduje się w zasobniku z ograniczeniami.
Testowanie działania zasobnika z ograniczeniami
Aby sprawdzić, jak zachowuje się aplikacja, gdy system umieszcza ją w zasobniku z ograniczonym dostępem, możesz przenieść ją ręcznie do tego zasobnika. Aby to zrobić, uruchom następujące 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ć, aby aplikacja miała dostęp tylko do przybliżonej lokalizacji.
Jeśli Twoja aplikacja prosi o uprawnienie środowiska wykonawczego ACCESS_FINE_LOCATION, poproś też o uprawnienie ACCESS_COARSE_LOCATION na potrzeby obsługi sytuacji, w której użytkownik przyznaje Twojej aplikacji przybliżony dostęp do lokalizacji. Obydwa uprawnienia należy uwzględnić w jednym żądaniu środowiska wykonawczego.
Okno uprawnień systemowych zawiera następujące opcje, jak widać na ilustracji 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
Na obsługiwanych urządzeniach z Androidem 12 lub nowszym użytkownicy mogą włączać i wyłączać dostęp do aparatu i mikrofonu dla wszystkich aplikacji na urządzeniu za pomocą jednego przełącznika. Użytkownicy mogą korzystać z przełączanych opcji w Szybkich ustawieniach, jak pokazano na ilustracji 1, lub z ekranu prywatności w ustawieniach systemowych.
Dowiedz się więcej o tych przełącznikach oraz o tym, jak sprawdzić, czy 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 oraz o tym, jak sprawdzić, czy 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 kierowane na Androida 11 (poziom interfejsu API 30) lub nowszego i wywołujące jedną z tych metod otrzymują przefiltrowany zestaw wyników na podstawie widoczności pakietu dla innych aplikacji:
Implementacja BouncyCastle została usunięta
Android 12 usuwa wiele implementacji algorytmów kryptograficznych BouncyCastle, które zostały wcześniej wycofane, w tym wszystkie algorytmy AES. System używa natomiast implementacji tych algorytmów Conscrypt.
Ta zmiana wpływa na Twoją aplikację, jeśli spełniony jest którykolwiek z tych warunków:
- Aplikacja używa 512-bitowych rozmiarów kluczy. Conscrypt nie obsługuje tego rozmiaru klucza. W razie potrzeby zaktualizuj logikę kryptograficzną aplikacji, tak aby używać innych rozmiarów kluczy.
Twoja aplikacja używa nieprawidłowych rozmiarów kluczy w polu
KeyGenerator. ImplementacjaKeyGeneratorw Conscrypt przeprowadza dodatkową weryfikację kluczowych parametrów w porównaniu z funkcją BouncyCastle. Na przykład Conscrypt nie zezwala aplikacji na generowanie 64-bitowego klucza AES, ponieważ AES obsługuje tylko klucze 128-, 192- i 256-bitowe.Funkcja BouncyCastle umożliwia generowanie kluczy o nieprawidłowych rozmiarach, ale później przestaje działać, jeśli te klucze są używane w obrębie
Cipher. Conscryption kończy się niepowodzeniem wcześniej.Inicjujesz mechanizmy szyfrowania Galois/Counter Mode (GCM), używając rozmiaru innego niż 12 bajtów. Implementacja
GcmParameterSpecw Conscrypt wymaga zainicjowania 12 bajtów, co jest zalecane przez NIST.
Powiadomienia o dostępie do schowka
Na Androidzie 12 i nowszych, gdy aplikacja wywoła metodę getPrimaryClip() po raz pierwszy w celu dostępu do danych klipu z innej aplikacji, użytkownik otrzyma powiadomienie o dostępie do schowka.
Tekst w komunikatorze ma taki format:
APP pasted from your clipboard.
Informacje o tekście w opisie klipu
W Androidzie 12 i nowszych getPrimaryClipDescription() może wykrywać te szczegóły:
- Stylizowany tekst w formacie
isStyledText(). - Różne klasyfikacje tekstu, np. adresów URL, za pomocą metody
getConfidenceScore().
Aplikacje nie mogą zamknąć okien systemowych
Aby zapewnić użytkownikom większą kontrolę podczas korzystania z aplikacji i systemu, w Androidzie 12 wycofaliśmy działanie intencji ACTION_CLOSE_SYSTEM_DIALOGS. Oprócz kilku szczególnych przypadków gdy aplikacja próbuje wywołać intencję zawierającą to działanie, system wykona 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
SecurityException. Jeśli Twoja aplikacja jest kierowana na Androida 11 (poziom interfejsu API 30) lub niższy, 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:
- Twoja aplikacja przeprowadza test instrumentu.
Twoja aplikacja jest kierowana na Androida 11 lub starszego i wyświetla okno nad szufladą powiadomień.
Twoja aplikacja jest kierowana na Androida 11 lub starszego. Poza tym użytkownik wszedł w interakcję z powiadomieniem, np. używając dostępnych w nim przycisków czynności, a aplikacja przetwarza w odpowiedzi na to usługę lub odbiornik.
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ń, skorzystaj z działania
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADEdotyczącego ułatwień dostępu.
Niezaufane zdarzenia dotknięcia są blokowane
Aby zapewnić bezpieczeństwo systemu i komfort użytkowników, Android 12 uniemożliwia aplikacjom wykorzystywanie zdarzeń kliknięcia, 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 ma wpływ na aplikacje, które zezwalają na dotyk przez okna, np. używając flagi FLAG_NOT_TOUCHABLE. Oto kilka przykładów:
- Nakładki, które wymagają uprawnień
SYSTEM_ALERT_WINDOW, np. okna używająceTYPE_APPLICATION_OVERLAY, i korzystające z flagiFLAG_NOT_TOUCHABLE. - Okna aktywności korzystające z flagi
FLAG_NOT_TOUCHABLE.
Wyjątki
W tych przypadkach dotknięcia metodą „przekazywania” są dozwolone:
- Interakcje z aplikacją.Aplikacja wyświetla nakładkę, która pojawia się tylko wtedy, gdy użytkownik wchodzi z nią w interakcję.
Zaufane okna. Te okna to między innymi:
Całkowicie przezroczyste okna. Właściwość
alphato 0,0 dla okna.Dostatecznie półprzezroczyste okna alertów systemu. System uznaje zestaw okien alertów systemowych za wystarczająco półprzezroczysty, gdy łączna przezroczystość jest mniejsza lub równa maksymalnej nieprzezroczystości zasłaniającej przy dotknięciach w systemie. W Androidzie 12 ta maksymalna przezroczystość domyślnie wynosi 0, 8.
Wykrywa zablokowanie niezaufanego dotknięcia
Jeśli działanie polegające na dotknięciu jest zablokowane przez system, Logcat zarejestruje ten komunikat:
Untrusted touch due to occlusion by PACKAGE_NAME
Testowanie zmiany
Niezaufane dotknięcia są domyślnie blokowane na urządzeniach z Androidem 12 lub nowszym. Aby zezwolić na niezaufane dotknięcia, uruchom w oknie terminala to polecenie ADB:
# A specific app adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps # If you'd still like to see a Logcat message warning when a touch would be # blocked, use 1 instead of 0. adb shell settings put global block_untrusted_touches 0
Aby przywrócić działanie domyślne (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 aktywności
Działania w głównym programie uruchamiającym nie są już kończone po naciśnięciu przycisku Wstecz
Android 12 zmienia domyślną obsługę systemowego naciśnięcia przycisku Wstecz. W poprzednich wersjach system kończył te działania przy użyciu naciśnięcia wstecznego. W Androidzie 12 system przenosi działanie i zadanie w tle, zamiast je zakończyć. Nowy sposób działania odpowiada obecnemu działaniu podczas opuszczenia 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ą Wróć, aby wyjść z aplikacji, będą mogli szybciej ją wznowić z stanu ciepłego, zamiast całkowicie uruchamiać ją z zimnego stanu.
Zalecamy przetestowanie aplikacji z tą zmianą. Jeśli Twoja aplikacja obecnie zastępuje parametr onBackPressed(), aby obsługiwać Wstecz, i dokończyć Activity, zaktualizuj implementację, aby wywoływała metodę super.onBackPressed() zamiast kończyć pracę. Wywołanie super.onBackPressed() w razie potrzeby przenosi aktywność i zadanie w tle oraz zapewnia bardziej spójną nawigację w różnych aplikacjach.
Pamiętaj też, że ogólnie zalecamy używanie interfejsów AndroidX Activity API do udostępniania niestandardowej nawigacji wstecz, zamiast zastępowania onBackPressed(). Jeśli nie ma żadnych komponentów przechwytujących systemowe naciśnięcia wsteczne, interfejsy AndroidX Activity API automatycznie przełączają się do właściwego działania systemu.
Grafika i obrazy
ulepszone przełączanie częstotliwości odświeżania;
W Androidzie 12 zmiany częstotliwości odświeżania z użyciem setFrameRate() mogą wystąpić niezależnie od tego, czy wyświetlacz umożliwia płynne przejście na nową częstotliwość odświeżania. Płynne przejście to brak zakłóceń wizualnych, takich jak czarny ekran przez sekundę czy dwie. Wcześniej, jeśli wyświetlacz nie obsługiwał płynnego przejścia, zazwyczaj po wywołaniu metody setFrameRate() używał tej samej częstotliwości odświeżania. Aby z wyprzedzeniem sprawdzić, czy przejście na nowe odświeżenie najprawdopodobniej przebiegnie bezproblemowo, wywołaj metodę getAlternativeRefreshRates().
Ogólnie wywołanie zwrotne onDisplayChanged() jest wywoływane po zakończeniu przełączania częstotliwości odświeżania, ale w przypadku niektórych wyświetlaczy podłączonych zewnętrznie jest wywoływane w trakcie płynnego przejścia.
Oto przykład, jak można to zastosować:
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 wdrożeniam sieci zastąpienie niezabezpieczonych portali przechwytujących, które używają otwartych sieci, bezpiecznymi sieciami Passpoint. Jeśli warunki korzystania z usługi muszą zostać zaakceptowane, użytkownik zobaczy powiadomienie. Aplikacje, które sugerują sieci Passpoint objęte warunkami korzystania z usługi, muszą najpierw wywołać ten interfejs API, aby sprawdzić, czy urządzenie obsługuje tę funkcję. Jeśli urządzenie nie obsługuje tej funkcji, nie będzie w stanie połączyć się z tą siecią i pojawi się sugerowana sieć zastępcza lub starsza wersja.isDecoratedIdentitySupported(): podczas uwierzytelniania w sieciach z ozdobnym prefiksem prefiks 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 na ten temat znajdziesz w RFC 7542).Android 12 implementuje tę funkcję zgodnie ze specyfikacją rozszerzeń WBA dla rozszerzeń PPS-MO. Aplikacje, które sugerują sieci Passpoint, które wymagają zidentyfikowanej 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 dekorowana, a uwierzytelnianie w sieci może się nie udać.
Aby można było utworzyć sugestię Passpoint, aplikacje muszą korzystać z klas PasspointConfiguration, Credential i HomeSp. Te klasy opisują profil Passpoint określony w specyfikacji Wi-Fi Alliance Passpoint.
Więcej informacji znajdziesz w artykule na temat interfejsu Wi-Fi Suger API for Internet (w języku angielskim).
Zaktualizowano ograniczenia interfejsu innego niż SDK
Android 12 zawiera zaktualizowane listy podlegających ograniczeniom interfejsów spoza pakietu SDK opracowane na podstawie współpracy z deweloperami aplikacji na Androida i najnowszych testów wewnętrznych. Zanim ograniczymy dostęp do interfejsów spoza SDK, dbamy o to, aby w miarę możliwości dostępne były publiczne alternatywy.
Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą Cię nie dotyczyć. Mimo że obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), korzystanie z dowolnych metod lub pól spoza pakietu SDK niesie ze sobą wysokie ryzyko awarii aplikacji.
Jeśli nie masz pewności, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, możesz przetestować ją, aby to sprawdzić. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych pakietów SDK. Zdajemy sobie jednak sprawę, że niektóre aplikacje mają odpowiednie przypadki użycia w zakresie interfejsów spoza SDK. Jeśli nie możesz znaleźć alternatywy dla interfejsu innego niż SDK dla funkcji w aplikacji, poproś o nowy publiczny interfejs API.
Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Aktualizacje ograniczeń interfejsu innego niż SDK na Androidzie 12. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia interfejsów innych niż SDK.