Zmiany w działaniu: wszystkie aplikacje

Platforma Android 12 obejmuje zmiany w działaniu, które mogą na Twoją aplikację. Poniższe zmiany w działaniu mają zastosowanie do wszystkich aplikacji, jeśli musi działać na Androidzie 12 (niezależnie od systemu targetSdkVersion). Zalecenia przetestować aplikację i w razie potrzeby zmodyfikować ją pod kątem zgodności z tymi zasadami. mają zastosowanie.

Przejrzyj też listę zmian w działaniu, które wpływają tylko na aplikacje kierowanych na Androida 12.

Interfejs użytkownika

Efekt rozciągania dalekiego przewijania

Na urządzeniach z Androidem 12 lub nowszym podczas przewijania przewinięcie zdarzeń.

Na Androidzie 11 i starszych wersjach zdarzenie przewijania powoduje, że elementy wizualne poświata; na Androidzie 12 i nowszych, elementy wizualne się rozciągają i odbijają lub przeciągania, a potem odbijają się na łóżku.

Więcej informacji znajdziesz w przewodniku po animowaniu przewijania gestów.

Ekrany powitalne aplikacji

Jeśli w Androidzie 11 został już zaimplementowany niestandardowy ekran powitalny lub niższych wartości, musisz przenieść aplikację do interfejsu API SplashScreen, aby mieć pewność, i wyświetla się prawidłowo od Androida 12. Brak migracji aplikacji spowoduje podczas uruchamiania aplikacji w pogorszonym lub niezamierzonym momencie.

Instrukcje znajdziesz w artykule Migracja istniejącego ekranu powitalnego aplikacji na Androida 12.

Dodatkowo od Androida 12 system zawsze stosuje nowy Android domyślny ekran powitalny systemu włączony „zimno” uruchomienia częściowo dla wszystkich aplikacji. Domyślnie ten systemowy domyślny ekran powitalny tworzy ikona programu uruchamiającego windowBackground z motyw (jeśli jest to jeden kolor).

Więcej informacji znajdziesz w przewodniku dla programistów dotyczącym ekranów powitalnych.

Rozwiązanie intencji w internecie

Począwszy od Androida 12 (poziom interfejsu API 31) ogólna intencja internetowa przestaje być aktywność w aplikacji tylko wtedy, gdy została ona zatwierdzona w określonej domenie zawartą w tej intencji internetowej. Jeśli Twoja aplikacja nie zostanie zatwierdzona w domenie, intencja internetowa jest kierowana do domyślnej przeglądarki użytkownika.

Aplikacje mogą uzyskać tę zgodę, wykonując jedną z tych czynności:

Jeśli Twoja aplikacja wywołuje intencje internetowe, rozważ dodanie promptu lub okna użytkownik musi potwierdzić działanie.

Ulepszenia trybu pojemnego dotyczącego nawigacji przy użyciu gestów

Android 12 konsoliduje dotychczasowe zachowania, aby ułatwić użytkownikom wykonuj polecenia nawigacyjne przy użyciu gestów w trybie pełnoekranowym . W Android 12 zapewnia zgodność wsteczną w przypadku aplikacji przyklejonych wciągający .

Display#getRealSize i getRealMetrics: wycofanie i ograniczenia

Urządzenia z Androidem są dostępne w wielu różnych formatach, np. w dużym rozmiarze na ekranach, tabletach i urządzeniach składanych. Aby odpowiednio renderować treści w przypadku każdego na urządzeniu, aplikacja musi określić rozmiar ekranu lub wyświetlacza. Z czasem Android udostępnia różne interfejsy API do pobierania tych informacji. Na Androidzie 11, wprowadziliśmy WindowMetrics API i wycofaliśmy te metody:

W Androidzie 12 nadal zalecamy korzystanie z WindowMetrics. wycofanie tych metod:

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 rozmiar nie jest w pełni możliwy. Może to mieć wpływ na aplikacje, które używają tych informacji w usłudze MediaProjection.

Aplikacje powinny używać interfejsów API WindowMetrics do wysyłania zapytań dotyczących granic jego okno i Configuration.densityDpi , aby wysłać zapytanie o obecną gęstość.

Aby zapewnić większą zgodność ze starszymi wersjami Androida, możesz użyć parametru biblioteki Jetpack WindowManager, która obejmuje zajęcia WindowMetrics który obsługuje Androida 4.0 (poziom interfejsu API 14) lub nowszego.

Przykłady korzystania z WindowMetrics

