Obsługa rozmiaru stron 16 KB

Wymaganie zgodności z Google Play w przypadku rozmiaru 16 KB

Od 1 listopada 2025 roku wszystkie nowe aplikacje i aktualizacje istniejących aplikacji przesyłane do Google Play i kierowane na urządzenia z Androidem 15 lub nowszym muszą obsługiwać rozmiary stron 16 KB na urządzeniach 64-bitowych.

Więcej informacji →

W przeszłości Android obsługiwał tylko strony pamięci o rozmiarze 4 KB, co optymalizowało wydajność pamięci systemowej pod kątem średniej ilości pamięci całkowitej, jaką zwykle miały urządzenia z Androidem. Od Androida 15 AOSP obsługuje urządzenia skonfigurowane do używania rozmiaru strony 16 KB (urządzenia 16 KB). Jeśli Twoja aplikacja używa bibliotek NDK bezpośrednio lub pośrednio za pomocą pakietu SDK, musisz ją przebudować, aby działała na urządzeniach o rozmiarze strony 16 KB.

Producenci urządzeń nadal tworzą urządzenia z większą ilością pamięci fizycznej (RAM). Wiele z nich będzie korzystać ze stron o rozmiarze 16 KB (a w przyszłości większych), aby zoptymalizować wydajność urządzenia. Dodanie obsługi urządzeń ze stronami o rozmiarze 16 KB umożliwia uruchamianie aplikacji na tych urządzeniach i korzystanie z powiązanych z tym ulepszeń wydajności. Bez ponownej kompilacji aplikacje nie będą działać na urządzeniach 16 KB w przyszłych wersjach Androida.

Aby pomóc Ci dodać obsługę w aplikacji, przygotowaliśmy wskazówki dotyczące sprawdzania, czy zmiana ma wpływ na Twoją aplikację, ponownego jej kompilowania (w odpowiednich przypadkach) oraz testowania aplikacji w środowisku 16 KB przy użyciu emulatorów (w tym obrazów systemu Android 15 dla emulatora Androida).

Korzyści i wzrost wydajności

Urządzenia skonfigurowane z użyciem stron o rozmiarze 16 KB zużywają średnio nieco więcej pamięci, ale zyskują też różne ulepszenia wydajności zarówno systemu, jak i aplikacji:

• Krótszy czas uruchamiania aplikacji, gdy system jest pod presją pamięci: średnio o 3,16% krótszy, a w przypadku niektórych testowanych aplikacji o znacznie więcej (do 30%).
• Zmniejszone zużycie energii podczas uruchamiania aplikacji: średnio o 4,56%
• Szybsze uruchamianie aparatu: średnio o 4,48% szybsze uruchomienia z pamięci i o 6,60% szybsze uruchomienia „na zimno”
• Skrócony czas uruchamiania systemu: skrócenie o 8% (około 950 milisekund)

Te ulepszenia bazują na naszych wstępnych testach. Wyniki na rzeczywistych urządzeniach mogą się różnić. W miarę kontynuowania testów będziemy przeprowadzać dodatkową analizę potencjalnych zysków w przypadku aplikacji.

Sprawdzanie, czy zmiana wpłynie na Twoją aplikację

Jeśli Twoja aplikacja używa kodu natywnego, zrekompiluj ją, aby obsługiwała urządzenia 16-kilobajtowe. Jeśli nie masz pewności, czy Twoja aplikacja używa kodu natywnego, możesz za pomocą narzędzia APK Analyzer sprawdzić, czy zawiera ona kod natywny, a następnie sprawdzić wyrównanie segmentów ELF w przypadku znalezionych bibliotek współdzielonych. Android Studio udostępnia też funkcje, które pomagają automatycznie wykrywać problemy z wyrównaniem.

Jeśli Twoja aplikacja używa tylko kodu napisanego w języku programowania Java lub Kotlin, w tym wszystkich bibliotek i pakietów SDK, to już obsługuje urządzenia 16-bitowe. Zalecamy jednak przetestowanie aplikacji w środowisku 16 KB, aby sprawdzić, czy nie występują nieoczekiwane regresje w jej działaniu.

