Zmiany w działaniu: aplikacje kierowane na Androida 12

Tak jak we wcześniejszych wersjach, Android 12 wprowadza zmiany w działaniu, które mogą wpłynąć na działanie Twojej aplikacji. 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 musisz ją zmodyfikować, aby odpowiednio obsługiwała te zachowania.

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

Z perspektywy użytkownika

Niestandardowe powiadomienia

Android 12 zmienia wygląd i działanie w pełni niestandardowych powiadomień. Wcześniej powiadomienia niestandardowe mogły obejmować cały obszar powiadomień oraz własne układy i style. W rezultacie pojawiały się w nich wzorce, które mogły wprowadzać użytkowników w błąd i 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 całego obszaru powiadomień. Zamiast tego system zastosuje szablon standardowy. Szablon zapewnia, że powiadomienia niestandardowe będą miały taki sam wygląd jak inne powiadomienia we wszystkich stanach, np. ikonę powiadomienia i opcje rozwijania (w stanie zwiniętym) oraz ikonę powiadomienia, nazwę aplikacji i asortyment zwijania (w stanie rozwinięcia). Jest to niemal identyczne jak działanie Notification.DecoratedCustomViewStyle.

W ten sposób na Androidzie 12 wszystkie powiadomienia są wizualnie spójne i łatwe do przeglądania, a użytkownik może je łatwo znajdować i rozwijać.

Ilustracja przedstawiająca niestandardowe powiadomienie w szablonie standardowym:

Poniższe przykłady pokazują, jak niestandardowe powiadomienia renderują się w stanie zwiniętym i rozwiniętym:

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