Przede wszystkim upewnij się, że działania w aplikacji można w pełni zmienić.

Aktywność powinna wykorzystywać atrybut WindowMetrics z kontekstu działania w przypadku dowolnego prac związanych z interfejsem użytkownika, WindowManager.getCurrentWindowMetrics(). czy jetpack WindowMetricsCalculator.computeCurrentWindowMetrics()

Jeśli aplikacja tworzy MediaProjection, progi muszą mieć odpowiedni rozmiar ponieważ rzutowanie rejestruje partycję wyświetlacza, w której aplikacja jest uruchomiony.

Jeśli można w pełni zmienić rozmiar aplikacji, kontekst aktywności zwraca prawidłowe granice. np.:

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ć, musi ona wysyłać zapytania z WindowContext i pobierz WindowMetrics granic aktywności za pomocą WindowManager.getMaximumWindowMetrics(). albo 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 konfiguracji aplikacji. Jeśli resizeableActivity="false" gdy jest to niezbędne do obsługi wyświetlacza, aplikacja jest przełączana w tryb zgodności. wymiarów.

Na małych ekranach (sW < 600 dp) system sprawdza minWidth oraz minHeight aby określić, czy aktywność może działać w trybie wielu okien. Jeśli resizeableActivity="false" aplikacja nie może działać w trybie wielu okien niezależnie od wartości 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łą zależność między orientacją od urządzenia i formatu obrazu podglądu z aparatu. Na dużym ekranie np. urządzenia składane czy tryby wyświetlania, pod kątem wyświetlania na wielu ekranach, kwestionuj to założenie.

na Androidzie 12: aplikacje aparatu, które żądają określonego ekranu. orientacji i nie można automatycznie zmienić rozmiaru (resizeableActivity="false") włącz tryb wcięcia obrazu proporcje obrazu w podglądzie z aparatu. Na urządzeniach składanych i innych urządzeniach z aparatem warstwa abstrakcji sprzętowej (HAL), dodatkowy obrót jest stosowany do wyjścia kamery, aby kompensować ruch ma orientację czujnika, a obraz wyjściowy z aparatu jest przycięty do formatu obrazu podglądu aparatu w aplikacji. Dzięki przycinaniu i dodatkowym obróceniu prezentacji podglądu z aparatu niezależnie od orientacji urządzenia i złożonego. lub rozłożony.

Opóźnienie UX w powiadomieniach usługi na pierwszym planie

Zapewnienie sprawnej obsługi dla krótkoterminowych kampanii na pierwszym planie usług, na urządzeniach z obsługą Android 12 lub nowszy może opóźniać wyświetlanie usługi na pierwszym planie powiadomienia o 10 sekund, kilka minut . Ten daje możliwość wykonania krótkotrwałych zadań przed otrzymaniem powiadomień .

Wydajność

Zasobnik gotowości aplikacji z ograniczonym dostępem

W Androidzie 11 (poziom interfejsu API 30) wprowadzono ograniczone Zasobnik w trybie gotowości aplikacji Zasobnik. Od Androida 12 ten zasobnik jest domyślnie aktywny. Zasobnik z ograniczeniami ma najniższy priorytet (i najwyższe ograniczenia) do wszystkich zasobników. Dostępne są te zbiory danych w kolejności od najwyższego do najniższego:

  1. Aktywna: aplikacja jest obecnie lub była używana niedawno.
  2. Zestaw roboczy: aplikacja jest regularnie używana.
  3. Częste: aplikacja jest często używana, ale nie codziennie.
  4. Rzadko: aplikacja nie jest często używana.
  5. Ograniczona: aplikacja zużywa duże ilości zasobów systemu lub może niepożądane zachowanie.

System analizuje zachowanie aplikacji, nie tylko wzorce używania, zdecydować, czy umieścić aplikację w zasobniku z ograniczeniami.

Jest mniej prawdopodobne, że Twoja aplikacja zostanie umieszczona w zasobniku z ograniczonym dostępem, jeśli aplikacja używa bardziej odpowiedzialnie. System umieszcza aplikację w krótszym czasie zasobnik z ograniczeniem, jeśli użytkownik wchodzi w bezpośrednią interakcję z Twoją 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 zwracana przez tę metodę wartość to STANDBY_BUCKET_RESTRICTED, aplikacja jest w zasobniku z ograniczeniami.

Testowanie działania zasobnika z ograniczeniami

Aby przetestować zachowanie aplikacji, gdy system umieszcza ją w tagu z ograniczonym dostępem możesz ręcznie przenieść aplikację 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

