Platforma Android 12 obejmuje zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu mają zastosowanie do wszystkich aplikacji działających na Androidzie 12 niezależnie od wersji targetSdkVersion. Przetestuj aplikację, a następnie w razie potrzeby zmodyfikuj ją, aby obsługiwała te funkcje.
Zapoznaj się też z listą zmian w działaniu, które wpływają tylko na aplikacje kierowane na Androida 12.
Z perspektywy użytkownika
Efekt rozciągania dalekiego przewijania
Na urządzeniach z Androidem 12 lub nowszym zmienia się sposób wyświetlania zdarzeń przewijania ponad ekranem.
W Androidzie 11 i starszych wersjach zdarzenie przesuwania palcem po ekranie sprawia, że elementy wizualne są blasku. Na Androidzie 12 i nowszych są one rozciągane i odbijane po wystąpieniu przeciągania, a po nim odbijają się i wracają do siebie.
Więcej informacji znajdziesz w przewodniku po animowaniu 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. Jeśli nie przeniesiesz aplikacji, jej uruchomienie może się pogorszyć lub w niezamierzony sposób.
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 w przypadku wszystkich aplikacji „na zimno” i uruchomienia „na zimno”.
Domyślnie ten systemowy ekran powitalny jest utworzony z elementu ikony Menu z aplikacjami i elementu 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ólna intencja internetowa przestaje być widoczna w działaniu w aplikacji tylko wtedy, gdy zostanie ona zatwierdzona dla określonej domeny zawartej w tej intencji. 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ź własność domeny przy użyciu 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. Sprawdź, czy w filtrach intencji aplikacji 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 Twojej 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 pojemnego dotyczącego nawigacji przy użyciu gestów
Android 12 scala dotychczasowe zachowania, aby ułatwić użytkownikom wykonywanie poleceń nawigacyjnych przy użyciu gestów w trybie pojemnym. 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 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 metody 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 te interfejsy API w przypadku aplikacji, których rozmiar nie można w pełni zmienić. Może to mieć wpływ na aplikacje, które używają tych informacji w MediaProjection.
Aplikacje powinny używać interfejsów API WindowMetrics do wysyłania zapytań dotyczących granic okna oraz Configuration.densityDpi do wysyłania zapytań dotyczących bieżącej gęstości.
Aby uzyskać szerszą zgodność ze starszymi wersjami Androida, możesz użyć biblioteki Jetpacka WindowManager, która zawiera klasę WindowMetrics obsługującą Androida 4.0 (poziom interfejsu API 14) i nowsze.
Przykłady korzystania z 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, granice muszą być poprawnie dopasowane, ponieważ rzutowanie przechwytuje partycję wyświetlacza, na której działa aplikacja projektora.
Jeśli aplikację można w pełni zmienić rozmiar, 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 aplikacji nie można w pełni zmienić rozmiaru, musi ona wykonać zapytanie z instancji WindowContext i pobrać WindowMetrics granic aktywności za pomocą WindowManager.getMaximumWindowMetrics() lub metody Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().
Kotlin
val windowContext = context.createWindowContext(mContext.display!!,
WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
.maximumWindowMetrics
Java
Context windowContext = context.createWindowContext(mContext.getDisplay(),
WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
.getMaximumWindowMetrics();
Wszystkie aplikacje w trybie wielu okien
Android 12 standardowo działa w trybie wielu okien.
Na dużych ekranach (sw >= 600 dp) platforma obsługuje wszystkie aplikacje w trybie wielu okien 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 wyświetlacza.
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. 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 aparatu na dużych ekranach
Aplikacje aparatu zwykle zakładają stały związek między orientacją urządzenia a formatem obrazu na podglądzie z aparatu. Jednak urządzenia z dużym ekranem, np. urządzenia składane oraz tryby wyświetlania, takie jak wiele okien i różnych wyświetlaczy, 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. W przypadku urządzeń składanych i innych z warstwą abstrakcji obrazu z aparatu (HAL) generowany jest dodatkowy obrót obrazu wyjściowego kamery, który kompensuje orientację czujnika. Obraz z kamery jest przycinany zgodnie ze formatem obrazu podglądu w aparacie w aplikacji. Przycinanie i dodatkowy obrót zapewniają prawidłowe wyświetlanie podglądu z aparatu niezależnie od orientacji urządzenia oraz po złożeniu lub rozłożeniu.
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 szansę na wykonanie krótkotrwałych zadań, zanim pojawią się powiadomienia.
Wydajność
Zasobnik gotowości aplikacji z ograniczonym dostępem
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. Zasobnik z ograniczeniami ma najniższy priorytet (i najwyższe ograniczenia) ze wszystkich zasobników. Dostępne są te zbiory danych w kolejności od najwyższego do najniższego:
- Aktywna: aplikacja jest obecnie lub była używana niedawno.
- Zestaw roboczy: aplikacja jest regularnie używana.
- Częste: aplikacja jest często używana, 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.
Aby zdecydować, czy umieścić aplikację w zasobniku z ograniczeniami, system bierze pod uwagę nie tylko wzorce użycia, 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. Poza tym system umieszcza Twoją aplikację w mniej restrykcyjnym zasobniku, jeśli użytkownik wchodzi w bezpośrednią interakcję z aplikacją.
Sprawdzanie, czy aplikacja znajduje się w zasobniku z ograniczeniami
Aby sprawdzić, czy system umieścił Twoją aplikację w zasobniku z ograniczeniami, wywołaj getAppStandbyBucket().
Jeśli ta metoda zwraca wartość STANDBY_BUCKET_RESTRICTED, Twoja aplikacja znajduje się w zasobniku z ograniczeniami.
Testowanie działania zasobnika 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 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.
Okno uprawnień systemowych zawiera te opcje użytkownika, tak jak na ilustracji 1:
- Dokładna: umożliwia dostęp do informacji o dokładnej lokalizacji.
- Przybliżona: umożliwia dostęp tylko do informacji o przybliżonej 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 widać 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 korzysta z mikrofonu lub aparatu, na pasku stanu pojawia się ikona.
Dowiedz się więcej o tych wskaźnikach i o tym, jak sprawdzić, czy Twoja aplikacja jest zgodna ze sprawdzonymi metodami dotyczącymi uprawnień CAMERA i RECORD_AUDIO.
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 poniższych metod otrzymują przefiltrowany zestaw wyników na podstawie widoczności pakietów w innych aplikacjach:
Implementacja BouncyCastle została usunięta
Android 12 usuwa wiele wycofanych wcześniej implementacji algorytmów kryptograficznych BouncyCastle, w tym wszystkie algorytmy AES. System używa natomiast implementacji tych algorytmów Conscrypt.
Ta zmiana ma wpływ na Twoją aplikację, jeśli spełniony jest dowolny 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, aby użyć różnych rozmiarów kluczy.
Twoja aplikacja używa nieprawidłowych rozmiarów kluczy w polu
KeyGenerator. ImplementacjaKeyGeneratorw Conscryptu przeprowadza dodatkową weryfikację parametrów kluczowych 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 kończy się to niepowodzeniem, jeśli są one używane z
Cipher. Protokół Conscrypt kończy się niepowodzeniem.Inicjujesz mechanizmy szyfrowania Galois/licznika (GCM) o rozmiarze nieprzekraczającym 12 bajtów. Implementacja
GcmParameterSpecw Conscrypt wymaga inicjowania 12 bajtów, co zaleca 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 wyświetlanej wiadomości ma następujący format:
APP pasted from your clipboard.
Informacje o tekście w opisie klipu
W 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 wyjątkowych przypadków, gdy aplikacja próbuje wywołać intencję obejmującą to działanie, na podstawie jej docelowej wersji pakietu SDK system wykonuje jedną z tych czynności:
- Jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego, występuje 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 przeprowadza test instrumentacji.
Aplikacja jest kierowana na Androida 11 lub starszego i wyświetla okno u góry szuflady powiadomień.
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 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 wygodę użytkowników, Android 12 uniemożliwia aplikacjom korzystanie z zdarzeń dotknięcia, 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 ma wpływ na aplikacje, które pozwalają na przechodzenie dotykiem przez okna, na przykład za pomocą flagi FLAG_NOT_TOUCHABLE. Oto kilka przykładów:
- Nakładki, które wymagają uprawnienia
SYSTEM_ALERT_WINDOW, takie jak okna korzystające zTYPE_APPLICATION_OVERLAYi flagiFLAG_NOT_TOUCHABLE. - Okna aktywności używające 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ść
alphato 0,0 dla 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 niezaufanego dotknięcia
Jeśli system zablokuje kliknięcie dotykiem, Logcat rejestruje 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 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 aktywności
Działania z programu uruchamiającego roota 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 korzystają z funkcji Wstecz, aby wyjść z aplikacji, będą mogli szybciej wznowić ją z stanu gotowości do działania bez konieczności całkowitego ponownego uruchamiania aplikacji (stan „na zimno”).
Zalecamy przetestowanie aplikacji po wprowadzeniu tej zmiany. 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 super.onBackPressed() przenosi aktywność i jej zadanie w tle w razie potrzeby i zapewnia użytkownikom bardziej spójną nawigację w różnych aplikacjach.
Pamiętaj też, że do udostępniania niestandardowej nawigacji wstecz zalecamy używanie interfejsów AndroidX Activity API. Zamiast zastępować onBackPressed(). Interfejsy API działań AndroidaX automatycznie przyjmują odpowiednie działanie systemu, jeśli nie ma żadnych komponentów przechwytujących system naciśnięcia Wstecz.
Grafika i grafika
Ulepszone przełączanie częstotliwości odświeżania
W Androidzie 12 zmiany częstotliwości odświeżania wykorzystujące 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 takie, w którym nie występują żadne zakłócenia wizualne, takie jak czarny ekran przez sekundę lub dwie. Wcześniej, jeśli wyświetlacz nie obsługiwał płynnego przejścia, zwykle po wywołaniu funkcji setFrameRate() używał 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().
Wywołanie zwrotne onDisplayChanged() zwykle jest wywoływane po zakończeniu działania 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ład, jak możesz 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 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 wymagane jest zaakceptowanie warunków korzystania z usługi, użytkownikowi 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 mogło połączyć się z tą siecią. W takiej sytuacji trzeba też zaproponować sieć alternatywną lub starszą.isDecoratedIdentitySupported(): Podczas uwierzytelniania w sieciach z dodanym przedrostkiem ozdobiony prefiks tożsamości umożliwia operatorom sieci aktualizowanie identyfikatora dostępu do sieci (NAI) w celu bezpośredniego routingu przez wiele serwerów proxy w sieci AAA (więcej informacji na ten temat znajdziesz w RFC 7542).Android 12 wdraża tę funkcję, aby zapewnić zgodność ze specyfikacją WBA 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 powieść.
Aby można było utworzyć sugestię Passpoint, aplikacje muszą używać klas PasspointConfiguration, Credential i HomeSp. Te klasy opisują profil Passpoint zdefiniowany w specyfikacji Wi-Fi Alliance Passpoint.
Więcej informacji znajdziesz w sekcji Interfejs API sugestii Wi-Fi na potrzeby połączeń z internetem.
Zaktualizowano ograniczenia interfejsu spoza 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. 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 korzysta z interfejsów innych niż SDK, możesz to przetestować. Jeśli Twoja aplikacja wymaga interfejsów innych niż SDK, zacznij planować migrację na alternatywne wersje pakietów SDK. Zdajemy sobie jednak sprawę, że niektóre aplikacje mogą prawidłowo korzystać z interfejsów innych niż SDK. 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 wprowadzonych w tej wersji Androida znajdziesz w artykule Aktualizacje ograniczeń interfejsu innego niż SDK w Androidzie 12. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK.