Podobnie jak w poprzednich wersjach Android 13 zawiera zmiany w działaniu aplikacji, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą tylko 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 w działaniu, które wpływają 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 odmówi przyznania uprawnień do wyświetlania 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 zadań 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) pozwala na realizację takich zastosowań 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 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 dotyczące multimediów
READ_MEDIA_AUDIO.Jeśli Twoja aplikacja jest kierowana na Androida 13 lub nowszego i potrzebuje dostępu do plików multimedialnych utworzonych przez inne aplikacje, zamiast uprawnienia READ_EXTERNAL_STORAGE musisz poprosić o co najmniej 1 z tych uprawnień dotyczących szczegółowych multimediów:
| 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 uprawnienia dotyczące szczegółowych multimediów.
Rysunek 1 przedstawia aplikację, która prosi o uprawnienie READ_MEDIA_AUDIO.
Jeśli poprosisz jednocześnie o uprawnienie READ_MEDIA_IMAGES i READ_MEDIA_VIDEO, pojawi się tylko 1 okno uprawnień systemowych.
Jeśli Twojej aplikacji przyznano wcześniej uprawnienia READ_EXTERNAL_STORAGE, wszystkie wymagane uprawnienia READ_MEDIA_* zostaną przyznane automatycznie podczas uaktualniania. 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 nowych uprawnień
W Androidzie 13 wprowadziliśmy koncepcję dostępu „podczas używania” do czujników na ciele, takich jak tętno, temperatura czy procent tlenu we krwi. 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 ustawi Twoją aplikację w stanie „ograniczonym” z powodu wykorzystania baterii w tle, gdy aplikacja jest kierowana na Androida 13, system nie udostępni transmisji BOOT_COMPLETED ani LOCKED_BOOT_COMPLETED, dopóki aplikacja nie zostanie uruchomiona z innych powodów.
Z perspektywy użytkownika
Opcje sterowania multimediami pochodzą z: PlaybackState
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) i nowsze wersje system czerpie opcje sterowania multimediami z działań PlaybackState. Dzięki temu system może wyświetlać bogatszy zestaw opcji, które są technicznie spójne między telefonami i tabletami, a także są zgodne z tym, jak elementy sterujące multimediami są renderowane na innych platformach z Androidem, takich jak Android Auto i Android TV.
Ilustracja 2 pokazuje przykład, jak to wygląda na telefonie i tablecie.
Przed Androidem 13 system wyświetlał maksymalnie 5 działań z powiadomienia MediaStyle w kolejności ich dodania.
W trybie kompaktowym, na przykład w zwiniętych szybkich ustawieniach, wyświetlane były maksymalnie 3 działania określone za pomocą funkcji 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 które nie zawierają elementu PlaybackState, system wyświetli ustawienia na podstawie listy Action dodanej do powiadomienia MediaStyle w sposób opisany w poprzednim akapicie.
| Boks | Działanie | Kryteria |
|---|---|---|
| 1 | Odtwarzaj |
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 elementu PlaybackState.
Motyw kolorystyczny aplikacji jest stosowany automatycznie do treści WebView
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) lub nowszego metoda setForceDark() jest wycofana, co powoduje, że w przypadku jej wywołania nie działa.
Zamiast tego WebView zawsze ustawia zapytanie o media 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 z internetu jest automatycznie stosowany do motywu aplikacji, jeśli obsługuje go.
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 chcesz dostosować zachowanie motywu kolorystycznego swojej aplikacji, użyj metody setAlgorithmicDarkeningAllowed(). Aby zapewnić 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.
Połączenia
Wycofane BluetoothAdapter#enable() i BluetoothAdapter#disable()
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) lub nowszego metody BluetoothAdapter#enable() i BluetoothAdapter#disable() zostały 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
Wymagana zgoda na 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 API 33) lub nowszego, muszą zadeklarować normalne uprawnienia AD_ID w pliku manifestu aplikacji 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 Twoja aplikacja nie zadeklaruje tych uprawnień na Androidzie 13 lub nowszym, identyfikator wyświetlania reklam zostanie automatycznie usunięty i zastąpiony ciągiem zer.
Jeśli Twoja aplikacja korzysta z pakietów SDK, które w pliku manifestu biblioteki deklarują uprawnienia AD_ID, uprawnienia te są domyślnie łączone z plikiem manifestu aplikacji. W takiej sytuacji nie musisz deklarować uprawnień w najbardziej zaawansowanym pliku aplikacji.
Więcej informacji znajdziesz w artykule Identyfikator wyświetlania reklam w Centrum pomocy Konsoli Play.
Zaktualizowano ograniczenia spoza pakietu 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. 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 13, 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 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.