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 nowszą wersję, w razie potrzeby zmodyfikuj ją, aby 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 widzą powiadomienia związane z usługami na pierwszym planie w Menedżerze zadań, niezależnie od tego, czy przyznano uprawnienia do wysyłania powiadomień.
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, aby umożliwić jej wykonywanie kilku typowych zadań związanych z Wi-Fi.
Ponieważ użytkownicy mają trudności z powiązaniem uprawnień dotyczących lokalizacji z funkcjami Wi-Fi, Android 13 (poziom API 33) wprowadza uprawnienie w czasie działania w grupie uprawnień NEARBY_DEVICES dla aplikacji, które zarządzają połączeniami urządzenia z punktami dostępu w pobliżu 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;
Dzięki temu aplikacja może wykonywać takie zadania:
- otrzymywać informacje o AP poza pasmem, np. przez BLE;
- wykrywać urządzenia i łączyć się z nimi przez Wi-Fi Aware oraz łączyć się z hotspotem tylko lokalnym.
- Wykrywanie urządzeń i łączenie 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. Podczas deklarowania uprawnienia NEARBY_WIFI_DEVICES musisz wyraźnie zadeklarować, ż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 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
READ_MEDIA_AUDIOuprawnienia.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 mediów | Prośba o uprawnienia |
|---|---|
| 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 nowego uprawnienia
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 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 API 33) lub nowszego system wyprowadza 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 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 akcji na podstawie PlaybackState, jak opisano w tabeli poniżej. 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 | Odtwórz |
Bieżący stan elementu PlaybackState to:
|
| Wskaźnik postępu ładowania |
Obecny stan PlaybackState to:
|
|
| Wstrzymaj | Bieżący stan elementu PlaybackState nie stanowi żadnej z powyższych opcji. |
|
| 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 | PlaybackState Dodatkowe informacje obejmują 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ść | PlaybackState Działania nie obejmują elementów ACTION_SKIP_TO_NEXT i PlaybackState, a działania 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ą działanie niestandardowe, które nie zostało jeszcze umieszczone. |
| 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 aplikacji, ale warto przetestować aplikację, aby sprawdzić, czy nie ma żadnych przypadków, w których użytkownik mógł ręcznie kontrolować ustawienia trybu ciemnego.
Jeśli nadal musisz dostosować zachowanie motywu kolorów w aplikacji, użyj metody setAlgorithmicDarkeningAllowed(). Aby zapewnić zgodność wsteczną z wcześniejszymi wersjami Androida, zalecamy użycie w Androidzie X 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ść
Funkcje BluetoothAdapter#enable() i BluetoothAdapter#disable() są przestarzałe
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.
Zmiany te nie dotyczą aplikacji z tych kategorii:
- 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.
Zaktualizowane ograniczenia inne niż związane z pakietem SDK
Android 13 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK, które zostały opracowane we współpracy z deweloperami Androida i na podstawie 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 mieć na Ciebie natychmiastowego wpływu. 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 używa interfejsów innych niż SDK, możesz przetestować ją, aby się tego dowiedzieć. 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 w tej wersji Androida znajdziesz w artykule Zmiany ograniczeń interfejsu niebędącego interfejsem SDK w Androidzie 13. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia interfejsów innych niż SDK.