Zmiany w działaniu: aplikacje kierowane na Androida 12

Podobnie jak w przypadku wcześniejszych wersji Androida, w Androidzie 12 wprowadziliśmy zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany dotyczą wyłącznie aplikacji kierowanych na Androida 12 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 12, zmodyfikuj ją tak, aby w odpowiednich przypadkach prawidłowo obsługiwała te zachowania.

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

Interfejs użytkownika

Niestandardowe powiadomienia

Android 12 zmienia wygląd i działanie w pełni niestandardowych powiadomień. Wcześniej powiadomienia niestandardowe mogły zajmować cały obszar powiadomień i mieć własne układy oraz style. Powodowało to powstawanie antypatternów, 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 na Androida 12 powiadomienia z niestandardowymi widokami treści nie będą już zajmować całego obszaru powiadomień. Zamiast tego system zastosuje standardowy szablon. Ten szablon zapewnia, że powiadomienia niestandardowe mają takie same elementy dekoracyjne jak inne powiadomienia we wszystkich stanach, np. ikona powiadomienia i możliwość rozwinięcia (w stanie zwiniętym) oraz ikona powiadomienia, nazwa aplikacji i możliwość zwinięcia (w stanie rozwiniętym). Działanie to jest niemal identyczne z działaniem Notification.DecoratedCustomViewStyle.

Dzięki temu wszystkie powiadomienia w Androidzie 12 są spójne wizualnie i łatwe do przejrzenia, a użytkownicy mogą je rozwijać w znany sobie sposób.

Ilustracja poniżej przedstawia powiadomienie niestandardowe w szablonie standardowym:

Poniższe przykłady pokazują, jak powiadomienia niestandardowe będą wyświetlane w stanie zwiniętym i rozwiniętym:

Zmiana w Androidzie 12 wpływa 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 używa w pełni niestandardowych powiadomień, zalecamy jak najszybsze przetestowanie nowego szablonu.

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

    1. Zmień wartość targetSdkVersion na S, aby włączyć nowe zachowanie.
    2. Ponownie skompiluj.
    3. Zainstaluj aplikację na urządzeniu lub emulatorze z Androidem 12.
  2. Przetestuj wszystkie powiadomienia, które korzystają z widoków niestandardowych, aby upewnić się, że wyglądają w panelu powiadomień zgodnie z Twoimi oczekiwaniami. Podczas testowania weź pod uwagę te kwestie i wprowadź niezbędne zmiany:

    • Wymiary widoków niestandardowych uległy zmianie. Ogólnie wysokość przydzielana powiadomieniom niestandardowym jest mniejsza niż wcześniej. W stanie zwiniętym maksymalna wysokość treści niestandardowych zmniejszyła się ze 106 dp do 48 dp. Jest też mniej miejsca w poziomie.

    • Wszystkie powiadomienia w aplikacjach kierowanych na Androida 12 można rozwijać. Zwykle oznacza to, że jeśli używasz setCustomContentView, musisz też używać setBigCustomContentView, aby mieć pewność, że stany zwinięty i rozwinięty są spójne.

    • Aby stan „Podnieś głowę” wyglądał zgodnie z oczekiwaniami, nie zapomnij ustawić ważności kanału powiadomień na „WYSOKA” (wyskakuje na ekranie).

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ść linków do aplikacji i dają deweloperom aplikacji oraz użytkownikom większą kontrolę.

Jeśli do otwierania linków internetowych w aplikacji używasz weryfikacji linków do aplikacji na Androida, sprawdź, czy podczas dodawania filtrów intencji na potrzeby weryfikacji linków do aplikacji na Androida używasz prawidłowego formatu. Sprawdź w szczególności, czy filtry intencji zawierają kategorię BROWSABLE i obsługują schemat https.

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

Ulepszenia działania obrazu w obrazie

Android 12 wprowadza ulepszenia działania trybu obrazu w obrazie oraz zalecane zmiany wizualne w animacjach przejść w przypadku nawigacji gestami i nawigacji opartej na elementach.

Więcej informacji znajdziesz w sekcji Ulepszenia trybu obraz w obrazie.

Nowy wygląd toastu

