Zmiany w działaniu: aplikacje kierowane na Androida 12

Podobnie jak we wcześniejszych wersjach, Android 12 zawiera zmiany w działaniu, które co może mieć wpływ na Twoją aplikację. Te zmiany w działaniu dotyczą tylko aplikacji kierowane na Androida 12 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 12, musisz zmodyfikować aplikację, aby obsługiwała te zachowania jeśli jest to wymagane.

Zapoznaj się też z listą zmian w działaniu, które mają wpływ na wszystkie aplikacje na Androidzie 12.

Interfejs użytkownika

Niestandardowe powiadomienia

Android 12 zmienia wygląd i działanie powiadomień niestandardowych. Wcześniej powiadomienia niestandardowe mogły obejmować cały obszar powiadomień i udostępniać własne układy i style. Pozwoliło to uzyskać antywzorce, może zdezorientować użytkowników lub spowodować problemy ze zgodnością układu na różnych urządzeniach.

W przypadku aplikacji kierowanych na Androida 12 powiadomienia z niestandardowymi widokami treści nie będą dłużej korzystać z pełnego obszaru powiadomień; zamiast tego system stosuje standardowy szablon. Ten szablon zapewnia, że powiadomienia niestandardowe będą miały taki sam dekoruj jako inne powiadomienia we wszystkich stanach, na przykład ikonę powiadomienia i afordancje rozwinięcia (w stanie zwiniętym) oraz ikonę powiadomienia; nazwa aplikacji i zwinięcie afordancji (w stanie rozwinięcia). Działanie to jest prawie taki sam jak w przypadku Notification.DecoratedCustomViewStyle

Dzięki temu w Androidzie 12 wszystkie powiadomienia są wizualnie spójne i łatwe dzięki wykrywalnemu, dobrze znanemu rozszerzeniu powiadomień dla użytkowników.

Poniższa ilustracja przedstawia niestandardowe powiadomienie w szablonie standardowym:

Poniższe przykłady pokazują, jak powiadomienia niestandardowe będą renderowane w zwiniętej reklamie i stan rozwinięty:

Zmiana w Androidzie 12 wpływa na aplikacje, które definiują niestandardowe podklasy Notification.Style lub które używają funkcji Metody użytkownika Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) oraz setCustomHeadsUpContentView(RemoteViews).

Jeśli Twoja aplikacja korzysta w pełni z powiadomień niestandardowych, zalecamy przetestowanie jej za pomocą jak najszybciej.

1. Włącz zmianę dotyczącą powiadomień niestandardowych:

   1. Aby włączyć nowe zachowanie, zmień targetSdkVersion aplikacji na S.
   2. Skompiluj ponownie.
   3. Zainstaluj aplikację na urządzeniu lub w emulatorze z Androidem 12.

2. Przetestuj wszystkie powiadomienia, które korzystają z widoków niestandardowych, aby sprawdzić, czy wyglądają tak samo jak Ty. w cieniu. Podczas testowania weź pod uwagę te kwestie i wprowadź niezbędne zmiany:

   • Zmieniły się wymiary widoków niestandardowych. Ogólnie wysokość na powiadomienia niestandardowe jest teraz mniejsza niż do tej pory. W grupie zwiniętej maksymalna wysokość niestandardowej treści spadła z 106 dp. do 48 dp. Obszar w poziomie jest też mniejszy.

   • Wszystkie powiadomienia są rozwijane w przypadku aplikacji kierowanych na Androida 12. Zazwyczaj oznacza to, że jeśli używasz setCustomContentView, warto też używać setBigCustomContentView aby mieć pewność, że stan zwinięty i rozwinięty jest taki sam.

   • Aby przycisk Uważaj na przejściu stan zgodny z oczekiwaniami, nie zapomnij zwiększyć znaczenie kanału powiadomień na „WYSOKI” (Wyświetla się ekranu).

Zmiany weryfikacji linków aplikacji na Androida

W przypadku aplikacji kierowanych na Androida 12 lub nowszego system kilka zmian w sposobie działania linków aplikacji na Androida zweryfikowane. Te poprawia niezawodność łączenia aplikacji i zapewnia więcej jak również deweloperom aplikacji i użytkownikom.

Jeśli używasz weryfikacji linku aplikacji na Androida do otwierania linków internetowych w aplikacji, Sprawdź, czy używasz właściwego formatu podczas dodawania intencji filtry w przypadku Weryfikacja linku aplikacji na Androida. W szczególności zadbaj o to, aby te zamiary filtry obejmują kategorię BROWSABLE i obsługują schemat https.

