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 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 udzielenia uprawnień do powiadomień, nie będzie widzieć powiadomień związanych z usługami na pierwszym planie w schowku powiadomień. 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 do działania w ramach grupy 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;
Ten proces umożliwia aplikacji wykonywanie takich zadań:
- 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.
- wykrywać urządzenia i łączyć się z nimi przez Wi-Fi Direct.
- Inicjowanie połączenia z znanym SSID, takim jak samochód czy inteligentne urządzenie domowe.
- Uruchom hotspot lokalny.
- Zasięg do urządzeń z obsługą Wi-Fi Aware w pobliżu.
Jeśli Twoja aplikacja nie uzyskuje informacji o fizycznej lokalizacji z interfejsów API Wi-Fi, to gdy kierujesz ją na Androida 13 lub nowszego i korzystasz z interfejsów API Wi-Fi, żądaj 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 tego, który wykonujesz w Androidzie 12 (poziom interfejsu API 31) lub nowszym, gdy potwierdzasz, że informacje o urządzeniu 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 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 | 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.
Na rysunku 1 widać aplikację, która prosi o uprawnienie READ_MEDIA_AUDIO.
Jeśli żądasz jednocześnie uprawnień 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ć 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
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 tego, który został wprowadzony w systemie w przypadku lokalizacji w Androidzie 10 (poziom interfejsu API 29).
Jeśli Twoja aplikacja jest kierowana na Androida 13 i wymaga dostępu do informacji z czujników na ciele podczas działania w tle, musisz zadeklarować nowe uprawnienia BODY_SENSORS_BACKGROUND oprócz dotychczasowych uprawnień BODY_SENSORS.
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 przekaże 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 dodania.
W trybie kompaktowym, np. w zwiniętej szybkiej ustawień, 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 pierwsze 3 miejsca na akcję. W przypadku aplikacji, które nie są przeznaczone 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 usługi PlaybackState to:
|
|
| Wstrzymaj | Obecny stan 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 | PlaybackState Dodatkowe informacje obejmują 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 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ą działanie niestandardowe, które nie zostało jeszcze umieszczone. |
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 akcji.
Zamiast tego WebView zawsze ustawia zapytanie o multimedia prefers-color-scheme zgodnie z atrybutem motywu aplikacji (isLightTheme). Innymi słowy, jeśli isLightTheme to true lub nie jest określony, prefers-color-scheme to light; w przeciwnym razie jest to 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().
Więcej informacji o zachowaniu aplikacji w zależności od ustawień targetSdkVersion i motywów znajdziesz w dokumentacji danej metody.
Łączność
Funkcje BluetoothAdapter#enable() i BluetoothAdapter#disable() są przestarzałe
W przypadku aplikacji kierowanych na Androida 13 (poziom API 33) lub nowszego metody BluetoothAdapter#enable() i BluetoothAdapter#disable() są wycofane i zawsze zwracają false.
Z tych zmian wyłączone są aplikacje 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 Twoja aplikacja nie zadeklaruje tego uprawnienia, a jest kierowana na Androida 13 lub nowszego, 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.