W Androidzie 12 widok toast został przeprojektowany. Wiadomości typu toast są teraz ograniczone do 2 wierszy tekstu i wyświetlają ikonę aplikacji obok tekstu.

Obraz urządzenia z Androidem z wyskakującym powiadomieniem z tekstem „Wysyłanie wiadomości” obok ikony aplikacji.

Więcej informacji znajdziesz w omówieniu 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 przypadku Twojej aplikacji.

Nowoczesne pliki cookie SameSite w WebView

Komponent WebView na Androidzie jest oparty na Chromium, czyli projekcie open source, który jest podstawą przeglądarki Google Chrome. Chromium wprowadził zmiany w obsłudze plików cookie innych firm, aby zapewnić większe bezpieczeństwo i prywatność oraz większą przejrzystość i kontrolę dla użytkowników. Od Androida 12 te zmiany są też uwzględniane w WebView, gdy aplikacje są kierowane na Androida 12 (API na poziomie 31) lub nowszego.

Atrybut SameSite pliku cookie określa, czy może on być wysyłany z dowolnymi żądaniami, czy tylko z żądaniami pochodzącymi z tej samej witryny. Poniższe zmiany dotyczące ochrony prywatności poprawiają domyślne działanie plików cookie innych firm i pomagają 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ż określać atrybut Secure, co oznacza, że wymagają bezpiecznego kontekstu i powinny być wysyłane przez HTTPS.
  • Linki między wersjami witryny HTTP i HTTPS są teraz traktowane jako żądania z innej witryny, więc pliki cookie nie są wysyłane, chyba że są odpowiednio oznaczone jako SameSite=None; Secure.

Ogólne wytyczne dla deweloperów to zidentyfikowanie w kluczowych ścieżkach użytkownika zależności od plików cookie innych witryn i zapewnienie, że w razie potrzeby atrybut SameSite zostanie wyraźnie ustawiony z odpowiednimi wartościami. Musisz wyraźnie określić pliki cookie, które mogą działać w różnych witrynach lub w przypadku nawigacji w tej samej witrynie, która przechodzi z HTTP na HTTPS.

Pełne wytyczne dla deweloperów stron internetowych dotyczące tych zmian znajdziesz w artykułach SameSite Cookies ExplainedSchemeful SameSite.

Testowanie zachowań SameSite w aplikacji

Jeśli Twoja aplikacja korzysta z komponentu WebView lub zarządzasz witryną bądź usługą, która używa plików cookie, zalecamy przetestowanie przepływów w komponencie WebView na Androidzie 12. Jeśli wykryjesz problemy, może być konieczne zaktualizowanie plików cookie, aby obsługiwały nowe zachowania atrybutu SameSite.

Zwróć uwagę na problemy z logowaniem i osadzonymi treściami, a także na procesy logowania, zakupu i inne procesy uwierzytelniania, w których użytkownik zaczyna od niezabezpieczonej strony i przechodzi na stronę zabezpieczoną.

Aby przetestować aplikację z WebView, musisz włączyć w niej nowe zachowania SameSite. Możesz to zrobić, wykonując jedną z tych czynności:

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

Inne materiały

Więcej informacji o nowoczesnych zachowaniach SameSite i wdrażaniu ich w Chrome i WebView znajdziesz na stronie aktualizacji Chromium SameSite. Jeśli znajdziesz błąd w WebView lub Chromium, możesz go zgłosić w publicznym trackerze problemów Chromium.

Czujniki ruchu mają ograniczone możliwości

Aby chronić potencjalnie poufne informacje o użytkownikach, w przypadku aplikacji kierowanych na Androida 12 lub nowszego system ogranicza częstotliwość odświeżania danych z niektórych czujników ruchu i czujników położenia.

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

Hibernacja aplikacji

Android 12 rozszerza automatyczne resetowanie uprawnień, które zostało wprowadzone w Androidzie 11 (poziom API 30). Jeśli Twoja aplikacja jest przeznaczona na Androida 12, a użytkownik nie korzysta z niej przez kilka miesięcy, system automatycznie resetuje przyznane uprawnienia i przenosi aplikację w stan hibernacji.

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

Deklaracja atrybucji w ramach sprawdzania dostępu do danych

Interfejs Data Access Auditing API, 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ślonego typu danych.

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

Ograniczenie tworzenia kopii zapasowej za pomocą ADB

Aby chronić dane aplikacji prywatnych, 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 wszelkich innych danych systemowych eksportowanych z urządzenia.

Jeśli w procesach testowania lub tworzenia aplikacji korzystasz z danych aplikacji, możesz teraz włączyć eksportowanie danych aplikacji, ustawiając wartość android:debuggable na true w pliku manifestu aplikacji.adb backup

Bezpieczniejsze eksportowanie komponentów

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

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

Poniższy fragment kodu pokazuje przykład usługi, która zawiera filtr intencji z atrybutem android:exported ustawionym 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 Twoja aplikacja zawiera aktywność, usługę lub odbiornik, który używa filtrów intencji, ale nie deklaruje android:exported, w zależności od wersji Androida Studio wyświetlą się te komunikaty ostrzegawcze:

Android Studio 2020.3.1 Canary 11 lub nowsza wersja

Pojawią się te komunikaty:

  1. W pliku manifestu pojawia się to ostrzeżenie narzędzia lint:

    When using intent filters, please specify android:exported as well
    
  2. Podczas próby skompilowania aplikacji pojawi 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ść intencji oczekujących

Jeśli Twoja aplikacja jest kierowana na Androida 12, musisz określić zmienność każdego obiektu PendingIntent tworzonego przez aplikację. 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 narzędzia lint:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Uruchamianie niebezpiecznych intencji

Aby zwiększyć bezpieczeństwo platformy, Android 12 i nowsze wersje udostępniają funkcję debugowania, która wykrywa niebezpieczne uruchomienia intencji. Gdy system wykryje takie niebezpieczne uruchomienie, nastąpi naruszenie trybu ścisłego.

Wydajność

Ograniczenia dotyczące uruchamiania usług na pierwszym planie

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

Rozważ użycie WorkManagera do planowania i uruchamiania przyspieszonych zadań, gdy aplikacja działa w tle. Aby wykonać działania wymagające natychmiastowej reakcji, o które prosi użytkownik, 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, które są przeznaczone na Androida 12 lub nowszego i ustawiają dokładne alarmy, muszą mieć dostęp do funkcji „Alarmy i przypomnienia”, która pojawia się na ekranie Specjalny dostęp aplikacji w ustawieniach systemu.

Aby uzyskać ten specjalny dostęp do aplikacji, poproś o uprawnienie SCHEDULE_EXACT_ALARM w pliku manifestu.

Dokładne alarmy powinny być używane tylko w przypadku funkcji widocznych dla użytkownika. Dowiedz się więcej o dopuszczalnych przypadkach użycia ustawiania dokładnego alarmu.

Wyłączanie zmiany działania

Podczas przygotowywania aplikacji do działania na Androidzie 12 możesz tymczasowo wyłączyć zmianę w zachowaniu w wersji do debugowania na potrzeby testów. Aby to zrobić, wykonaj jedno z tych zadań:

  • Na ekranie ustawień Opcje programisty wybierz Zmiany w zakresie zgodności aplikacji. Na ekranie, który się pojawi, kliknij nazwę aplikacji, a potem wyłącz 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 trampolin powiadomień

Gdy użytkownicy wchodzą w interakcję z powiadomieniami, niektóre aplikacje reagują na kliknięcia powiadomień, uruchamiając komponent aplikacji, który ostatecznie rozpoczyna działanie, które użytkownik widzi i z którym wchodzi w interakcję. Ten komponent aplikacji jest znany jako trampolina powiadomień.

Aby poprawić wydajność aplikacji i UX, aplikacje kierowane na Androida 12 lub nowszego nie mogą uruchamiać aktywności z usług ani odbiorników transmisji, które są używane jako trampoliny powiadomień. Innymi słowy, po kliknięciu przez użytkownika powiadomienia lub przycisku działania w powiadomieniu aplikacja nie może wywoływać funkcji startActivity() w usłudze ani w odbiorniku transmisji.

Gdy aplikacja spróbuje uruchomić aktywność z usługi lub odbiornika transmisji, który działa jako trampolina powiadomień, system uniemożliwi uruchomienie aktywności, a w Logcat pojawi 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óra usługa lub odbiornik transmisji działał w niej jako trampolina powiadomień. Aby to zrobić, sprawdź dane wyjściowe tego polecenia w terminalu:

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