Okno zawiera 2 zestawy opcji, jeden nad inny
Rysunek 1. Okno uprawnień systemowych, które umożliwia użytkownikowi aby przyznać informacje o przybliżonej lokalizacji.

Na urządzeniach z Androidem 12 lub nowszym użytkownicy mogą poprosić o udostępnienie aplikacji dostęp tylko do przybliżonej lokalizacji i informacjami o nich.

Jeśli Twoja aplikacja prosi o zgodę na ACCESS_FINE_LOCATION uprawnienia w czasie działania, musisz też poprosić o zgodę na ACCESS_COARSE_LOCATION uprawnienia do obsługi przypadku, w których użytkownik przyznał dostęp do przybliżonej lokalizacji do Twojej aplikacji. Oba uprawnienia należy uwzględnić w jednym środowisku wykonawczym .

Okno uprawnień systemowych zawiera następujące opcje związane z użytkownikiem: zgodnie z ilustracją 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 umożliwiają użytkownikom: włączać i wyłączać dostęp do kamery i mikrofonu wszystkim aplikacjom na urządzeniu przez naciskając opcję przełączania. Użytkownicy mają dostęp do opcji przełączania w Szybkie ustawienia, jak pokazano na ekranie ilustrację 1 lub na Ekranie prywatności w ustawieniach systemu.

Dowiedz się więcej na ten temat przełączniki i jak sprawdzić, że aplikacja jest zgodna ze sprawdzonymi metodami dotyczącymi: CAMERA i RECORD_AUDIO. uprawnień.

Wskaźniki mikrofonu i aparatu

na urządzeniach z Androidem 12 lub nowszym, gdy aplikacja uzyskuje dostęp do: mikrofonu lub kamery, na pasku stanu pojawi się ikona.

Dowiedz się więcej na ten temat wskaźniki i instrukcje sprawdź, czy aplikacja jest zgodna ze sprawdzonymi metodami dotyczącymi CAMERA i RECORD_AUDIO. uprawnień.

Kafelki Szybkich ustawień mają etykietę „Dostęp do aparatu” oraz „Dostęp do mikrofonu”
Rysunek 2. Przełącznik mikrofonu i aparatu Szybkie ustawienia.
zaokrąglonego prostokąta w prawym górnym rogu, zawiera ikonę kamery i mikrofonu
Rysunek 3. wskaźniki mikrofonu i aparatu, które pokazują niedawny dostęp do danych.

Widoczność pakietu uprawnień

Na urządzeniach z Androidem 12 lub nowszym aplikacje kierowane Androida 11 (poziom interfejsu API 30) lub nowszego, który wywołuje jedną z podanych niżej metod. otrzymują przefiltrowany zestaw wyników na podstawie pakietu aplikacji, widoczność innych aplikacji:

Implementacja BouncyCastle została usunięta

Android 12 usuwa wiele Implementacje funkcji BouncyCastle algorytmy kryptograficzne, które zostały wcześniej wycofane, w tym wszystkie szyfrowanie AES. za pomocą algorytmów. System używa zamiast tego makra Implementacje Conscrypt dla tych algorytmów.

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. Implementacja funkcji Conscrypt KeyGenerator ma dodatkowe wyniki weryfikacji kluczowych parametrów w porównaniu z narzędziem BouncyCastle. Na przykład Conscrypt nie zezwala aplikacji na generowanie 64-bitowego klucza AES, ponieważ AES obsługuje tylko 128-, 192- i 256-bitowe klucze.

    BouncyCastle umożliwia generowanie kluczy o nieprawidłowych rozmiarach, ale później kończy się to niepowodzeniem jeśli te klucze są używane z Cipher. Protokół Conscrypt kończy się niepowodzeniem.

  • Inicjujesz mechanizmy szyfrowania w trybie Galois/Licznik (GCM), używając parametru o innym rozmiarze ponad 12 bajtów. Implementacja funkcji Conscrypt GcmParameterSpec wymaga: zainicjowanie 12 bajtów (zalecane przez NIST).

Powiadomienia o dostępie do schowka

Na urządzeniach z Androidem 12 i nowszym, gdy aplikacja dzwoni getPrimaryClip() aby uzyskać dostęp do danych klipu z innego po raz pierwszy, wyświetli się Toast. powiadamia użytkownika o dostępie do tego schowka.

Tekst w wysłanej 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 szczegóły:

Aplikacje nie mogą zamykać okien systemowych

Aby zapewnić użytkownikom większą kontrolę podczas interakcji z aplikacjami i systemem, ACTION_CLOSE_SYSTEM_DIALOGS Działanie intencji jest wycofane w Androidzie 12. Oprócz kilku w szczególnych przypadkach, gdy aplikacja próbuje wywołać intencję, która zawiera to działanie, Na podstawie docelowej wersji pakietu SDK system wykonuje jedną z tych czynności:

  • Jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego, SecurityException ma miejsce.

  • Jeśli Twoja aplikacja jest kierowana na Androida 11 (poziom interfejsu API 30) lub niższym, intencja nie i następujący komunikat pojawi się w Logcat:

    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 Android 12 lub nowszy:

  • Aplikacja uruchamia instrukcję test.

  • Aplikacja jest kierowana na Androida 11 lub starszego i wyświetla się w oknie który jest widoczny nad powiadomieniem szuflada.

  • Aplikacja jest kierowana na Androida 11 lub starszego. Dodatkowo użytkownik ma Użytkownik mógł wejść w interakcję z powiadomieniem, prawdopodobnie przy użyciu działania powiadomienia , a aplikacja będzie przetwarzanie usługi lub transmisji, w odpowiedzi na dane 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ń, GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE ułatwienia dostępu.

Zdarzenia niezaufanego dotknięcia są blokowane

Aby zapewnić bezpieczeństwo systemu i wygodę użytkowników, Android 12 zapobiega używaniu dotyku przez aplikacje zdarzeń, gdy nakładka zasłania aplikację w niebezpieczny sposób. Innymi słowy, 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 umożliwiają klikanie na przykład za pomocą FLAG_NOT_TOUCHABLE flaga. Oto kilka przykładów:

  • Nakładki, które wymagają atrybutu SYSTEM_ALERT_WINDOW uprawnienia, takie jak okna, na których jest używany TYPE_APPLICATION_OVERLAY, i użyć flagi FLAG_NOT_TOUCHABLE.
  • Okna aktywności używające flagi FLAG_NOT_TOUCHABLE.

Wyjątki

W następujących przypadkach ustawienie „przejściowe” dotykanie są dozwolone:

  • Interakcje w aplikacji. Aplikacja wyświetla nakładkę i nakładkę. pojawia się tylko wtedy, gdy użytkownik wchodzi w interakcję z aplikacją.

  • Zaufane okna. Okna te to m.in.: :

    .

  • Niewidoczne okna. Główny widok okna to GONE lub INVISIBLE

  • Całkowicie przezroczyste okna. Usługa alpha wynosi 0,0 dla okna.

  • wystarczająco przezroczyste okna z alertami systemowymi. System uznaje zbiór okna z alertami systemowymi, aby były wystarczająco półprzezroczyste, gdy łączna przezroczystość jest mniejsza od maksymalnej przezroczystości systemu zaciemniającego dotknięcia lub jest równa maksymalnej przezroczystości systemu. W Androidzie 12 maksymalne przezroczystość wynosi domyślnie 0, 8.

Wykrywanie zablokowania niezaufanego dotknięcia

Jeśli dotknięcie zostanie zablokowane przez system, Logcat rejestruje ten komunikat:

Untrusted touch due to occlusion by PACKAGE_NAME

Testowanie zmiany

Niezaufane dotknięcia są domyślnie blokowane na uruchomionych urządzeniach Androida 12 lub nowszego, Aby zezwolić na niezaufane punkty kontaktu, uruchom polecenie 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 polecenie 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 i czynności stanowiących podstawę ich działań. W poprzednich wersjach system może wykonać tę czynność naciśnięciem przycisku wstecz. W Androidzie 12 system przenoszę do tła aktywność i jej zadanie, a nie ją dokończyć. Nowe zachowanie odpowiada obecnemu działaniu 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ą Wstecz, aby przejść mogą szybciej wznowić aplikację ze stanu gotowości, zamiast ponownego uruchamiania aplikacji stan zimny.

Zalecamy przetestowanie aplikacji po wprowadzeniu tej zmiany. Jeśli Twoja aplikacja obecnie zastępuje onBackPressed() do obsługi Wróć do nawigacji i dokończ Activity, zaktualizuj implementację, by ją wywołać do super.onBackPressed(), zamiast zakończyć. Łączę Aplikacja super.onBackPressed() przenosi aktywność i powiązane z nią zadanie w tle, gdy odpowiednie i pozwala użytkownikom na bardziej spójną nawigację w różnych aplikacjach.

