Podobnie jak w przypadku wcześniejszych wersji, Android 13 zawiera zmiany zachowania, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany zachowania mają zastosowanie wyłącznie do aplikacji kierowanych na Androida 13 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 13 lub nowszego, zmodyfikuj aplikację, aby w stosownych przypadkach prawidłowo obsługiwała te funkcje.
Zapoznaj się też z listą zmian zachowania, które mają wpływ na wszystkie aplikacje działające na Androidzie 13.
Prywatność
Uprawnienia dotyczące powiadomień wpływają na wygląd usługi działającej na pierwszym planie
Jeśli użytkownik odmówi przyznania uprawnień na wyświetlanie powiadomień, nie zobaczy w panelu powiadomień powiadomień związanych z usługami na pierwszym planie. Użytkownicy nadal będą jednak widzieć powiadomienia związane z usługami działającymi na pierwszym planie w Menedżerze zadań niezależnie od tego, czy przyznali odpowiednie uprawnienia.
Nowe uprawnienia w czasie działania dla urządzeń Wi-Fi w pobliżu
W poprzednich wersjach Androida użytkownik musi przyznać aplikacji uprawnienia ACCESS_FINE_LOCATION
do wykonywania kilku typowych działań związanych z Wi-Fi.
Ponieważ użytkownikom trudno jest powiązać dostęp do lokalizacji z funkcją Wi-Fi, Android 13 (poziom interfejsu API 33) wprowadza uprawnienia w czasie 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 uprawnienie,
NEARBY_WIFI_DEVICES
,
spełnia potrzeby związane z Wi-Fi, takie jak:
- znajdować urządzenia w pobliżu i łączyć się z nimi, np. drukarki lub urządzenia do przesyłania multimediów;
Ten proces umożliwia aplikacji wykonywanie takich zadań:
- Odbieraj informacje AP spoza zakresu, na przykład przez BLE.
- Wykrywanie urządzeń i łączenie się z nimi przez Wi-Fi Aware oraz łączenie się za pomocą lokalnego hotspotu.
- wykrywać urządzenia i łączyć się z nimi przez Wi-Fi Direct.
- Nawiązywanie połączenia z znanym SSID, takim jak samochód czy urządzenie inteligentnego domu.
- Uruchom lokalny hotspot.
- zasięg do urządzeń z obsługą Wi-Fi Aware w pobliżu;
O ile aplikacja nie pobiera informacji o lokalizacji fizycznej z interfejsów Wi-Fi API, gdy jest kierowana na Androida 13 lub nowszego i korzysta z interfejsów Wi-Fi API, poproś o to NEARBY_WIFI_DEVICES
zamiast ACCESS_FINE_LOCATION
. Zadeklarując uprawnienie NEARBY_WIFI_DEVICES
, zdecydowanie zapewnij, że Twoja aplikacja nigdy nie pobiera informacji o fizycznej lokalizacji z interfejsów API Wi-Fi. Aby to zrobić, ustaw atrybut android:usesPermissionFlags
na neverForLocation
. Ten proces jest podobny do procesu w Androidzie 12 (poziom interfejsu API 31) i nowszych, gdy deklarujesz, że informacje z urządzenia Bluetooth nigdy nie są używane do określania lokalizacji.
Dowiedz się więcej o tym, jak poprosić o dostęp 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 wymaga dostępu do plików multimedialnych utworzonych przez inne aplikacje, musisz poprosić o co najmniej 1 z tych szczegółowych uprawnień dostępu do multimediów zamiast uprawnień READ_EXTERNAL_STORAGE
:
Typ multimediów | Uprawnienia, o które możesz poprosić |
---|---|
Obrazy i zdjęcia | READ_MEDIA_IMAGES |
Filmy | READ_MEDIA_VIDEO |
Pliki audio | READ_MEDIA_AUDIO |
Zanim uzyskasz dostęp do plików multimedialnych innej aplikacji, sprawdź, czy użytkownik przyznał Twojej aplikacji odpowiednie szczegółowe uprawnienia do multimediów.
Rysunek 1 przedstawia aplikację, która prosi o uprawnienie READ_MEDIA_AUDIO
.
Jeśli jednocześnie poprosisz 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 uprawnienia READ_EXTERNAL_STORAGE
, wszystkie żądane uprawnienia READ_MEDIA_*
zostaną automatycznie przyznane podczas aktualizacji. Aby sprawdzić ulepszone 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 nowych uprawnień
Android 13 wprowadza koncepcję dostępu „podczas używania” dla czujników na ciele, takich jak tętno, temperatura i poziom saturacji. Ten model dostępu jest bardzo podobny do modelu wprowadzonego przez system na potrzeby lokalizacji na Androidzie 10 (poziom interfejsu API 29).
Jeśli Twoja aplikacja jest kierowana na Androida 13 i wymaga dostępu do informacji z czujnika na ciele, gdy działa w tle, oprócz dotychczasowego uprawnienia BODY_SENSORS
musisz zadeklarować nowe uprawnienie BODY_SENSORS_BACKGROUND
.
Wydajność i bateria
Wykorzystanie zasobów baterii
Jeśli użytkownik umieści Twoją aplikację w stanie „ograniczony” pod względem zużycia baterii w tle, a Twoja aplikacja jest kierowana na Androida 13, system nie wyśle transmisji BOOT_COMPLETED
ani LOCKED_BOOT_COMPLETED
, dopóki aplikacja nie zostanie uruchomiona z innych powodów.
Interfejs użytkownika
Elementy sterujące multimediami pochodzące z PlaybackState
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) i nowsze wersje system uzyskuje opcje sterowania 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 wyświetlaniem elementów sterowania multimediami na innych platformach Androida, takich jak Android Auto i Android TV.
Na rysunku 2. widać, jak to wygląda na telefonie i tablecie.
Przed Androidem 13 system wyświetlał maksymalnie 5 działań z MediaStyle
powiadomienia w kolejności ich dodawania.
W trybie kompaktowym, np. w zwiętych szybkich ustawieniach, wyświetlano maksymalnie 3 działania określone za pomocą setShowActionsInCompactView()
.
Począwszy od Androida 13 system wyświetla maksymalnie 5 przycisków poleceń na podstawie elementu PlaybackState
, jak opisano w tej tabeli. W trybie kompaktowym wyświetlane są tylko
trzy pierwsze przedziały działań. W przypadku aplikacji, które nie są kierowane na Androida 13 lub nie zawierają PlaybackState
, system wyświetli elementy sterujące na podstawie listy Action
dodanej do powiadomienia MediaStyle
zgodnie z opisem w poprzednim akapicie.
Boks | Działanie | Kryteria |
---|---|---|
1 | Odtwórz |
Obecny stan PlaybackState to:
|
Wskaźnik postępu wczytywania |
Obecny stan PlaybackState to:
|
|
Wstrzymaj | Obecny stanPlaybackState PlaybackState nie jest żaden z wymienionych powyżej. |
|
2 | Wstecz | PlaybackState Działania obejmują ACTION_SKIP_TO_PREVIOUS . |
Możliwość | PlaybackState Działania nie obejmują elementów ACTION_SKIP_TO_PREVIOUS i PlaybackState , a działania niestandardowe obejmują działanie niestandardowe, które nie zostało jeszcze umieszczone. |
|
Puste | Rozszerzenia PlaybackState zawierają wartość logiczną true dla klucza SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV . |
|
3 | Dalej | PlaybackState Działania obejmują ACTION_SKIP_TO_NEXT . |
Możliwość | PlaybackState czynności nie obejmują elementów ACTION_SKIP_TO_NEXT i PlaybackState , a czynności niestandardowe obejmują działanie niestandardowe, które nie zostało jeszcze umieszczone. |
|
Puste | PlaybackState Dodatkowe informacje obejmują wartość logiczną true dla klucza SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT . |
|
4 | Możliwość | PlaybackState działania niestandardowe obejmują takie, które nie zostały jeszcze zastosowane. |
5 | Możliwość | PlaybackState działania niestandardowe obejmują takie, które nie zostały jeszcze zastosowane. |
Działania niestandardowe są umieszczane w takim samym porządku, w jakim zostały dodane do PlaybackState
.
Motyw kolorów aplikacji zastosowany automatycznie do treści WebView
W przypadku aplikacji kierowanych na Androida 13 (poziom API 33) lub nowszego metoda setForceDark()
jest wycofana, co powoduje, że jej wywołanie 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 isLightTheme
ma wartość true
lub nie jest określona, prefers-color-scheme
to light
. W przeciwnym razie ma wartość dark
. Oznacza to, że jasny lub ciemny styl treści internetowych jest automatycznie stosowany do dopasowania do motywu aplikacji, jeśli treści to umożliwiają.
W przypadku większości aplikacji nowe zachowanie powinno automatycznie stosować odpowiednie style, ale warto przetestować aplikację pod kątem ręcznego sterowania ustawieniami trybu ciemnego.
Jeśli nadal musisz dostosować zachowanie motywu kolorów w aplikacji, użyj metody setAlgorithmicDarkeningAllowed()
. Aby uzyskać zgodność wsteczną z poprzednimi wersjami Androida, zalecamy użycie w AndroidzieX odpowiednika metody setAlgorithmicDarkeningAllowed()
.
Zapoznaj się z dokumentacją tej metody, by dowiedzieć się, jakiego działania możesz się spodziewać w aplikacji w zależności od jej ustawień targetSdkVersion
i motywu.
Łączność
Wycofane BluetoothAdapter#enable() i BluetoothAdapter#disable()
W przypadku aplikacji kierowanych na Androida 13 (poziom API 33) lub nowszego metody BluetoothAdapter#enable()
i BluetoothAdapter#disable()
są wycofane i zawsze zwracają false
.
Tych zmian nie dotyczą te typy aplikacji:
- Aplikacje właściciela urządzenia
- Aplikacje właściciela profilu
- Aplikacje systemowe
Usługi Google Play
Wymagany dostęp do identyfikatora wyświetlania reklam
Aplikacje, które używają identyfikatora wyświetlania reklam Usług Google Play i są kierowane na Androida 13 (poziom interfejsu API 33) lub nowszego, muszą w pliku manifestu zadeklarować 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 nie zadeklaruje tego uprawnienia w przypadku wersji Androida 13 lub nowszej, 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
, te uprawnienia zostaną domyślnie połączone z pliku 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.
Zaktualizowano ograniczenia spoza SDK
Android 13 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. Zawsze, gdy to możliwe, sprawdzamy, czy dostępne są publiczne alternatywy, zanim zaczniemy ograniczać interfejsy inne niż SDK.
Jeśli Twoja aplikacja nie jest kierowana na Androida 13, niektóre z tych zmian mogą nie od razu Cię dotyczyć. Obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z metod lub pól spoza pakietu SDK zawsze wiąże się z wysokim ryzykiem awarii aplikacji.
Jeśli nie masz pewności, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, możesz to przetestować. Jeśli Twoja aplikacja korzysta z interfejsów spoza pakietu SDK, zaplanuj migrację do alternatywnych pakietów SDK. Zdajemy sobie jednak sprawę, że w niektórych przypadkach interfejsy inne niż SDK mogą być przydatne. Jeśli nie możesz znaleźć alternatywy dla interfejsu spoza pakietu SDK, który jest używany w funkcji Twojej aplikacji, poproś o nowy publiczny interfejs API.
Więcej informacji o zmianach wprowadzonych w tej wersji Androida znajdziesz w artykule Aktualizacje ograniczeń interfejsu 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.