Fragment danych wyjściowych zawiera tekst „NotifInteractionLog”. Ta sekcja zawiera informacje niezbędne do zidentyfikowania komponentu, który uruchamia się w wyniku kliknięcia 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 migracji:

  1. Utwórz obiekt PendingIntent, który jest powiązany z aktywnością widoczną dla użytkowników po kliknięciu powiadomienia.
  2. Użyj obiektu PendingIntent utworzonego w poprzednim kroku w ramach tworzenia powiadomienia.

Aby określić źródło aktywności, np. w celu rejestrowania zdarzeń, podczas publikowania powiadomienia używaj dodatkowych informacji. W przypadku scentralizowanego logowania użyj ActivityLifecycleCallbacks lub obserwatorów cyklu życia Jetpack.

Przełączanie działania

Podczas testowania wersji aplikacji z możliwością debugowania możesz włączać i wyłączać to ograniczenie za pomocą NOTIFICATION_TRAMPOLINE_BLOCKflagi zgodności aplikacji.

tworzenie i przywracanie kopii zapasowej;

W przypadku aplikacji działających na Androidzie 12 (poziom API 31) i kierowanych na ten system zmienił się sposób działania kopii zapasowych i przywracania. Tworzenie i przywracanie kopii zapasowej na Androidzie ma 2 formy:

  • Kopie zapasowe w chmurze: dane użytkownika są przechowywane na jego Dysku Google, dzięki czemu można je później przywrócić na tym samym lub nowym urządzeniu.
  • Przenoszenie danych z urządzenia na urządzenie: dane użytkownika są przesyłane bezpośrednio ze starszego urządzenia na nowe, 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 zapasowejTworzenie kopii zapasowej par klucz-wartość za pomocą usługi Android Backup Service.

Zmiany w funkcji przesyłania danych z urządzenia na urządzenie

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

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

  • Na urządzeniach niektórych producentów określenie android:allowBackup="false" wyłącza tworzenie kopii zapasowych na Dysku Google, ale nie wyłącza przesyłania danych z urządzenia na urządzenie w przypadku aplikacji.

Nowy format uwzględniania i wykluczania

Aplikacje działające na Androidzie 12 i nowszym oraz kierowane na te wersje systemu operacyjnego używają innego formatu konfiguracji XML. Ten format wyraźnie rozróżnia kopię zapasową na Dysku Google i przenoszenie danych z urządzenia na urządzenie, ponieważ wymaga oddzielnego określenia reguł uwzględniania i wykluczania dla kopii zapasowych w chmurze i przenoszenia danych z urządzenia na urządzenie.

Opcjonalnie możesz też użyć go do określania reguł tworzenia kopii zapasowych. W takim przypadku wcześniej używana konfiguracja jest ignorowana na urządzeniach z Androidem 12 lub nowszym. Starsza konfiguracja jest nadal wymagana na urządzeniach z Androidem 11 lub starszym.

Zmiany w formacie XML

W Androidzie 11 i starszych wersjach do konfiguracji tworzenia i przywracania kopii zapasowych używany jest ten format:

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

Zmiany w formacie są pogrubione.

<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 przewodnika dotyczącego tworzenia kopii zapasowych danych użytkownika za pomocą automatycznej kopii zapasowej.

Flaga w pliku manifestu aplikacji

Skieruj aplikacje do nowego pliku konfiguracji XML, używając atrybutu android:dataExtractionRules w pliku manifestu. Gdy wskażesz nowy plik konfiguracji XML, atrybut android:fullBackupContent wskazujący starą konfigurację zostanie zignorowany 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

W Androidzie 12 wprowadzono uprawnienia BLUETOOTH_SCAN, BLUETOOTH_ADVERTISEBLUETOOTH_CONNECT. Te uprawnienia ułatwiają aplikacjom przeznaczonym na Androida 12 interakcję z urządzeniami Bluetooth, zwłaszcza tym, 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ń Bluetooth.

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

