Tak jak w poprzednich wersjach, Android 13 wprowadza zmiany w działaniu, które mogą wpłynąć na działanie aplikacji. Poniższe zmiany w działaniu dotyczą tylko aplikacji kierowanych na Androida 13 lub nowszego. Jeśli aplikacja jest kierowana na Androida 13 lub nowszego, w stosownych przypadkach musisz ją zmodyfikować, aby prawidłowo obsługiwała te zachowania.
Zapoznaj się też z listą zmian w działaniu, które wpływają na wszystkie aplikacje działające na Androidzie 13.
prywatność
Zgodę na wyświetlanie powiadomień ma wpływ na wygląd usługi na pierwszym planie
Jeśli użytkownik odmówi przyznania uprawnień do powiadomień, nie zobaczy w panelu powiadomień powiadomień dotyczących usług na pierwszym planie. Użytkownicy nadal będą jednak widzieć w Menedżerze zadań powiadomienia o usługach na pierwszym planie bez względu na to, czy zostały im przyznane.
Nowe uprawnienia w czasie działania dla urządzeń Wi-Fi w pobliżu
W poprzednich wersjach Androida użytkownik musi przyznać aplikacji uprawnienie ACCESS_FINE_LOCATION, aby móc wykonywać kilka typowych przypadków użycia sieci Wi-Fi.
Ponieważ trudno jest użytkownikom powiązać uprawnienia do lokalizacji z funkcjami Wi-Fi, Android 13 (poziom interfejsu API 33) wprowadza w grupie uprawnień NEARBY_DEVICES uprawnienia w czasie działania w przypadku aplikacji, które zarządzają połączeniami urządzenia z pobliskimi punktami dostępu przez Wi-Fi. To uprawnienie NEARBY_WIFI_DEVICES spełnia te kryteria użycia sieci Wi-Fi:
- Znajduj urządzenia w pobliżu, takie jak drukarki i urządzenia przesyłające multimedia, lub łącz się z nimi.
Ten przepływ pracy umożliwia aplikacji wykonywanie takich zadań:
- odbieranie informacji o punkcie dostępu poza pasmem, np. przez BLE.
- Wykrywaj urządzenia i łącz się z nimi przez Wi-Fi Aware oraz łącz się za pomocą lokalnego hotspotu.
- Wykrywaj urządzenia i łącz 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 obejmuje pobliskie urządzenia Wi-Fi Aware.
Jeśli aplikacja nie pobiera informacji o lokalizacji fizycznej z interfejsów API Wi-Fi, w przypadku kierowania na Androida 13 lub nowszego i korzystania z interfejsów API Wi-Fi poproś o NEARBY_WIFI_DEVICES zamiast ACCESS_FINE_LOCATION. Deklarując uprawnienie NEARBY_WIFI_DEVICES, zdecydowanie oświadczaj, że aplikacja nigdy nie pobiera informacji o lokalizacji fizycznej z interfejsów API Wi-Fi. Aby to zrobić, ustaw atrybut android:usesPermissionFlags na neverForLocation. Ten proces jest podobny do procesu na Androidzie 12 (poziom interfejsu API 31) i nowszych, gdy twierdzisz, że dane 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_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 szczegółowych uprawnień do multimediów:
| Typ multimediów | Uprawnienia do wysyłania prośby |
|---|---|
| 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 do 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, wyświetli się tylko jedno okno uprawnień systemowych.
Jeśli Twoja aplikacja otrzymała wcześniej uprawnienie READ_EXTERNAL_STORAGE, wszystkie wymagane uprawnienia READ_MEDIA_* są przyznawane 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ń
Android 13 wprowadza koncepcję dostępu do czujników na ciele, takich jak tętno, temperatura i procent tlenu we krwi „podczas używania”. Ten model dostępu jest bardzo podobny do modelu wprowadzonego w systemie lokalizacji na Androidzie 10 (poziom interfejsu API 29).
Jeśli Twoja aplikacja jest kierowana na Androida 13 i gdy działa w tle, wymaga dostępu do informacji z czujników na ciele, 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 dla aplikacji stan „ograniczony” w związku z wykorzystaniem baterii w tle, a aplikacja jest kierowana na Androida 13, system nie wykona transmisji BOOT_COMPLETED ani LOCKED_BOOT_COMPLETED, dopóki aplikacja nie zostanie uruchomiona z innych powodów.
Z perspektywy użytkownika
Elementy sterujące multimediami pochodzą ze źródła PlaybackState
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) i nowsze wersje system określa opcje multimediów z działań PlaybackState. Dzięki temu system może wyświetlać bogatszy zestaw elementów sterujących, które technicznie są zgodne z telefonami i tabletami, oraz być zgodne ze sposobem renderowania elementów sterujących multimediami na innych platformach z Androidem, np. Android Auto i Android TV.
Rysunek 2 przedstawia przykład tej konfiguracji na telefonie i tablecie.
Przed Androidem 13 system wyświetlał do 5 działań z powiadomienia MediaStyle w kolejności, w jakiej zostały dodane.
W trybie kompaktowym, na przykład w zwiniętych szybkich ustawieniach, wyświetlane były maksymalnie 3 działania określone przy użyciu setShowActionsInCompactView().
Począwszy od Androida 13 system wyświetla do 5 przycisków poleceń na podstawie PlaybackState. Opisaliśmy to w tabeli poniżej. W trybie kompaktowym wyświetlają się tylko 3 pierwsze przedziały działań. W przypadku aplikacji, które nie są kierowane na Androida 13 lub nie zawierają interfejsu PlaybackState, system wyświetli elementy sterujące oparte na liście Action dodanej do powiadomienia MediaStyle, jak opisano w poprzednim akapicie.
| Boks | Działanie | Kryteria |
|---|---|---|
| 1 | Odtwórz |
Obecny stan elementu PlaybackState to:
|
| Wskaźnik wczytywania |
Obecny stan elementu PlaybackState to:
|
|
| Wstrzymaj | Obecny stan (PlaybackState) nie jest jednym z powyższych. |
|
| 2 | Wstecz | PlaybackState działania obejmują ACTION_SKIP_TO_PREVIOUS. |
| Możliwość | PlaybackState działania nie obejmują ACTION_SKIP_TO_PREVIOUS ani PlaybackState działań niestandardowych, które nie obejmują działania niestandardowego, które nie zostało jeszcze wykonane. |
|
| Brak | PlaybackState extras zawiera 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ą ACTION_SKIP_TO_NEXT ani PlaybackState działań niestandardowych, które nie obejmują działania niestandardowego, które nie zostało jeszcze wykonane. |
|
| Brak | PlaybackState extras zawiera 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 wykonane. |
| 5 | Możliwość | PlaybackState działania niestandardowe obejmują działanie niestandardowe, które nie zostało jeszcze wykonane. |
Działania niestandardowe są umieszczane w kolejności, w jakiej zostały dodane do zakresu PlaybackState.
Motyw kolorystyczny aplikacji automatycznie stosowany do treści WebView
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) lub nowszego metoda setForceDark() jest wycofywana, co spowoduje brak operacji, jeśli zostanie wywołana.
Zamiast tego WebView zawsze ustawia zapytanie o media prefers-color-scheme zgodnie z atrybutem motywu aplikacji isLightTheme. Inaczej mówiąc, jeśli isLightTheme ma wartość true lub nie został określony, prefers-color-scheme ma wartość light. W przeciwnym razie ma wartość dark. Oznacza to, że jasny lub ciemny styl treści internetowych jest automatycznie stosowany do motywu aplikacji (jeśli treść go obsługuje).
W przypadku większości aplikacji nowe zachowanie powinno automatycznie stosować odpowiednie style aplikacji, ale zalecamy przetestowanie aplikacji pod kątem ewentualnego ręcznego sterowania ustawieniami trybu ciemnego.
Jeśli nadal chcesz dostosować działanie motywu kolorystycznego aplikacji, użyj metody setAlgorithmicDarkeningAllowed(). Aby zapewnić wsteczną zgodność z poprzednimi wersjami Androida, zalecamy użycie odpowiedniej metody setAlgorithmicDarkeningAllowed() w AndroidzieX.
Zapoznaj się z dokumentacją tej metody, aby dowiedzieć się, jakiego działania możesz oczekiwać w zależności od jej ustawień targetSdkVersion i motywu.
Połączenia
Wycofanie funkcji BluetoothAdapter#enable() i BluetoothAdapter#disable()
W przypadku aplikacji kierowanych na Androida 13 (poziom interfejsu API 33) lub nowszy metody BluetoothAdapter#enable() i BluetoothAdapter#disable() zostały wycofane i zawsze zwracają false.
Te rodzaje aplikacji nie są objęte tymi zmianami:
- Aplikacje właściciela urządzenia
- Aplikacje właściciela profilu
- Aplikacje systemowe
Usługi Google Play
Wymagane uprawnienia dotyczące 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ą 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 deklaruje tych uprawnień w ustawieniach kierowania na Androida 13 lub nowszego, identyfikator wyświetlania reklam jest automatycznie usuwany i zastępowany ciągiem zer.
Jeśli Twoja aplikacja korzysta z pakietów SDK, które w pliku manifestu biblioteki deklarują uprawnienie AD_ID, są one domyślnie scalone z plikiem manifestu. W takim przypadku nie musisz deklarować uprawnień w pliku zarządzania aplikacją.
Więcej informacji znajdziesz w artykule o identyfikatorze wyświetlania reklam w Centrum pomocy Konsoli Play.
Zaktualizowano ograniczenia dotyczące aplikacji innych niż SDK
Android 13 zawiera zaktualizowane listy podlegających ograniczeniom interfejsów spoza pakietu SDK opracowane na podstawie współpracy z deweloperami aplikacji na Androida i najnowszych testów wewnętrznych. Zanim ograniczymy dostęp do interfejsów spoza SDK, dbamy o to, aby w miarę możliwości dostępne były publiczne alternatywy.
Jeśli Twoja aplikacja nie jest kierowana na Androida 13, niektóre z tych zmian mogą Cię nie odczuć od razu. Mimo że obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), używanie dowolnej metody lub pola spoza pakietu SDK niesie ze sobą wysokie ryzyko uszkodzenia aplikacji.
Jeśli nie masz pewności, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, możesz przetestować ją, aby to sprawdzić. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych pakietów SDK. Zdajemy sobie jednak sprawę, że niektóre aplikacje mają odpowiednie przypadki użycia w zakresie interfejsów spoza SDK. Jeśli nie możesz znaleźć alternatywy dla interfejsu innego niż SDK dla funkcji w aplikacji, poproś o nowy publiczny interfejs API.
Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Aktualizacje ograniczeń interfejsu spoza pakietu SDK w Androidzie 13. Więcej informacji o interfejsach spoza SDK znajdziesz w artykule Ograniczenia interfejsów innych niż SDK.