Zmiany w działaniu: aplikacje kierowane na Androida 12

Podobnie jak w poprzednich wersjach Android 12 obejmuje zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą tylko 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 na Androidzie 12.

Z perspektywy 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. Powstały dzięki temu antywzorce, które mogą 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ż korzystać z pełnego obszaru powiadomień. Zamiast tego system zastosuje szablon standardowy. Ten szablon zapewnia, że powiadomienia niestandardowe będą miały takie same dekoracje jak pozostałe powiadomienia we wszystkich stanach, np. ikonę powiadomienia i przywiązania rozwinięcia (w stanie zwiniętym) oraz ikonę powiadomienia, nazwę aplikacji i afordancję zwijania (w stanie rozwinięcia). Działa to prawie tak samo jak Notification.DecoratedCustomViewStyle.

W ten sposób Android 12 sprawia, że wszystkie powiadomienia są spójne wizualnie i łatwe do przeskanowania. Rozszerzenie powiadomień jest widoczne 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 stanie zwiniętym i rozwiniętym:

Zmiana w Androidzie 12 wpływa na aplikacje, które definiują niestandardowe podklasy obiektu Notification.Style lub korzystają z metod Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) i setCustomHeadsUpContentView(RemoteViews).

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

  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, upewniając się, że wyglądają w cieniu tak, jak chcesz. Podczas testowania bierz pod uwagę te kwestie i wprowadź niezbędne korekty:

    • Zmieniły się wymiary widoków niestandardowych. Powiadomienia niestandardowe są zazwyczaj niższe niż do tej pory. W stanie zwiniętym maksymalna wysokość treści niestandardowej 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. 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 funkcji Uważaj na przejściu jest zgodny z oczekiwaniami, nie zapomnij zwiększyć znaczenia kanału powiadomień do poziomu „WYSOKIEGO” (wyświetla się na ekranie).

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 oraz zapewniają większą kontrolę deweloperom aplikacji i użytkownikom.

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. W szczególności sprawdź, czy te filtry intencji zawierają kategorię BROWSABLE i obsługują schemat https.

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

Ulepszone działanie obrazu w obrazie

Android 12 wprowadza ulepszenia działania trybu obraz w obrazie oraz zalecane kosmetyczne ulepszenia animacji przejścia zarówno w przypadku nawigacji przy użyciu 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 są teraz ograniczone do dwóch wierszy tekstu i wyświetlają obok tekstu 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 podanie przybliżonej lokalizacji aplikacji.

Nowoczesne pliki cookie SameSite w komponencie WebView

Komponent WebView Androida jest oparty na Chromium – projekcie typu open source, który działa w przeglądarce 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 jak 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.

Ogólnie rzecz biorąc, deweloperzy powinni zidentyfikować zależności plików cookie pochodzących z różnych witryn w kluczowych przepływach użytkowników i upewnić się, że atrybut SameSite ma w razie potrzeby odpowiednie wartości. 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.

Przetestuj zachowanie SameSite w swojej aplikacji

Jeśli Twoja aplikacja używa WebView albo zarządzasz witryną lub usługą, która korzysta z plików cookie, zalecamy przetestowanie przepływów w komponencie WebView Androida 12. Jeśli napotkasz problemy, konieczne może być zaktualizowanie plików cookie pod kątem nowego sposobu działania SameSite.

Zwróć uwagę na problemy z logowaniem i umieszczoną treścią, a także z procesami logowania, zakupami i innymi procesami uwierzytelniania, podczas których użytkownik zaczyna od niezabezpieczonej strony i przechodzi na stronę bezpieczną.

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 nowoczesnych działaniach SameSite i ich wdrażaniu w Chrome i komponencie WebView znajdziesz na stronie z informacjami o aktualizacji funkcji SameSite w Chromium. Jeśli znajdziesz błąd w komponencie WebView lub Chromium, możesz go zgłosić w publicznym narzędziu do śledzenia problemów z Chromium.

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

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 będzie z niej korzystać przez kilka miesięcy, system automatycznie resetuje przyznane uprawnienia i wprowadza 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 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 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ę, 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ść 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 oczekującej zmiany zmienności intencji

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

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

Rozważ użycie WorkManagera do planowania i rozpoczynania pracy przyspieszonej, gdy aplikacja działa w tle. Aby wykonać pilne działania użytkownika, uruchom usługi na pierwszym planie z poziomu dokładnie takiego alarmu.

Uprawnienie dostępu do precyzyjnych alarmów

Aby zachęcać aplikacje do oszczędzania zasobów systemu, aplikacje kierowane na Androida 12 lub nowszego i ustawiające precyzyjne alarmy muszą mieć dostęp do funkcji „Alarmy i przypomnienia”, która jest widoczna na ekranie Specjalny dostęp aplikacji w ustawieniach systemu.

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

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

Wyłącz zmianę działania

Przygotowując aplikację do kierowania na Androida 12, możesz tymczasowo wyłączyć zmianę działania w możliwym do debugowania wariant kompilacji na potrzeby testów. Aby to zrobić, wykonaj jedno z tych zadań:

  • Na ekranie ustawień Opcje programisty wybierz Zmiany zgodności aplikacji. Na ekranie, który się pojawi, kliknij nazwę aplikacji i wyłącz 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 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. Oznacza to, że gdy użytkownik kliknie powiadomienie lub przycisk polecenia w powiadomieniu, aplikacja nie będzie mogła wywołać startActivity() wewnątrz usługi lub odbiornika.

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óra usługa lub odbiornik pełniący funkcję trampoliny powiadomień w aplikacji. Aby to zrobić, spójrz na dane wyjściowe tego polecenia w terminalu:

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 powiązany z aktywnością, którą użytkownicy zobaczą po kliknięciu powiadomienia.
  2. Użyj obiektu PendingIntent utworzonego w poprzednim kroku w ramach tworzenia powiadomienia.

