Android 10 zawiera zmiany w zachowaniu systemu, które mogą mieć wpływ na Twoją aplikację. Zmiany wymienione na tej stronie mają zastosowanie wyłącznie do aplikacji kierowanych na platformę API 29 lub nowszą. 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.
Uwaga: oprócz zmian wymienionych na tej stronie Android 10 wprowadza wiele zmian i ograniczeń dotyczących prywatności, w tym:
- Miejsce na dane ograniczone
- Dostęp do numeru seryjnego urządzenia USB
- możliwość włączania, wyłączania i konfigurowania Wi-Fi;
- Uprawnienia dostępu do lokalizacji w przypadku interfejsów API związanych z połączeniemi
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 ograniczeń interfejsu innego niż SDK
Aby zapewnić stabilność i zgodność aplikacji, platforma zaczęła ograniczać interfejsy spoza pakietu SDK, których Twoja aplikacja może używać w Androidzie 9 (poziom API 28). Android 10 zawiera zaktualizowane listy ograniczonych interfejsów spoza pakietu SDK, które powstały w ramach 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. Obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z metod lub pól spoza pakietu SDK zawsze wiąże się z wysokim ryzykiem awarii 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 alternatywy dla pakietu SDK. Zdajemy sobie jednak sprawę, że w niektórych przypadkach interfejsy inne niż SDK mogą być przydatne. Jeśli nie możesz znaleźć alternatywy dla interfejsu spoza pakietu SDK, który jest używany w funkcji Twojej aplikacji, poproś 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 map. Deweloperzy aplikacji powinni przetestować format /proc/<pid>/maps na urządzeniach z Androidem 10 lub nowszym i odpowiednio przeanalizować, czy aplikacja zależy od formatów map 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 Javy Androida do tworzenia regionów pamięci współdzielonej. Ta zmiana zwiększa bezpieczeństwo i stabilność podczas pracy z wspólna 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 wczytywać tylko kod binarny zawarty w 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 ładowarki klas, czyli ładowarki klas napisane przez aplikacje, w przeciwieństwie do ładowarek klas z pakietu
dalvik.system, nie są kompilowane AOT. Dzieje się tak, ponieważ podczas wykonywania BERT nie może wiedzieć o niestandardowej implementacji wyszukiwania klasy. - 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 zalecamy stosowanie rozdzielników i rezygnację z plików indeksu pomocniczego.
- Biblioteki udostępnione w Androidzie (elementy <library> i <uses-library> w pliku manifestu Androida) są implementowane przy użyciu innej hierarchii ładowarki klas niż ta używana w poprzednich wersjach platformy.
Zmiany uprawnień do intencji pełnoekranowych
Aplikacje kierowane na Androida 10 lub nowszego, które używają powiadomień z intencjami pełnoekranowymi, muszą w pliku manifestu aplikacji poprosić o USE_FULL_SCREEN_INTENTuprawnienia. 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
Android 10 zawiera zmiany, które umożliwiają korzystanie z urządzeń składanych i z urządzeń z dużym ekranem.
Gdy aplikacja działa 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 myl „focus” z aktywizacją „topmost resumed”. 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ło się też działanie atrybutu pliku 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.