Możesz też ręcznie zweryfikuj linki do aplikacji, aby przetestować rzetelność deklaracji.

Ulepszone działanie obrazu w obrazie

W Androidzie 12 wprowadziliśmy ulepszenia w działaniu trybu obrazu w obrazie (PIP). i zalecane ulepszenia kosmetyczne w animacjach przejść dla obu gestów nawigacji i nawigacji opartej na elementach.

Zobacz Obraz w obrazie , aby dowiedzieć się więcej. i informacjami o nich.

Nowy wygląd toatów

W Androidzie 12 widok tosty zaprojektowany od nowa. Komunikaty są teraz ograniczone do 2 wierszy tekstu i pokazują aplikację obok tekstu.

Więcej informacji znajdziesz w artykule Omówienie powiadomień.

Prywatność i bezpieczeństwo

Przybliżona lokalizacja

Na urządzeniach z Androidem 12 lub nowszym użytkownicy mogą poprosić o dostęp przybliżona lokalizacja dokładności.

Nowoczesne pliki cookie SameSite w komponencie WebView

Komponent WebView Androida jest oparty na Chromium, projektu open source, na którym opiera się przeglądarka Google Chrome. Wprowadzenie Chromium zmian w obsłudze plików cookie innych firm, aby zapewnić większe bezpieczeństwo prywatności oraz zapewnić użytkownikom większą przejrzystość i kontrolę. Począwszy od Androida 12: te zmiany są też uwzględnione w WebView, gdy aplikacje są kierowane Androida 12 (poziom API 31) lub nowszego.

Atrybut SameSite pliku cookie określa, czy może on być wysyłany z dowolnym lub tylko w przypadku żądań z tej samej witryny. Następujące elementy chroniące prywatność poprawia domyślną obsługę plików cookie innych firm i pomaga chronić przed niezamierzonym udostępnianiem w witrynach.

• Pliki cookie bez atrybutu SameSite są traktowane jak SameSite=Lax.
• Pliki cookie z atrybutem SameSite=None muszą też mieć określony atrybut Secure, co oznacza wymagają bezpiecznego kontekstu i powinny być wysyłane przez HTTPS.
• Linki między wersjami HTTP i HTTPS witryny są teraz traktowane jak linki z innych witryn żądań, więc pliki cookie nie są wysyłane, chyba że są odpowiednio oznaczone jako SameSite=None; Secure

Dla programistów ogólną wskazówką jest identyfikowanie plików cookie pochodzących z innych witryn. zależności w krytycznych przepływach użytkowników i upewnij się, że SameSite atrybut jest jawnie ustawiony za pomocą odpowiednich wartości tam, gdzie jest to wymagane. Musisz wyraźnie określić pliki cookie, które mogą działać w różnych witrynach, w ramach nawigacji w tej samej witrynie i przejścia z HTTP do HTTPS.

Pełne wskazówki dla programistów stron internetowych dotyczące tych zmian znajdziesz w artykule Pliki cookie SameSite Wyjaśnij i Schemeful SameSite.

Przetestuj zachowanie SameSite w swojej aplikacji

Jeśli Twoja aplikacja używa WebView albo zarządzasz witryną lub usługą, która używa plików cookie, zalecamy przetestowanie przepływów w komponencie WebView Androida 12. Jeśli napotkasz problemy, być może będzie trzeba zaktualizować pliki cookie, by obsługiwały Zachowania SameSite.

Zwróć uwagę na problemy z logowaniem, umieszczaniem treści i procesem logowania, zakupów i innych procesów uwierzytelniania, w których użytkownik zaczyna od niezabezpieczonej i przechodzi na stronę zabezpieczoną.

Aby przetestować aplikację za pomocą WebView, musisz włączyć nowe zachowania SameSite w przypadku parametru którą chcesz przetestować, wykonując jedną z tych czynności:

• Ręcznie włącz zachowania SameSite na urządzeniu testowym, przełączając flagę interfejsu webview-enable-modern-cookie-same-site w narzędziach deweloperskich WebView.

  Ta metoda umożliwia testowanie na dowolnym urządzeniu z Androidem 5.0 (poziom interfejsu API 21) lub nowszym – w tym na Androidzie 12 i komponencie WebView w wersji 89.0.4385.0 lub wyższą.

• Skompiluj aplikację, aby była kierowana na Androida 12 (poziom interfejsu API 31) do targetSdkVersion.

  Jeśli chcesz skorzystać z tej metody, musisz użyć urządzenia, które działa Android 12.

