Zmiany w działaniu: aplikacje kierowane na Androida 12

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

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

Interfejs użytkownika

Niestandardowe powiadomienia

Android 12 zmienia wygląd i działanie niestandardowych powiadomień. Wcześniej powiadomienia niestandardowe mogły używać całej obszaru powiadomień i zapewniać własne układy oraz style. W rezultacie powstały wzorce, które mogły wprowadzać użytkowników w błąd 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). Takie działanie jest niemal identyczne z działaniem 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.

Ilustracja poniżej przedstawia powiadomienie niestandardowe 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) i setCustomHeadsUpContentView(RemoteViews).

Jeśli Twoja aplikacja używa powiadomień całkowicie niestandardowych, zalecamy jak najszybsze przetestowanie ich za pomocą nowego szablonu.

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

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

2. Przetestuj wszystkie powiadomienia, które korzystają z widoków niestandardowych, aby mieć pewność, że wyglądają tak, jak chcesz. Podczas testowania weź pod uwagę te kwestie i wprowadź niezbędne poprawki:

   • Wymiary widoków niestandardowych uległy zmianie. Ogólnie wysokość powiadomień niestandardowych jest mniejsza niż wcześniej. W skompresowanym stanie maksymalna wysokość treści niestandardowych została zmniejszona z 106 pikseli dp do 48 pikseli dp. Poza tym zajmuje mniej miejsca na ekranie.

   • Wszystkie powiadomienia są rozwijane w przypadku aplikacji kierowanych na Androida 12. Zwykle oznacza to, że jeśli używasz setCustomContentView, musisz też używać setBigCustomContentView, aby mieć pewność, że stany złożony 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).

Zmiany w weryfikacji linków aplikacji na Androida

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

Jeśli do otwierania linków internetowych w aplikacji używasz weryfikacji linków aplikacji na Androida, sprawdź, czy podczas dodawania filtrów intencji do weryfikacji linków 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.

Ulepszenia działania 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 Ulepszenia funkcji Picture-in-picture.

Nowy wygląd tostów

W Androidzie 12 widok toasta został przeprojektowany. Komunikaty typu toast są teraz ograniczone do 2 wierszy tekstu i mają wyświetlaną obok ikonę aplikacji.

Więcej informacji znajdziesz w artykule Omówienie komunikatów wyskakujących.

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 WebView