Jeśli Twoja aplikacja wykorzystuje w pełni niestandardowe powiadomienia, zalecamy jak najszybsze przetestowanie nowego szablonu.

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

   1. Aby włączyć nowe działanie, zmień targetSdkVersion w aplikacji na S.
   2. Przeprowadź ponowną kompilację.
   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ą zgodnie z oczekiwaniami. Podczas testowania pamiętaj o tych kwestiach i wprowadzaj niezbędne korekty:

   • Zmieniły się wymiary widoków niestandardowych. Ogólnie wysokość, jaką zapewniają powiadomienia niestandardowe, jest mniejsza niż wcześniej. W stanie zwiniętym maksymalna wysokość niestandardowej zawartości zmniejszyła się z 106 dp do 48 dp. Mniej miejsca w poziomie.

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

   • Aby mieć pewność, że stan „Uważaj na przejściu” wygląda zgodnie z oczekiwaniami, nie zapomnij zwiększyć znaczenia kanału powiadomień na „WYSOKI” (komunikaty wyświetlane 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 weryfikowania linków aplikacji na Androida. Te zmiany poprawiają niezawodność łączenia aplikacji oraz dają większą kontrolę deweloperom i użytkownikom.

Jeśli do otwierania linków w aplikacji używasz weryfikacji linku do aplikacji na Androida, sprawdź, czy podczas dodawania filtrów intencji na potrzeby weryfikacji Android App Link używasz właściwego 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 do aplikacji, aby przetestować wiarygodność deklaracji.

Ulepszenie działania funkcji obraz w obrazie

W Androidzie 12 wprowadziliśmy ulepszenia w działaniu w trybie obraz w obrazie (PIP) oraz zalecane poprawki kosmetycznych dotyczące animacji przejścia w przypadku nawigacji przy użyciu gestów i nawigacji przy użyciu elementów.

Więcej informacji znajdziesz w artykule Poprawki obrazu w obrazie.

Nowy wygląd komunikatu

W Androidzie 12 zmieniliśmy widok komunikatu. Komunikaty są teraz ograniczone do 2 wierszy tekstu, a obok tekstu wyświetla się ikona aplikacji.

Aby dowiedzieć się więcej, zobacz Omówienie powiadomień.

Prywatność i bezpieczeństwo

Przybliżona lokalizacja

Na urządzeniach z Androidem 12 lub nowszym użytkownicy mogą prosić o dostęp do przybliżonej lokalizacji Twojej aplikacji.

Uwaga: w niektórych wersjach Androida 12 ta zmiana zawsze ma wpływ na Twoją aplikację, niezależnie od docelowej wersji pakietu SDK.

Nowoczesne pliki cookie SameSite w komponencie WebView

Komponent WebView Androida bazuje na Chromium – projekcie open source, który obsługuje przeglądarkę Chrome Google. W Chromium wprowadzono zmiany w sposobie obsługi plików cookie innych firm, aby zapewnić większe bezpieczeństwo i prywatność oraz zapewnić użytkownikom większą przejrzystość i kontrolę. Począwszy od Androida 12 zmiany te będą też widoczne w WebView w przypadku aplikacji kierowanych na Androida 12 (poziom API 31) lub nowszego.

Atrybut SameSite pliku cookie określa, czy można go wysyłać z dowolnymi żądaniami czy tylko z żądaniami tej samej witryny. Opisane poniżej zmiany zwiększające ochronę prywatności poprawiają domyślną obsługę plików cookie innych firm i pomagają chronić przed niezamierzonym udostępnianiem danych między witrynami:

• Pliki cookie bez atrybutu SameSite są traktowane jako SameSite=Lax.
• Pliki cookie z atrybutem SameSite=None muszą też zawierać atrybut Secure. Oznacza to, że wymagają bezpiecznego kontekstu i powinny być przesyłane przez HTTPS.
• Linki między wersjami HTTP i HTTPS witryny są teraz traktowane jako żądania z innych witryn, więc pliki cookie nie są wysyłane, chyba że są odpowiednio oznaczone jako SameSite=None; Secure.

Deweloperzy powinni według ogólnych wskazówek określić zależności między plikami cookie z różnych witryn w najważniejszych przepływach użytkowników i w razie potrzeby wyraźnie ustawić atrybut SameSite z odpowiednimi wartościami. Musisz wyraźnie wskazać, które pliki cookie mogą działać w różnych witrynach lub w elementach nawigacyjnych w tej samej witrynie, które przechodzą z protokołu HTTP do HTTPS.

Pełne wskazówki dla programistów stron internetowych dotyczące tych zmian znajdziesz w dokumentach SameSite Cookie Explained i Schemeful SameSite.

Testowanie zachowań SameSite w aplikacji

Jeśli Twoja aplikacja używa WebView lub zarządzasz witryną lub usługą, która używa 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, aby obsługiwały nowe sposoby działania SameSite.

Uważaj na problemy z logowaniem się i umieszczonymi treściami, a także procesami logowania, zakupami i innymi procesami uwierzytelniania, gdy użytkownik otwiera niezabezpieczone strony i przechodzi na bezpieczną stronę.

Aby przetestować aplikację za pomocą WebView, musisz włączyć nowe zachowania SameSite w przypadku aplikacji, którą chcesz przetestować. W tym celu wykonaj jedną z tych czynności:

• Ręcznie włącz zachowania SameSite na urządzeniu testowym, przełączając flagę UI 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 na Androidzie 12, i komponencie WebView w wersji 89.0.4385.0 lub nowszej.

• Skompiluj aplikację pod kątem kierowania na Androida 12 (poziom API 31) do targetSdkVersion.

  Jeśli używasz tej metody, musisz używać urządzenia z Androidem 12.

Informacje o zdalnym debugowaniu komponentu WebView na Androidzie znajdziesz w artykule Pierwsze kroki ze zdalnym debugowaniem na urządzeniach z Androidem.

Inne materiały

Więcej informacji o nowoczesnym zachowaniu SameSite oraz o wdrażaniu w Chrome i komponencie WebView znajdziesz na stronie o aktualizacjach SameSite w Chromium. Jeśli znajdziesz błąd w WebView lub Chromium, możesz go zgłosić w publicznym narzędziu do śledzenia problemó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 czujników pozycji.

Dowiedz się więcej o ograniczaniu szybkości wykrywania czujników.

Hibernacja aplikacji

Android 12 rozszerza sposób automatycznego resetowania uprawnień, który wprowadzono w Androidzie 11 (poziom interfejsu 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 przyznane uprawnienia i przenosi aplikację w stan hibernacji.

Więcej informacji znajdziesz w przewodniku o hibernacji aplikacji.

Deklaracja atrybucji w kontroli dostępu do danych

Wprowadzony w Androidzie 11 (poziom API 30) interfejs API kontroli dostępu do danych umożliwia tworzenie tagów atrybucji na podstawie przypadków użycia aplikacji. Te tagi ułatwiają określenie, która część aplikacji ma dostęp do danych określonego typu.

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

Ograniczenie kopii zapasowej ADB

Aby chronić dane aplikacji prywatnych, Android 12 zmienia domyślne zachowanie 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 bazują na danych aplikacji korzystających z usługi adb backup, możesz teraz włączyć eksportowanie danych o aplikacji. Aby to zrobić, w pliku manifestu aplikacji możesz ustawić wartość android:debuggable na true.

Uwaga: aby lepiej chronić dane aplikacji, przed opublikowaniem aplikacji ustaw 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 transmisji, które używają filtrów intencji, musisz wyraźnie zadeklarować atrybut android:exported dla tych komponentów aplikacji.

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

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 zawiera przykład usługi, która zawiera filtr intencji, którego atrybut android:exported jest ustawiony na false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Wiadomości w Android Studio

Jeśli aplikacja zawiera aktywność, usługę lub odbiornik, który używa filtrów intencji, ale nie deklaruje android:exported, w zależności od używanej wersji Androida Studio pojawią się te komunikaty ostrzegawcze:

Android Studio 2020.3.1 Canary 11 lub nowszy

Wyświetlane są te komunikaty:

1. W pliku manifestu pojawi się to ostrzeżenie o lintowaniu:

   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ść oczekujących intencji

Jeśli aplikacja jest kierowana na Androida 12, musisz określić zmienność każdego tworzonego przez nią obiektu PendingIntent. To dodatkowe wymaganie zwiększa bezpieczeństwo aplikacji.

Testowanie oczekującej zmiany zmienności intencji

Aby sprawdzić, czy w Twojej aplikacji brakuje deklaracji zmienności, w Android Studio poszukaj 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 mają funkcję debugowania, która wykrywa niebezpieczne uruchomienia intencji. Gdy system wykryje takie niebezpieczne uruchomienie, następuje naruszenie zasad StrictMode.

Wyniki

Ograniczenia dotyczące uruchamiania usług działających na pierwszym planie

Aplikacje kierowane na Androida 12 lub nowszego nie mogą uruchamiać usług działających w tle (z wyjątkiem kilku szczególnych przypadków). Jeśli aplikacja próbuje uruchomić usługę na pierwszym planie podczas działania w tle, występuje wyjątek (z wyjątkiem kilku szczególnych przypadków).

Rozważ użycie WorkManagera do planowania i rozpoczynania szybkiej pracy, gdy aplikacja działa w tle. Aby wykonać zależne od czasu działania, o które prosi użytkownik, uruchom usługi działające na pierwszym planie w dokładnym alarmie.

Uprawnienie dostępu do precyzyjnych alarmów

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

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

Dokładnych alarmów należy używać tylko w przypadku funkcji widocznych dla użytkownika. Dowiedz się więcej o akceptowanych przypadkach użycia dokładnego alarmu.

Wyłącz zmianę działania

Podczas przygotowywania aplikacji do kierowania na Androida 12 możesz tymczasowo wyłączyć zmianę działania w wariancie kompilacji możliwej do debugowania. Aby to zrobić, wykonaj jedną z tych czynności:

• Na ekranie ustawień Opcje programisty wybierz Zmiany zgodności aplikacji. Na ekranie, który się pojawi, kliknij nazwę aplikacji, a potem wyłącz REQUIRE_EXACT_ALARM_PERMISSION.

• W oknie terminala na komputerze, na którym pracujesz, uruchom następujące polecenie:

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

Ograniczenia dotyczące powiadomień z trampolina

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

Aby zwiększyć wydajność i wygodę użytkowników, aplikacje kierowane na Androida 12 lub nowszego nie mogą rozpoczynać aktywności z usług ani odbiorników, które są wykorzystywane jako trampoliny powiadomień. Inaczej mówiąc, gdy użytkownik kliknie powiadomienie lub przycisk polecenia w powiadomieniu, aplikacja nie może wywołać funkcji startActivity() z poziomu usługi lub odbiornika.

Gdy aplikacja próbuje uruchomić aktywność z usługi lub odbiornika, która działa jako trampolina powiadomień, system uniemożliwia jej uruchomienie, a w narzędziu Logcat pojawi się następujący komunikat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Zidentyfikuj komponenty aplikacji, które działają jak trampoliny z powiadomieniami

Podczas testowania aplikacji po kliknięciu powiadomienia możesz sprawdzić, która usługa lub odbiornik pełnił w niej funkcję trampoliny. W tym celu sprawdź dane wyjściowe następującego 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ę po kliknięciu powiadomienia.

Zaktualizuj aplikację

Jeśli aplikacja rozpoczyna działanie z usługi lub odbiornika, który działa jako trampolina powiadomień, wykonaj te czynności:

1. Utwórz obiekt PendingIntent powiązany z aktywnością, którą 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 przeprowadzenia logowania, należy użyć dodatków przy publikowaniu powiadomienia. W przypadku scentralizowanego logowania użyj funkcji ActivityLifecycleCallbacks lub obserwatorów cyklu życia Jetpack.

Przełącz działanie

Jeśli testujesz wersję aplikacji z możliwością debugowania, możesz włączyć lub wyłączyć to ograniczenie za pomocą flagi zgodności aplikacji NOTIFICATION_TRAMPOLINE_BLOCK.

tworzenie i przywracanie kopii zapasowej;

Wprowadziliśmy zmiany w sposobie działania tworzenia i przywracania kopii zapasowych w aplikacjach, które działają na Androidzie 12 (poziom interfejsu API 31) i na niego są kierowane. Tworzenie i przywracanie kopii zapasowej Androida ma 2 formularze:

• Kopie zapasowe w chmurze: dane użytkownika są przechowywane na Dysku Google użytkownika, aby można je później przywrócić na danym urządzeniu lub nowym urządzeniu.
• Przenoszenie między urządzeniami (D2D): dane użytkownika są przesyłane bezpośrednio ze starszego urządzenia na nowe urządzenie, np. przy użyciu kabla.

Więcej informacji o tworzeniu i przywracaniu kopii zapasowych danych znajdziesz w artykułach Tworzenie kopii zapasowej danych użytkowników przy użyciu Automatycznej kopii zapasowej i Tworzenie kopii zapasowej par klucz-wartość przy użyciu Android Backup Service.

Zmiany w funkcjach przenoszenia danych D2D

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

• Określenie reguł uwzględniania i wykluczania za pomocą mechanizmu konfiguracji XML nie ma wpływu na transfery D2D, ale nadal wpływa na tworzenie i przywracanie kopii zapasowych w chmurze (na przykład na kopie zapasowe na Dysku Google). Aby określić reguły transferów D2D, musisz użyć nowej konfiguracji omówionej 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 transferów D2D dla aplikacji.

Nowy format uwzględniania i wykluczania

Aplikacje działające na Androidzie 12 i nowszym oraz na niego używają innego formatu konfiguracji XML. Ten format wyraźnie odróżnia kopię zapasową na Dysku Google od transferu D2D, ponieważ wymaga osobnego określania reguł uwzględniania i wykluczania w przypadku kopii zapasowych w chmurze i transferu D2D.

Możesz też go używać do określania reguł tworzenia kopii zapasowych. W takim przypadku używana wcześniej konfiguracja zostanie zignorowana na urządzeniach z Androidem 12 lub nowszym. 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ć na urządzeniach z Androidem 12 lub nowszym, nawet jeśli nie kierujesz jeszcze aplikacji na ten system.

Zmiany formatu XML

Oto format używany do konfiguracji tworzenia i przywracania kopii zapasowej na 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 pogrubiono 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 na temat tworzenia kopii zapasowych danych użytkowników przy użyciu Automatycznej kopii zapasowej.

Flaga w pliku manifestu aplikacji

Skieruj swoje aplikacje na nową konfigurację XML, korzystając z 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. Ten przykładowy kod pokazuje wpisy w nowym 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. Uprawnienia te ułatwiają aplikacjom kierowanym 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 reklam na Androida 12 lub nowszego, zaktualizuj logikę aplikacji. Zamiast deklarować starszy zestaw uprawnień Bluetooth, zadeklaruj nowoczesny zestaw uprawnień Bluetooth.

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

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 połączenia z internetem, mogą utrzymać jednoczesne połączenia Wi-Fi zarówno z urządzeniem równorzędnym, jak i z główną siecią dostarczającą internet, co zwiększa wygodę użytkowników. Aplikacje kierowane na Androida 11 (poziom interfejsu API 30) lub starszego nadal działają w starszy sposób: podstawowa sieć Wi-Fi jest odłączona przed nawiązaniem połączenia z urządzeniem równorzędnym.

Zgodność

WifiManager.getConnectionInfo() może zwrócić wartość WifiInfo tylko w przypadku 1 sieci. Z tego powodu w Androidzie 12 i nowszych działanie interfejsu API uległo zmianie 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 wywołująca uruchomiła połączenie peer-to-peer, zwracany jest WifiInfo odpowiadający urządzeniu równorzędnemu.
• Jeśli dostępna jest więcej niż 1 sieć Wi-Fi, a aplikacja wywołująca nie wywołała połączenia peer-to-peer, zwracany jest typ WifiInfo podstawowego połączenia internetowego.

Aby zapewnić użytkownikom lepsze wrażenia na urządzeniach, które obsługują podwójne równoczesne sieci Wi-Fi, zalecamy przejście na wszystkie aplikacje – zwłaszcza te, które uruchamiają połączenia peer-to-peer – zamiast tego użyj funkcji NetworkCallback.onCapabilitiesChanged(), aby uzyskać wszystkie obiekty WifiInfo zgodne z obiektem NetworkRequest użytym do zarejestrowania NetworkCallback.WifiManager.getConnectionInfo() W Androidzie 12 funkcja getConnectionInfo() jest wycofywana.

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 się w sytuacji, gdy 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(), system NSD uruchomił demona mDNSResponder, nawet jeśli aplikacja nie wywołała jeszcze żadnych metod NsdManager. Następnie demon zasubskrybował urządzenie do grup multiemisji wszystkich węzłów, co spowodowało częstsze wybudzanie systemu i zwiększenie mocy. Aby zminimalizować wykorzystanie baterii, w Androidzie 12 i nowszych system uruchamia teraz demona mDNSResponder tylko wtedy, gdy jest to potrzebne w przypadku zdarzeń NSD, a później zatrzymuje.

Ponieważ ta zmiana wpływa na dostępność demona mDNSResponder, aplikacje, które zakładają, że demon mDNSResponder zostanie uruchomiony po wywołaniu metody getSystemService(), mogą otrzymywać z systemu komunikaty z informacją, że demon mDNSResponder jest niedostępny. Ta zmiana nie ma wpływu na aplikacje korzystające z metody NsdManager, które 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ń są domyślnie niedostępne, jeśli aplikacja jest kierowana na Androida 12 (poziom API 31) lub nowszy. Biblioteki są dostępne tylko wtedy, gdy o ich wyraźnie poprosisz w tagu <uses-native-library>.

Jeśli aplikacja jest kierowana na Androida 11 (poziom interfejsu API 30) lub niższy, tag <uses-native-library> nie jest wymagany. W takim przypadku wszystkie natywne biblioteki współdzielone są dostępne niezależnie od tego, czy są biblioteką NDK.

Zaktualizowano ograniczenia dotyczące aplikacji innych niż SDK

Android 12 zawiera zaktualizowane listy podlegających ograniczeniom interfejsów spoza pakietu SDK opracowane na podstawie współpracy z deweloperami aplikacji na Androida i najnowszych testów wewnętrznych. Zanim ograniczymy dostęp do interfejsów spoza SDK, dbamy o to, aby w miarę możliwości dostępne były publiczne alternatywy.

Jeśli Twoja aplikacja nie jest kierowana na Androida 12, niektóre z tych zmian mogą Cię nie dotyczyć. Mimo że obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), korzystanie z dowolnych metod lub pól spoza pakietu SDK niesie ze sobą wysokie ryzyko awarii aplikacji.

Jeśli nie masz pewności, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, możesz przetestować ją, aby to sprawdzić. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych pakietów SDK. Zdajemy sobie jednak sprawę, że niektóre aplikacje mają odpowiednie przypadki użycia w zakresie interfejsów spoza SDK. Jeśli nie możesz znaleźć alternatywy dla interfejsu innego niż SDK dla funkcji w aplikacji, poproś o nowy publiczny interfejs API.

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