Pamiętaj też, że ogólnie zalecamy używanie interfejsów AndroidX Activity API do udostępnianie spersonalizowanej nawigacji wstecz, zamiast zastępowania onBackPressed(). Interfejsy API związane z aktywnością w AndroidX automatycznie skup się na odpowiednim zachowaniu systemu, jeśli komponenty przechwytujące system. Naciśnij Wstecz.

Grafika i grafika

Ulepszone przełączanie częstotliwości odświeżania

W Androidzie 12 częstotliwość odświeżania zmienia się za pomocą wartości setFrameRate() może wystąpić niezależnie od tego, czy wyświetlacz umożliwia płynne przejście nową częstotliwość odświeżania, płynne przejście to takie, które nie zawiera żadnych elementów wizualnych, zakłócenia, np. czarny ekran przez sekundę lub dwie. Wcześniej, jeśli nie umożliwiał płynnego przejścia, przeważnie byłby tę samą częstotliwość odświeżania po wywołaniu funkcji setFrameRate(). Możesz określić w czy przejście na nowe odświeżanie będzie prawdopodobnie płynne, Wywołuję: getAlternativeRefreshRates(). Zwykle wywołanie zwrotne onDisplayChanged() jest wywoływana po zakończeniu zmiany częstotliwości odświeżania, ale dla niektórych zewnętrznych wyświetlaczy, jest ona wywoływana podczas 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);

Łączność

Aktualizacje Passpoint

W Androidzie 12 dodano te interfejsy API:

  • isPasspointTermsAndConditionsSupported(): Warunki korzystania z usługi to Passpoint funkcja pozwalająca wdrożeniam sieciowym zastępować niezabezpieczone portale przechwytujące, które korzystają z sieci otwartych i bezpiecznej sieci Passpoint. Powiadomienie to wyświetlane użytkownikowi, gdy trzeba zaakceptować warunki korzystania z usługi. Aplikacje sugerujące sieci Passpoint podlegające zasadom korzystania z usługi musi 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ę sieć oraz musisz zasugerować alternatywną lub starszą sieć.

  • isDecoratedIdentitySupported(): Podczas uwierzytelniania w sieciach z dekoracją prefiksu prefiks tożsamości umożliwia operatorom sieci aktualizowanie dostępu do sieci Identyfikator (NAI) do jednoznacznego routingu przez wiele serwerów proxy w środku sieci AAA (patrz RFC 7542 dla więcej na ten temat).

    Android 12 wdraża tę funkcję, aby zapewnić zgodność ze specyfikacją WBA dla PPS-MO . Aplikacje sugerujące sieci Passpoint, które wymagają ozdobionej tożsamości, muszą najpierw wywołaj 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 może też nie udać się uwierzytelnianie w sieci.

Aby utworzyć sugestię Passpoint, aplikacje muszą używać protokołu PasspointConfiguration Credential i HomeSp zajęć. Te klasyfikują profil Passpoint, który jest zdefiniowany w Wi-Fi Alliance Protokół Passpoint specyfikacji.

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 list aplikacji spoza pakietu SDK oparte na współpracy z deweloperami aplikacji na Androida oraz do testów wewnętrznych. Gdy tylko jest to możliwe, dbamy o to, by alternatywne rozwiązania były dostępne publicznie, zanim wprowadzimy ograniczenia w interfejsach innych niż SDK.

Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą nie być od razu widoczne. Mimo że obecnie możesz korzystać z wybranych interfejsy inne niż SDK (w zależności od docelowego poziomu interfejsu API aplikacji), Korzystanie z dowolnej metody lub pola niezwiązanego z pakietem SDK zawsze wiąże się z dużym ryzykiem naruszenia .

Jeśli nie wiesz, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, możesz przetestować aby się dowiedzieć. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migracji do alternatywnych pakietów SDK. Rozumiemy jednak, że niektóre aplikacje z prawidłowymi zastosowaniami interfejsów innych niż SDK. Jeśli nie możesz znaleźć innej do interfejsu innego niż SDK w przypadku danej funkcji, musisz poprosić o utworzenie nowego publicznego interfejsu API.

Więcej informacji o zmianach w tej wersji Androida znajdziesz w sekcji Aktualizacje ograniczenia korzystania z interfejsu spoza SDK w Androidzie 12. Aby dowiedzieć się więcej, o interfejsach innych niż SDK znajdziesz w sekcji Ograniczenia dotyczące interfejsów spoza SDK .