Komponent WebView w Androidzie jest oparty na Chromium, czyli projekcie open source, na którym opiera się przeglądarka Google Chrome. Chromium wprowadził zmiany w obsługiwaniu plików cookie innych firm, aby zapewnić większą ochronę i prywatność oraz większą przejrzystość i kontrolę dla użytkowników. Od Androida 12 te zmiany są również uwzględniane w WebView, gdy aplikacje są kierowane na Androida 12 (poziom 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. Te zmiany dotyczące ochrony prywatności poprawiają domyślne obchodzenie plików cookie innych firm i chronią przed niezamierzonym udostępnianiem danych w różnych witrynach:

• Pliki cookie bez atrybutu SameSite są traktowane jako SameSite=Lax.
• Pliki cookie z atrybutem SameSite=None muszą też zawierać atrybut Secure, co oznacza, że wymagają bezpiecznego kontekstu i powinny być wysyłane przez HTTPS.
• Linki między wersjami witryny w protokołach HTTP i HTTPS są teraz traktowane jako żądania między witrynami, więc pliki cookie nie są wysyłane, chyba że 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 upewnić się, że atrybut SameSitejest wyraźnie ustawiony z odpowiednimi wartościami w odpowiednich miejscach. Musisz wyraźnie określić pliki cookie, które mogą działać w witrynach lub w przypadku nawigacji w ramach tej samej witryny, gdy przechodzi się z HTTP na HTTPS.

Pełne wskazówki dla deweloperów dotyczące tych zmian znajdziesz w artykułach SameSite Cookies Explained (w języku angielskim) 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. Jeśli znajdziesz problemy, konieczne może być zaktualizowanie plików cookie, aby obsługiwały nowe zachowania 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ę z WebView, musisz włączyć nowe zachowania SameSite w aplikacji, którą chcesz przetestować. Aby to zrobić, wykonaj jedną z tych czynności:

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

  Dzięki temu możesz przetestować aplikację na dowolnym urządzeniu z Androidem 5.0 (poziom interfejsu API 21) lub nowszym, w tym z Androidem 12, oraz z aplikacją WebView w wersji 89.0.4385.0 lub nowszej.

• Zkompiluj aplikację pod kątem Androida 12 (poziom API 31) za pomocą targetSdkVersion.

  W tym przypadku musisz użyć urządzenia z Androidem 12.

Informacje o zdalnym debugowaniu WebView na Androidzie znajdziesz w artykule Pierwsze kroki z zdalnym debugowaniem 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 niektórych czujników ruchu i położenia.

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

Hibernacja aplikacji

Android 12 rozszerza zachowanie 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.

Oświadczenie o atrybucji w sprawdzaniu dostępu do danych

Interfejs API do weryfikowania dostępu do danych, wprowadzony w Androidzie 11 (poziom 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 uzyskuje dostęp do określonych danych.

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 zachowanie 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 tworzenia oparte są na danych aplikacji używających adb backup, możesz teraz włączyć eksportowanie danych aplikacji, ustawiając w pliku manifestu aplikacji wartość android:debuggable na true.

Bezpieczniejsze eksportowanie komponentów

Jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego i zawiera aktywności, usługi lub odbiorniki transmisji danych, 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 pokazuje 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 Twoja aplikacja zawiera aktywność, usługę lub odbiornik transmisji, który używa filtrów intencji, ale nie deklaruje android:exported, w zależności od wersji Android Studio, z której korzystasz, wyświetlą się te ostrzeżenia:

Android Studio 2020.3.1 Canary 11 lub nowsza wersja

Wyświetlają się te komunikaty:

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

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

2. Podczas kompilowania aplikacji pojawia się ten komunikat o błędzie:

   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]

Uruchamianie niebezpiecznych intencji

Aby zwiększyć bezpieczeństwo platformy, Android 12 i nowsze wersje zawierają funkcję debugowania, która wykrywa niebezpieczne uruchamianie intencji. Gdy system wykryje takie niebezpieczne uruchomienie, nastąpi naruszenie Trybu rygorystycznego.

Wydajność

Ograniczenia dotyczące uruchamiania usług na pierwszym planie

Aplikacje kierowane na Androida 12 lub nowszego nie mogą uruchamiać usług na pierwszym planie podczas działania w tlecie, 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 szczególnych przypadków).

Zastanów się nad użyciem WorkManagera do zaplanowania i rozpoczęcia przyspieszonego działania, 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.

Dokładne alarmy powinny być używane tylko w przypadku funkcji przeznaczonych dla użytkowników. Dowiedz się więcej o dopuszczalnych przypadkach użycia do ustawienia dokładnego alarmu.

Wyłączanie zmiany zachowania

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 Opcje dla deweloperów wybierz Zmiany dotyczące 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 trampoliny powiadomień

Gdy użytkownicy wchodzą w interakcję z powiadomieniami, niektóre aplikacje reagują na kliknięcia powiadomień, uruchamiając element aplikacji, który uruchamia w końcu aktywność, którą użytkownik w końcu zobaczy i z którą wejdzie w interakcję. Ten komponent aplikacji jest nazywany trampoliną powiadomień.

Aby poprawić wydajność aplikacji i wrażenia użytkownika, aplikacje kierowane na Androida 12 lub nowszego nie mogą uruchamiać czynności z usług ani odbiorników transmisji, które są używane jako trampoliny powiadomień. 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ść z usługi lub odbiornika transmisji, który działa jako trampolina powiadomień, system uniemożliwia jej uruchomienie, a w Logcat pojawia się ten komunikat:

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

Określanie, które komponenty aplikacji działają jako trampoliny powiadomień

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

W sekcji danych wyjściowych znajduje się tekst „NotifInteractionLog”. Ta sekcja zawiera informacje niezbędne do zidentyfikowania komponentu, który uruchamia się po kliknięciu powiadomienia.

Zaktualizuj aplikację

