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ą wyłącznie aplikacji kierowanych na interfejs API w wersji 29 lub nowszej. Jeśli Twoja aplikacja ma ustawiony parametr targetSdkVersion na „29” lub nowszy, musisz ją zmodyfikować, aby prawidłowo obsługiwała te zmiany w działaniu.

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

Uwaga: Oprócz zmian wymienionych na tej stronie Android 10 wprowadza wiele zmian i ograniczeń związanych z prywatnością, w tym:

  • ograniczony dostęp do miejsca na dane,
  • dostęp do numeru seryjnego urządzenia USB,
  • możliwość włączania, wyłączania i konfigurowania Wi-Fi,
  • uprawnienia do lokalizacji w przypadku interfejsów API łączności.

Te zmiany, które mają wpływ na aplikacje kierowane na poziom interfejsu API 29 lub nowszy, zwiększają prywatność użytkowników. Więcej informacji o tym, jak obsługiwać te zmiany, znajdziesz na stronie Zmiany dotyczące prywatności.

Aktualizacje ograniczeń dotyczących interfejsów innych niż SDK

Aby zapewnić stabilność i zgodność aplikacji, platforma zaczęła ograniczać interfejsy inne niż SDK , których aplikacja może używać w Androidzie 9 (poziom interfejsu API 28). Android 10 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK, które powstały na podstawie współpracy z deweloperami Androida i najnowszych testów wewnętrznych. Naszym celem jest zapewnienie, że przed ograniczeniem interfejsów innych niż SDK dostępne będą ich publiczne odpowiedniki.

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. Chociaż obecnie możesz używać niektórych interfejsów innych niż SDK (w zależności od docelowego poziomu interfejsu API aplikacji), używanie dowolnej metody lub pola spoza 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 to sprawdzić, testując ją. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych pakietów SDK. Rozumiemy jednak, że niektóre aplikacje mają uzasadnione przypadki użycia interfejsów innych niż SDK. Jeśli nie możesz znaleźć alternatywy dla używania interfejsu innego niż SDK w przypadku funkcji w aplikacji, powinieneś poprosić o nowy publiczny interfejs API.

Więcej informacji znajdziesz w artykułach Aktualizacje ograniczeń dotyczących interfejsów innych niż SDK w Androidzie 10 i Ograniczenia dotyczące interfejsów innych niż SDK.

Pamięć współużytkowana

Ashmem zmienił format map dalvik w /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 go przeanalizować, jeśli aplikacja zależy od formatów map dalvik.

Aplikacje kierowane na Androida 10 nie mogą bezpośrednio używać ashmem (/dev/ashmem) i zamiast tego muszą uzyskiwać dostęp do pamięci współużytkowanej za pomocą klasyASharedMemory w NDK. Ponadto aplikacje nie mogą wykonywać bezpośrednich IOCTL na istniejących deskryptorach plików ashmem i zamiast tego muszą używać klasy ASharedMemory w NDK lub interfejsów API Java na Androida do tworzenia regionów pamięci współużytkowanej. Ta zmiana zwiększa bezpieczeństwo i niezawodność podczas pracy z pamięcią współużytkowaną, co poprawia wydajność i bezpieczeństwo Androida.

Usunięto uprawnienie do wykonywania plików w katalogu głównym aplikacji

Wykonywanie plików z zapisywalnego katalogu głównego aplikacji jest naruszeniem zasady W^X. Aplikacje powinny wczytywać tylko kod binarny, który jest osadzony w pliku APK aplikacji.

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

Ponadto aplikacje kierowane na Androida 10 nie mogą modyfikować w pamięci kodu wykonywalnego z plików otwartych za pomocą funkcji dlopen() i oczekiwać, że zmiany te zostaną zapisane na dysku, ponieważ biblioteka nie mogła zostać zmapowana za pomocą funkcji PROT_EXEC przez zapisywalny deskryptor pliku. Dotyczy to wszystkich plików obiektów współdzielonych (.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 AOT (ahead-of-time) wykonywana przez środowisko wykonawcze Androida (ART) mogła powodować awarie w czasie działania, 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 powoduje następujące zmiany w działaniu:

  • Niestandardowe moduły ładujące klasy – czyli moduły ładujące klasy napisane przez aplikacje, w przeciwieństwie do modułów ładujących klasy z pakietu dalvik.system – nie są kompilowane AOT. Dzieje się tak, ponieważ ART nie może znać niestandardowej implementacji wyszukiwania klas w czasie działania.
  • Dodatkowe pliki dex – czyli pliki dex wczytywane ręcznie przez aplikacje, które nie znajdują się w głównym pliku APK – są kompilowane AOT w tle. Dzieje się tak, ponieważ kompilacja przy pierwszym użyciu może być zbyt kosztowna, co prowadzi do niepożądanych opóźnień przed wykonaniem. Pamiętaj, że w przypadku aplikacji zalecamy stosowanie podziałów i rezygnację z dodatkowych plików dex.
  • Biblioteki współdzielone w Androidzie (wpisy <library> i <uses-library> w pliku manifestu Androida) są implementowane przy użyciu innej hierarchii modułów wczytujących klasy niż ta, która była używana w poprzednich wersjach platformy.

Zmiany uprawnień w przypadku intencji pełnoekranowych

Aplikacje kierowane na Androida 10 lub nowszego, które używają powiadomień z intencjami pełnoekranowymi muszą poprosić o uprawnienie 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łnoekranową bez żądania niezbędnego uprawnienia, 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

Android 10 zawiera zmiany, które obsługują urządzenia składane i urządzenia z dużym ekranem.

Gdy aplikacja działa na Androidzie 10, metody onResume() i onPause() działają inaczej. Gdy kilka aplikacji pojawia się jednocześnie w trybie wielu okien lub wielu wyświetlaczy, wszystkie aktywności z możliwością ustawienia fokusu w widocznych stosach są w stanie wznowienia, ale tylko jedna z nich, aktywność „najwyższa wznowiona”, ma fokus. W przypadku wersji wcześniejszych niż Android 10 w systemie może być wznowiona tylko jedna aktywność, a wszystkie inne widoczne aktywności są wstrzymane.

Nie myl „fokusu” z aktywnością „najwyższą wznowioną”. System przypisuje priorytety aktywnościom na podstawie kolejności z, aby nadać wyższy priorytet aktywnościom, z którymi użytkownik ostatnio wchodził w interakcję. Aktywność może być najwyższa wznowiona, ale nie mieć fokusu (np. jeśli jest rozwinięty obszar powiadomień).

W Androidzie 10 (poziom interfejsu API 29) i nowszych wersjach możesz subskrybować wywołanie zwrotne onTopResumedActivityChanged(), aby otrzymywać powiadomienia, gdy Twoja aktywność uzyska lub utraci pozycję najwyższej wznowionej. Jest to odpowiednik stanu wznowienia sprzed Androida 10 i może być przydatny jako wskazówka, jeśli Twoja aplikacja używa zasobów wyłącznych lub singletonów, które mogą wymagać udostępnienia innym aplikacjom.

Zmieniło się też działanie atrybutu manifestu resizeableActivity. Jeśli aplikacja ustawi wartość resizeableActivity=false w Androidzie 10 (poziom interfejsu API 29) lub nowszym, może zostać przełączona w tryb zgodności, gdy zmieni się dostępny rozmiar ekranu lub gdy aplikacja przeniesie się z jednego ekranu na drugi.

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

Od wersji 3.5 narzędzie emulatora Android Studio zawiera wirtualne urządzenia o przekątnej 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.