Android 10 zawiera zaktualizowane zmiany w działaniu systemu, które mogą wpłynąć 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 wyższą, 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 10.
Uwaga: oprócz zmian wymienionych na tej stronie w Androidzie 10 wprowadziliśmy wiele zmian i ograniczeń związanych z prywatnością, w tym:
- Ograniczone miejsce na dane
- Dostęp do numeru seryjnego urządzenia USB
- Możliwość włączania, wyłączania i konfiguracji Wi-Fi
- Uprawnienia do lokalizacji dla interfejsów API połączeń
Te zmiany, które mają wpływ na aplikacje kierowane na interfejs API na poziomie 29 lub wyższym, zwiększają prywatność użytkowników. Więcej informacji o tym, jak dostosować się do tych zmian, znajdziesz na stronie Zmiany prywatności.
Aktualizacje ograniczeń interfejsu spoza pakietu SDK
Aby zapewnić stabilność i zgodność aplikacji, platforma zaczęła ograniczać, z których interfejsów innych niż SDK może korzystać aplikacja na Androidzie 9 (poziom API 28). Android 10 zawiera zaktualizowane listy ograniczonych interfejsów spoza SDK opracowane na podstawie współpracy z programistami aplikacji na Androida i najnowszych testów wewnętrznych. Naszym celem jest zapewnienie dostępności publicznych alternatywnych rozwiązań, zanim ograniczymy dostęp do interfejsów spoza SDK.
Jeśli nie będziesz kierować aplikacji na Androida 10 (poziom interfejsu API 29), 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), korzystanie z dowolnych metod lub pól spoza pakietu SDK niesie ze sobą wysokie ryzyko awarii aplikacji.
Jeśli nie masz pewności, czy Twoja aplikacja używa interfejsów spoza SDK, możesz przetestować ją, aby się tego dowiedzieć. 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 znajdziesz w artykule Aktualizacje ograniczeń interfejsu innych niż SDK na Androida 10 oraz Ograniczenia dotyczące interfejsów spoza SDK.
Udostępnione wspomnienie
Ashmem zmienił format map Dalvik w katalogu /proc/<pid>/maps, co ma wpływ na aplikacje, które bezpośrednio analizują plik map. Deweloperzy aplikacji powinni przetestować format /proc/<pid>/maps na urządzeniach z Androidem 10 lub nowszym i odpowiednio przeanalizować, jeśli aplikacja korzysta z formatów map Dalvik.
Aplikacje kierowane na Androida 10 nie mogą bezpośrednio używać kodu ashmem (/dev/ashmem) i muszą mieć dostęp do pamięci współdzielonej przez klasę ASharedMemory NDK.
Poza tym aplikacje nie mogą kierować IOCTL do istniejących deskryptorów plików ashmem. Zamiast tego do tworzenia regionów pamięci współdzielonej muszą używać klasy ASharedMemory pakietu NDK lub interfejsów API Java na Androidzie. Ta zmiana zwiększa bezpieczeństwo i niezawodność podczas pracy z pamięcią współdzieloną, poprawiając wydajność i ogólnie bezpieczeństwo Androida.
Usunięto uprawnienie do wykonywania w katalogu głównym aplikacji
Uruchamianie plików z katalogu głównego aplikacji z możliwością zapisu jest naruszeniem W^X. Aplikacje powinny wczytywać tylko kod binarny umieszczony w jej pliku APK.
Niezaufane aplikacje kierowane na Androida 10 nie mogą wywoływać execve() bezpośrednio w przypadku plików znajdujących się w katalogu głównym aplikacji.
Poza tym aplikacje kierowane na Androida 10 nie mogą w pamięci modyfikować kodu wykonywalnego z plików otwartych za pomocą dlopen() i spodziewają się zapisać tych zmian na dysku, ponieważ biblioteki nie udało się zmapować PROT_EXEC za pomocą deskryptora plików z możliwością zapisu. Obejmuje to wszystkie pliki udostępnionych 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.
Wymuszanie poprawności AOT w ART
W przeszłości kompilacja wczesnej wersji (AOT) przeprowadzana przez środowisko wykonawcze Androida (ART) mogła powodować awarie w środowisku wykonawczym, jeśli środowisko classpath nie było takie samo w czasie kompilacji i w czasie wykonywania. Android 10 i nowsze wersje wymagają, aby te konteksty środowiska były takie same, co powoduje te zmiany w działaniu:
- Niestandardowe moduły ładowania klas, czyli moduły ładowania klas tworzone przez aplikacje, w przeciwieństwie do modułów ładowania klas z pakietu
dalvik.system, nie są kompilowane przez AOT. Dzieje się tak, ponieważ ART nie ma dostępu do informacji o dostosowanej implementacji wyszukiwania klas w czasie działania. - Dodatkowe pliki .dex, czyli pliki .dex załadowane ręcznie przez aplikacje, których nie ma w głównym pliku APK, są kompilowane w tle. Dzieje się tak, ponieważ kompilacja pierwszego użycia może być zbyt kosztowna i powodować niepożądane opóźnienia przed wykonaniem. Pamiętaj, że w przypadku aplikacji zalecane jest stosowanie podziałów i odejście od dodatkowych plików dex.
- Biblioteki udostępnione na 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ń w intencjach pełnoekranowych
Aplikacje kierowane na Androida 10 lub nowszego i korzystające z powiadomień z zamiarem pełnoekranowym muszą prosić o uprawnienie USE_FULL_SCREEN_INTENT w pliku manifestu. Jest to normalne uprawnienie, więc system automatycznie przyznaje je aplikacji, która wysłała żądanie.
Jeśli aplikacja kierowana na Androida 10 lub nowszego spróbuje utworzyć powiadomienie z intencją pełnoekranowym bez żądania wymaganych uprawnień, system zignoruje intencję pełnoekranową i wygeneruje następujący 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 wprowadzono zmiany dotyczące urządzeń składanych i urządzeń z dużym ekranem.
Gdy aplikacja działa na Androidzie 10, metody onResume() i onPause() działają inaczej. Gdy wiele aplikacji pojawia się jednocześnie w trybie wielu okien lub wielu wyświetlaczy, wszystkie możliwe do zaznaczenia aktywności z góry w widocznych stosach są w stanie wznowione, ale tylko jedna z nich, czyli aktywność „najwyżej wznowiona”, jest skupiona. Jeśli korzystasz z systemu w wersji starszej niż 10, jednorazowo można wznowić tylko jedną aktywność w systemie. Wszystkie inne widoczne aktywności zostaną wstrzymane.
Nie myl działania „fokus” z aktywnością „wznowiona najwyżej”. System przypisuje priorytety do działań na podstawie kolejności nakładania elementów, nadając wyższy priorytet aktywnościom, z którymi użytkownik ostatnio wchodził w interakcje. Aktywność może zostać wznowiona w momencie wznowienia, ale nie będzie w niej aktywna (np. jeśli rozwinie się obszar powiadomień).
Na urządzeniu z Androidem 10 (poziom interfejsu API 29) i nowszym możesz zasubskrybować wywołanie zwrotne onTopResumedActivityChanged(), aby otrzymywać powiadomienia, gdy 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 aplikacja korzysta z indywidualnych lub pojedynczych zasobów, które mogą wymagać udostępnienia innym aplikacjom.
Zmieniło się też działanie atrybutu resizeableActivity w pliku manifestu. Jeśli aplikacja ma ustawioną funkcję resizeableActivity=false na Androidzie 10 (poziom interfejsu API 29) lub nowszym, może zostać przełączona w tryb zgodności, gdy dostępny rozmiar ekranu się zmieni lub gdy aplikacja przejdzie z jednego ekranu na drugi.
Aplikacje mogą korzystać z atrybutu android:minAspectRatio wprowadzonego w Androidzie 10, aby wskazywać współczynniki ekranu obsługiwane przez daną aplikację.
Od wersji 3.5 narzędzie Android Studio do emulatora obejmuje urządzenia wirtualne 7, 3 cala i 8 cali do testowania kodu na większych ekranach.
Więcej informacji znajdziesz w artykule Projektowanie aplikacji na urządzenia składane.