Podobnie jak w przypadku poprzednich wersji Androida, w Androidzie 12 wprowadziliśmy zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wyłącznie aplikacji kierowanych na Androida 12 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 12, zmodyfikuj ją, aby w odpowiednich przypadkach prawidłowo obsługiwała te działania.
Zapoznaj się też z listą zmian w działaniu, które wpływają na wszystkie aplikacje działające na Androidzie 12.
Interfejs użytkownika
Niestandardowe powiadomienia
Android 12 zmienia wygląd i działanie w pełni niestandardowych powiadomień. Wcześniej powiadomienia niestandardowe mogły korzystać z całego obszaru powiadomień i miały własne układy i style. Prowadziło to do powstawania antywzorców, które mogły dezorientować użytkowników lub powodować problemy ze zgodnością układu na różnych urządzeniach.
W przypadku aplikacji kierowanych na Androida 12 powiadomienia z niestandardowymi widokami treści nie będą już używać całego obszaru powiadomień. Zamiast tego system zastosuje szablon standardowy. Ten szablon zapewnia, że powiadomienia niestandardowe mają takie same elementy dekoracyjne jak inne powiadomienia we wszystkich stanach, np. ikonę powiadomienia i elementy umożliwiające rozwinięcie (w stanie zwiniętym) oraz ikonę powiadomienia, nazwę aplikacji i element umożliwiający zwinięcie (w stanie rozwiniętym). Działa to niemal identycznie jak Notification.DecoratedCustomViewStyle.
Dzięki temu w Androidzie 12 wszystkie powiadomienia są spójne wizualnie i łatwe do przejrzenia, a użytkownicy mogą je łatwo rozwijać.
Poniższa ilustracja przedstawia powiadomienie niestandardowe 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 dotyczy aplikacji, które definiują niestandardowe podklasy Notification.Style lub używają metod setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) i setCustomHeadsUpContentView(RemoteViews) klasy Notification.Builder.
Jeśli Twoja aplikacja używa w pełni niestandardowych powiadomień, zalecamy jak najszybsze przetestowanie nowego szablonu.
Włącz zmianę powiadomień niestandardowych:
- Aby włączyć nowe zachowanie, zmień
targetSdkVersionaplikacji naS. - Skompiluj ponownie.
- Zainstaluj aplikację na urządzeniu lub emulatorze z Androidem 12.
- Aby włączyć nowe zachowanie, zmień
Przetestuj wszystkie powiadomienia, które korzystają z widoków niestandardowych, aby upewnić się, że wyglądają tak, jak oczekujesz. Podczas testowania weź pod uwagę te kwestie i wprowadź niezbędne zmiany:
Wymiary widoków niestandardowych uległy zmianie. Ogólnie wysokość powiadomień niestandardowych jest mniejsza niż wcześniej. W stanie zwiniętym maksymalna wysokość treści niestandardowych została zmniejszona ze 106 dp do 48 dp. Jest też mniej miejsca w poziomie.
W przypadku aplikacji kierowanych na Androida 12 wszystkie powiadomienia można rozwijać. Zwykle oznacza to, że jeśli używasz
setCustomContentView, warto też użyćsetBigCustomContentView, aby mieć pewność, że stany zwinięty i rozwinięty są spójne.Aby upewnić się, że stan „Powiadomienie” wygląda zgodnie z oczekiwaniami, nie zapomnij podnieść ważności kanału powiadomień do „WYSOKA” (Pojawia się na ekranie).
Zmiany dotyczące weryfikacji linków aplikacji na Androida
W aplikacjach kierowanych na Androida 12 lub nowszego system wprowadza kilka zmian w sposobie weryfikacji linków do aplikacji na Androida. Te zmiany zwiększają niezawodność linkowania aplikacji i zapewniają 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. Upewnij się, że te filtry intencji zawierają kategorię BROWSABLE i obsługują schemat https.
Możesz też ręcznie zweryfikować linki aplikacji, aby sprawdzić wiarygodność deklaracji.
Ulepszenia działania funkcji obraz w obrazie
Android 12 wprowadza ulepszenia działania trybu obrazu w obrazie (PiP) oraz zalecane ulepszenia wizualne 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 Ulepszenia funkcji obraz w obrazie.
Nowy wygląd powiadomień
W Androidzie 12 widok powiadomienia został przeprojektowany. Powiadomienia są teraz ograniczone do 2 wierszy tekstu i zawierają ikonę aplikacji obok tekstu.
Więcej informacji znajdziesz w artykule Omówienie powiadomień typu toast.
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 z atrybutem SameSite w komponencie WebView
Komponent WebView na Androidzie jest oparty na Chromium, projekcie open source, który stanowi podstawę przeglądarki Google Chrome. W Chromium wprowadziliśmy zmiany w obsłudze plików cookie innych firm, aby zapewnić większe bezpieczeństwo i prywatność oraz zaoferować użytkownikom większą przejrzystość i kontrolę. 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 z tej samej witryny. Te zmiany dotyczące ochrony prywatności ulepszają domyślne działanie plików cookie innych firm i pomagają chronić przed niezamierzonym udostępnianiem danych między witrynami:
- Pliki cookie bez atrybutu
SameSitesą traktowane jakoSameSite=Lax. - Pliki cookie z atrybutem
SameSite=Nonemuszą też mieć atrybutSecure, co oznacza, że wymagają bezpiecznego kontekstu i powinny być wysyłane przez HTTPS. - Linki między wersjami HTTP i HTTPS witryny 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.
Deweloperom zalecamy zidentyfikowanie zależności od plików cookie innych firm w krytycznych wzorcach przeglądania i upewnienie się, że atrybut SameSite jest w razie potrzeby 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 ramach nawigacji w tej samej witrynie, która przechodzi z HTTP na HTTPS.
Pełne wskazówki dla programistów stron internetowych dotyczące tych zmian znajdziesz w artykułach SameSite Cookies Explained (Pliki cookie z atrybutem SameSite – wyjaśnienie) i Schemeful SameSite (Pliki cookie z atrybutem SameSite z uwzględnieniem schematu).
Testowanie zachowań SameSite w aplikacji
Jeśli Twoja aplikacja używa komponentu WebView lub zarządzasz witryną bądź usługą, która korzysta z plików cookie, zalecamy przetestowanie przepływów w komponencie WebView na Androidzie 12. Jeśli znajdziesz problemy, może być konieczne zaktualizowanie plików cookie, aby obsługiwały nowe zachowania SameSite.
Zwróć uwagę na problemy z logowaniem i umieszczonymi treściami, a także z procesami logowania, zakupów i innymi procesami uwierzytelniania, w których użytkownik zaczyna od niezabezpieczonej strony i przechodzi na stronę zabezpieczoną.
Aby przetestować aplikację z komponentem WebView, musisz włączyć w niej nowe zachowania SameSite, wykonując jedną z tych czynności:
Ręcznie włącz zachowania SameSite na urządzeniu testowym, przełączając flagę interfejsu webview-enable-modern-cookie-same-site w narzędziach deweloperskich WebView.
To podejście umożliwia testowanie na dowolnym urządzeniu z Androidem 5.0 (poziom interfejsu API 21) lub nowszym – w tym z Androidem 12 – i WebView w wersji 89.0.4385.0 lub nowszej.
Skompiluj aplikację, aby była kierowana na Androida 12 (poziom API 31) do
targetSdkVersion.Jeśli używasz tej metody, musisz mieć urządzenie z Androidem 12.
Informacje o zdalnym debugowaniu WebView na Androidzie znajdziesz w artykule Pierwsze kroki ze zdalnym debugowaniem urządzeń z Androidem.
Inne zasoby
Więcej informacji o nowoczesnych zachowaniach SameSite i wdrażaniu ich w Chrome i WebView znajdziesz na stronie aktualizacji SameSite w Chromium. Jeśli znajdziesz błąd w WebView lub Chromium, możesz go zgłosić w publicznym narzędziu Issue Tracker Chromium.
Czujniki ruchu mają ograniczoną liczbę żądań
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 pozycji.
Dowiedz się więcej o ograniczaniu częstotliwości czujnika.
hibernacja aplikacji
Android 12 rozszerza funkcję automatycznego resetowania uprawnień wprowadzoną 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 resetuje wszystkie przyznane uprawnienia i przełącza aplikację w stan hibernacji.
Więcej informacji znajdziesz w przewodniku na temat hibernacji aplikacji.
Deklaracja atrybucji w ramach sprawdzania dostępu do danych
Interfejs API do sprawdzania 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 wykonuje określony typ dostępu do 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 są wykluczane z innych danych systemowych eksportowanych z urządzenia.
Jeśli Twoje procesy testowania lub programowania opierają się na danych aplikacji korzystających z adb backup, możesz teraz wyrazić zgodę na eksportowanie danych aplikacji, ustawiając 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, 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.
Poniższy 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, który używa filtrów intencji, ale nie deklaruje android:exported, pojawią się te komunikaty ostrzegawcze (w zależności od używanej wersji Android Studio):
Android Studio 2020.3.1 Canary 11 lub nowsza wersja,
Wyświetlą się te komunikaty:
W pliku manifestu pojawi się to ostrzeżenie:
When using intent filters, please specify android:exported as wellGdy 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, który tworzy. To dodatkowe wymaganie zwiększa bezpieczeństwo aplikacji.
Testowanie zmiany zmienności intencji oczekującej
Aby sprawdzić, czy w aplikacji brakuje deklaracji zmienności, poszukaj w Android Studio tego ostrzeżenia linta:
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, występuje naruszenie 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, 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 rozpoczynania prac priorytetowych, gdy aplikacja działa w tle. Aby wykonywać działania, które użytkownik chce przeprowadzić w określonym czasie, uruchamiaj usługi na pierwszym planie w ramach alarmu precyzyjnego.
Uprawnienie dostępu do precyzyjnych alarmów
Aby zachęcić deweloperów do oszczędzania zasobów systemowych, aplikacje kierowane na Androida 12 lub nowszego, które ustawiają alarmy precyzyjne, muszą mieć dostęp do funkcji „Alarmy i przypomnienia” widocznej na ekranie Aplikacje ze specjalnym dostępem w ustawieniach systemowych.
Aby uzyskać ten specjalny dostęp do aplikacji, poproś o uprawnienie SCHEDULE_EXACT_ALARM w pliku manifestu.
Alarmy precyzyjne powinny być używane tylko w przypadku funkcji dla użytkownika. Dowiedz się więcej o dopuszczalnych przypadkach użycia ustawiania alarmu precyzyjnego.
Wyłączanie zmiany działania
Podczas przygotowywania aplikacji do kierowania na Androida 12 możesz tymczasowo wyłączyć zmianę działania w wariancie kompilacji z możliwością debugowania 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, a następnie wyłącz uprawnienie REQUIRE_EXACT_ALARM_PERMISSION.
W oknie terminala na komputerze używanym do programowania 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 aktywność, którą użytkownik widzi i z którą wchodzi 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ć aktywności z usług ani odbiorników, które są używane jako trampoliny powiadomień. Innymi słowy, gdy użytkownik kliknie powiadomienie lub przycisk polecenia w powiadomieniu, aplikacja nie może wywołać metody startActivity() w usłudze ani w odbiorniku komunikatów.
Gdy aplikacja próbuje rozpocząć aktywność z usługi lub odbiornika komunikatów, który działa jako trampolina powiadomień, system uniemożliwia rozpoczęcie aktywności, a w Logcat pojawia się ten komunikat:
Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.
Identyfikowanie komponentów aplikacji, które działają jako trampoliny powiadomień
Podczas testowania aplikacji po kliknięciu powiadomienia możesz określić, która usługa lub który odbiorca transmisji działał jako trampolina powiadomień w aplikacji. Aby to zrobić, sprawdź dane wyjściowe tego polecenia terminala:
adb shell dumpsys activity service \ com.android.systemui/.dump.SystemUIAuxiliaryDumpService
Sekcja danych wyjściowych zawiera tekst „NotifInteractionLog”. Ta sekcja zawiera informacje niezbędne do zidentyfikowania komponentu, który uruchamia się w wyniku kliknięcia powiadomienia.
Zaktualizuj aplikację
Jeśli aplikacja rozpoczyna aktywność z usługi lub odbiornika komunikatów, który działa jako trampolina powiadomień, wykonaj te czynności migracji:
- Utwórz obiekt
PendingIntentpowiązany z aktywnością, którą użytkownicy zobaczą po kliknięciu powiadomienia. - Użyj obiektu
PendingIntentutworzonego w poprzednim kroku w ramach tworzenia powiadomienia.
Aby zidentyfikować źródło aktywności, np. w celu rejestrowania, podczas publikowania powiadomienia użyj dodatków. W przypadku scentralizowanej analizy logów użyj ActivityLifecycleCallbacks lub obserwatorów cyklu życia Jetpack.
Przełączanie zachowania
Podczas testowania wersji aplikacji z możliwością debugowania możesz włączać i wyłączać to ograniczenie za pomocą flagi zgodności aplikacji NOTIFICATION_TRAMPOLINE_BLOCK.
tworzenie i przywracanie kopii zapasowej;
W aplikacjach, które działają na Androidzie 12 (poziom API 31) i są kierowane na tę wersję, zmienił się sposób tworzenia i przywracania kopii zapasowych. Kopia zapasowa Androida i przywracanie danych może odbywać się na 2 sposoby:
- 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 między urządzeniami: dane użytkownika są wysyłane bezpośrednio ze starego urządzenia na nowe, np. za pomocą kabla.
Więcej informacji o tworzeniu i przywracaniu kopii zapasowej danych znajdziesz w artykułach Tworzenie kopii zapasowej danych użytkownika przy użyciu Automatycznej kopii zapasowej i Tworzenie kopii zapasowej par klucz-wartość przy użyciu Android Backup Service.
Zmiany funkcji przenoszenia danych między urządzeniami
W przypadku aplikacji działających na Androidzie 12 lub nowszym i kierowanych na te wersje:
Określanie reguł uwzględniania i reguł wykluczających za pomocą mechanizmu konfiguracji XML nie ma wpływu na przenoszenie danych między urządzeniami, ale nadal wpływa na tworzenie i przywracanie kopii zapasowych działających w chmurze (np. kopii zapasowych na Dysku Google). Aby określić reguły transferów D2D, musisz użyć nowej konfiguracji opisanej w następnej sekcji.
Na urządzeniach niektórych producentów określenie wartości
android:allowBackup="false"wyłącza kopie zapasowe na Dysku Google, ale nie wyłącza przesyłania danych między urządzeniami w przypadku aplikacji.
Nowy format uwzględniania i wykluczania
Aplikacje działające na Androidzie 12 lub nowszym i kierowane na te wersje systemu używają innego formatu konfiguracji XML. Ten format wyraźnie rozróżnia kopię zapasową na Dysku Google od przenoszenia danych między urządzeniami, ponieważ wymaga osobnego określenia reguł uwzględniania i reguł wykluczania dla kopii zapasowych w chmurze i przenoszenia danych między urządzeniami.
Opcjonalnie możesz też użyć go do określenia 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 w przypadku urządzeń z Androidem 11 lub starszym.
Zmiany formatu XML
Poniżej znajdziesz format używany do konfiguracji tworzenia i przywracania kopii zapasowej w Androidzie 11 i starszych wersjach:
<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 pogrubioną czcionką zaznaczono zmiany 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żytkownika za pomocą automatycznej kopii zapasowej.
Flaga w pliku manifestu dotycząca aplikacji
Skieruj aplikacje na nową konfigurację XML, używając atrybutu android:dataExtractionRules w pliku manifestu. Gdy wskażesz nową konfigurację XML, atrybut android:fullBackupContent wskazujący starą konfigurację będzie 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
W Androidzie 12 wprowadzono uprawnienia BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE i BLUETOOTH_CONNECT. Te uprawnienia ułatwiają aplikacjom kierowanym na Androida 12 interakcję z urządzeniami Bluetooth, zwłaszcza w przypadku aplikacji, które nie wymagają dostępu do lokalizacji urządzenia.
Aby przygotować urządzenie do kierowania na Androida 12 lub nowszego, zaktualizuj logikę aplikacji. Zamiast deklarować starszy zestaw uprawnień Bluetooth, zadeklaruj nowocześniejszy zestaw uprawnień Bluetooth.
Jednoczesne połączenie peer-to-peer i połączenie z internetem
W przypadku aplikacji kierowanych na Androida 12 (API na poziomie 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-to-peer i główną siecią zapewniającą dostęp do internetu, co ułatwia użytkownikom korzystanie z aplikacji. Aplikacje kierowane na Androida 11 (API na poziomie 30) lub starszego nadal działają w starszy sposób, czyli podstawowa sieć Wi-Fi jest rozłączana przed połączeniem z urządzeniem równorzędnym.
Zgodność
WifiManager.getConnectionInfo() może zwracać WifiInfo tylko dla jednej sieci. Z tego powodu w Androidzie 12 i nowszych działanie interfejsu API zostało zmienione w następujący sposób:
- Jeśli dostępna jest tylko jedna sieć Wi-Fi, zwracana jest jej wartość
WifiInfo. - Jeśli dostępna jest więcej niż 1 sieć Wi-Fi, a aplikacja do dzwonienia wywołała połączenie peer-to-peer, zwracany jest
WifiInfoodpowiadający urządzeniu równorzędnemu. - Jeśli dostępnych jest kilka sieci Wi-Fi, a aplikacja do dzwonienia nie wywołała połączenia peer-to-peer, zwracana jest wartość
WifiInfogłównego połączenia zapewniającego dostęp do internetu.
Aby zapewnić lepsze wrażenia użytkownikom urządzeń, które obsługują 2 jednoczesne sieci Wi-Fi, zalecamy, aby wszystkie aplikacje – zwłaszcza te, które wywołują połączenia peer-to-peer – przestały wywoływać metodę WifiManager.getConnectionInfo() i zamiast tego używały metody NetworkCallback.onCapabilitiesChanged() do pobierania wszystkich obiektów WifiInfo, które pasują do obiektu NetworkRequest użytego do zarejestrowania obiektu NetworkCallback. W Androidzie 12 metoda getConnectionInfo() została wycofana.
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
Android 12 zmienia sposób, w jaki 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 żadnych metod NsdManager. Następnie demon subskrybował urządzenie do grup multiemisji wszystkich węzłów, co powodowało częstsze wybudzanie systemu i dodatkowe zużycie energii. Aby zminimalizować wykorzystanie baterii, w Androidzie 12 i nowszych system uruchamia teraz demona mDNSResponder tylko wtedy, gdy jest on potrzebny do obsługi zdarzeń NSD, a następnie 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 niedostępności demona mDNSResponder. Ta zmiana nie ma wpływu na aplikacje, które używają NsdManager i nie korzystają z natywnego interfejsu API mDNSResponder.
Biblioteki dostawców
Natywne biblioteki udostępnione dostarczane przez dostawcę
Jeśli aplikacja jest kierowana na Androida 12 (poziom interfejsu API 31) lub nowszego, natywne biblioteki współdzielone inne niż NDK dostarczane przez dostawców układów scalonych lub producentów urządzeń są domyślnie niedostępne. 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 współdzielona jest dostępna niezależnie od tego, czy jest to biblioteka NDK.
Zaktualizowane ograniczenia dotyczące interfejsów niebędących częścią pakietu SDK
Android 12 zawiera zaktualizowane listy ograniczonych interfejsów spoza pakietu SDK, które powstały we współpracy z programistami aplikacji na Androida i na podstawie najnowszych testów wewnętrznych. Zanim ograniczymy dostęp do interfejsów innych niż SDK, staramy się zapewnić 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 pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale 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 używa interfejsów innych niż SDK, możesz ją przetestować, aby to sprawdzić. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych rozwiązań SDK. Rozumiemy jednak, że niektóre aplikacje mają uzasadnione przypadki użycia interfejsów spoza pakietu SDK. Jeśli nie możesz znaleźć alternatywy dla interfejsu spoza pakietu 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 spoza pakietu SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów spoza pakietu SDK.