Zmiany w działaniu: aplikacje kierowane na Androida 13 lub nowszego

Podobnie jak w przypadku wcześniejszych wersji Androida, w Androidzie 13 wprowadziliśmy zmiany w sposobie działania, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany dotyczą wyłącznie aplikacji kierowanych na Androida 13 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 13 lub nowszego, w odpowiednich przypadkach zmodyfikuj ją, aby prawidłowo obsługiwała te zachowania.

Zapoznaj się też z listą zmian w zachowaniu, które mają wpływ na wszystkie aplikacje działające na Androidzie 13.

Prywatność

Uprawnienia do powiadomień wpływają na wygląd usługi działającej na pierwszym planie

Jeśli użytkownik odmówi przyznania uprawnień do powiadomień, nie będzie widzieć powiadomień związanych z usługami działającymi na pierwszym planie w panelu powiadomień. Użytkownicy nadal widzą jednak powiadomienia związane z usługami działającymi na pierwszym planie w Menedżerze zadań, niezależnie od tego, czy przyznano uprawnienia do powiadomień.

Nowe uprawnienie w czasie działania aplikacji dotyczące urządzeń Wi-Fi w pobliżu

W starszych wersjach Androida użytkownik musi przyznać aplikacji uprawnienia ACCESS_FINE_LOCATION, aby można było wykonać kilka typowych czynności związanych z Wi-Fi.

Użytkownikom trudno jest powiązać uprawnienia dostępu do lokalizacji z funkcjami Wi-Fi, dlatego w Androidzie 13 (API na poziomie 33) wprowadziliśmy uprawnienia czasu działania w grupie uprawnień NEARBY_DEVICES dla aplikacji, które zarządzają połączeniami urządzenia z pobliskimi punktami dostępu przez Wi-Fi. To uprawnienieNEARBY_WIFI_DEVICES umożliwia realizację przypadków użycia Wi-Fi, takich jak:

• znajdować urządzenia w pobliżu, takie jak drukarki czy urządzenia do przesyłania multimediów, i łączyć się z nimi; Ten proces umożliwia aplikacji wykonywanie takich zadań:
  • Otrzymywanie informacji o punkcie dostępu poza pasmem, np. przez BLE.
  • wykrywać urządzenia i łączyć się z nimi za pomocą Wi-Fi Aware oraz łączyć się za pomocą lokalnego hotspota;
  • Wykrywanie urządzeń i łączenie się z nimi za pomocą Wi-Fi Direct.
• nawiązywanie połączenia ze znanym identyfikatorem SSID, np. z samochodem lub inteligentnym urządzeniem domowym;
• Uruchamianie lokalnego hotspota.
• Zasięg urządzeń Wi-Fi Aware w pobliżu.

Jeśli Twoja aplikacja nie uzyskuje informacji o fizycznej lokalizacji z interfejsów API Wi-Fi, gdy kierujesz ją na Androida 13 lub nowszego i używasz interfejsów API Wi-Fi, wysyłaj żądanie NEARBY_WIFI_DEVICES zamiast ACCESS_FINE_LOCATION. Gdy deklarujesz uprawnienie NEARBY_WIFI_DEVICES, stanowczo oświadcz, że Twoja aplikacja nigdy nie uzyskuje informacji o fizycznej lokalizacji z interfejsów API Wi-Fi. Aby to zrobić, ustaw atrybut android:usesPermissionFlags na neverForLocation. Ten proces jest podobny do tego, który wykonujesz w Androidzie 12 (poziom interfejsu API 31) i nowszym, gdy zapewniasz, że informacje o urządzeniu Bluetooth nigdy nie są używane do określania lokalizacji.

Dowiedz się więcej o tym, jak poprosić o uprawnienia dostępu do urządzeń Wi-Fi w pobliżu.

Szczegółowe uprawnienia do multimediów