W przypadku aplikacji kierowanych na Androida 12 (API na poziomie 31) lub nowszego urządzenia obsługujące jednoczesne połączenia peer-to-peer i internetowe mogą utrzymywać równoczesne połączenia Wi-Fi z urządzeniem peer-to-peer i główną siecią zapewniającą dostęp do internetu, co zwiększa komfort użytkownika. Aplikacje kierowane na Androida 11 (API na poziomie 30) lub starszego nadal działają w starszy sposób, czyli przed połączeniem z urządzeniem równorzędnym odłączają się od głównej sieci Wi-Fi.

Zgodność

WifiManager.getConnectionInfo() może zwrócić WifiInfo tylko w przypadku jednej sieci. Z tego powodu w Androidzie 12 i nowszych wersjach systemu zmieniliśmy działanie interfejsu API w ten sposób:

  • Jeśli dostępna jest tylko jedna sieć Wi-Fi, zwracany jest jej identyfikator WifiInfo.
  • Jeśli dostępnych jest więcej niż 1 sieć Wi-Fi, a aplikacja do połączeń zainicjowała połączenie peer-to-peer, zwracany jest identyfikator WifiInfo odpowiadający urządzeniu peer.
  • Jeśli dostępnych jest więcej niż jedna sieć Wi-Fi, a aplikacja do połączeń nie wywołała połączenia peer-to-peer, zwracane jest WifiInfo główne połączenie zapewniające dostęp do internetu.

Aby zapewnić lepsze wrażenia użytkownikom urządzeń obsługujących 2 jednoczesne sieci Wi-Fi, zalecamy, aby wszystkie aplikacje, zwłaszcza te, które inicjują połączenia peer-to-peer, przestały wywoływać funkcję WifiManager.getConnectionInfo() i zamiast tego używały funkcji NetworkCallback.onCapabilitiesChanged() do pobierania wszystkich obiektów WifiInfo pasujących do funkcji NetworkRequest użytej do rejestracji funkcji NetworkCallback. getConnectionInfo() zostało wycofane w Androidzie 12.

Poniższy przykładowy kod pokazuje, jak uzyskać WifiInfoNetworkCallback:

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 zmieniliśmy sposób, w jaki 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 multiemisji wszystkich węzłów, co spowodowało częstsze wybudzanie systemu i większe zużycie energii. Aby zminimalizować zużycie baterii, w Androidzie 12 i nowszych system uruchamia demona mDNSResponder tylko wtedy, gdy jest on potrzebny do obsługi zdarzeń NSD, a następnie go zatrzymuje.

Ponieważ ta zmiana wpływa na dostępność demona mDNSResponder, aplikacje, które zakładają, że demon mDNSResponder zostanie uruchomiony po wywołaniu metody getSystemService(), mogą otrzymywać z systemu komunikaty o niedostępności demona mDNSResponder. Zmiana nie dotyczy aplikacji, które korzystają z NsdManager i nie używają natywnego interfejsu API mDNSResponder.

Biblioteki dostawców

Biblioteki natywne udostępnione przez dostawcę

Natywne biblioteki współdzielone inne niż NDK dostarczane przez producentów krzemu lub urządzeń są domyślnie niedostępne dla aplikacji kierowanych na Androida 12 (poziom interfejsu API 31) lub nowszego. Biblioteki są dostępne tylko wtedy, gdy są wyraźnie wymagane za pomocą tagu <uses-native-library>.

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

Zaktualizowane ograniczenia dotyczące interfejsów API innych niż SDK

Android 12 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK, które powstały na podstawie współpracy z programistami Androida i najnowszych testów wewnętrznych. W miarę możliwości przed ograniczeniem interfejsów innych niż SDK udostępniamy publiczne alternatywy.

Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą nie mieć na nią natychmiastowego wpływu. Obecnie możesz używać niektórych interfejsów spoza SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z dowolnej metody lub pola spoza 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 to sprawdzić, testując ją. Jeśli Twoja aplikacja korzysta z interfejsów spoza SDK, zacznij planować migrację na alternatywne rozwiązania SDK. Rozumiemy jednak, że w przypadku niektórych aplikacji używanie interfejsów innych niż SDK jest uzasadnione. Jeśli nie możesz znaleźć alternatywy dla używania interfejsu innego niż SDK w przypadku funkcji w aplikacji, poproś o nowy publiczny interfejs API.

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