Informacje o zdalnym debugowaniu komponentu WebView na Androidzie znajdziesz w artykule Pierwsze kroki. za pomocą zdalnego debugowania urządzeń z Androidem.

Inne materiały

Więcej informacji o nowoczesnych działaniach SameSite i ich wdrożeniu w Chrome i WebView, zapoznaj się z aktualizacjami Chromium SameSite . Jeśli znajdziesz błąd w komponencie WebView lub Chromium, możesz zgłosić je publicznie w problemie z Chromium .

Czujniki ruchu mają ograniczoną szybkość działania

Aby chronić potencjalnie poufne informacje o użytkownikach, jeśli Twoja aplikacja jest kierowana w Androidzie 12 lub nowszym system nakłada limit odświeżania. szybkości transmisji danych z określonych czujników ruchu i pozycji.

Więcej informacji o czujniku .

Hibernacja aplikacji

Android 12 rozwija się po automatycznym resetowaniu uprawnień. zachowanie wprowadzonej w Androidzie 11 (poziom API 30). Jeśli Twoja aplikacja jest kierowana Android 12 a użytkownik nie wchodzi w interakcję z aplikacją przez kilka minut miesięcy, system automatycznie resetuje wszystkie przyznane uprawnienia i umieszcza aplikację w hibernacji.

Więcej informacji znajdziesz w przewodniku na temat aplikacji hibernacji.

Deklaracja atrybucji w ramach kontroli dostępu do danych

Za pomocą interfejsu API kontroli dostępu do danych wprowadzonego w Androidzie 11 (poziom API 30) możesz: aby utworzyć atrybucję tagi na podstawie przypadków użycia aplikacji. Te tagi ułatwiają określenie, która część korzysta z określonego rodzaju danych.

Jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego, musisz zadeklarować te zasady tagów atrybucji w plik manifestu aplikacji.

Ograniczenie kopii zapasowej ADB

Aby chronić prywatne dane aplikacji, Android 12 zmienia domyślne działanie adb backup. W przypadku aplikacji kierowanych na Androida 12 (poziom API 31) lub nowszego: gdy użytkownik uruchomi polecenie adb backup, dane aplikacji zostaną wykluczone z pozostałych danych systemowych eksportowanych z urządzenia.

Jeśli Twoje procesy testowania i programowania wykorzystują dane aplikacji w narzędziu adb backup, możesz teraz włączyć eksportowanie danych aplikacji przez android:debuggable. do true w pliku manifestu aplikacji.

Bezpieczniejsze eksportowanie komponentów

Jeśli aplikacja jest kierowana na Androida 12 lub nowszego i zawiera aktywność, usługi lub transmisja odbiorcy, którzy używają intentu , musisz zadeklaruj Atrybut android:exported dla tych komponentów aplikacji.

Jeśli komponent aplikacji zawiera Ustawiona kategoria LAUNCHER android:exported do true. W większości innych przypadków ustaw android:exported na false

Ten fragment kodu to przykład usługi zawierającej intencję filtr, którego atrybut android:exported jest ustawiony na false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Wiadomości w Android Studio

Jeśli aplikacja zawiera aktywność, usługę lub odbiornik, który korzysta z usługi filtry intencji, ale nie deklaruje: android:exported, to ostrzeżenie W zależności od używanej wersji Android Studio:

Android Studio 2020.3.1 Canary 11 lub nowszy

Pojawią się te komunikaty:

1. W pliku manifestu jest wyświetlane to ostrzeżenie dotyczące lintowania:

   When using intent filters, please specify android:exported as well
   

2. Gdy spróbujesz skompilować aplikację, zobaczysz ten komunikat o błędzie kompilacji pojawia się:

   Manifest merger failed : Apps targeting Android 12 and higher are required \
   to specify an explicit value for android:exported when the corresponding \
   component has an intent filter defined.
   

Starsze wersje Android Studio

Jeśli spróbujesz zainstalować aplikację, Logcat. wyświetla następujący komunikat o błędzie:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

Zmienność intencji oczekujących

Jeśli Twoja aplikacja jest kierowana na Androida 12, musisz określić zmienność każdy obiekt PendingIntent które tworzy aplikacja. To dodatkowe wymaganie zwiększa bezpieczeństwo aplikacji.

Testowanie oczekującej zmiany zmienności intencji

Aby sprawdzić, czy w Twojej aplikacji brakuje deklaracji zmienności, poszukaj parametru to ostrzeżenie o Lint w Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Uruchomienia niebezpiecznych intencji

Aby zwiększyć bezpieczeństwo platformy, Android 12 i nowsze wersje funkcji debugowania, która wykrywa niebezpieczne uruchomienia . Kiedy system wykryje takie niebezpieczne uruchomienie, Występuje naruszenie zasad StrictMode.

Wydajność

Ograniczenia dotyczące uruchamiania usług działających na pierwszym planie

Aplikacje kierowane na Androida 12 lub nowszego nie mogą uruchamiać pierwszego planu w systemie w tle, oprócz kilku wyjątkowych . Jeśli aplikacja próbuje uruchomić usługę na pierwszym planie podczas może wystąpić wyjątek (z wyjątkiem kilku szczególnych przypadków).

Rozważ użycie WorkManagera do planowania i uruchamiania przyspieszonych praca gdy aplikacja działa w tle. Aby móc wykonywać działania wymagające uwagi zgodnie z żądaniami użytkownika, należy uruchomić usługi na pierwszym planie w obszarze ścisłym, alarm.

Uprawnienie dostępu do precyzyjnych alarmów

Aby zachęcić aplikacje do oszczędzania zasobów systemowych, Androida 12 lub nowszego i ustaw ścisłe alarmy muszą mieć dostęp do sekcji „Alarmy przypomnienia” która pojawia się na ekranie Specjalny dostęp do aplikacji w ustawieniach systemu.

Aby go uzyskać, poproś o dostęp do SCHEDULE_EXACT_ALARM uprawnienia użytkownika w pliku manifestu.

Precyzyjne alarmy powinny być stosowane tylko w przypadku funkcji przeznaczonych dla użytkownika. Dowiedz się więcej o dopuszczalnych przypadków użycia alarm.

Wyłącz zmianę działania

Przygotowując aplikację na Androida 12, możesz tymczasowo wyłącz zmianę działania w kompilacji możliwej do debugowania. wersji do celów testowych. Aby to zrobić, ukończ jedno z tych zadań:

• Na ekranie ustawień Opcje dla programistów wybierz Zgodność aplikacji Zmiany. Na ekranie, który się pojawi, kliknij nazwę aplikacji i wyłącz ją. REQUIRE_EXACT_ALARM_PERMISSION.

• W oknie terminala na komputerze, którego używasz do programowania, uruchom to polecenie:

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

Ograniczenia dotyczące powiadomień z trampolinami

Gdy użytkownicy wchodzą w interakcję z: powiadomień, niektóre aplikacje reagują na kliknięcia powiadomień po uruchomieniu aplikacji , który na końcu które użytkownik widzi i z którym wchodzi w interakcję. Ten komponent aplikacji jest zwany trampoliną do powiadomień.

Aby poprawić wydajność i wygodę użytkowania, aplikacje na Androida 12 lub na wyższym poziomie nie mogą uruchamiać działań z usług lub odbiornikach używanych jako trampoliny powiadomień. Innymi słowy, gdy użytkownik kliknie powiadomienie, lub przycisk polecenia w aplikacja nie może nawiązać połączenia startActivity(). wewnątrz usługi lub odbiornika.

Gdy aplikacja próbuje rozpocząć aktywność w usłudze lub odbiorniku która działa jak trampolina do powiadomień, system zapobiega i pojawi się następujący komunikat w Logcat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Określ, które komponenty aplikacji działają jak trampoliny z powiadomieniami

Podczas testowania aplikacji po kliknięciu powiadomienia możesz określić, które usługi lub odbiornika pełniły w Twojej aplikacji rolę trampolina powiadomień. Aby to zrobić, przejrzyj dane wyjściowe tego polecenia terminala:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

Sekcja danych wyjściowych zawiera tekst „NotifInteractionLog”. Ta sekcja zawiera informacje niezbędne do zidentyfikowania komponentu, który rozpoczyna się w przypadku kliknięcia powiadomienia.

Zaktualizuj aplikację

Jeśli aplikacja rozpoczyna aktywność usługi lub odbiornika, który działa jako Trampolinę powiadomień, wykonaj te czynności migracji:

1. Utwórz obiekt PendingIntent, który jest powiązana z aktywnością, którą użytkownicy widzą po kliknięciu tego przycisku. powiadomienia.
2. Użyj w ramach tego obiektu PendingIntent utworzonego w poprzednim kroku o tworzeniu powiadomienia.

