Podobnie jak w przypadku poprzednich wersji Androida, w Androidzie 13 wprowadziliśmy zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wyłącznie aplikacji kierowanych na Androida 13 lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 13 lub nowszego, zmodyfikuj ją, aby w odpowiednich przypadkach obsługiwała te działania.
Zapoznaj się też z listą zmian w działaniu, które wpływają na wszystkie aplikacje działające na Androidzie 13.
Prywatność
Zgoda na wyświetlanie powiadomień wpływa na wygląd usługi działającej na pierwszym planie
Jeśli użytkownik nie wyrazi zgody na wyświetlanie powiadomień, nie będzie widzieć powiadomień związanych z usługami działającymi na pierwszym planie w obszarze powiadomień. Użytkownicy nadal będą jednak widzieć powiadomienia związane z usługami na pierwszym planie w Menedżerze zadań, niezależnie od tego, czy przyznano zgodę na wyświetlanie powiadomień.
Nowe uprawnienia w czasie działania aplikacji dotyczące urządzeń Wi-Fi w pobliżu
W starszych wersjach Androida użytkownik musi przyznać aplikacji uprawnienie ACCESS_FINE_LOCATION, aby mogła ona wykonywać kilka typowych działań związanych z Wi-Fi.
Użytkownikom trudno jest powiązać uprawnienia dostępu do lokalizacji z funkcjami Wi-Fi, dlatego w Androidzie 13 (API na poziomie 33) wprowadziliśmy uprawnienia w czasie działania aplikacji 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) umożliwia korzystanie z Wi-Fi w takich przypadkach jak:
- znajdować urządzenia w pobliżu, takie jak drukarki czy urządzenia do przesyłania multimediów, i łączyć się z nimi;
Ten proces umożliwia aplikacji wykonywanie takich zadań:
- otrzymywać informacje o AP poza pasmem, np. przez BLE;
- wykrywanie urządzeń i łączenie się z nimi przez Wi-Fi Aware oraz łączenie się za pomocą lokalnego hotspotu;
- wykrywać urządzenia i łączyć się z nimi przez Wi-Fi Direct;
- nawiązywać połączenie ze znanym identyfikatorem SSID, np. samochodu lub inteligentnego urządzenia domowego;
- Uruchom hotspot tylko lokalny.
- Zasięg do urządzeń Wi-Fi Aware w pobliżu.
Jeśli aplikacja nie pobiera informacji o lokalizacji fizycznej z interfejsów API Wi-Fi, poproś o NEARBY_WIFI_DEVICES zamiast ACCESS_FINE_LOCATION, gdy kierujesz aplikację na Androida 13 lub nowszego i używasz interfejsów API Wi-Fi. Gdy deklarujesz uprawnienie NEARBY_WIFI_DEVICES, wyraźnie zaznacz, że aplikacja nigdy nie uzyskuje informacji o lokalizacji fizycznej z interfejsów API Wi-Fi. Aby to zrobić, ustaw atrybut android:usesPermissionFlags na neverForLocation. Ten proces jest podobny do tego, który wykonujesz na 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 proszeniu o uprawnienia dostępu 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 musi mieć dostęp 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 uprawnienia READ_EXTERNAL_STORAGE:
| Typ multimediów | Uprawnienia do wysyłania próśb |
|---|---|
| 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 poprosisz jednocześnie o uprawnienia READ_MEDIA_IMAGES i READ_MEDIA_VIDEO, pojawi się tylko jedno okno uprawnień systemowych.
Jeśli Twoja aplikacja miała wcześniej uprawnienie READ_EXTERNAL_STORAGE, wszystkie uprawnienia READ_MEDIA_*, o które poprosisz, zostaną automatycznie przyznane 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 biometrycznych w tle wymaga nowych uprawnień
W Androidzie 13 wprowadziliśmy koncepcję dostępu „podczas używania” do czujników biometrycznych, takich jak tętno, temperatura i poziom saturacji krwi. Ten model dostępu jest bardzo podobny do modelu wprowadzonego w systemie w przypadku lokalizacji na Androidzie 10 (poziom interfejsu API 29).
Jeśli Twoja aplikacja jest kierowana na Androida 13 i wymaga dostępu do informacji z czujników biometrycznych podczas działania w tle, musisz zadeklarować nowe uprawnienie BODY_SENSORS_BACKGROUND oprócz dotychczasowego uprawnienia BODY_SENSORS.
Wydajność i bateria
Wykorzystanie zasobów baterii
Jeśli użytkownik przełączy aplikację w stan „ograniczony” w odniesieniu do wykorzystania baterii w tle, a aplikacja jest kierowana na Androida 13, system nie dostarczy komunikatu BOOT_COMPLETED ani LOCKED_BOOT_COMPLETED, dopóki aplikacja nie zostanie uruchomiona z innych powodów.
Interfejs użytkownika
Opcje sterowania multimediami pochodzące z aplikacji PlaybackState
W przypadku aplikacji kierowanych na Androida 13 (API na poziomie 33) i nowsze wersje system pobiera opcje sterowania 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 między telefonami i tabletami, a także są zgodne ze sposobem renderowania elementów sterujących multimediami na innych platformach Androida, takich jak Android Auto i Android TV.
Rysunek 2 pokazuje, jak wygląda to na telefonie i tablecie.
W wersjach starszych niż Android 13 system wyświetlał maksymalnie 5 działań z powiadomienia MediaStyle w kolejności, w jakiej zostały dodane.
W trybie kompaktowym, np. w zwiniętych szybkich ustawieniach, wyświetlane były maksymalnie 3 działania określone za pomocą setShowActionsInCompactView().
Począwszy od Androida 13 system wyświetla maksymalnie 5 przycisków poleceń na podstawie PlaybackState, jak opisano w tabeli poniżej. W trybie kompaktowym wyświetlane są tylko pierwsze 3 miejsca na działania. W przypadku aplikacji, które nie są przeznaczone na Androida 13, lub tych, które nie zawierają elementu PlaybackState, system wyświetli elementy sterujące na podstawie listy Action dodanej do powiadomienia MediaStyle, jak opisano w poprzednim akapicie.
| Boks | Działanie | Kryteria |
|---|---|---|
| 1 | Odtwórz |
Bieżący stan zasobu PlaybackState to jedna z tych wartości:
|
| Wskaźnik postępu wczytywania |
Bieżący stan zasobu PlaybackState to jedna z tych wartości:
|
|
| Wstrzymaj | Bieżący stan zasobu PlaybackState nie jest żadnym z powyższych. |
|
| 2 | Wstecz | PlaybackState działania obejmują ACTION_SKIP_TO_PREVIOUS. |
| Niestandardowy | PlaybackState działania nie obejmują ACTION_SKIP_TO_PREVIOUS, a PlaybackState działania niestandardowe obejmują działanie niestandardowe, które nie zostało jeszcze umieszczone. |
|
| Pusta | Dodatki PlaybackState zawierają wartość logiczną true dla klucza SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV. |
|
| 3 | Dalej | PlaybackState działania obejmują ACTION_SKIP_TO_NEXT. |
| Niestandardowy | PlaybackState działania nie obejmują ACTION_SKIP_TO_NEXT, a PlaybackState działania niestandardowe obejmują działanie niestandardowe, które nie zostało jeszcze umieszczone. |
|
| Pusta | Dodatki PlaybackState zawierają wartość logiczną true dla klucza SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT. |
|
| 4 | Niestandardowy | PlaybackState działania niestandardowe zawierają działanie niestandardowe, które nie zostało jeszcze umieszczone. |
| 5 | Niestandardowy | PlaybackState działania niestandardowe zawierają działanie niestandardowe, które nie zostało jeszcze umieszczone. |
Działania niestandardowe są umieszczane w kolejności, w jakiej zostały dodane do PlaybackState.
Motyw kolorystyczny aplikacji jest automatycznie stosowany do treści WebView
W przypadku aplikacji kierowanych na Androida 13 (API na poziomie 33) lub nowszego metoda setForceDark() jest wycofana, co oznacza, że jej wywołanie nie przyniesie żadnego efektu.
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 ma wartość light. W przeciwnym razie ma wartość dark. Oznacza to, że jasny lub ciemny styl treści z internetu jest stosowany automatycznie, aby pasował do motywu aplikacji, jeśli treści go obsługują.
W przypadku większości aplikacji nowe zachowanie powinno automatycznie stosować odpowiednie style aplikacji, ale warto przetestować aplikację, aby sprawdzić, czy nie występują przypadki, w których ustawienia trybu ciemnego były kontrolowane ręcznie.
Jeśli nadal chcesz dostosować zachowanie motywu kolorystycznego aplikacji, użyj metody setAlgorithmicDarkeningAllowed(). Aby zapewnić zgodność wsteczną z poprzednimi wersjami Androida, zalecamy użycie odpowiednika metody setAlgorithmicDarkeningAllowed() w AndroidX.
Więcej informacji o tym, jakiego zachowania możesz oczekiwać w aplikacji w zależności od ustawień targetSdkVersion i motywu, znajdziesz w dokumentacji tej metody.
Połączenia
Wycofanie metod BluetoothAdapter#enable() i BluetoothAdapter#disable()
W przypadku aplikacji kierowanych na Androida 13 (API na poziomie 33) lub nowszego metody BluetoothAdapter#enable() i BluetoothAdapter#disable() są wycofane i zawsze zwracają wartość false.
Te zmiany nie dotyczą tych typów aplikacji:
- aplikacje właściciela urządzenia,
- Aplikacje właściciela profilu
- Aplikacje systemowe
Usługi Google Play
Uprawnienia wymagane w przypadku identyfikatora wyświetlania reklam
Aplikacje, które używają identyfikatora wyświetlania reklam Usług Google Play i są kierowane na Androida 13 (API na poziomie 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 tych uprawnień, gdy 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 deklarują uprawnienie AD_ID w pliku manifestu biblioteki, uprawnienie to jest domyślnie scalane z plikiem 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 dotyczące interfejsów niebędących częścią pakietu SDK
Android 13 zawiera zaktualizowane listy ograniczonych interfejsów spoza pakietu SDK, które powstały we współpracy z programistami aplikacji na Androida i na podstawie najnowszych testów wewnętrznych. Zanim ograniczymy dostęp do interfejsów innych niż SDK, staramy się zapewnić publiczne alternatywy.
Jeśli Twoja aplikacja nie jest kierowana na Androida 13, niektóre z tych zmian mogą nie mieć na nią 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 używanie jakiejkolwiek metody lub pola spoza pakietu SDK zawsze wiąże się z dużym ryzykiem awarii aplikacji.
Jeśli nie masz pewności, czy Twoja aplikacja używa interfejsów innych niż SDK, możesz ją przetestować, aby to sprawdzić. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych rozwiązań SDK. Rozumiemy jednak, że niektóre aplikacje mają uzasadnione przypadki użycia interfejsów spoza pakietu SDK. Jeśli nie możesz znaleźć alternatywy dla interfejsu spoza pakietu SDK w przypadku funkcji w aplikacji, poproś o nowy publiczny interfejs API.
Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Aktualizacje ograniczeń interfejsów innych niż SDK w Androidzie 13. Więcej informacji o interfejsach spoza pakietu SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów spoza pakietu SDK.