Zmiany w działaniu: aplikacje kierowane na interfejs API w wersji 29 lub nowszej

Android 10 zawiera zaktualizowane zmiany w działaniu systemu, które mogą mieć wpływ na Twoją aplikację. Zmiany wymienione na tej stronie dotyczą tylko aplikacji kierowanych na interfejs API na poziomie 29 lub wyższym. Jeśli Twoja aplikacja ustawia wartość targetSdkVersion na „29” lub wyższą, musisz ją odpowiednio zmodyfikować, aby obsługiwała te zachowania.

Zapoznaj się też z listą zmian zachowania, które mają wpływ na wszystkie aplikacje działające na Androidzie 10.

Zmiany w ograniczeniach interfejsu innego niż SDK

Aby zapewnić stabilność i zgodność aplikacji, platforma zaczęła ograniczać możliwość używania interfejsów innych niż SDK w Androidzie 9 (poziom API 28). Android 10 zawiera zaktualizowane listy ograniczonych interfejsów spoza pakietu SDK, które powstały na podstawie współpracy z deweloperami Androida i ostatnich testów wewnętrznych. Chcemy się upewnić, że dostępne są publiczne alternatywy, zanim zaczniemy ograniczać interfejsy inne niż SDK.

Jeśli nie będziesz kierować aplikacji na Androida 10 (poziom interfejsu API 29), niektóre z tych zmian mogą nie mieć na Ciebie natychmiastowego wpływu. Mimo że obecnie można korzystać z niektórych interfejsów innych niż SDK (w zależności od docelowego poziomu interfejsu API aplikacji), użycie dowolnej metody lub pola spoza pakietu SDK zawsze wiąże się z dużym ryzykiem uszkodzenia aplikacji.

Jeśli nie masz pewności, czy Twoja aplikacja używa interfejsów innych niż SDK, możesz ją przetestować, aby się tego dowiedzieć. Jeśli Twoja aplikacja korzysta z interfejsów spoza pakietu SDK, zaplanuj migrację na alternatywne pakiety SDK. Zdajemy sobie jednak sprawę, że w niektórych przypadkach interfejsy inne niż SDK mogą być przydatne. Jeśli nie możesz znaleźć w swojej aplikacji interfejsu innego niż interfejs SDK, musisz poprosić o nowy publiczny interfejs API.

Więcej informacji znajdziesz w artykule Aktualizacje ograniczeń interfejsów innych niż SDK w Androidzie 10 oraz Ograniczenia interfejsów innych niż SDK.

Udostępniona pamięć

Ashmem zmienił format map dalvik w katalogu /proc/<pid>/maps, co ma wpływ na aplikacje, które bezpośrednio analizują plik maps. Programiści aplikacji powinni przetestować format /proc/<pid>/maps na urządzeniach z Androidem 10 lub nowszym i odpowiednio przeanalizować aplikację, jeśli wymaga ona formatów mapy dalvik.

Aplikacje przeznaczone na Androida 10 nie mogą bezpośrednio używać ashmem (/dev/ashmem). Zamiast tego muszą uzyskiwać dostęp do pamięci współdzielonej za pomocą klasy ASharedMemory NDK. Aplikacje nie mogą też bezpośrednio wysyłać poleceń IOCTL do istniejących deskryptorów plików ashmem. Zamiast tego muszą używać klasy ASharedMemory NDK lub interfejsów API Java na Androida do tworzenia regionów pamięci współdzielonej. Ta zmiana zwiększa bezpieczeństwo i stabilność podczas pracy z wspólnej pamięci, co poprawia ogólną wydajność i bezpieczeństwo Androida.

Usunięto uprawnienie do wykonywania w katalogu domowym aplikacji

Uruchamianie plików z katalogu głównego aplikacji, w którym można zapisywać, jest naruszeniem zasady W^X. Aplikacje powinny ładować tylko kod binarny osadzony w jej pliku APK.

Niezaufane aplikacje przeznaczone na Androida 10 nie mogą wywoływać funkcji execve()bezpośrednio w plikach w katalogu głównym aplikacji.

Ponadto aplikacje na Androida 10 nie mogą modyfikować w pamięci kodu wykonywalnego z plików otwartych za pomocą dlopen() i oczekiwać, że te zmiany zostaną zapisane na dysk, ponieważ biblioteka nie może być mapowana PROT_EXEC za pomocą zapisywalnego deskryptora pliku. Obejmuje to wszystkie pliki obiektów współdzielonych (.so) z przemieszczonym tekstem.

środowisko uruchomieniowe Androida akceptuje tylko pliki OAT wygenerowane przez system;

Środowisko wykonawcze Androida (ART) nie wywołuje już funkcji dex2oat z procesu aplikacji. Ta zmiana oznacza, że ART będzie akceptować tylko pliki OAT wygenerowane przez system.

Wymuszanie poprawności AOT w ART

W przeszłości kompilacja z wyprzedzeniem (AOT) wykonywana przez środowisko uruchomieniowe Androida (ART) mogła powodować awarie w czasie wykonywania, jeśli środowisko classpath było inne w momencie kompilacji i wykonania. Android 10 i nowsze wersje wymagają, aby te konteksty środowiska były zawsze takie same. W rezultacie występują następujące zmiany w zachowaniu:

• Niestandardowe moduły ładujące klas, czyli programy wczytujące klasy tworzone przez aplikacje, w przeciwieństwie do modułów ładowania klas z pakietu dalvik.system, nie są kompilowane przez AOT. Powodem jest to, że ART nie może uzyskać informacji o niestandardowej implementacji wyszukiwania klas w czasie działania.
• Dodatkowe pliki DEX, czyli pliki DEX wczytane ręcznie przez aplikacje, które nie znajdują się w głównym pliku APK, są kompilowane w tle w trybie AOT. Dzieje się tak, ponieważ kompilacja przy pierwszym użyciu może być zbyt kosztowna i prowadzić do niechcianej zwłoki przed wykonaniem. Pamiętaj, że w przypadku aplikacji zalecane jest zastosowanie podziałów i rezygnacja z dodatkowych plików dex.
• Biblioteki udostępnione w Androidzie (wpisy <library> i <uses-library> w pliku manifestu Androida) są zaimplementowane przy użyciu innej hierarchii ładowania klas niż używana w poprzednich wersjach platformy.

Zmiany uprawnień do intencji pełnoekranowych

Aplikacje kierowane na Androida 10 lub nowszego i korzystające z powiadomień z intencjami pełnoekranowymi muszą prosić o uprawnienia USE_FULL_SCREEN_INTENT w pliku manifestu aplikacji. Jest to normalne uprawnienie, więc system automatycznie przyznaje je aplikacji, która o nie prosi.

Jeśli aplikacja kierowana na Androida 10 lub nowszego spróbuje utworzyć powiadomienie z intencją pełnego ekranu bez poproszenia o wymagane uprawnienia, system zignoruje intencję pełnego ekranu i wyświetli następujący komunikat logowania:

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

Obsługa urządzeń składanych

W Androidzie 10 wprowadziliśmy zmiany dotyczące urządzeń składanych i urządzeń z dużym ekranem.

W przypadku aplikacji na Androidzie 10 metody onResume() i onPause() działają inaczej. Gdy w trybie wielookiennym lub wieloekranowym pojawia się jednocześnie kilka aplikacji, wszystkie widoczne na wierzchu aplikacje, które można ustawić jako aktywne, są w stanie wznowionej aktywności, ale tylko jedna z nich, czyli „najwyższa” aktywna aplikacja, jest faktycznie aktywna. W wersjach starszych niż Android 10 można wznowić tylko jedną aktywność w systemie, a wszystkie inne widoczne aktywności są wstrzymywane.

Nie należy mylić „fokusu” z aktywnością, która znajduje się na samej górze. System przypisuje priorytety aktywnościom na podstawie kolejności z-wartości, aby nadać wyższy priorytet aktywnościom, z którymi użytkownik ostatnio się zaangażował. Aktywność może być wznowiona, ale nie może mieć natywnego fokusa (na przykład, jeśli pasek powiadomień jest rozwinięty).

W Androidzie 10 (poziom interfejsu API 29) i nowszych możesz subskrybować wywołanie zwrotne onTopResumedActivityChanged(), aby otrzymywać powiadomienia, gdy Twoja aktywność uzyska lub utraci najwyższą pozycję w łańcuchu wznawiania. Stan ten jest odpowiednikiem stanu wznowionego przed Androidem 10 i może być przydatny, jeśli aplikacja używa zasobów typu singleton lub zasobów, które mogą być udostępniane innym aplikacjom.

Zmienił się też sposób działania atrybutu manifestu resizeableActivity. Jeśli aplikacja ustawia resizeableActivity=false w Androidzie 10 (poziom interfejsu API 29) lub nowszym, może zostać przeniesiona do trybu zgodności, gdy zmieni się dostępny rozmiar ekranu lub gdy aplikacja przejdzie z jednego ekranu na inny.

Aplikacje mogą używać atrybutu android:minAspectRatio, wprowadzonego w Androidzie 10, aby wskazać proporcje ekranu, które obsługuje aplikacja.

Od wersji 3.5 emulator Android Studio zawiera urządzenia wirtualne o przekątnej 7, 3 cale i 8 cali do testowania kodu na większych ekranach.

Więcej informacji znajdziesz w artykule Projektowanie aplikacji na urządzenia składane.