Aby zidentyfikować źródło aktywności, np. zapisywać dane, podczas publikowania powiadomienia używaj elementów dodatkowych. W przypadku scentralizowanego logowania użyj ActivityLifecycleCallbacks lub obserwatorów cyklu życia Jetpacka.

Przełącz działanie

Podczas testowania wersji aplikacji z możliwością debugowania możesz włączyć lub wyłączyć tę funkcję za pomocą flagi zgodności aplikacji NOTIFICATION_TRAMPOLINE_BLOCK.

tworzenie i przywracanie kopii zapasowej;

Zmieniliśmy sposób działania tworzenia i przywracania kopii zapasowych w aplikacjach Android 12 (poziom API 31). Tworzenie i przywracanie kopii zapasowej Androida ma 2 formy:

• Kopie zapasowe w chmurze: dane użytkownika są przechowywane na Dysku Google użytkownika, które można później przywrócić na tym lub nowym urządzeniu.
• Przenoszenie między urządzeniami (D2D): dane użytkownika są wysyłane bezpośrednio do nowego urządzenia użytkownika ze starszego urządzenia, na przykład za pomocą kabla.

Więcej informacji na temat tworzenia kopii zapasowych i przywracania danych znajdziesz w artykule Tworzenie kopii zapasowej danych użytkownika danych za pomocą Automatycznej kopii zapasowej i tworzenia kopii zapasowych par klucz-wartość za pomocą funkcji Android Backup Service.

Zmiany funkcji przenoszenia danych D2D

W przypadku aplikacji działających na Androidzie 12 lub nowszym i kierowanych na niego:

• Określanie reguł uwzględniania i wykluczania za pomocą kodu XML nie wpływa na transfery D2D, wpływa na tworzenie i przywracanie kopii zapasowych działających w chmurze (np. na kopie zapasowe na Dysku Google). Do określ reguły dla transferów D2D, musisz użyć nowej konfiguracji, której to dotyczy w następnej sekcji.

• Na urządzeniach niektórych producentów po określeniu android:allowBackup="false" wyłącza tworzenie kopii zapasowych na Dysku Google, ale nie wyłącza przenoszenia D2D dla aplikacji.

Nowy format uwzględniania i wykluczania

Aplikacje działające na Androidzie 12 lub nowszym i kierowane na niego używają inny format dla konfiguracji XML. Ten format sprawia, między kopią zapasową Dysku Google a przenoszeniem danych w D2D, wymagając możesz oddzielnie określić reguły uwzględniania i wykluczania dla kopii zapasowych w chmurze i D2D i przenieś.

Opcjonalnie możesz go też używać do określania reguł kopii zapasowej, w którym to przypadku wcześniej używana konfiguracja jest ignorowana na urządzeniach z Androidem 12 lub wyższe. Starsza konfiguracja jest nadal wymagana na urządzeniach z Androidem 11 lub niższy.

Zmiany formatu XML

Poniżej znajduje się format służący do tworzenia i przywracania kopii zapasowych w Androidzie 11 i starsze:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

Poniżej przedstawiono zmiany pogrubione w formacie.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

Więcej informacji znajdziesz w odpowiedniej sekcji na i dowiedz się, jak tworzyć kopie zapasowe danych użytkowników przy użyciu Automatycznej kopii zapasowej.

Flaga pliku manifestu w przypadku aplikacji

Skieruj swoje aplikacje do nowej konfiguracji XML, korzystając z Atrybut android:dataExtractionRules w pliku manifestu . Gdy wskażesz nową konfigurację XML, parametr Atrybut android:fullBackupContent wskazujący starą konfigurację jest ignorowany na urządzeniach z Androidem 12 lub nowszym. Poniższa próbka kodu pokazuje nowy Wpisy w pliku manifestu:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

Łączność

Uprawnienia Bluetooth

Android 12 wprowadza BLUETOOTH_SCAN BLUETOOTH_ADVERTISE, oraz BLUETOOTH_CONNECT uprawnień. Uprawnienia te ułatwiają korzystanie z aplikacji kierowanych Android 12 obsługuje Bluetootha urządzeń, zwłaszcza w przypadku aplikacji, które nie korzystają wymagają dostępu do lokalizacji urządzenia.

Aby przygotować urządzenie do kierowania na Androida 12 lub nowszego, zaktualizuj do zasad Twojej aplikacji. Zamiast deklarować starszy zestaw Bluetootha uprawnienia, zadeklaruj nowocześniejszy zestaw Bluetooth uprawnienia.

Równoczesne połączenie peer-to-peer + połączenie z internetem

W przypadku aplikacji kierowanych na Androida 12 (poziom interfejsu API 31) lub nowszego, urządzenia, które obsługują równoczesne połączenia peer-to-peer i połączenia internetowe umożliwiają jednoczesne korzystanie z Wi-Fi zarówno z urządzeniem równorzędnym, jak i główną siecią udostępniającą internet. co zwiększa wygodę użytkowników. Kierowanie na aplikacje W Androidzie 11 (poziom interfejsu API 30) lub starszym nadal działa starszy sposób działania, gdzie podstawowa sieć Wi-Fi jest odłączona przed połączeniem z peerem urządzenia.

Zgodność

WifiManager.getConnectionInfo() może zwrócić WifiInfo dla tylko jedną sieć. Z tego powodu interfejs API zmienił się w ten sposób na Androidzie 12 i nowszych:

• Jeśli dostępna jest tylko jedna sieć Wi-Fi, zwracana jest jej WifiInfo.
• Jeśli jest dostępna więcej niż jedna sieć Wi-Fi, a aplikacja do połączeń uruchomiła połączenia peer-to-peer, urządzenie WifiInfo odpowiadające urządzeniu równorzędnego to .
• Jeśli jest dostępna więcej niż jedna sieć Wi-Fi, a aplikacja do rozmów nie aktywuje połączenie peer-to-peer, czyli podstawowe połączenie zapewniające dostęp do internetu. Zwracana jest wartość WifiInfo.

Aby zapewnić użytkownikom lepsze wrażenia na urządzeniach, które obsługują podwójne funkcje równoczesne sieci Wi-Fi, zalecamy wszystkie aplikacje – zwłaszcza te, które uruchamiają połączenia peer-to-peer – migracja z funkcji połączeń WifiManager.getConnectionInfo() i zamiast tego użyj NetworkCallback.onCapabilitiesChanged(). aby pobrać wszystkie obiekty (WifiInfo) pasujące do obiektu NetworkRequest użytego do rejestracji NetworkCallback. Interfejs getConnectionInfo() jest wycofany Android 12.

Poniższy przykładowy kod pokazuje, jak uzyskać WifiInfo w NetworkCallback:

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

Natywny interfejs API mDNSResponder

W Androidzie 12 aplikacje mogą wchodzić w interakcje z demonem mDNSResponder za pomocą natywny interfejs API mDNSResponder. Wcześniej, gdy aplikacja rejestrowała usługę w sieci. i nazwano getSystemService() systemowa usługa NSD uruchomiła demona mDNSResponder, nawet jeśli aplikacja nie wywołała jeszcze żadnych metod NsdManager. Demon zasubskrybował następnie do grup transmisji grupowych we wszystkich węzłach, co powoduje częstsze wybudzanie systemu często i zużywaj więcej energii. Aby zminimalizować zużycie baterii, w Androidzie 12 a wyżej system uruchamia demona mDNSResponder tylko wtedy, gdy jest to potrzebne w przypadku wystąpienia NSD i zatrzymuje go później.

Ponieważ ta zmiana wpływa na dostępność demona mDNSResponder, aplikacje przy założeniu, że demon mDNSResponder zostanie uruchomiony po wywołaniu funkcji Metoda getSystemService() może otrzymywać z systemu komunikaty o tym, demon mDNSResponder jest niedostępny. Aplikacje, które korzystają z funkcji NsdManager i nie używają używają natywnego interfejsu API mDNSResponder, nie mają wpływu na tę zmianę.

Biblioteki dostawców

Natywne biblioteki udostępnione dostarczone przez dostawcę

Natywne biblioteki udostępnione inne niż NDK dostarczane przez dostawców krzemu lub producentów urządzeń są niedostępne. domyślnie, jeśli aplikacja jest kierowana na Androida 12 (poziom interfejsu API 31) lub nowszego. biblioteki są dostępne tylko wtedy, gdy zostaną wyraźnie zażądane za pomocą funkcji <uses-native-library> .

Jeśli aplikacja jest kierowana na Androida 11 (poziom API 30) lub niższy, parametr Tag <uses-native-library> nie jest wymagany. W takim przypadku każdy zasób natywny udostępniony jest dostępna niezależnie od tego, czy jest to biblioteka NDK.

Zaktualizowano ograniczenia spoza pakietu 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 dotyczące interfejsów spoza 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łowych zastosowań 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 .