Zmiany w działaniu: wszystkie aplikacje

Platforma Android 15 wprowadza zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Te zmiany w działaniu dotyczą wszystkich aplikacji działających na Androidzie 15, niezależnie od targetSdkVersion. Przetestuj aplikację, a potem w razie potrzeby zmodyfikuj ją, aby prawidłowo je obsługiwać.

Zapoznaj się też z listą zmian w działaniu, które mają wpływ tylko na aplikacje kierowane na Androida 15.

Główna funkcja

Android 15 modyfikuje i rozwija różne podstawowe funkcje systemu Android.

Zmiany stanu zatrzymania pakietu

Intencją stanu pakietu FLAG_STOPPED (który użytkownicy mogą korzystać z kompilacji AOSP przez przytrzymanie ikony aplikacji i wybranie „Wymuś zatrzymanie”) zawsze polegał na utrzymywaniu aplikacji w tym stanie do momentu, gdy użytkownik wyraźnie usunie ją z tego stanu, bezpośrednio ją uruchamiając lub pośrednio wchodząc z nią w interakcję (np. za pomocą arkusza udostępniania lub widżetu, wybierając ją jako animowaną tapetę itp.). W Androidzie 15 aktualizujemy działanie systemu, aby dostosować je do zamierzonego działania. Aplikacje można usuwać ze stanu zatrzymania tylko poprzez bezpośrednie lub pośrednie działania użytkownika.

Aby umożliwić działanie zamierzonego działania, oprócz dotychczasowych ograniczeń system anuluje też wszystkie intencje oczekujące, gdy aplikacja zostanie zatrzymana na Androidzie 15. Gdy działanie użytkownika spowoduje usunięcie aplikacji ze stanu zatrzymania, transmisja ACTION_BOOT_COMPLETED zostanie przesłana do aplikacji, co da Ci możliwość ponownej rejestracji oczekujących intencji.

Możesz wywołać nową metodę ApplicationStartInfo.wasForceStopped(), aby sprawdzić, czy aplikacja została zatrzymana.

Obsługa rozmiaru stron 16 KB

Do tej pory Android obsługiwał tylko strony o rozmiarze 4 KB, co zapewniało optymalną wydajność pamięci systemowej pod kątem średniej ilości pamięci dostępnej zwykle na urządzeniach z Androidem. Począwszy od Androida 15, Android obsługuje urządzenia, na których rozmiar strony wynosi 16 KB (16 KB).

Producenci wciąż tworzą urządzenia z większą ilością pamięci RAM, dlatego wiele z nich zostanie prawdopodobnie skonfigurowanych tak, aby rozmiar strony wynosił 16 KB (i w miarę potrzeby można zwiększyć ich wydajność). Dodanie obsługi urządzeń 16 KB umożliwia działanie aplikacji na tych urządzeniach i ułatwia jej poprawę wydajności. Aby Ci w tym pomóc, przygotowaliśmy wskazówki dotyczące sprawdzania, czy dotyczy to Twojej aplikacji, odtwarzania aplikacji (w stosownych przypadkach) oraz przetestowania aplikacji w środowisku o rozmiarze 16 KB przy użyciu emulatorów i urządzeń fizycznych.

Korzyści i wzrost skuteczności

Urządzenia o rozmiarze stron o rozmiarze 16 KB zużywają średnio trochę więcej pamięci, ale poprawiają też wydajność zarówno systemu, jak i aplikacji:

  • Krótszy czas uruchamiania aplikacji, gdy system wykorzystuje pamięć: średnio o 3,16% krótszy niż w przypadku niektórych testowanych aplikacji
  • Mniejsze wykorzystanie energii podczas uruchamiania aplikacji: średnio o 4,56%
  • Szybsze uruchamianie kamery: średnio o 4,48% szybsze uruchomienia z pamięci i o 6,60% szybsze uruchomienia „na zimno”
  • Skrócony czas uruchamiania systemu: średnio o 1,5% (około 0,8 sekundy).

Te ulepszenia są oparte na naszych wstępnych testach, więc wyniki na rzeczywistych urządzeniach będą się prawdopodobnie różnić. W trakcie testów będziemy przeprowadzać dodatkową analizę potencjalnych korzyści związanych z aplikacjami.

Sprawdź, czy ta zmiana dotyczy Twojej aplikacji

Jeśli Twoja aplikacja korzysta z kodu natywnego, musisz odbudować ją na urządzeniach z obsługą 16 KB. Jeśli nie masz pewności, czy Twoja aplikacja używa kodu natywnego, możesz skorzystać z Analizatora plików APK, by sprawdzić, czy w aplikacji znajduje się kod natywny.

Jeśli Twoja aplikacja używa tylko kodu napisanego w języku Java lub w Kotlin, w tym wszystkich bibliotek i pakietów SDK, obsługuje już urządzenia z 16 KB. Zalecamy jednak przetestowanie aplikacji w środowisku 16 KB, aby sprawdzić, czy w jej działaniu nie występują nieoczekiwane regresje.

Wymagane zmiany w niektórych aplikacjach do obsługi obszaru prywatnego

Obszar prywatny to nowa funkcja Androida 15, która umożliwia użytkownikom utworzenie na urządzeniu osobnego obszaru, w którym mogą chronić poufne aplikacje przed nieupoważnionymi aplikacjami dzięki dodatkowej warstwie uwierzytelniania. Aplikacje w obszarze prywatnym mają ograniczoną widoczność, dlatego niektóre typy aplikacji muszą wykonać dodatkowe czynności, aby móc wyświetlać aplikacje w przestrzeni prywatnej użytkownika i wchodzić z nimi w interakcje.

Wszystkie aplikacje

Aplikacje w obszarze prywatnym są przechowywane w osobnym profilu użytkownika (podobnie jak w przypadku profili służbowych). Aplikacje nie powinny zakładać, że wszystkie zainstalowane kopie ich aplikacji, których nie ma w profilu głównym, znajdują się w profilu służbowym. Jeśli Twoja aplikacja obsługuje logikę związaną z aplikacjami z profilu służbowym, które przyjęły takie założenia, musisz dostosować tę logikę.

Launchery

Jeśli tworzysz aplikację uruchamiającą, musisz wykonać te czynności, aby aplikacje w obszarze prywatnym stały się widoczne:

  1. Aplikacja musi być przypisana jako domyślna aplikacja uruchamiająca na urządzeniu, czyli mieć przypisaną rolę ROLE_HOME.
  2. Aplikacja musi zadeklarować normalne uprawnienia ACCESS_HIDDEN_PROFILES w pliku manifestu.

Aplikacje Menu z aplikacjami, które deklarują uprawnienie ACCESS_HIDDEN_PROFILES, muszą obsługiwać te przypadki użycia w przestrzeni prywatnej:

  1. Aplikacja musi mieć osobny kontener programu uruchamiającego dla aplikacji zainstalowanych w obszarze prywatnym.
  2. Użytkownik musi mieć możliwość ukrycia i wyświetlenia kontenera obszaru prywatnego.
  3. Użytkownik musi mieć możliwość zablokowania i odblokowania kontenera obszaru prywatnego.
  4. Gdy to zrobisz, żadne aplikacje w kontenerze obszaru prywatnego nie powinny być widoczne ani możliwe do znalezienia za pomocą takich mechanizmów jak wyszukiwanie.
  5. Jeśli użytkownik zablokuje urządzenie, gdy kontener obszaru prywatnego jest odblokowany, kontener obszaru prywatnego również powinien być zablokowany.

Aplikacje ze sklepu z aplikacjami

Obszar prywatny zawiera przycisk „Zainstaluj aplikacje”, który uruchamia niejawną chęć instalowania aplikacji w obszarze prywatnym użytkownika. Aby aplikacja otrzymywała tę intencję niejawną, zadeklaruj w jej pliku manifestu <intent-filter> z wartością <category> o wartości CATEGORY_APP_MARKET.

Zwiększono minimalną docelową wersję pakietu SDK z 23 do 24

Android 15 bazuje na zmianach wprowadzonych w Androidzie 14 i jeszcze bardziej rozszerza te zabezpieczenia. W Androidzie 15 nie można instalować aplikacji z wartością targetSdkVersion mniejszą niż 24. Wymóg zgodności aplikacji z nowoczesnymi poziomami interfejsów API pomaga zapewnić lepsze zabezpieczenia i prywatność.

Złośliwe oprogramowanie często jest kierowane na niższe poziomy interfejsów API, aby ominąć zabezpieczenia i ochronę prywatności, które zostały wprowadzone w nowszych wersjach Androida. Na przykład w niektórych aplikacjach zawierających złośliwe oprogramowanie parametr targetSdkVersion ma wartość 22, co pozwala uniknąć podlegania modelowi uprawnień czasu działania wprowadzonemu w Androidzie 6.0 Marshmallow (poziom interfejsu API 23) w 2015 r. Ta zmiana w Androidzie 15 utrudnia złośliwym oprogramowaniem o ulepszenie zabezpieczeń i prywatności. Próba zainstalowania aplikacji kierowanej na interfejs API niższego poziomu zakończy się niepowodzeniem instalacji, a w narzędziu Logcat pojawi się komunikat podobny do tego:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 7

Na urządzeniach z Androidem 15 wszystkie aplikacje z wartością targetSdkVersion mniejszą niż 24 pozostaną zainstalowane.

Jeśli musisz przetestować aplikację kierowaną na starszy poziom interfejsu API, użyj tego polecenia ADB:

adb install --bypass-low-target-sdk-block FILENAME.apk

Aparat i multimedia

Android 15 wprowadza te zmiany w działaniu aparatu i multimediów we wszystkich aplikacjach.

W przypadku osiągnięcia limitu zasobów odtwarzanie audio eliminuje teraz bezpośrednie i odciążanie ścieżek audio, które były wcześniej otwarte lub przeciążone.

Przed Androidem 15, jeśli aplikacja zażądała bezpośredniego odtwarzania dźwięku lub odciążenia go, gdy inna aplikacja odtwarzała dźwięk, a osiągnięto limity zasobów, aplikacja nie otwierała nowego AudioTrack.

Począwszy od Androida 15, gdy aplikacja prosi o odtwarzanie bezpośrednie lub odciążanie i osiągnięte zostaną limity zasobów, system unieważnia aktualnie otwarte obiekty AudioTrack, co uniemożliwia realizację nowego żądania śledzenia.

Ścieżki audio są zwykle otwierane w celu odtwarzania skompresowanych formatów audio. Typowym przypadkiem użycia bezpośredniego odtwarzania dźwięku jest przesyłanie dźwięku zakodowanego przez HDMI na telewizor. Ścieżki audio są zwykle używane do odtwarzania skompresowanego dźwięku na urządzeniu mobilnym ze sprzętową akceleracją DSP.

Wygoda użytkownika i interfejs systemu

W Androidzie 15 wprowadziliśmy kilka zmian, które mają zapewnić bardziej spójną i intuicyjną obsługę użytkowników.

Animacje przewidywanego przejścia wstecz włączone w aplikacjach, które wyraziły na to zgodę

W Androidzie 15 opcja dla programistów dotycząca prognozowanych animacji wstecznych została usunięta. Animacje systemowe, np. powrót do ekranu głównego, wykonywanie różnych zadań czy wielozadaniowość, są teraz widoczne w aplikacjach, które włączyły gest przewidywanego przejścia wstecz w całości lub na poziomie aktywności. Jeśli dotyczy to Twojej aplikacji, wykonaj te czynności:

  • Aby korzystać z przewidywanego gestu wstecznego, upewnij się, że aplikacja została prawidłowo przeniesiona.
  • Upewnij się, że przejścia fragmentów działają z prognozowaniem poprzedniej nawigacji.
  • Zrezygnuj z przejścia animacji i platformy na rzecz animacji i przejścia androidx.
  • Przejdź z powrotem na stosy wsteczne, o których FragmentManager nie wie. Użyj zamiast nich stosów zwrotnych zarządzanych przez FragmentManager lub komponent Nawigacja.

Elementy wycofane

W każdej wersji określone interfejsy API Androida mogą stać się przestarzałe lub wymagać refaktoryzacji, aby zapewnić lepsze wrażenia programistom lub obsługiwać nowe funkcje platformy. W takich przypadkach oficjalnie wycofujemy przestarzałe interfejsy API i kierujemy deweloperów do alternatywnych interfejsów API.

Oznacza to, że zakończyliśmy oficjalną obsługę interfejsów API, ale nadal będą one dostępne dla deweloperów. Więcej informacji o istotnych wycofywaniu tej wersji Androida znajdziesz na stronie o wycofaniach.