Podobnie jak w poprzednich wersjach, Android 13 zawiera zmiany w działaniu, które mogą mieć wpływ . Poniższe zmiany w działaniu dotyczą tylko aplikacji, na które są kierowane Androida w wersji 13 lub nowszej. Jeśli Twoja aplikacja jest kierowana na Androida 13 lub nowszego, w razie potrzeby zmodyfikować aplikację, aby obsługiwała te zachowania.
Zapoznaj się też z listą zmian w działaniu, które mają wpływ na wszystkie aplikacje na Androidzie 13.
Prywatność
Uprawnienia dotyczące powiadomień wpływają na wygląd usługi na pierwszym planie
Jeśli użytkownik zaprzecza zgodę na wyświetlanie powiadomień, nie widzą powiadomień związanych z usługami na pierwszym planie panelu powiadomień. Użytkownicy nadal będą jednak widzieć powiadomienia związane z usługami na pierwszym planie w Menedżer zadań, niezależnie od tego, czy użytkownik wyraził zgodę na wyświetlanie powiadomień.
Nowe uprawnienia w czasie działania dla urządzeń Wi-Fi w pobliżu
W poprzednich wersjach Androida użytkownik musi przyznać aplikacji:
ACCESS_FINE_LOCATION
i dostęp do niej w kilku typowych przypadkach użycia Wi-Fi.
Ponieważ użytkownikom trudno jest powiązać dostęp do lokalizacji z Wi-Fi
funkcji, Android 13 (poziom interfejsu API 33) wprowadza uprawnienia czasu działania
NEARBY_DEVICES
grupa uprawnień dla aplikacji, które zarządzają połączeniami urządzenia z dostępem w pobliżu
punktów przez Wi-Fi. To uprawnienie,
NEARBY_WIFI_DEVICES
obsługuje takie przypadki użycia Wi-Fi:
- Znajduj urządzenia w pobliżu, takie jak drukarki czy urządzenia przesyłające multimedia, i łącz się z nimi.
Dzięki temu aplikacja może wykonywać takie zadania:
- 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.
- Wykrywanie urządzeń i łączenie się z nimi przez Wi-Fi Direct.
- Zainicjuj połączenie ze znanym identyfikatorem SSID, takim jak samochód lub inteligentne urządzenie domowe.
- Uruchom lokalny hotspot.
- Zasięg z urządzeniami Wi-Fi Aware w pobliżu.
O ile aplikacja nie pobiera informacji o lokalizacji fizycznej z Wi-Fi
API należy wysłać żądanie NEARBY_WIFI_DEVICES zamiast ACCESS_FINE_LOCATION, gdy
są kierowane na Androida 13 lub nowszego i używają interfejsów API Wi-Fi; Gdy zadeklarujesz
NEARBY_WIFI_DEVICES, stanowczo oznacz, że aplikacja nigdy
pobiera informacje o lokalizacji fizycznej z interfejsów API Wi-Fi. W tym celu ustaw parametr
android:usesPermissionFlags do neverForLocation. Ten proces
podobnie jak w Androidzie 12 (poziom interfejsu API 31) i nowszym,
deklarować, że informacje z urządzenia Bluetooth nigdy nie są używane do
lokalizacji.
Dowiedz się więcej o tym, poprosić o dostęp do urządzeń Wi-Fi w pobliżu
Szczegółowe uprawnienia dotyczące multimediów
READ_MEDIA_AUDIO.Jeśli Twoja aplikacja jest kierowana na Androida 13 lub nowszego i wymaga
dostęp do plików multimedialnych zainstalowanych przez inne aplikacje
utworzony, musisz
poproś o co najmniej jedno z tych szczegółowych uprawnień dotyczących multimediów zamiast
READ_EXTERNAL_STORAGE.
uprawnienie:
| 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 w innej aplikacji, sprawdź, czy użytkownik ją przyznał odpowiednie uprawnienia dotyczące szczegółowych multimediów w aplikacji.
Rysunek 1 przedstawia aplikację, która prosi o uprawnienie READ_MEDIA_AUDIO.
Jeśli poprosisz o uprawnienie READ_MEDIA_IMAGES oraz
READ_MEDIA_VIDEO uprawnienie jednocześnie, tylko 1 uprawnienie systemowe
pojawi się okno dialogowe.
Jeśli Twojej aplikacji przyznano wcześniej
READ_EXTERNAL_STORAGE
wszystkie wymagane uprawnienia READ_MEDIA_*
automatycznie podczas uaktualniania. Aby to sprawdzić, możesz użyć tego polecenia ADB
ulepszone uprawnienia:
adb shell cmd appops get --uid PACKAGE_NAME
Korzystanie z czujników na ciele w tle wymaga nowych uprawnień
Android 13 wprowadza pojęcie „podczas używania” dostęp dla czujniki ciała, takie jak tętno, temperatura i procent tlenu we krwi. Ten jest bardzo podobny do modelu wprowadzonego przez system dla lokalizacji w Androidzie 10 (poziom interfejsu API 29).
Jeśli Twoja aplikacja jest kierowana na Androida 13 i wymaga dostępu do czujnika na ciele
podczas działania w tle, musisz zadeklarować nowy
BODY_SENSORS_BACKGROUND
oprócz istniejących uprawnień
BODY_SENSORS
uprawnienia.
Wydajność i bateria
Wykorzystanie zasobów baterii
Jeśli użytkownik umieści aplikację w
„z ograniczeniami” stan dla
wykorzystanie baterii w tle
jeśli aplikacja jest kierowana na Androida 13, system nie udostępnia
BOOT_COMPLETED lub LOCKED_BOOT_COMPLETED do
aplikacja została uruchomiona z innych powodów.
Interfejs użytkownika
Opcje sterowania multimediami pochodzą z: PlaybackState
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) i nowsze wersje system
opcje sterowania multimediami z:
PlaybackState działania. Ten
pozwala systemowi na wyświetlanie bogatszego zestawu ustawień, które technicznie
między telefonami i tabletami, a także
elementy sterujące są renderowane na innych platformach Androida, takich jak Android Auto
Android TV.
Ilustracja 2 pokazuje, jak to wygląda na telefonie i tablecie. .
Przed Androidem 13 system wyświetlał do 5 działań z MediaStyle
powiadomienia w kolejności, w jakiej zostały dodane.
W trybie kompaktowym, na przykład w zwiniętych szybkich ustawieniach, do
3 działania określone za pomocą parametru setShowActionsInCompactView()
które zostały wyświetlone.
Począwszy od Androida 13 system wyświetla do 5 przycisków polecenia w zależności od tego,
w PlaybackState, jak opisano w tej tabeli. W trybie kompaktowym tylko pierwsze trzy
przedziały czasu na działania. W przypadku aplikacji, które nie są kierowane na Androida 13 lub
które nie zawierają parametru PlaybackState, system wyświetli ustawienia na podstawie:
listę Action dodaną do powiadomienia MediaStyle zgodnie z opisem w
poprzedniego akapitu.
| Boks | Działanie | Kryteria |
|---|---|---|
| 1 | Odtwórz |
Bieżący stan elementu PlaybackState to:
|
| Wskaźnik postępu ładowania |
Bieżący stan elementu PlaybackState to:
|
|
| Wstrzymaj | Bieżący stan elementu PlaybackState nie stanowi żadnej z powyższych opcji. |
|
| 2 | Wstecz | PlaybackState działań, w tym ACTION_SKIP_TO_PREVIOUS. |
| Możliwość | Działania PlaybackState nie obejmują działań niestandardowych ACTION_SKIP_TO_PREVIOUS i PlaybackState, które obejmują działanie niestandardowe, które nie zostały jeszcze wykonane. |
|
| Puste | Rozszerzenia PlaybackState zawierają wartość logiczną true dla klucza SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV. |
|
| 3 | Dalej | PlaybackState działań, w tym ACTION_SKIP_TO_NEXT. |
| Możliwość | Działania PlaybackState nie obejmują działań niestandardowych ACTION_SKIP_TO_NEXT i PlaybackState, które obejmują działanie niestandardowe, które nie zostały jeszcze wykonane. |
|
| Puste | Rozszerzenia PlaybackState zawierają 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 kolejności, w jakiej zostały dodane do
PlaybackState
Motyw kolorystyczny aplikacji jest stosowany automatycznie do treści WebView
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) lub nowszego parametr
setForceDark()
jest przestarzała, co skutkuje wywołaniem tej metody bez działania.
Zamiast tego WebView teraz zawsze ustawia
zapytanie o media prefers-color-scheme zgodnie z atrybutem motywu aplikacji,
isLightTheme W innym
słowa, jeśli isLightTheme ma wartość true lub nie określono, prefers-color-scheme to
light; w przeciwnym razie ma wartość dark. Takie działanie oznacza, że treści internetowe
jasny lub ciemny styl jest stosowany automatycznie, aby pasował do motywu aplikacji, jeśli
treści, które ją obsługują.
W przypadku większości aplikacji nowy sposób działania powinien obejmować odpowiednie style aplikacji. automatycznie. Warto jednak przetestować aplikację i sprawdzić, czy nie mógł ręcznie sterować ustawieniami trybu ciemnego.
Jeśli nadal chcesz dostosować działanie motywu kolorystycznego aplikacji, skorzystaj z
setAlgorithmicDarkeningAllowed()
. Aby zapewnić zgodność wsteczną z poprzednimi wersjami Androida,
zalecamy użycie odpowiednika
setAlgorithmicDarkeningAllowed()
w AndroidzieX.
Zapoznaj się z dokumentacją danej metody, aby dowiedzieć się, jakie działania
w zależności od
targetSdkVersion i motyw
ustawieniach.
Łączność
Wycofane BluetoothAdapter#enable() i BluetoothAdapter#disable()
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) lub nowszego
BluetoothAdapter#enable() i
Metody BluetoothAdapter#disable() zostały wycofane i zawsze
zwróć 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
Wymagana zgoda na dostęp do identyfikatora wyświetlania reklam
Aplikacje korzystające z reklam w Usługach Google Play
Identyfikator oraz
są kierowane na Androida 13 (poziom API 33) i nowsze
zadeklarować normalne uprawnienia AD_ID w
manifestu 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 deklaruje tych uprawnień w ramach kierowania na Androida 13 lub identyfikator wyświetlania reklam jest automatycznie usuwany i zastępowany ciągiem znaków. zer.
Jeśli Twoja aplikacja używa pakietów SDK, które zadeklarują uprawnienia AD_ID w bibliotece
pliku manifestu, uprawnienia zostaną scalone z plikiem manifestu aplikacji przez
wartość domyślną. W takim przypadku nie musisz deklarować uprawnień w sekcji
.
Więcej informacji znajdziesz w artykule Reklamy ID w w Centrum pomocy Konsoli Play.
Zaktualizowano ograniczenia spoza pakietu SDK
Android 13 zawiera zaktualizowane listy ograniczonych list aplikacji spoza pakietu SDK oparte na współpracy z deweloperami aplikacji na Androida oraz do testów wewnętrznych. Gdy tylko jest to możliwe, dbamy o to, by alternatywne rozwiązania były dostępne publicznie, zanim wprowadzimy ograniczenia w interfejsach innych niż SDK.
Jeśli Twoja aplikacja nie jest kierowana na Androida 13, niektóre z tych zmian mogą nie być od razu widoczne. Mimo że obecnie możesz korzystać z wybranych interfejsy inne niż SDK (w zależności od docelowego interfejsu API aplikacji, ), Korzystanie z dowolnej metody lub pola niezwiązanego z pakietem SDK zawsze wiąże się z dużym ryzykiem naruszenia .
Jeśli nie wiesz, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, możesz przetestować aby się dowiedzieć. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migracji do alternatywnych pakietów SDK. Rozumiemy jednak, że niektóre aplikacje z prawidłowymi zastosowaniami interfejsów innych niż SDK. Jeśli nie możesz znaleźć innej do interfejsu innego niż SDK w przypadku danej funkcji, musisz poprosić o utworzenie nowego publicznego interfejsu API.
Więcej informacji o zmianach w tej wersji Androida znajdziesz w sekcji Aktualizacje ograniczeń związanych z interfejsem innym niż SDK w Androidzie 13. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK .