Zmiany w działaniu: aplikacje kierowane na Androida 12

Podobnie jak w przypadku wcześniejszych wersji, Android 12 wprowadza zmiany działania, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany działania dotyczą wyłącznie aplikacji kierowanych na Androida 12 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 12, w stosownych przypadkach zmodyfikuj aplikację, aby odpowiednio obsługiwała te zachowania.

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

Interfejs użytkownika

Niestandardowe powiadomienia

Android 12 zmienia wygląd i działanie powiadomień niestandardowych. Wcześniej powiadomienia niestandardowe mogły korzystać z całego obszaru powiadomień oraz mieć własne układy i style. Pojawiły się antywzorce, które mogły dezorientować użytkowników lub powodować 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ą już używać całej powierzchni powiadomienia. Zamiast tego system zastosuje standardowy szablon. Dzięki temu szablonowi powiadomienia niestandardowe mają takie same ozdobienia jak inne powiadomienia we wszystkich stanach, takie jak ikona powiadomienia i możliwości rozwinięcia (w stanie zwiniętym) oraz ikona powiadomienia, nazwa aplikacji i możliwość zwinięcia (w stanie rozwiniętym). Działa to prawie tak samo jak Notification.DecoratedCustomViewStyle.

Dzięki temu w Androidzie 12 wszystkie powiadomienia są wizualnie spójne i łatwe do przejrzenia, a ich rozszerzenie jest łatwe do znalezienia i znane użytkownikom.

Poniższa ilustracja przedstawia niestandardowe powiadomienie w szablonie standardowym:

Z poniższych przykładów dowiesz się, jak renderują się powiadomienia niestandardowe w stanie zwiniętym i rozwiniętym:

Zmiana w Androidzie 12 ma wpływ na aplikacje, które definiują niestandardowe podklasy Notification.Style lub używają metod Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews)setCustomHeadsUpContentView(RemoteViews).

Jeśli Twoja aplikacja korzysta z w pełni niestandardowych powiadomień, zalecamy jak najszybsze przetestowanie jej z użyciem nowego szablonu.

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

    1. Aby włączyć nowe zachowanie, zmień targetSdkVersion aplikacji na S.
    2. Skompiluj ponownie.
    3. Zainstaluj aplikację na urządzeniu lub emulatorze z Androidem 12.
  2. Przetestuj wszystkie powiadomienia, które korzystają z widoków niestandardowych, upewniając się, że wyglądają w cieniu zgodnie z oczekiwaniami. Podczas testowania bierz pod uwagę te kwestie i wprowadź niezbędne korekty:

    • Zmieniły się wymiary widoków niestandardowych. Powiadomienia niestandardowe mają z reguły mniejszą wysokość. W stanie zwiniętym maksymalna wysokość treści niestandardowej spadła z 106 dp do 48 dp. Poza tym zajmuje mniej miejsca na ekranie.

    • W przypadku aplikacji kierowanych na Androida 12 wszystkie powiadomienia są rozwijane. Zwykle oznacza to, że jeśli używasz setCustomContentView, warto też użyć interfejsu setBigCustomContentView, by mieć pewność, że stany zwinięty i rozwinięty są spójne.

    • Aby mieć pewność, że stan „Heads Up” wygląda tak, jak chcesz, nie zapomnij podnieść rangi kanału powiadomień do „WYSOKA” (powiadomienia wyskakujące).

W przypadku aplikacji kierowanych na Androida 12 lub nowszego system wprowadza kilka zmian w sposobie weryfikowania linków aplikacji na Androida. Te zmiany zwiększają niezawodność procesu łączenia aplikacji i dają deweloperom oraz użytkownikom większą kontrolę.

Jeśli używasz weryfikacji linku aplikacji na Androida do otwierania linków internetowych w aplikacji, sprawdź, czy podczas dodawania filtrów intencji na potrzeby weryfikacji linku aplikacji na Androida używasz prawidłowego formatu. Upewnij się, że te filtry intencji obejmują kategorię BROWSABLE i obsługują schemat https.

Możesz też ręcznie zweryfikować linki w aplikacji, aby sprawdzić wiarygodność deklaracji.

Ulepszone działanie obrazu w obrazie

Android 12 wprowadza ulepszenia zachowania w trybie obrazu w obrazie (PiP) oraz zalecane ulepszenia kosmetyczne animacji przejść zarówno w przypadku nawigacji za pomocą gestów, jak i nawigacji opartej na elementach.

Więcej informacji znajdziesz w artykule o ulepszeniach funkcji obraz w obrazie.