Czy Twoja aplikacja korzysta z kodu natywnego?

Aplikacja korzysta z kodu natywnego, jeśli spełnia któreś z tych kryteriów:

• Aplikacja używa kodu C/C++ (natywnego). Jeśli aplikacja korzysta z Androida NDK, używa kodu natywnego.
• Twoja aplikacja jest połączona z bibliotekami natywnymi lub zależnościami innych firm (np. pakietami SDK), które ich używają.
• Twoja aplikacja została utworzona przez narzędzie do tworzenia aplikacji innych firm, które używa bibliotek natywnych na urządzeniu.

Identyfikowanie bibliotek natywnych za pomocą narzędzia APK Analyzer

Analizator APK to narzędzie, które umożliwia ocenę różnych aspektów skompilowanego pliku APK. Aby sprawdzić, czy Twoja aplikacja używa kodu natywnego (niezależnie od tego, czy jest zgodna z trybem 16 KB):

1. Otwórz Android Studio, a następnie kliknij Plik > Otwórz i wybierz dowolny projekt.

2. Na pasku menu kliknij Build > Analyze APK... (Kompilacja > Analizuj plik APK...).

   

3. Wybierz plik APK, który chcesz przeanalizować.

4. Sprawdź folder lib, w którym znajdują się pliki udostępnionych obiektów (.so), jeśli takie istnieją. Jeśli są obecne jakiekolwiek udostępnione pliki obiektowe, aplikacja używa kodu natywnego. W kolumnie Wyrównanie wyświetlają się komunikaty ostrzegawcze dotyczące plików, w których występują problemy z wyrównaniem. Jeśli nie ma plików obiektów współdzielonych lub folderu lib, aplikacja nie używa kodu natywnego.

   

Wykrywanie problemów z wyrównaniem za pomocą automatycznych kontroli

Android Studio z wyprzedzeniem ostrzega, jeśli wstępnie skompilowane biblioteki lub pliki APK nie są zgodne z wymaganiem 16 KB. Użyj analizatora APK, aby sprawdzić, które biblioteki wymagają aktualizacji lub czy konieczne są zmiany w kodzie.

Lint w Android Studio wyróżnia też biblioteki natywne, które nie są zgodne z trybem 16 KB.

Sprawdzanie wyrównania segmentów ELF w przypadku bibliotek współdzielonych

W przypadku wszystkich bibliotek udostępnionych sprawdź, czy segmenty ELF bibliotek udostępnionych są prawidłowo wyrównane przy użyciu wyrównania ELF 16 KB. Jeśli tworzysz aplikację w systemie Linux lub macOS, możesz użyć skryptu check_elf_alignment.sh w sposób opisany w następnej sekcji. Możesz też bezpośrednio używać narzędzi wiersza poleceń.

Użyj skryptu check_elf_alignment.sh (Linux lub macOS)

Aby sprawdzić wyrównanie segmentów ELF za pomocą skryptu check_elf_alignment.sh:

1. Zapisz skrypt check_elf_alignment.sh w pliku.

2. Uruchom skrypt na pliku APK aplikacji:

   check_elf_alignment.sh APK_NAME.apk
   

   Skrypt zwraca wartość ALIGNED lub UNALIGNED dla wszystkich arm64-v8azasobów wspólnych.

3. Jeśli którekolwiek biblioteki współdzielone arm64-v8a lub x86_64 są UNALIGNED, musisz zaktualizować pakiet tych bibliotek, a następnie ponownie skompilować aplikację i przeprowadzić test, wykonując czynności opisane w tej sekcji.

Bezpośrednie używanie narzędzi wiersza poleceń

Aby sprawdzić wyrównanie segmentów ELF bezpośrednio za pomocą narzędzi wiersza poleceń, wykonaj te czynności:

1. Upewnij się, że zarówno narzędzia Android SDK Build-Tools w wersji 35.0.0 lub nowszej, jak i pakiet Android NDK są zainstalowane za pomocą Menedżera SDK w Android Studio lub narzędzia wiersza poleceń sdkmanager.

