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.
Włącz zmianę dotyczącą powiadomień niestandardowych:
- Aby włączyć nowe zachowanie, zmień
targetSdkVersion
aplikacji naS
. - Skompiluj ponownie.
- Zainstaluj aplikację na urządzeniu lub w emulatorze z Androidem 12.
- Aby włączyć nowe zachowanie, zmień
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ć interfejsusetBigCustomContentView
, 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).
Zmiany weryfikacji linków aplikacji na Androida
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.
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 jakSameSite=Lax
. - Pliki cookie z atrybutem
SameSite=None
muszą 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 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:
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.
Ta metoda umożliwia testowanie na dowolnym urządzeniu z Androidem 5.0 (poziom interfejsu API 21) lub nowszym, w tym z Androidem 12, oraz komponentem WebView w wersji 89.0.4385.0 lub nowszej.
Skompiluj aplikację, aby była kierowana na Androida 12 (poziom interfejsu API 31) do
targetSdkVersion
.Jeśli chcesz skorzystać z tej metody, musisz korzystać z 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 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:
W pliku manifestu jest wyświetlane to ostrzeżenie dotyczące lintowania:
When using intent filters, please specify android:exported as well
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:
- Utwórz obiekt
PendingIntent
powiązany z aktywnością, którą użytkownicy zobaczą po kliknięciu powiadomienia. - 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.