Nowy wygląd toatów

W Androidzie 12 zmieniliśmy wygląd widoku ekranu. Komunikaty typu toast są teraz ograniczone do 2 wierszy tekstu i mają wyświetlaną obok ikonę aplikacji.

Obraz urządzenia z Androidem z wyskakującym okienkiem z komunikatem „Wysyłam wiadomość” obok ikony aplikacji

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 przybliżoną dokładność lokalizacji w Twojej aplikacji.

Nowoczesne pliki cookie SameSite w komponencie WebView

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

Atrybut SameSite pliku cookie określa, czy może on być wysyłany z dowolnymi żądaniami, czy tylko z żądaniami z tej samej witryny. Następujące zmiany w zakresie ochrony prywatności poprawiają domyślną obsługę plików cookie innych firm i pomagają chronić się przed niezamierzonym udostępnianiem treści między witrynami:

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

Deweloperzy powinni ogólnie określić zależności plików cookie w różnych witrynach w kluczowych ścieżkach użytkowników i zadbać o to, aby atrybut SameSitebył wyraźnie ustawiony z odpowiednimi wartościami w odpowiednich miejscach. Musisz wyraźnie określić pliki cookie, które mogą działać w różnych witrynach lub w ramach tej samej nawigacji w witrynie, która przechodzi z HTTP do HTTPS.

Pełne wskazówki dla programistów stron internetowych dotyczące tych zmian znajdziesz w artykułach SameSite Cookies Explained i Schemeful SameSite.

Testowanie zachowania SameSite w aplikacji

Jeśli Twoja aplikacja korzysta z WebView lub zarządzasz witryną lub usługą, która używa plików cookie, zalecamy przetestowanie swoich procesów w komponencie WebView w Androidzie 12. W przypadku wystąpienia problemów konieczne może być zaktualizowanie plików cookie pod kątem nowego sposobu działania SameSite.

Zwróć uwagę na problemy z logowaniem i osadzonym treściami, a także procesami logowania, zakupów i innymi procesami uwierzytelniania, w których użytkownik zaczyna na niechronionej stronie, a przechodzi na stronę chronioną.

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

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

Inne materiały

Więcej informacji o nowych zachowaniach SameSite i ich wdrożeniu w Chrome oraz WebView znajdziesz na stronie aktualizacji SameSite w Chromium. Jeśli znajdziesz błąd w WebView lub Chromium, możesz go zgłosić w publicznym dzienniku błędów Chromium.

Czujniki ruchu mają ograniczoną częstotliwość

Aby chronić potencjalnie poufne informacje o użytkownikach, jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego, system ogranicza częstotliwość odświeżania danych z określonych czujników ruchu i pozycji.

Dowiedz się więcej o ograniczaniu szybkości czujnika.

Hibernacja aplikacji

Android 12 rozszerza działanie automatycznego resetowania uprawnień wprowadzone w Androidzie 11 (poziom API 30). Jeśli Twoja aplikacja jest kierowana na Androida 12, a użytkownik nie korzysta z niej przez kilka miesięcy, system automatycznie zresetuje przyznane uprawnienia i przełączy aplikację w stan hibernacji.

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

Deklaracja atrybucji w ramach kontroli dostępu do danych

Interfejs API kontroli dostępu do danych wprowadzony w Androidzie 11 (poziom interfejsu API 30) umożliwia tworzenie tagów atrybucji na podstawie przypadków użycia aplikacji. Te tagi ułatwiają określenie, która część aplikacji wymaga dostępu do danych określonego typu.

Jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego, musisz zadeklarować te tagi atrybucji w pliku manifestu aplikacji.

Ograniczenie kopii zapasowej ADB

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

Jeśli Twoje procesy testowania lub programowania bazują na danych aplikacji za pomocą usługi adb backup, możesz teraz włączyć eksportowanie danych aplikacji, ustawiając właściwość android:debuggable na true w pliku manifestu aplikacji.

Bezpieczniejsze eksportowanie komponentów

Jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego i zawiera aktywności, usługi lub odbiorniki radiowe, które używają filtrów intencji, musisz wyraźnie zadeklarować atrybut android:exported dla tych komponentów aplikacji.

Jeśli komponent aplikacji zawiera kategorię LAUNCHER, ustaw wartość android:exported na true. W większości innych przypadków ustaw android:exported na false.

