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 na poziomie 29 lub wyższym. Jeśli w aplikacji ustawisz targetSdkVersion na „29” lub więcej, zmodyfikuj ją, aby w odpowiednich przypadkach obsługiwała te działania.
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 Android 10 wprowadza wiele zmian i ograniczeń związanych z prywatnością, w tym:
- Scoped storage
- Dostęp do numeru seryjnego urządzenia USB
- Możliwość włączania, wyłączania i konfigurowania Wi-Fi
- Dostęp do lokalizacji w przypadku interfejsów API połączeń
Te zmiany, które dotyczą aplikacji kierowanych 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 dotyczące prywatności.
Zmiany dotyczące ograniczeń 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 API 28). Android 10 zawiera zaktualizowane listy ograniczonych interfejsów innych niż SDK, które powstały we współpracy z programistami aplikacji na Androida oraz na podstawie najnowszych testów wewnętrznych. Naszym celem jest zapewnienie, że publiczne alternatywy będą dostępne, zanim ograniczymy 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. Obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale 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 to sprawdzić. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych rozwiązań SDK. Rozumiemy jednak, że niektóre aplikacje mają uzasadnione przypadki użycia interfejsów spoza pakietu SDK. Jeśli nie możesz znaleźć alternatywy dla interfejsu spoza pakietu SDK w przypadku funkcji w aplikacji, poproś o nowy publiczny interfejs API.
Więcej informacji znajdziesz w artykułach Aktualizacje ograniczeń interfejsów innych niż SDK w Androidzie 10 i Ograniczenia 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 muszą uzyskiwać dostęp do pamięci współdzielonej za pomocą klasy ASharedMemory pakietu NDK.
Ponadto aplikacje nie mogą wykonywać bezpośrednich wywołań IOCTL do istniejących deskryptorów plików ashmem i muszą używać klasy ASharedMemory NDK lub interfejsów API Androida w języku Java do tworzenia regionów pamięci współdzielonej. Ta zmiana zwiększa bezpieczeństwo i niezawodność podczas pracy z pamięcią współdzieloną, co poprawia wydajność i bezpieczeństwo Androida.
Usunięto uprawnienia do wykonywania dla katalogu domowego aplikacji
Wykonywanie plików z katalogu domowego aplikacji z możliwością zapisu jest naruszeniem zasady W^X. Aplikacje powinny wczytywać tylko kod binarny umieszczony w pliku APK aplikacji.
Niezaufane aplikacje kierowane na Androida 10 nie mogą wywoływać execve() bezpośrednio na 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 za pomocą dlopen(), i oczekiwać, że te zmiany zostaną zapisane na dysku, ponieważ biblioteka nie mogła zostać zmapowana PROT_EXEC za pomocą deskryptora pliku z możliwością zapisu. Obejmuje to wszystkie pliki obiektów udostępnionych (.so) z relokacjami tekstu.
Środowisko wykonawcze Androida akceptuje tylko pliki OAT wygenerowane przez system
Środowisko wykonawcze Androida (ART) nie wywołuje już metody 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 z wyprzedzeniem (AOT) wykonywana przez środowisko wykonawcze Androida (ART) mogła powodować awarie w czasie działania, jeśli środowisko ścieżki klasy 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 zachowaniu:
- Niestandardowe programy ładujące klasy, czyli programy ładujące klasy napisane przez aplikacje, w przeciwieństwie do programów ładujących klasy z pakietu
dalvik.system, nie są kompilowane w trybie AOT. Dzieje się tak, ponieważ środowisko 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, 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, 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 udostępnione w Androidzie (wpisy <library> i <uses-library> w pliku manifestu Androida) są implementowane przy użyciu innej hierarchii modułów ładujących klasy niż ta używana w poprzednich wersjach platformy.
Zmiany uprawnień dotyczących intencji pełnoekranowych
Aplikacje kierowane na Androida 10 lub nowszego, które używają powiadomień z intencjami pełnoekranowymi, muszą prosić o uprawnienie USE_FULL_SCREEN_INTENT w pliku manifestu aplikacji. Jest to uprawnienie normalne, więc system automatycznie przyznaje je aplikacji, która o nie prosi.
Jeśli aplikacja kierowana na Androida 10 lub nowszego próbuje utworzyć powiadomienie z intencją pełnoekranową bez żądania niezbędnych uprawnień, system ignoruje intencję pełnoekranową i wyświetla 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 w trybie wielu okien lub wielu wyświetlaczy jednocześnie pojawia się kilka aplikacji, wszystkie możliwe do zaznaczenia działania na górze widocznych stosów są w stanie wznowienia, ale tylko jedno z nich, „najwyższe wznowione”, jest faktycznie zaznaczone. W przypadku wersji starszych niż Android 10 w systemie można wznowić tylko jedną aktywność naraz, a wszystkie pozostałe widoczne aktywności są wstrzymane.
Nie należy mylić „fokusu” z „najwyższą wznowioną” aktywnością. System przypisuje priorytety aktywnościom na podstawie kolejności osi Z, aby nadać wyższy priorytet aktywnościom, z którymi użytkownik ostatnio wchodził w interakcję. Aktywność może być wznowiona na pierwszym planie, ale nie mieć fokusu (np. gdy obszar powiadomień jest rozwinięty).
W Androidzie 10 (API na poziomie 29) i nowszych możesz zasubskrybować wywołanie zwrotne onTopResumedActivityChanged(), aby otrzymywać powiadomienia, gdy aktywność uzyska lub utraci najwyższą pozycję wznowienia. Jest to odpowiednik stanu wznowienia sprzed Androida 10 i może być przydatny jako wskazówka, jeśli aplikacja używa zasobów wyłącznych lub pojedynczych, które mogą wymagać udostępnienia innym aplikacjom.
Zmieniło się też działanie 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 zmieni się dostępny rozmiar ekranu lub gdy aplikacja zostanie przeniesiona z jednego ekranu na drugi.
Aplikacje mogą używać atrybutu android:minAspectRatio wprowadzonego w Androidzie 10, aby wskazywać obsługiwane proporcje ekranu.
Począwszy od wersji 3.5, emulator Android Studio zawiera urządzenia wirtualne o rozmiarze 7,3 cala i 8 cali, które umożliwiają testowanie kodu na większych ekranach.
Więcej informacji znajdziesz w artykule Projektowanie aplikacji na urządzenia składane.