Jeśli aplikacja uruchamia aktywność z usługi lub odbiornika transmisji, który działa jako trampolina powiadomień, 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 prowadzić scentralizowane rejestrowanie, użyj funkcji ActivityLifecycleCallbacks lub obserwatorów cyklu życia Jetpacka.

Przełącz zachowanie

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.
• Przeniesienie z urządzenia na urządzenie: dane użytkownika są wysyłane bezpośrednio na nowe urządzenie użytkownika ze starszego urządzenia, np. za pomocą kabla.

Więcej informacji o tworzeniu i przywracaniu kopii zapasowych danych znajdziesz w artykułach Tworzenie kopii zapasowej danych użytkownika za pomocą Automatycznej kopii zapasowej i Tworzenie kopii zapasowej par klucz-wartość za pomocą usługi Android Backup Service.

Zmiany funkcji przesyłania 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 dotyczące 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 Androidzie 12 lub nowszym i kierowane na ten system używają innego formatu konfiguracji XML. Ten format wyraźnie odróżnia kopię zapasową na Dysku Google od transferu D2D, ponieważ wymaga oddzielnego określenia reguł uwzględniania i wykluczania w przypadku 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 12 lub nowszym wcześniej 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 konfigurowania 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 zmiany w formacie są oznaczone pogrubieniem.

<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 w pliku manifestu dotycząca aplikacji

Wskazuj aplikacje na nową konfigurację XML, używając 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 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_ADVERTISE i BLUETOOTH_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 deklarowania starszego zestawu uprawnień Bluetooth, zadeklaruj nowocześniejszy zestaw uprawnień Bluetooth.

Jednoczesne 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ą jednoczesne połączenia peer-to-peer i internetowe, mogą utrzymywać jednoczesne połączenia Wi-Fi z urządzeniem peer i główną siecią internetową, co zapewnia płynniejsze działanie aplikacji. Aplikacje kierowane na Androida 11 (poziom interfejsu API 30) lub starszego nadal działają zgodnie ze starszym zachowaniem, w którym główna sieć Wi-Fi jest odłączana przed połączeniem z urządzeniem peer.

Zgodność

WifiManager.getConnectionInfo()może zwrócić WifiInfo tylko dla jednej sieci. Z tego powodu w Androidzie 12 i nowszych wersjach zachowanie interfejsu API zostało zmienione 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 sieci Wi-Fi, a aplikacja do połączeń nie wywołała połączenia peer-to-peer, zwracana jest wartośćWifiInfo głównego połączenia zapewniającego dostęp do internetu.

Aby zapewnić większą wygodę użytkownikom urządzeń obsługujących 2 jednoczesne sieci Wi-Fi, zalecamy, aby wszystkie aplikacje, zwłaszcza te, które wywołują połączenia typu peer-to-peer, przestały używać funkcji WifiManager.getConnectionInfo(), a zamiast tego korzystały z funkcji NetworkCallback.onCapabilitiesChanged(), aby pobierać wszystkie obiekty WifiInfo pasujące do NetworkRequest używanego do rejestrowania NetworkCallback. Środowisko wykonawcze getConnectionInfo() zostało wycofane w Androidzie 12.

Poniższy przykładowy kod pokazuje, jak uzyskać element WifiInfo w elementzie 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;
    ...
  }
  ...
};

Natywne interfejsy 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. Następnie demon zasubskrybował urządzenie w grupach wielowęzłowych dla wszystkich węzłów, co spowodowało, że system częściej się budził i korzystał z dodatkowej 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 można uzyskać dostęp do dowolnej natywnej biblioteki współdzielonej, niezależnie od tego, czy jest to biblioteka NDK.

Zaktualizowane ograniczenia inne niż związane z pakietem 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 używa interfejsów innych niż SDK, możesz przetestować ją, aby się tego dowiedzieć. Jeśli Twoja aplikacja korzysta z interfejsów spoza pakietu SDK, zaplanuj migrację do alternatywnych pakietów SDK. Zdajemy sobie jednak sprawę, że w niektórych przypadkach interfejsy inne niż SDK mogą być przydatne. 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.