Ten fragment kodu to przykład usługi zawierającej filtr intencji, którego atrybut android:exported ma wartość 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 używa filtrów intencji, ale nie deklaruje funkcji android:exported, w zależności od używanej wersji Android Studio pojawiają się te ostrzeżenia:

Android Studio 2020.3.1 Canary 11 lub nowszy

Pojawią się te komunikaty:

  1. W pliku manifestu pojawi się takie ostrzeżenie lint:

    When using intent filters, please specify android:exported as well
    
  2. Gdy spróbujesz skompilować aplikację, pojawi się ten komunikat o błędzie kompilacji:

    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świetli ten 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ść oczekujących intencji

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

Testowanie zmiany zmienności oczekującego zamiaru

Aby sprawdzić, czy w aplikacji brakuje deklaracji zmienności, poszukaj w Android Studio tego ostrzeżenia lint:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Uruchomienia niebezpiecznych intencji

Aby zwiększyć bezpieczeństwo platformy, Android 12 i nowsze wersje udostępniają funkcję debugowania, która wykrywa niebezpieczne uruchomienia zamiarów. Gdy system wykryje takie niebezpieczne uruchomienie, dochodzi do naruszenia StrictMode.

Wydajność

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

Aplikacje kierowane na Androida 12 lub nowszego nie mogą uruchamiać usług na pierwszym planie podczas działania w tle (z wyjątkiem kilku szczególnych przypadków). Jeśli aplikacja próbuje uruchomić usługę na pierwszym planie, gdy działa w tle, występuje wyjątek (z wyjątkiem kilku przypadków specjalnych).

Zastanów się nad użyciem WorkManagera do zaplanowania i rozpoczęcia przyspieszonej pracy, gdy aplikacja działa w tle. Aby wykonać działania wymagające szybkiego działania na żądanie użytkownika, uruchamiaj usługi na pierwszym planie w ramach dokładnego alarmu.

Uprawnienie dostępu do precyzyjnych alarmów

Aby zachęcić aplikacje do oszczędzania zasobów systemowych, aplikacje kierowane na Androida 12 i nowsze, które ustawiają dokładne alarmy, muszą mieć dostęp do funkcji „Alarmy i przypomnienia”, która pojawia się na ekranie Dostęp aplikacji specjalnych w ustawieniach systemu.

Aby uzyskać ten specjalny dostęp aplikacji, poproś o SCHEDULE_EXACT_ALARMw pliku manifestu.

Precyzyjne alarmy powinny być stosowane tylko w przypadku funkcji przeznaczonych dla użytkownika. Dowiedz się więcej o dopuszczalnych przypadkach użycia do ustawienia dokładnego alarmu.

Wyłącz zmianę działania

Podczas przygotowywania aplikacji na potrzeby Androida 12 możesz tymczasowo wyłączyć zmianę zachowania w wersji z możliwością debugowania na potrzeby testów. Aby to zrobić, wykonaj jedną z tych czynności:

  • Na ekranie ustawień Opcje programisty wybierz Zmiany zgodności aplikacji. Na wyświetlonym ekranie kliknij nazwę aplikacji, a potem wyłącz opcję REQUIRE_EXACT_ALARM_PERMISSION.
  • W oknie terminala na komputerze deweloperskim 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 interakcje z powiadomieniami, niektóre aplikacje reagują na dotknięcia powiadomień, uruchamiając komponent aplikacji, który ostatecznie rozpoczyna działanie, które użytkownik w końcu widzi i z którym wchodzi w interakcję. Ten komponent aplikacji jest nazywany trampoliną powiadomień.

Aby poprawić wydajność i wygodę użytkowników, aplikacje kierowane na Androida 12 lub nowszego nie mogą uruchamiać działań z usług ani odbiorników używanych jako trampolin z powiadomieniami. Innymi słowy, gdy użytkownik kliknie powiadomienie lub przycisk działania w powiadomieniu, aplikacja nie może wywołać funkcji startActivity() w ramach usługi lub odbiornika transmisji.

Gdy aplikacja próbuje uruchomić aktywność w usłudze lub odbiorniku, który działa jak trampolina powiadamiająca, system uniemożliwia rozpoczęcie aktywności, a w narzędziu Logcat pojawia się ten komunikat:

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 sprawdzić, który usługa lub odbiornik transmisji działał jako trampolina powiadomienia w aplikacji. Aby to zrobić, sprawdź 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 potrzebne do identyfikowania komponentu, który uruchamia się po kliknięciu powiadomienia.

Zaktualizuj aplikację