2. Wyodrębnij plik APK aplikacji:

   Linux lub macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. W katalogu tymczasowym, do którego został wyodrębniony plik APK, sprawdź zawartość katalogu lib pod kątem plików obiektów współdzielonych (.so). Są to te same pliki obiektów współdzielonych, które można było zobaczyć podczas identyfikowania bibliotek natywnych za pomocą narzędzia APK Analyzer. Uruchom to polecenie w przypadku każdego pliku obiektu współdzielonego:

   Linux lub macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   gdzie SDK_ROOT_LOCATION to ścieżka do katalogu, w którym zainstalowano pakiet Android SDK, SHARED_OBJECT_FILE to nazwa sprawdzanego pliku obiektu współdzielonego, a NDK_VERSION to zainstalowana wersja pakietu Android NDK (np. 28.0.12433566). Dane wyjściowe będą wyglądać podobnie do tych poniżej w przypadku każdego sprawdzanego pliku:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. Sprawdź wiersze wyjściowe, aby upewnić się, że segmenty ładowania nie mają wartości mniejszych niż 2**14. Jeśli którykolwiek z segmentów ładowania ma wartość 2**13, 2**12 lub niższą, musisz zaktualizować pakiet tych bibliotek, a następnie ponownie skompilować aplikację i przeprowadzić test, wykonując czynności opisane w tej sekcji.

5. Następnie uruchom narzędzie wiersza poleceń zipalign na pliku APK aplikacji:

   Linux lub macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   gdzie SDK_ROOT_LOCATION to ścieżka do katalogu, w którym zainstalowano pakiet SDK Androida, a APK_NAME to nazwa pliku APK aplikacji. Jeśli wszystkie biblioteki współdzielone są prawidłowo dopasowane, w ostatnim wierszu danych wyjściowych pojawi się komunikat „Verification successful” (Weryfikacja zakończona).

   Jeśli weryfikacja się nie powiodła, niektóre biblioteki współdzielone wymagają ponownego wyrównania. W takim przypadku musisz zaktualizować pakiet tych bibliotek, a następnie ponownie skompilować aplikację i przeprowadzić test zgodnie z instrukcjami w tej sekcji.

Tworzenie aplikacji z obsługą urządzeń 16 KB

Jeśli Twoja aplikacja używa kodu natywnego, wykonaj czynności opisane w poniższych sekcjach, aby upewnić się, że obsługuje urządzenia o rozmiarze 16 KB:

1. Aktualizowanie pakietów bibliotek udostępnionych
2. Skompiluj aplikację z wyrównaniem ELF 16 KB
3. Poprawianie kodu i rozwiązywanie problemów z czasem działania
4. Sprawdzanie, czy pakiety SDK obsługują strony pamięci o rozmiarze 16 KB

Aktualizowanie pakietów bibliotek wspólnych

Zalecamy przejście na AGP w wersji 8.5.1 lub nowszej i używanie nieskompresowanych bibliotek wspólnych.

AGP w wersji 8.5.1 lub nowszej.

Urządzenia 16 KB wymagają, aby aplikacje dostarczane z nieskompresowanymi bibliotekami współużytkowanymi były wyrównane do granicy 16 KB wyrównanej do pliku ZIP. Aby to zrobić, musisz przejść na wtyczkę Androida do obsługi Gradle (AGP) w wersji 8.5.1 lub nowszej. Szczegółowe informacje o procesie uaktualniania znajdziesz w sekcji Asystent uaktualniania wtyczki Gradle do Androida.

AGP w wersji 8.5 lub starszej

Jeśli nie możesz uaktualnić AGP do wersji 8.5.1 lub nowszej, możesz zamiast tego używać skompresowanych bibliotek współdzielonych. Zaktualizuj konfigurację Gradle, aby podczas pakowania aplikacji narzędzie Gradle kompresowało biblioteki udostępnione. Pozwoli to uniknąć problemów z instalacją aplikacji z niewyrównanymi bibliotekami udostępnionymi.

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