Jeśli Twoja aplikacja jest kierowana na Androida 13 lub nowszego i musi mieć dostęp do plików multimedialnych utworzonych przez inne aplikacje, zamiast uprawnień READ_EXTERNAL_STORAGE musisz poprosić o co najmniej 1 z tych szczegółowych uprawnień do multimediów:

Zanim uzyskasz dostęp do plików multimedialnych innej aplikacji, sprawdź, czy użytkownik przyznał Twojej aplikacji odpowiednie szczegółowe uprawnienia do multimediów.

Na ilustracji 1 widać aplikację, która prosi o uprawnienie READ_MEDIA_AUDIO.

Jeśli poprosisz jednocześnie o uprawnienia READ_MEDIA_IMAGES i READ_MEDIA_VIDEO, pojawi się tylko jedno okno uprawnień systemowych.

Jeśli Twoja aplikacja miała wcześniej przyznane uprawnienie READ_EXTERNAL_STORAGE, to podczas uaktualniania wszystkie wymagane uprawnienia READ_MEDIA_* są przyznawane automatycznie. Aby sprawdzić uaktualnione uprawnienia, możesz użyć tego polecenia ADB:

adb shell cmd appops get --uid PACKAGE_NAME

Korzystanie z czujników na ciele w tle wymaga nowego uprawnienia

W Androidzie 13 wprowadzono koncepcję dostępu „podczas używania” w przypadku czujników na ciele, takich jak czujniki tętna, temperatury i poziomu saturacji. Ten model dostępu jest bardzo podobny do tego, który został wprowadzony w systemie w przypadku lokalizacji w Androidzie 10 (poziom 29 interfejsu API).

Jeśli aplikacja jest kierowana na Androida 13 i potrzebuje dostępu do informacji z czujników na ciele podczas działania w tle, musisz zadeklarować nowe uprawnienie BODY_SENSORS_BACKGROUND oprócz dotychczasowego uprawnienia BODY_SENSORS.

Wydajność i bateria

Wykorzystanie baterii

Jeśli użytkownik ustawi aplikację w stanie „ograniczonym” w przypadku zużycia baterii w tle, a aplikacja jest przeznaczona na Androida 13, system nie dostarczy transmisji BOOT_COMPLETED ani LOCKED_BOOT_COMPLETED, dopóki aplikacja nie zostanie uruchomiona z innych powodów.

Interfejs użytkownika

Sterowanie multimediami pochodzi z PlaybackState

W przypadku aplikacji kierowanych na Androida 13 (API na poziomie 33) lub nowszego system wyodrębnia elementy sterujące multimediami z działań PlaybackState. Dzięki temu system może wyświetlać bogatszy zestaw elementów sterujących, które są technicznie spójne na telefonach i tabletach, a także zgodne z tym, jak elementy sterujące multimediami są renderowane na innych platformach Androida, takich jak Android Auto i Android TV.

Ilustracja 2 pokazuje, jak to wygląda na telefonie i tablecie.

W Androidzie 12 i starszych system wyświetlał maksymalnie 5 działań z MediaStylepowiadomienia w kolejności, w jakiej zostały dodane. W trybie kompaktowym, np. w zwiniętych szybkich ustawieniach, wyświetlane były maksymalnie 3 działania określone za pomocą właściwości setShowActionsInCompactView().

Od Androida 13 system wyświetla maksymalnie 5 przycisków działań na podstawie PlaybackState, jak opisano w tabeli poniżej. W trybie kompaktowym wyświetlane są tylko 3 pierwsze miejsca na działania. W przypadku aplikacji, które nie są przeznaczone na Androida 13 lub nie zawierają elementu PlaybackState, system wyświetli elementy sterujące na podstawie listy Action dodanej do powiadomienia MediaStyle, zgodnie z opisem w poprzednim akapicie.

Działania niestandardowe są umieszczane w kolejności, w jakiej zostały dodane do PlaybackState.

Automatyczne stosowanie motywu kolorystycznego aplikacji do treści WebView

