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, 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 korzystać z całego obszaru powiadomień oraz mieć własne układy i 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 prawie 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.

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) i setCustomHeadsUpContentView(RemoteViews).

Jeśli Twoja aplikacja używa powiadomień całkowicie niestandardowych, 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ń 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 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 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 w aplikacji, aby sprawdzić wiarygodność deklaracji.

Ulepszenia zachowania 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 zmieniliśmy wygląd widoku ekranu. Komunikaty są teraz ograniczone do dwóch wierszy tekstu i wyświetlają obok tekstu 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.

Uwaga: w niektórych wersjach Androida 12 ta zmiana zawsze dotyczy aplikacji niezależnie od docelowej wersji pakietu SDK.

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. 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. 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 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 witrynach lub w przypadku przechodzenia z HTTP na HTTPS w ramach tej samej witryny.

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ę na Androida 12 (poziom API 31) za pomocą targetSdkVersion.

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

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 położenia.

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 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 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 tworzenia aplikacji korzystają z danych aplikacji za pomocą adb backup, możesz teraz włączyć eksportowanie danych aplikacji, ustawiając w pliku manifestu aplikacji wartość android:debuggable na true.

Uwaga: aby chronić dane aplikacji, przed jej opublikowaniem ustaw wartość android:debuggable na false.

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.

Ostrzeżenie: jeśli działanie, usługa lub odbiornik używa filtrów intencji i nie ma wyraźnie zadeklarowanej wartości dla parametru android:exported, Twojej aplikacji nie można zainstalować na urządzeniu z Androidem 12 lub nowszym.

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Uruchomienia 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, dochodzi do naruszenia StrictMode.

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ąpi wyjątek (z wyjątkiem kilku szczególnych przypadków).

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łączanie zmiany zachowania

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

Uwaga: chociaż aplikacje z SYSTEM_ALERT_WINDOWzezwoleniem na uruchamianie działań za pomocą trampoliny powiadomień nadal mogą to robić, należy unikać tego wzorca UX i zamiast tego użyć PendingIntent.

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

Część 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ść 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 przenoszenia danych D2D

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

• Określenie 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 dotyczące 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ą 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 w wersji 12 lub nowszej poprzednio używana konfiguracja jest ignorowana. Starsza konfiguracja jest nadal wymagana na urządzeniach z Androidem 11 lub starszym.

Uwaga: jeśli używasz nowego formatu konfiguracji, aplikacja będzie działać zgodnie z nowymi zasadami na urządzeniu z Androidem 12 lub nowszym, nawet jeśli nie kierujesz jej na tę wersję.

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 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 wskazujący 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.

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ą 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 typu 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. 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 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

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 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 wymaga interfejsów innych niż SDK, zacznij planować migrację na alternatywne wersje 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źć w swojej aplikacji interfejsu innego niż interfejs SDK, musisz poprosić 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.