Skompiluj aplikację pod kątem obsługi stron 16 KB przez format ELF

Aby aplikacja działała na urządzeniach 16 KB, segmenty ELF bibliotek współdzielonych muszą być prawidłowo wyrównane za pomocą wyrównania ELF 16 KB.

Jeśli jesteś deweloperem gier, a Twoja gra działa na silniku Unity, zapoznaj się z przewodnikiem po Unity. Jeśli Twoja gra działa na silniku Unreal Engine, zapoznaj się z przewodnikiem po Unreal. Jeśli używasz natywnych silników gier, postępuj zgodnie z instrukcjami w tym przewodniku.

Aby skompilować aplikację z użyciem wyrównania ELF 16 KB, wykonaj czynności opisane w jednej z tych sekcji w zależności od używanej wersji Android NDK.

Android NDK w wersji r28 lub nowszej

NDK w wersji r28 i nowszych domyślnie kompiluje kod z wyrównaniem do 16 KB.

Android NDK r27

Aby obsługiwać kompilowanie bibliotek współdzielonych wyrównanych do 16 KB za pomocą Android NDK w wersji r27 lub nowszej, musisz zaktualizować flagi ndk-build, build.gradle, build.gradle.kts lub linkera w ten sposób:

APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
      }
    }
  }
}

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments += listOf("-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
      }
    }
  }
}

-Wl,-z,max-page-size=16384

Android NDK r26 i starsze

Aby obsługiwać kompilowanie bibliotek współdzielonych dostosowanych do stron 16 KB za pomocą Android NDK w wersji r26 lub starszej, musisz zaktualizować konfigurację ndk-build lub cmake w ten sposób:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")

Android NDK w wersji r22 lub starszej

Jeśli używasz NDK w wersji 22 lub starszej, oprócz czynności opisanej w przypadku NDK w wersji 26 i starszych musisz ustawić common-page-size=16384. Ustawienie common-page-size=16384 jest wymagane ze względu na błędy w starszych wersjach linkerów GNU ld i LLVM lld. Zdecydowanie zalecamy jednak zaktualizowanie narzędzi do nowszej wersji, aby całkowicie uniknąć tych błędów.

Aby skompilować biblioteki udostępnione zgodne ze stronami 16 KB za pomocą Android NDK w wersji r22 lub starszej, zaktualizuj konfigurację ndk-build lub cmake w ten sposób:

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"
LOCAL_LDFLAGS += "-Wl,-z,common-page-size=16384"

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")
target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,common-page-size=16384")

Poprawianie kodu i rozwiązywanie problemów z czasem działania

Nawet jeśli aplikacja jest dostosowana do rozmiaru 16 KB, mogą w niej występować błędy, jeśli w kodzie znajdują się miejsca, w których zakłada się, że urządzenie używa określonego rozmiaru strony. Aby tego uniknąć, wykonaj te czynności:

1. Usuń z logiki kodu wszystkie zależności zakodowane na stałe, które odwołują się do stałej PAGE_SIZE lub instancji, które zakładają, że rozmiar strony urządzenia wynosi 4 KB (4096).

   Zamiast tego użyj getpagesize() lub sysconf(_SC_PAGESIZE).

2. Wyszukaj użycia funkcji mmap() i innych interfejsów API, które wymagają argumentów wyrównanych do strony, i w razie potrzeby zastąp je alternatywnymi rozwiązaniami.

W niektórych przypadkach, jeśli Twoja aplikacja używa wartości PAGE_SIZE jako wygodnej wartości, która nie jest powiązana z rozmiarem strony, nie spowoduje to nieprawidłowego działania aplikacji w trybie 16 KB. Jeśli jednak ta wartość zostanie przekazana do jądra z parametrem mmap bez MAP_FIXED, jądro nadal używa całej strony, co powoduje marnowanie pamięci. Z tych powodów wartość PAGE_SIZE jest nieokreślona, gdy w NDK w wersji r27 i nowszych włączony jest tryb 16 KB.