W przypadku aplikacji kierowanych na Androida 13 (API na poziomie 33) lub nowszego metoda setForceDark() jest wycofana, co oznacza, że wywołanie tej metody nie powoduje żadnej operacji.

Zamiast tego WebView zawsze ustawia zapytanie o multimedia prefers-color-scheme zgodnie z atrybutem motywu aplikacji, isLightTheme. Innymi słowy, jeśli wartość isLightTheme to true lub nie została określona, wartość prefers-color-scheme to light. W przeciwnym razie jest to dark. Oznacza to, że jasny lub ciemny styl treści internetowych jest stosowany automatycznie, aby dopasować się do motywu aplikacji, jeśli treść go obsługuje.

W przypadku większości aplikacji nowe działanie powinno automatycznie stosować odpowiednie style aplikacji, ale warto przetestować aplikację, aby sprawdzić, czy nie ma przypadków, w których ręcznie kontrolujesz ustawienia trybu ciemnego.

Jeśli nadal chcesz dostosować działanie motywu kolorystycznego aplikacji, użyj metody setAlgorithmicDarkeningAllowed(). Aby zachować wsteczną zgodność z poprzednimi wersjami Androida, zalecamy używanie odpowiedniej metody setAlgorithmicDarkeningAllowed() w Androidzie X.

Więcej informacji o tym, jak będzie działać aplikacja w zależności od jej targetSdkVersion i ustawień motywu, znajdziesz w dokumentacji tej metody.

Łączność

Metody BluetoothAdapter#enable() i BluetoothAdapter#disable() zostały wycofane

W przypadku aplikacji kierowanych na Androida 13 (API na poziomie 33) lub nowszego metody BluetoothAdapter#enable() i BluetoothAdapter#disable() są wycofane i zawsze zwracają wartość false.

Te typy aplikacji są zwolnione z tych zmian:

• Aplikacje właściciela urządzenia
• Aplikacje właściciela profilu
• Aplikacje systemowe

Usługi Google Play

Uprawnienia wymagane w przypadku identyfikatora wyświetlania reklam

Aplikacje, które używają identyfikatora wyświetlania reklam Usług Google Play i są kierowane na Androida 13 (API na poziomie 33) lub nowszego, muszą zadeklarować w pliku manifestu aplikacji normalne uprawnienia AD_ID w ten sposób:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

Jeśli aplikacja kierowana na Androida 13 lub nowszego nie zadeklaruje tych uprawnień, identyfikator wyświetlania reklam zostanie automatycznie usunięty i zastąpiony ciągiem zer.

Jeśli Twoja aplikacja używa pakietów SDK, które w pliku manifestu biblioteki deklarują uprawnienia AD_ID, są one domyślnie łączone z plikiem manifestu aplikacji. W takim przypadku nie musisz deklarować uprawnień w pliku manifestu aplikacji.

Więcej informacji znajdziesz w artykule Identyfikator wyświetlania reklam w Centrum pomocy Konsoli Play.

Zaktualizowane ograniczenia dotyczące interfejsów API innych niż SDK

Android 13 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK, które powstały na podstawie współpracy z programistami Androida i najnowszych testów wewnętrznych. W miarę możliwości przed ograniczeniem interfejsów innych niż SDK udostępniamy publiczne alternatywy.

Jeśli Twoja aplikacja nie jest kierowana na Androida 13, niektóre z tych zmian mogą nie mieć na Ciebie natychmiastowego wpływu. Obecnie możesz używać niektórych interfejsów spoza SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z dowolnej metody lub pola spoza 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 to sprawdzić, testując ją. Jeśli Twoja aplikacja korzysta z interfejsów spoza SDK, zacznij planować migrację na alternatywne rozwiązania SDK. Rozumiemy jednak, że w przypadku niektórych aplikacji używanie interfejsów innych niż SDK jest uzasadnione. Jeśli nie możesz znaleźć alternatywy dla używania interfejsu innego niż 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 13. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK.