Zmiany w działaniu: aplikacje kierowane na interfejs API na poziomie 29 lub nowszym

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 targetSdkVersion na „29” lub więcej, zmodyfikuj aplikację, aby obsługiwała te zachowania prawidłowo (w stosownych przypadkach).

Przejrzyj też listę zmian w działaniu, które wpływają na wszystkie aplikacje na Androidzie 10.

Aktualizacje ograniczeń dotyczących 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 SDK przygotowane na podstawie współpracy z deweloperami aplikacji na Androida i najnowszych testów wewnętrznych. Naszym celem jest udostępnienie publicznych alternatywnych rozwiązań, zanim ograniczymy dostęp do interfejsów innych niż SDK.

Jeśli nie kierujesz reklam na Androida 10 (poziom interfejsu API 29), niektóre z tych zmian mogą nie od razu Cię dotyczyć. 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 korzysta z interfejsów innych niż SDK, możesz to sprawdzić, przetestując aplikację. 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 mogą prawidłowo korzystać z interfejsów innych niż SDK. 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ń związanych z interfejsami innymi niż SDK w Androidzie 10 oraz w artykule Ograniczenia dotyczące interfejsów spoza SDK.

Udostępnione wspomnienie

Ashmem zmienił format map dalvik w kodzie /proc/<pid>/maps, co wpływa na aplikacje, które bezpośrednio analizują plik map. 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 kierowane na Androida 10 nie mogą bezpośrednio używać ashmem (/dev/ashmem) i muszą mieć dostęp do pamięci współdzielonej za pomocą klasy ASharedMemory NDK. Oprócz tego aplikacje nie mogą tworzyć bezpośrednich IOCTL do istniejących deskryptorów plików ashmem i muszą zamiast tego używać klasy ASharedMemory NDK lub interfejsów Java API na Androida do tworzenia regionów pamięci współdzielonej. Ta zmiana zwiększa bezpieczeństwo i niezawodność podczas pracy z pamięcią współdzieloną, a także wydajność i ogólne bezpieczeństwo Androida.

Usunięto uprawnienia do uruchamiania katalogu głównego aplikacji

Wykonywanie plików z katalogu głównego aplikacji z możliwością zapisu jest naruszeniem W^X. Aplikacje powinny ładować tylko kod binarny umieszczony w jej pliku APK.

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

Ponadto aplikacje kierowane na Androida 10 nie mogą modyfikować w pamięci kodu wykonywalnego z plików, które zostały otwarte przy użyciu dlopen() i oczekują, że zmiany zostaną zapisane na dysku, ponieważ biblioteki nie można zmapować PROT_EXEC za pomocą deskryptora pliku z możliwością zapisu. Dotyczy to też wszystkich udostępnionych plików obiektów (.so) z relokacjami tekstu.

Środowisko wykonawcze 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.

Egzekwowanie poprawności AOT w ART

W przeszłości kompilacja (AOT) wykonywana przez środowisko wykonawcze Androida (ART) mogła powodować awarie środowiska wykonawczego, jeśli środowisko classpath nie było takie samo w czasie kompilacji i w czasie działania. Android 10 i nowsze wersje zawsze wymagają, aby te konteksty środowiska były takie same, co skutkuje tymi zmianami w działaniu:

• 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 wczytywane ręcznie przez aplikacje spoza głównego pakietu APK, są kompilowane w tle przez AOT. Dzieje się tak, ponieważ kompilacja „pierwszego użycia” może być zbyt kosztowna i prowadzi do niepożądanych opóźnień 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łnoekranowej

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 wysłała żądanie.

Jeśli aplikacja na Androida 10 lub nowszego próbuje utworzyć powiadomienie z intencją pełnoekranową bez żądania wymaganych uprawnień, system zignoruje intencję pełnoekranową i wyświetli ten komunikat logu:

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 wielu okien lub wyświetlacza pojawia się wiele aplikacji, wszystkie najważniejsze działania, które można zaznaczyć w widocznych stosach, są wznowione, ale tylko jedna z nich, czyli „najwyższa wznowiona”, jest aktywna. Jeśli system działa w wersjach starszych niż Android 10, naraz można wznowić tylko 1 działanie w systemie, a wszystkie inne widoczne działania 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 nakładania elementów, by nadać wyższy priorytet aktywnościom, z którymi użytkownik wszedł w interakcję jako ostatni. Działanie może być wznawiane w całości, ale bez zaznaczenia (np. gdy obszar powiadomień jest rozwinięty).

W Androidzie 10 (poziom interfejsu API 29) i nowszych możesz zasubskrybować wywołanie zwrotne onTopResumedActivityChanged(), aby otrzymywać powiadomienia, gdy Twoja aktywność uzyska lub straci najwyższą wznowioną pozycję. Jest to odpowiednik stanu wznowienia sprzed Androida 10 i może być przydatny jako wskazówka, jeśli Twoja aplikacja korzysta z zasobów na wyłączność lub zasobów pojedynczych, które być może trzeba udostępnić innym aplikacjom.

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

Aplikacje mogą korzystać z atrybutu android:minAspectRatio wprowadzonego w Androidzie 10 do wskazywania współczynników ekranów, które obsługuje Twoja aplikacja.

Emulator w Android Studio od wersji 3.5 zawiera urządzenia wirtualne 7, 3- i 8-calowe do testowania kodu na większych ekranach.

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