Aby zidentyfikować pochodzenie działania, na przykład włączyć rejestrowanie, przy publikowaniu powiadomienia używaj dodatków. Do scentralizowanego logowania używaj funkcji ActivityLifecycleCallbacks lub obserwatorów cyklu życia Jetpacka.

Przełącz działanie

Jeśli testujesz wersję aplikacji możliwą do debugowania, możesz włączać i wyłączać to ograniczenie 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 działających na Androidzie 12 (poziom interfejsu API 31) i nastawionych na nie. Tworzenie i przywracanie kopii zapasowej Androida ma 2 formy:

  • Kopie zapasowe w chmurze: dane użytkownika są przechowywane na Dysku Google użytkownika, aby można było je później przywrócić na tym 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

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

  • Wskazywanie reguł uwzględniających i wykluczonych za pomocą mechanizmu konfiguracji XML nie ma wpływu na transfery D2D, ale nadal wpływa na tworzenie i przywracanie kopii zapasowych 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 określenie android:allowBackup="false" wyłącza tworzenie kopii zapasowych na Dysku Google, ale nie wyłącza przenoszenia danych D2D dla 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 go też używać do określania reguł kopii zapasowej. W takim przypadku wcześniej używana konfiguracja będzie ignorowana na urządzeniach z Androidem 12 lub nowszym. Starsza konfiguracja jest nadal wymagana na urządzeniach z Androidem 11 lub starszym.

Zmiany formatu 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 przewodnika po tworzeniu kopii zapasowych danych użytkowników przy użyciu Automatycznej kopii zapasowej.

Flaga pliku manifestu w przypadku aplikacji

Skieruj swoje aplikacje do nowej konfiguracji XML, używając atrybutu android:dataExtractionRules w pliku manifestu. Gdy wskazujesz nową konfigurację XML, atrybut android:fullBackupContent wskazujący 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>

Połączenia

Uprawnienia Bluetooth

Android 12 wprowadza uprawnienia BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE i BLUETOOTH_CONNECT. Te uprawnienia ułatwiają aplikacjom 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ń dotyczących Bluetootha, zadeklaruj nowocześniejszy zestaw uprawnień dotyczących Bluetootha.

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 internet, mogą utrzymywać jednoczesne połączenia Wi-Fi zarówno z urządzeniem równorzędnym, jak i z 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ć zapytanie 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 dostępnych jest więcej sieci Wi-Fi, a aplikacja do połączeń uruchomiła połączenie peer-to-peer, zwrócony zostanie interfejs WifiInfo odpowiadający urządzeniu peer-to-peer.
  • Jeśli jest dostępna więcej niż 1 sieć Wi-Fi, a aplikacja do rozmów 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. Interfejs getConnectionInfo() został wycofany 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 API mDNSResponder. Wcześniej, gdy aplikacja rejestrowała usługę w sieci i wywołała metodę getSystemService(), systemowa usługa NSD uruchamiała demona mDNSResponder, nawet jeśli aplikacja nie wywołała jeszcze żadnych metod NsdManager. Demon zasubskrybował urządzenie w grupach multicast ze wszystkimi węzłami, dzięki czemu system częściej się wybudzał i korzystał z dodatkowej energii. Aby zminimalizować wykorzystanie baterii, w Androidzie 12 i nowszych system uruchamia demona mDNSResponder tylko wtedy, gdy jest to potrzebne do wystąpienia zdarzeń NSD, i zatrzymuje go później.

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, że demon mDNSResponder jest niedostępny. Ta zmiana nie ma wpływu na aplikacje, które używają interfejsu NsdManager i nie używają natywnego interfejsu API mDNSResponder.

Biblioteki dostawców

Natywne biblioteki udostępnione dostarczone przez dostawcę

Natywne biblioteki udostępnione inne niż NDK udostępniane przez dostawców krzemu lub producentów urządzeń nie są domyślnie dostępne, jeśli aplikacja jest kierowana na Androida 12 (poziom interfejsu API 31) lub nowszego. Biblioteki są dostępne tylko wtedy, gdy żądanie zostanie wysłane jednoznacznie za pomocą tagu <uses-native-library>.

Jeśli aplikacja jest kierowana na Androida 11 (poziom interfejsu API 30) lub starszego, 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 pakietu SDK

Android 12 zawiera zaktualizowane listy ograniczonych interfejsów spoza pakietu SDK utworzone na podstawie współpracy z deweloperami aplikacji na Androida i najnowszych testów wewnętrznych. W miarę możliwości dbamy o to, aby dostępne były publiczne alternatywy, zanim ograniczymy dostęp do interfejsów innych niż SDK.

Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą nie od razu Cię dotyczyć. Mimo że obecnie można korzystać z niektórych interfejsów innych niż SDK (w zależności od docelowego poziomu interfejsu API aplikacji), użycie dowolnej metody lub pola spoza pakietu SDK zawsze wiąże się z dużym ryzykiem uszkodzenia 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źć w swojej aplikacji interfejsu innego niż interfejs SDK, musisz poprosić o nowy publiczny interfejs API.

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