Jeśli Twoja aplikacja używa PAGE_SIZE w ten sposób i nigdy nie przekazuje tej wartości bezpośrednio do jądra, zamiast PAGE_SIZE utwórz nową zmienną o nowej nazwie, aby odzwierciedlić fakt, że jest ona używana do innych celów i nie odzwierciedla rzeczywistej strony pamięci.

Sprawdzanie, czy pakiety SDK obsługują strony pamięci o rozmiarze 16 KB

Wiele pakietów SDK jest zgodnych ze stronami o rozmiarze 16 KB, zwłaszcza jeśli tworzysz je samodzielnie lub korzystasz z najnowszych gotowych pakietów. Niektóre wstępnie skompilowane pakiety SDK lub wersje pakietów SDK nie są jednak zgodne z rozmiarem 16 KB, dlatego na stronie każdego dostawcy pakietu SDK należy sprawdzić, której wersji używać z rozmiarem 16 KB.

Testowanie aplikacji w środowisku 16 KB

Po utworzeniu aplikacji z obsługą urządzeń 16 KB warto ją przetestować w środowisku 16 KB, aby sprawdzić, czy nie występują w niej żadne regresje. W tym celu należy wykonać następujące czynności:

1. Skonfiguruj pakiet SDK Androida 15

2. Skonfiguruj jedno z tych środowisk testowych:

   • Konfigurowanie emulatora Androida z systemem Android 15 opartym na stronach 16 KB
     • Używanie Cuttlefish ze stronami o rozmiarze 16 KB na urządzeniach ARM64
     • Symulowanie Cuttlefish z rozmiarem strony 16 KB na platformie x86-64
   • Włączanie trybu 16 KB na urządzeniu za pomocą opcji programisty

3. Uruchom urządzenie testowe, a potem wykonaj to polecenie, aby sprawdzić, czy korzysta ono ze środowiska o rozmiarze 16 KB:

   adb shell getconf PAGE_SIZE
   

   Polecenie powinno zwrócić wartość 16384.

4. Uruchom to polecenie zipalign, aby sprawdzić, czy aplikacja jest wyrównana do 16 KB. Zastąp APK_NAME nazwą pliku APK aplikacji:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

5. Dokładnie przetestuj aplikację, zwracając szczególną uwagę na obszary, na które mogą mieć wpływ zmiany w instancjach kodu odwołujących się do określonych rozmiarów stron.

Konfigurowanie emulatora Androida z obrazem systemu Android 15 opartym na 16-kilobajtowych stronach

Aby skonfigurować środowisko 16 KB za pomocą emulatora Androida, wykonaj te czynności:

1. Obrazy systemu emulatora Androida 15 oparte na 16 KB są zgodne z Androidem Studio Jellyfish | 2023.3.1 lub nowszym. Aby jednak uzyskać najlepsze wrażenia podczas pracy z urządzeniami o pojemności 16 KB, używaj Androida Studio Ladybug w wersji 2024.2.1 lub nowszej.

   Stale pracujemy nad nowymi funkcjami, więc pobieraj nowsze wersje lub najnowszą wersję podglądową Android Studio, gdy tylko będą dostępne.

   Pamiętaj, że możesz zachować zainstalowaną wersję Android Studio, ponieważ możesz zainstalować kilka wersji obok siebie.

2. W Android Studio kliknij Tools > SDK Manager (Narzędzia > Menedżer SDK).

3. Na karcie Platformy pakietu SDK zaznacz Pokaż szczegóły pakietu, a następnie rozwiń sekcję Android VanillaIceCream lub nowszą i wybierz 1 lub 2 z tych obrazów systemu emulatora, w zależności od tego, jakie urządzenia wirtualne chcesz utworzyć:

   • Obraz systemu Google APIs Experimental 16 KB Page Size ARM 64 v8a
   • Google APIs Experimental 16 KB Page Size Intel x86_64 Atom System Image

   

4. Kliknij Zastosuj > OK, aby pobrać wybrane obrazy systemu.

5. Wykonaj czynności, aby skonfigurować urządzenie wirtualne z Androidem 15, a gdy pojawi się prośba o wybranie obrazu systemu, wybierz pobrany obraz systemu 16 KB. Jeśli nie jest zalecany automatycznie, obraz systemu o rozmiarze 16 KB znajdziesz na karcie Inne obrazy.

   

Dodatkowe czynności w przypadku niektórych wersji emulatora i obrazów systemu

Aby w przypadku emulatora Androida w wersjach od 35.1.5 do 35.1.20 oraz przed wersją 4 obrazów systemu Android 15.0 o rozmiarze strony 16 KB oferowanych w Menedżerze SDK symulować środowisko 16 KB na systemach x86_64, musisz też wykonać te czynności: Te kroki nie są potrzebne w przypadku wersji 35.1.21 i nowszych oraz w przypadku wersji 4 obrazów systemu Android 15.0 o rozmiarze strony 16 KB i nowszych.

1. W Menedżerze urządzeń kliknij 3 kropki obok obrazu o rozmiarze 16 KB, a następnie kliknij Pokaż na dysku.
2. W tym folderze znajdź plik config.ini.

3. Dodaj do pliku config.ini ten wiersz i zapisz zmiany:

   kernel.parameters = androidboot.page_shift=14
   

4. Aby sprawdzić zmiany, uruchom to polecenie, które powinno zwrócić wartość 16384:

   adb shell getconf PAGE_SIZE
   

Uruchamianie emulatora

Po skonfigurowaniu emulatora Androida i urządzeń wirtualnych uruchom emulator z menu urządzenia docelowego lub z wiersza poleceń.

Włączanie trybu 16 KB na urządzeniu za pomocą opcji programisty

Włącz opcję programisty Uruchom ze stroną 16 KB, aby uruchomić urządzenie w trybie 16 KB.

Od Androida 15 QPR1 możesz użyć opcji programisty dostępnej na niektórych urządzeniach, aby uruchomić urządzenie w trybie 16 KB i przeprowadzić testowanie na urządzeniu. Zanim skorzystasz z opcji programisty, otwórz Ustawienia > System > Aktualizacje oprogramowania i zastosuj dostępne aktualizacje.

Ta opcja dla programistów jest dostępna na tych urządzeniach:

• Pixel 8 i 8 Pro (z Androidem 15 QPR1 lub nowszym)

  Ostrzeżenie: z powodu znanego problemu z Androidem 15 QPR2 Beta 3 ekran dotykowy nie działa na urządzeniach Pixel 8 po zainstalowaniu Androida 15 QPR2 Beta 3 i uruchomieniu urządzenia w trybie 16 KB. Ten problem nie występuje na urządzeniach Pixel 8 Pro.

• Pixel 8a (z Androidem 15 QPR1 lub nowszym)

  Ostrzeżenie: z powodu znanego problemu z Androidem 15 QPR2 Beta 3 ekran dotykowy nie działa na urządzeniach Pixel 8a po zainstalowaniu Androida 15 QPR2 Beta 3 i uruchomieniu urządzenia w trybie 16 KB.

• Pixel 9, 9 Pro i 9 Pro XL (z Androidem 15 QPR2 Beta 2 lub nowszym)

Wymagania dotyczące zgodności z Google Play

Producenci urządzeń wyposażają je w większą ilość pamięci RAM, aby zoptymalizować wydajność. Wiele z nich będzie stosować większe rozmiary stron, np. 16 KB. Aby przygotować się na wprowadzenie tych urządzeń, Google Play wprowadza nowe wymaganie dotyczące zgodności: od 1 listopada 2025 r. wszystkie nowe aplikacje i aktualizacje istniejących aplikacji przesyłane do Google Play i kierowane na urządzenia z Androidem 15 (API na poziomie 35) lub nowszym muszą obsługiwać rozmiary stron 16 KB.

Więcej informacji o tym wymaganiu dotyczącym zgodności znajdziesz w tym poście na blogu.