Jeśli aplikacja uruchamia aktywność w usłudze lub odbiorniku, który działa jak trampolina z powiadomieniami, wykonaj te czynności:

  1. Utwórz obiekt PendingIntent, który jest powiązany z działaniem, jakie użytkownicy widzą po kliknięciu powiadomienia.
  2. Użyj obiektu PendingIntent utworzonego w poprzednim kroku w ramach tworzenia powiadomienia.

Aby zidentyfikować źródło aktywności, na przykład w celu rejestrowania, podczas publikowania powiadomienia użyj dodatkowych informacji. Aby scentralizować logowanie, używaj ActivityLifecycleCallbacks lub obserwatorów cyklu życia Jetpacka.

Przełącz działanie

Podczas testowania wersji aplikacji z debugowaniem możesz włączać i wyłączać tę restrykcję 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, które działają na Androidzie 12 (poziom API 31) i są na niego kierowane. Kopie zapasowe i przywracanie na Androidzie mogą mieć 2 postaci:

  • Kopie zapasowe w chmurze: dane użytkownika są przechowywane na jego Dysku Google, aby można je było później przywrócić na tym samym lub nowym urządzeniu.
  • Przenoszenie danych między urządzeniem (D2D): dane użytkownika są wysyłane ze starszego urządzenia bezpośrednio na nowe urządzenie, np. za pomocą kabla.

Więcej informacji o tworzeniu kopii zapasowej i przywracaniu danych znajdziesz w artykułach Tworzenie kopii zapasowej danych użytkowników przy użyciu Automatycznej kopii zapasowej i Tworzenie kopii zapasowych par klucz-wartość przy użyciu Android Backup Service.

Zmiany funkcji przenoszenia danych D2D

Aplikacje działające na Androidzie 12 lub nowszym i kierowane na ten system:

  • Określanie reguł uwzględniania i wykluczania za pomocą mechanizmu konfiguracji XML nie ma wpływu na przesyłanie D2D, ale nadal ma wpływ na tworzenie kopii zapasowych i przywracanie danych w chmurze (np. kopie zapasowe na Dysku Google). Aby określić reguły dla transferów D2D, musisz użyć nowej konfiguracji opisanej w następnej sekcji.

  • Na urządzeniach niektórych producentów ustawienie wartości android:allowBackup="false" wyłącza tworzenie kopii zapasowych na Dysku Google, ale nie wyłączy przesyłania D2D w aplikacji.

Nowy format uwzględniania i wykluczania

Aplikacje działające na Androida 12 i nowsze wersje oraz kierowane na niego używają innego formatu konfiguracji XML. Ten format wyraźnie odróżnia kopię zapasową Dysku Google od przenoszenia danych w D2D, ponieważ wymaga osobnego określenia reguł uwzględniania i wykluczania dla kopii zapasowych w chmurze i transferu D2D.

Opcjonalnie możesz też użyć go do określenia reguł kopii zapasowej. W takim przypadku na urządzeniach z Androidem w wersji 12 lub nowszej poprzednio używana konfiguracja jest ignorowana. Starsza konfiguracja jest nadal wymagana na urządzeniach z Androidem 11 lub starszym.

Zmiany w formacie XML

Oto format używany do konfiguracji kopii zapasowej i przywracania w Androidzie 11 i starszych:

<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 w przewodniku dotyczącym tworzenia kopii zapasowych danych użytkowników za pomocą automatycznego tworzenia kopii zapasowych.

Flaga pliku manifestu w przypadku aplikacji

Skieruj swoje aplikacje do nowej konfiguracji XML, korzystając z atrybutu android:dataExtractionRules w pliku manifestu. Gdy wskazujesz nową konfigurację XML, atrybut android:fullBackupContent, który wskazuje na starą konfigurację, jest ignorowany na urządzeniach z Androidem 12 lub nowszym. Poniższy przykładowy kod pokazuje nowe 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 uprawnienia BLUETOOTH_SCAN, BLUETOOTH_ADVERTISEBLUETOOTH_CONNECT. Te uprawnienia ułatwiają aplikacjom przeznaczonym na Androida 12 interakcję z urządzeniami Bluetooth, zwłaszcza w przypadku aplikacji, które nie wymagają dostępu do lokalizacji urządzenia.

Aby przygotować urządzenie do kierowania na Androida 12 lub nowszego, zaktualizuj logikę aplikacji. Zamiast deklarować starszy zestaw uprawnień Bluetooth, zadeklaruj nowocześniejszy zestaw uprawnień dotyczących Bluetootha.

Równoczesne połączenie peer-to-peer i internetowe

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 internet, mogą utrzymywać jednoczesne połączenia Wi-Fi z urządzeniem równorzędnym i główną siecią udostępniającą internet, co ułatwia korzystanie z internetu. W przypadku aplikacji kierowanych na Androida 11 (poziom interfejsu API 30) lub starszego nadal działa starszy sposób działania, w ramach którego główna sieć Wi-Fi jest odłączona przed nawiązaniem połączenia z urządzeniem równorzędnym.

Zgodność

WifiManager.getConnectionInfo()może zwrócić WifiInfo tylko dla jednej sieci. Z tego powodu działanie interfejsu API zmieniło się w Androidzie 12 i nowszych w następujący sposób:

  • Jeśli dostępna jest tylko jedna sieć Wi-Fi, zwracana jest jej WifiInfo.
  • Jeśli jest dostępna więcej niż 1 sieci Wi-Fi, a aplikacja do połączeń wywołała połączenie peer-to-peer, zwracana jest wartość WifiInfo odpowiadająca urządzeniu peer.
  • Jeśli jest dostępna więcej niż 1 sieć Wi-Fi, a aplikacja do połączeń nie uruchomiła połączenia peer-to-peer, zwracany jest kod WifiInfo podstawowego połączenia zapewniającego dostęp do internetu.

Aby zwiększyć wygodę użytkowników urządzeń, które obsługują podwójne równoczesne sieci Wi-Fi, zalecamy przejście wszystkich aplikacji – zwłaszcza tych, które aktywują połączenia peer-to-peer – z wywołania WifiManager.getConnectionInfo() i korzystania z NetworkCallback.onCapabilitiesChanged() w celu uzyskania wszystkich obiektów WifiInfo zgodnych z obiektami NetworkRequest użytymi do zarejestrowania NetworkCallback. Środowisko wykonawcze getConnectionInfo() zostało wycofane w Androidzie 12.

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

Kotlin

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
    ...
  }
}

Java

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ą natywnego interfejsu mDNSResponder API. Wcześniej, gdy aplikacja zarejestrowała usługę w sieci i wywołała metodę getSystemService(), usługa NSD systemu uruchamiała demona mDNSResponder, nawet jeśli aplikacja nie wywołała jeszcze żadnej metody NsdManager. Demon zasubskrybował urządzenie w grupach multicast ze wszystkimi węzłami, dzięki czemu system częściej się wybudzał i zużywał więcej energii. Aby zminimalizować zużycie baterii, w Androidzie 12 i nowszych system uruchamia demona mDNSResponder tylko wtedy, gdy jest to potrzebne do obsługi zdarzeń NSD, a potem go zatrzymuje.

Ta zmiana wpływa na dostępność demona mDNSResponder, dlatego aplikacje, które zakładają, że demon mDNSResponder zostanie uruchomiony po wywołaniu metody getSystemService(), mogą otrzymywać od systemu komunikaty o tym, że demon mDNSResponder jest niedostępny. Ta zmiana nie dotyczy aplikacji, które korzystają z interfejsu NsdManager, ale nie używają natywnego interfejsu mDNSResponder.

Biblioteki dostawców

Biblioteki udostępnione natywne dostarczane przez dostawcę

Biblioteki natywne inne niż NDK, które są dostarczane przez dostawców układów 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 zostanie wysłane żądanie ich pobrania za pomocą tagu <uses-native-library>.

Jeśli aplikacja jest kierowana na Androida 11 (poziom interfejsu API 30) lub niższego, tag <uses-native-library> nie jest wymagany. W takim przypadku każda natywna biblioteka współdzielona jest dostępna niezależnie od tego, czy jest to biblioteka NDK.

Zaktualizowano ograniczenia spoza SDK

Android 12 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK na podstawie współpracy z deweloperami Androida i najnowszych testów wewnętrznych. Zawsze, gdy to możliwe, sprawdzamy, czy dostępne są publiczne alternatywy, zanim zaczniemy ograniczać interfejsy inne niż SDK.

Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą nie mieć na Ciebie natychmiastowego wpływu. Obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z metod lub pól spoza pakietu SDK zawsze wiąże się z wysokim ryzykiem awarii aplikacji.

Jeśli nie masz pewności, czy Twoja aplikacja 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źć alternatywy dla interfejsu spoza pakietu SDK, który jest używany w funkcji Twojej aplikacji, poproś o nowy publiczny interfejs API.

Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Zmiany ograniczeń interfejsu niebędącego interfejsem SDK w Androidzie 12. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK.