Szybka odpowiedź
Google Play wymaga, aby aplikacje kierowane na Androida 15 (poziom API 35) lub nowszego obsługiwały rozmiar stron pamięci 16 KB na urządzeniach 64-bitowych, a od 1 lutego 2027 r. nie opublikujesz aktualizacji, które tego nie robią. Aplikacja napisana wyłącznie w Javie lub Kotlinie, wraz ze wszystkimi swoimi bibliotekami i pakietami SDK, spełnia wymóg już teraz. Aplikacja pakująca natywne biblioteki .so nie przejdzie, dopóki każda z nich nie zostanie skompilowana od nowa albo wymieniona, najlepiej z użyciem Android Gradle Plugin 8.5.1+ i NDK r28+, a kompilacja nie przejdzie dwóch osobnych kontroli: każdy segment LOAD w ELF wyrównany co najmniej do 2**14 oraz app bundle raportujący PAGE_ALIGNMENT_16K. Podniesienie wersji frameworka nie jest dowodem; dowodem jest plik wynikowy. Jeśli usuwanie tego ostrzeżenia zatrzymało testy zamknięte (closed testing), które właśnie prowadzisz, PrimeTestLab utrzymuje stronę testerską w ruchu, kiedy Ty kompilujesz od nowa.
Ostrzeżenie jest krótkie, w najlepszym razie podaje jedną nazwę pliku i pojawia się wtedy, gdy uznałeś kompilację za skończoną. Dlatego wciąż powtarzają się te same trzy złe skręty: deweloperzy ufają terminowi, który się przesunął, podnoszą wersję frameworka i zakładają, że sprawa załatwiona, albo sprawdzają jeden lokalny plik APK i nigdy nie zaglądają do bundle'a, z którego Google faktycznie buduje. Ten artykuł jest ułożony tak, jak problem naprawdę się rozwiązuje, czyli rozpoznaj, przypisz, napraw, udowodnij, a wszystko w nim jest aktualne na 5 sierpnia 2026 r. i sprawdzone względem przewodnika Google o rozmiarach stron tego samego dnia, w którym tamta strona była aktualizowana po raz ostatni. Tam, gdzie dowodem jest system zgłoszeń opiekuna pakietu, a nie oficjalna informacja o wydaniu, strona mówi to wprost na karcie, zamiast zaokrąglać to do faktu.
Laboratorium wyrównania
Dwanaście narzędzi zbudowanych pod ten jeden błąd. Żadne z nich nie wymaga konta, wgrywania plików ani połączenia z siecią; wszystkie działają w Twojej przeglądarce na wartościach, które sam wpiszesz.
Spis treści
Napraw to w trzech krokach
Każda prawdziwa naprawa tego błędu to te same trzy ruchy w tej samej kolejności: zidentyfikuj niewyrównaną bibliotekę natywną, zaktualizuj zależność, do której należy, a potem udowodnij poprawność pliku wynikowego, który zaraz prześlesz. Przeskakiwanie od razu do kroku drugiego to powód, dla którego tylu deweloperów podnosi wersję frameworka, kompiluje od nowa i patrzy, jak ostrzeżenie wraca w niezmienionej postaci.
Sam wymóg jest wąski. Przewodnik Google o rozmiarach stron mówi, że aplikacje kierowane na Androida 15 (poziom API 35) lub nowszego muszą obsługiwać rozmiar stron pamięci 16 KB na urządzeniach 64-bitowych oraz że od 1 lutego 2027 r. nie opublikujesz aktualizacji, które tego nie robią. Dotyczy to wyłącznie kodu natywnego. Jeśli Twoja aplikacja i każda biblioteka oraz każdy pakiet SDK w niej to czysta Java albo Kotlin, Google stwierdza, że Twoja aplikacja już obsługuje urządzenia 16 KB. Kłopot w tym, że większość deweloperów, którzy widzą to ostrzeżenie, uważa się za tę kategorię, a nią nie jest.
Zidentyfikuj wadliwy plik .so
Otwórz plik APK wersji wydania w Android Studio przez Build > Analyze APK..., rozwiń lib/arm64-v8a oraz lib/x86_64 i przeczytaj kolumnę Alignment. Zapisz każdą oznaczoną nazwę pliku. Te nazwy plików to jedyne wiarygodne klucze wyszukiwania, jakie masz.
Zaktualizuj to, do czego należy
Plik, który sam skompilowałeś, naprawia Twój zestaw narzędzi: AGP 8.5.1 lub nowszy z NDK r28 lub nowszym. Plik, który przyszedł we wtyczce, pakiecie SDK, silniku albo AAR, może naprawić tylko ten, kto go zbudował, więc działaniem jest podniesienie wersji, wymiana albo poproszenie tego pakietu o przebudowany plik.
Znajdź najkrótszą drogę dla swojego frameworkaUdowodnij plik wynikowy, a nie podniesienie wersji
Dwie niezależne kontrole muszą przejść obie. Każdy segment LOAD w ELF musi być wyrównany do 2**14 lub wyżej, a bundletool musi zgłosić PAGE_ALIGNMENT_16K dla bundle'a wydania. Zaliczenie jednej nie dowodzi niczego o drugiej.
Cała decyzja na jednym ekranie
Zanim ruszysz choć jedną wersję zależności, przejdź to drzewo. Zajmuje jakieś dwie minuty i decyduje o różnicy między naprawieniem właściwej rzeczy a podniesieniem wersji jedenastu pakietów, które nigdy nie były problemem.
Czy plik APK wersji wydania zawiera katalog lib z plikami .so?
Wymóg już spełniony
W pliku APK nie ma kodu natywnego. Google stwierdza, że aplikacja tylko w Javie albo Kotlinie, wraz z bibliotekami i pakietami SDK, obsługuje już urządzenia 16 KB. Mimo to wart jest jeden przebieg testowy, a także potwierdzenie, że sprawdziłeś tę samą kompilację, którą przesłałeś.
Czy APK Analyzer albo check_elf_alignment.sh wskazuje niewyrównaną bibliotekę?
Najpierw przypisz, potem podnoś wersję
Ustal, który framework, wtyczka, pakiet SDK albo silnik dostarcza dokładnie tę nazwę pliku, i zaktualizuj ten pakiet. Twoje własne NDK nie przepisze cudzego gotowego pliku binarnego.
Co bundletool dump config zgłasza dla bundle'a wydania?
PAGE_ALIGNMENT_4K
Biblioteki są w porządku, ale pakowanie już nie. Przejdź na AGP 8.5.1 lub nowszy i skompiluj od nowa albo zastosuj obejście ze starym pakowaniem, jeśli nie możesz podnieść wersji.
PAGE_ALIGNMENT_16K
Pakowanie jest poprawne. Teraz przetestuj pliki APK wygenerowane przez Play w prawdziwym środowisku 16 KB i przejrzyj kod działający w czasie wykonania, który zakłada stały rozmiar strony.
Pułapka w jednym zdaniu
Lokalny plik APK, który przechodzi każdą kontrolę wyrównania, nie dowodzi, że przesłany bundle jest poprawny. Google ostrzega wprost, że Android Gradle Plugin od 8.3 do 8.5 potrafi wyprodukować bundle, z którego Play buduje pliki APK niewyrównane prawidłowo w ZIP, nawet jeśli plik APK na Twoim komputerze wygląda idealnie. Ta rozbieżność jest zdecydowanie najczęstszym powodem, dla którego ostrzeżenie przeżywa "udaną" naprawę.
Co naprawdę oznacza ostrzeżenie w Play Console
Konsekwencja udokumentowana przez Google jest precyzyjna: od 1 lutego 2027 r. nie będziesz mógł publikować aktualizacji kierowanych na Androida 15 (poziom API 35) lub nowszego bez obsługi 16 KB. To blokada publikacji aktualizacji, a nie stwierdzenie, że opublikowana aplikacja zostanie tego dnia usunięta ze sklepu. Do tego czasu większość deweloperów widzi ostrzeżenie o zgodności, a nie twarde odrzucenie przy przesyłaniu.
Sformułowanie ma znaczenie, bo panikarska wersja tej historii podróżuje szybciej niż dokładna. Przeczytaj napisy, które Google faktycznie pokazuje, a zakres okaże się wąski i do ogarnięcia.
App must support 16 KB memory page sizes
Odtworzone ze zrzutu ekranu Play Console, który Google publikuje w przewodniku o rozmiarach stron. Etykiety zostają po angielsku dokładnie tak, jak na tamtym zrzucie: Twoja Konsola Play może pokazywać je po polsku, a układ i dostępne przyciski mogą różnić się w zależności od konta.
Dwa odczytania tej karty bywają błędne. Po pierwsze, "Action by Feb 1, 2027" nie jest odliczaniem do usunięcia; własny tekst Google na tej samej stronie opisuje skutek jako brak możliwości opublikowania tych aktualizacji. Po drugie, napis Extension granted pojawia się na zrzucie ekranu Google, ale to nie dowodzi, że procedura wnioskowania o przedłużenie jest teraz dla Ciebie otwarta. Uznaj przedłużenie za realne dopiero wtedy, gdy zobaczysz tę opcję we własnej Play Console.
Który termin właściwie przeczytałeś?
W obiegu są trzy daty, a obowiązuje tylko jedna. Wybierz tę, którą widziałeś, a narzędzie ustali jej status względem obecnej strony Google, aktualizowanej ostatnio 5 sierpnia 2026 r.
Narzędzie 01
Rozstrzygacz terminów
Google przesuwał ten termin już nieraz. Zanim ułożysz plan wydania wokół 1 lutego 2027 r., otwórz sam przewodnik o rozmiarach stron i sprawdź stempel "Last updated" na dole. Ten jeden nawyk jest wart więcej niż jakakolwiek data wydrukowana w artykule, włącznie z tym.
Czy wymóg 16 KB dotyczy mojej aplikacji?
Nie decyduje o tym Twój framework. Decyduje zawartość wygenerowanego pliku APK. Jeśli w katalogu lib są pliki .so, mieścisz się w zakresie niezależnie od tego, czy kiedykolwiek otwierałeś plik C++, a jeśli nie ma tam żadnych, własne wytyczne Google mówią, że już obsługujesz urządzenia 16 KB.
Aplikacje w czystej Javie albo Kotlinie
Google jest tu jednoznaczne: jeśli Twoja aplikacja i wszystkie jej biblioteki oraz pakiety SDK korzystają wyłącznie z Javy albo Kotlina, Twoja aplikacja już obsługuje urządzenia 16 KB. Google i tak zaleca test w środowisku 16 KB, żeby wychwycić nieoczekiwane regresje, a to kosztuje jeden przebieg na emulatorze.
Haczyk tkwi w zwrocie "i wszystkie jej biblioteki oraz pakiety SDK". Pojedyncza zależność bazodanowa, analityczna, do raportowania awarii, multimedialna, mapowa, uczenia maszynowego albo bezpieczeństwa potrafi dodać pliki natywne do projektu, w którego własnym kodzie nie ma nic poza Kotlinem. "Nie pisałem w C++" nie jest dowodem. Katalog lib jest.
Flutter, React Native, Unity, Kivy i kreatory bez kodu
Te stosy z założenia niosą natywne środowiska uruchomieniowe, pliki silników i biblioteki wtyczek, więc prawie zawsze mieszczą się w zakresie. Google wprost wymienia kreatory aplikacji firm trzecich korzystające z bibliotek natywnych jako sposób, w jaki aplikacja może zostać objęta wymogiem, nawet jeśli jej autor nigdy nie napisał linijki w C ani C++. Różni się nie to, czy masz kod natywny, ale który pakiet dostarczył wadliwy element, i dlatego przypisanie nazwy pliku wyprzedza jakiekolwiek podnoszenie wersji.
Jak dokładnie to sprawdzić
Otwórz plik APK wersji wydania, rozwiń lib i zobacz katalogi ABI w środku, zwykle arm64-v8a i x86_64. Obecność jakichkolwiek plików shared object oznacza, że Twoja aplikacja używa kodu natywnego. Brak plików .so i brak katalogu lib oznacza, że ten plik APK w ogóle nie używa kodu natywnego. Kolumna Alignment w analizatorze pokazuje komunikaty ostrzegawcze przy plikach z problemami wyrównania i to jest najszybsza droga od "coś jest nie tak" do nazwy pliku.
Narzędzie 02
Triaż zasięgu wymogu
01 Na co obecnie kierowana jest Twoja aplikacja?
02 Otwórz plik APK wydania w APK Analyzerze. Czy jest tam katalog lib?
03 Co najlepiej opisuje tę aplikację?
04 Czy uruchomiłeś bundletool dump config na bundle'u wydania?
Dlaczego plik 4 KB zawodzi na urządzeniu 16 KB
Strona pamięci to najmniejszy blok, który jądro mapuje za jednym razem. Android historycznie używał stron 4 KB; Android 15 dodał obsługę urządzeń skonfigurowanych ze stronami 16 KB. Biblioteka natywna zapisuje wyrównanie, pod które konsolidowano jej segmenty, a jeśli ta wartość jest mniejsza niż rozmiar strony urządzenia, program ładujący nie potrafi umieścić segmentu na granicy strony.
To cała mechanika i to ona wyjaśnia jedną liczbę, którą będziesz widzieć bez końca. Wyrównanie wyraża się jako potęgę dwójki: 2**12 to 4096 bajtów, a 2**14 to 16384 bajty. Reguła Google mówi, że każdy segment LOAD w bibliotece natywnej musi być wyrównany do 2**14 lub wyżej. Biblioteka zbudowana na 2**14 działa i na urządzeniach 4 KB, i na 16 KB, bo 16384 jest czystą wielokrotnością 4096. Biblioteka zbudowana na 2**12 działa tylko przy mniejszym rozmiarze strony. Ta asymetria jest powodem, dla którego naprawą zawsze jest "podnieś wyrównanie", a nigdy "wykryj urządzenie".
Narzędzie 03
Wizualizator stron pamięci
Wybierz wyrównanie, które zgłasza Twoja biblioteka, i zobacz, gdzie jej segmenty mogą się zaczynać na urządzeniu ze stronami 16 KB.
Przechodzi
Istnieje drugie, całkowicie odrębne ograniczenie, które żyje poza biblioteką. Nieskompresowane biblioteki natywne przechowywane wewnątrz pliku APK muszą również leżeć na granicy 16 KB w samym archiwum ZIP. To właściwość pakowania, sprawdzana poleceniem zipalign i konfigurowana przez Twoją wtyczkę kompilacji, i może być błędna nawet wtedy, gdy każda biblioteka w środku jest wyrównana idealnie. Rozdzielenie tych dwóch pojęć to najużyteczniejsza rzecz, jaką możesz wynieść z tej sekcji.
Jak czytać te liczby
Kiedy widzisz 2**14 w wyniku llvm-objdump, to zaliczenie. 2**13 albo 2**12 to niezaliczenie. Nie ma punktów częściowych ani "wystarczająco blisko": jeden niewyrównany segment LOAD w jednej bibliotece w jednym ABI wystarczy, żeby ostrzeżenie zostało na Twoim koncie.
Najkrótsza naprawa dla każdego frameworka
Gotowość frameworka i zgodność aplikacji to dwie różne rzeczy. React Native 0.77 oraz obsługiwane wersje Unity to prawdziwe, udokumentowane progi. Flutter nie ma weryfikowalnego uniwersalnego minimum. W każdym przypadku podniesienie wersji naprawia własne pliki frameworka i zostawia każdą wtyczkę firmy trzeciej dokładnie tak niezgodną, jak była.
Narzędzie 04
Wyszukiwarka frameworków
Co dalej może zawieść
Wszystkie progi w jednej tabeli
| Framework | Udokumentowany próg | Najkrótsze działanie | Pewność |
|---|---|---|---|
| Flutter | Brak zweryfikowanego uniwersalnego minimum; 3.38 to udokumentowany kamień milowy przygotowania (domyślne NDK r28) | Bieżący stabilny Flutter, aktualizacja wtyczek natywnych, czyszczenie, kompilacja od nowa, sprawdzenie każdej biblioteki | CZĘŚCIOWE |
| React Native | 0.77 | Obsługiwana ścieżka podniesienia wersji, potem aktualizacja modułów natywnych i pakietów SDK dostawców | POTWIERDZONE |
| Linia Unity 6.1 | 6000.1 lub nowsza | Podnieś edytor, zaktualizuj pakiety i wtyczki, skompiluj od nowa | POTWIERDZONE |
| Unity 6 LTS | 6000.0.38f1 lub nowsza | Tak samo jak wyżej | POTWIERDZONE |
| Unity 2022 LTS | 2022.3.56f1 lub nowsza | Tak samo jak wyżej | POTWIERDZONE |
| Unity 2021 | 2021.3.48f1 lub nowsza, wymagane uprawnienie do przedłużonego LTS | Podnieś wersję, jeśli masz uprawnienie, w przeciwnym razie przejdź na obsługiwany edytor | POTWIERDZONE |
| Unity Burst | 1.8.21 lub nowszy | Podnieś Burst, gdy wskazany jest lib_burst_generated.so |
POTWIERDZONE |
| Natywny Android | NDK r28+ z AGP 8.5.1+ | Skompiluj ponownie własny kod, zaktualizuj każdą gotową zależność | POTWIERDZONE |
| Przypięcie do starszego NDK | r27 lub starsze z obiema opcjami konsolidatora | Dodaj max-page-size i common-page-size, skompiluj od nowa wszystkie biblioteki |
DZIAŁA, ALE NIE JEST ZALECANE |
| Kivy albo kreator w Pythonie | Brak zweryfikowanej uniwersalnej wersji | Zaktualizuj kreator i receptury, zgłoś dokładną nazwę pliku twórcom | ZALEŻY OD DOSTAWCY |
| Kreator no-code | Brak zweryfikowanej uniwersalnej wersji | Wygeneruj ponownie na zgodnym stosie dostawcy, wyślij mu nazwę pliku | ZALEŻY OD DOSTAWCY |
Etykiety pewności znaczą to samo w całym tym artykule. POTWIERDZONE oznacza, że bieżące źródło pierwotne mówi to wprost. CZĘŚCIOWE oznacza, że wiarygodne źródło wspiera rdzeń twierdzenia, ale nie każdy szczegół wdrożenia. ZGŁOSZONE oznacza, że dowodem jest system zgłoszeń opiekuna albo relacje deweloperów, a nie oficjalna informacja o wydaniu.
Znajdź dokładnie tę bibliotekę, która powoduje błąd
Nazwa pliku to całe śledztwo. Gdy już wiesz, że wadliwym plikiem jest libfoo.so, pytanie przestaje brzmieć "jak naprawić obsługę 16 KB", a zaczyna brzmieć "który pakiet dostarcza libfoo.so i czy istnieje nowsza wersja". To drugie pytanie ma odpowiedź; pierwsze nie ma.
Zacznij od APK Analyzera
Otwórz Build > Analyze APK..., wczytaj plik APK wersji wydania i rozwiń lib. W środku zobaczysz po jednym katalogu na każde ABI, zwykle arm64-v8a i x86_64. Kolumna Alignment pokazuje komunikaty ostrzegawcze przy plikach z problemami wyrównania. Własne ostrzeżenia Android Studio i Lint również podświetlają niezgodne biblioteki natywne, więc to samo znalezisko możesz zobaczyć w więcej niż jednym miejscu.
Zapisz każdą oznaczoną nazwę pliku, zanim tkniesz choć jeden numer wersji. Sprawdź osobno oba katalogi ABI: całkowicie normalne jest, że arm64-v8a przechodzi, a x86_64 nie, albo odwrotnie, bo to różne pliki binarne budowane potencjalnie przez różne procesy.
Odczytaj wynik z wiersza poleceń
Jeśli wolisz pracować w terminalu, Google udostępnia check_elf_alignment.sh, który zgłasza ALIGNED albo UNALIGNED dla pliku APK, a pojedynczą bibliotekę możesz sprawdzić bezpośrednio przez llvm-objdump. Oba wymagają Android SDK Build-Tools 35.0.0 lub nowszych. Wklej poniżej to, co wypiszą, a narzędzie odczyta to dla Ciebie.
Narzędzie 05
Dekoder ELF
Wklej wynik z llvm-objdump -p plik.so | grep LOAD, check_elf_alignment.sh albo zipalign -c -P 16. Wszystko jest analizowane w Twojej przeglądarce; nic nigdzie nie jest wysyłane.
Ustal, do której zależności ona należy
Play Console i APK Analyzer dają Ci nazwę pliku i żadnego właściciela. Wpisz ją poniżej, a narzędzie powie Ci, co wiadomo o tym pliku, wraz z jakością dowodów, i poda polecenia wyszukiwania z już wstawioną Twoją nazwą pliku.
Narzędzie 06
Właściciel biblioteki
./gradlew app:dependencies pokazuje rozwiązany graf zależności i tak właśnie znajdziesz pakiet przechodni, który wciągnął bibliotekę nigdy przez Ciebie niedodaną. Nie powie Ci wprost, który artefakt zawiera dany plik .so, więc połącz to z rozpakowaniem podejrzanego pliku AAR. To praktyczne techniki diagnostyczne, a nie kroki nakazane przez Google.
Sprawdź app bundle, a nie tylko lokalny plik APK
Twój lokalny plik APK i pliki APK, które Google Play generuje z Twojego bundle'a, to różne pliki wynikowe. Wyrównanie ELF mieszka wewnątrz każdej biblioteki; wyrównanie ZIP jest właściwością tego, jak spakowano archiwum; a bundle niesie konfigurację mówiącą Play, którego z nich użyć. Wszystkie trzy mogą się różnić, a tylko ten ostatni decyduje o tym, co instalują użytkownicy.
To mechanizm stojący za najbardziej frustrującą wersją tego problemu: deweloper podnosi wszystkie wersje, sprawdza lokalny plik APK, widzi czysty wynik, przesyła i ostrzeżenie dalej tam jest. Nic z tego, co sprawdził, nie było błędne. Po prostu nigdy nie sprawdził tego, co ocenia Play.
Co sprawdziłeś
app-release.apk na Twoim komputerzeZbudowany bezpośrednio przez Gradle na Twoim sprzęcie, z Twoim zachowaniem pakowania. Zaliczenie zipalign tutaj dowodzi, że ten plik jest spakowany poprawnie.
Co ocenia Play
Pliki APK generowane z app-release.aabZbudowane przez Google z Twojego bundle'a, z wyrównaniem, o które prosi bundle. Jeśli bundle mówi 4 KB, są błędne bez względu na to, jak czysty był Twój lokalny plik APK.
Dlatego uruchamiaj to na bundle'u, który zaraz prześlesz, za każdym razem:
bundletool dump config --bundle=app-release.aab | grep alignment
PAGE_ALIGNMENT_16K to wynik, którego oczekujesz. PAGE_ALIGNMENT_4K oznacza, że bundle każe bundletool pakować biblioteki natywne na granicach 4 KB, więc każdy plik APK, który Play z niego zbuduje, będzie błędny. Google wprost ostrzega, że Android Gradle Plugin od 8.3 do 8.5 potrafi wyprodukować dokładnie taką rozbieżność: lokalna kompilacja wygląda na wyrównaną, a aplikacja budowana przez Play z bundle'a nie instaluje się poprawnie na urządzeniu 16 KB. Zalecaną naprawą jest przejście na Android Gradle Plugin 8.5.1 lub nowszy.
Każde polecenie z Twoimi własnymi nazwami plików
Wpisz swoje nazwy plików raz. Każde polecenie poniżej przepisze się samo, a każda zakładka pokazuje dokładny wynik, który liczy się jako zaliczenie, więc nigdy nie zgadujesz, czy rezultat był dobry.
Narzędzie 07
Laboratorium poleceń
Nie kończ na "APK Analyzer mówi, że wyrównane"
Zaliczona inspekcja pliku APK to jedna z czterech kontroli, a nie meta. Potwierdź wyrównanie LOAD w ELF, wyrównanie ZIP w pliku APK, konfigurację bundle'a oraz zachowanie w czasie wykonania tego pliku, który Play faktycznie generuje. Niezaliczenie choćby jednej z nich wystarczy, by ostrzeżenie zostało na Twoim koncie po kompilacji, którą uważałeś za naprawioną.
AGP, NDK i pułapka pakowania
Dwie wersje dźwigają większość ciężaru. NDK r28 lub nowszy kompiluje kod natywny domyślnie z wyrównaniem 16 KB, a Android Gradle Plugin 8.5.1 lub nowszy poprawnie pakuje nieskompresowane biblioteki natywne na granicach ZIP 16 KB. Żaden z nich nie naprawi wcześniej skompilowanego pliku, który przyszedł w zależności.
Niebezpiecznym środkiem jest Android Gradle Plugin od 8.3 do 8.5. W tym przedziale lokalna kompilacja może wyglądać całkowicie poprawnie, podczas gdy bundletool nie wyrównuje w ZIP plików APK, które produkuje z Twojego bundle'a dla Play, a Google określa skutek bez ogródek: aplikacja zbudowana z tego bundle'a nie zainstaluje się poprawnie. Jeśli jesteś na 8.5.0, a Twój lokalny plik APK przechodzi każdą kontrolę, jaka przychodzi Ci do głowy, to właśnie to trzeba wykluczyć w pierwszej kolejności.
Narzędzie 08
Kontrola toolchainu
Ściąga z ustawieniami kompilacji
| Sytuacja | Ustawienie | Uwagi |
|---|---|---|
| Zalecane NDK | r28 lub nowsze |
Produkuje domyślnie wyjście natywne wyrównane do 16 KB |
| Zalecane AGP | 8.5.1 lub nowsze |
Obsługuje nieskompresowane biblioteki natywne na granicach ZIP 16 KB |
| NDK r27 lub starsze | -Wl,-z,max-page-size=16384 |
Wymagana opcja konsolidatora przy każdym celu natywnym |
| NDK r27 lub starsze | -Wl,-z,common-page-size=16384 |
Używaj razem z opcją maksymalnego rozmiaru strony |
ndk-build |
LOCAL_LDFLAGS += ... |
Zastosuj obie opcje do każdego celu natywnego |
| CMake | target_link_options(...) |
Zastosuj obie opcje do każdego istotnego celu |
| Nie da się podnieść AGP | jniLibs.useLegacyPackaging = true |
Kompresuje biblioteki natywne; zwiększa zużycie dysku po instalacji |
| AGP 8.0 lub starszy | android.bundle.enableUncompressedNativeLibs=false |
Dodatkowa stara właściwość obok opcji powyżej |
| Kod w czasie wykonania | getpagesize() albo sysconf(_SC_PAGESIZE) |
Zastąp zaszyte na sztywno 4096 i założenia o stałym PAGE_SIZE |
Część, której pakowanie nie naprawi
Jeśli Twój własny kod w C albo C++ zakłada rozmiar strony, żadna flaga kompilacji Cię nie uratuje. Usuń zaszyte na sztywno wartości 4096 i wszelkie poleganie na stałej PAGE_SIZE, pytaj o prawdziwą wartość w czasie wykonania przez getpagesize() albo sysconf(_SC_PAGESIZE) i przejrzyj każde wywołanie mmap() wraz z każdym argumentem, który ręcznie wyrównujesz do strony. To ta klasa awarii, w której aplikacja instaluje się czysto na urządzeniu 16 KB, przechodzi kontrole bundle'a, a potem wywala się przy pierwszym dotknięciu mapowania pamięci.
Kolejność działań
Napraw stronę kompilatora przed stroną pakowania. Jeśli najpierw zastosujesz obejście ze starym pakowaniem, Twój plik APK zacznie przechodzić zipalign, podczas gdy biblioteki w środku wciąż będą zbudowane pod strony 4 KB, a Ty ukryjesz prawdziwy problem za zielonym wynikiem.
Przetestuj w prawdziwym środowisku 16 KB
O tym, czy Twój test cokolwiek znaczy, decyduje jedno polecenie: adb shell getconf PAGE_SIZE musi zwrócić 16384. Uruchamiaj je przed każdą sesją. Emulator, który po cichu wystartował w trybie 4 KB, przepuści zepsutą kompilację przez wszystko, co w nią rzucisz.
Masz trzy drogi praktyczne i dwie specjalistyczne. Wybierz tę, do której naprawdę dotrzesz dzisiaj; do wyłapywania błędów rozmiaru stron nie ma między nimi różnicy jakościowej.
Narzędzie 09
Wybór środowiska testowego
Ograniczenie
Potem, za każdym razem, przed każdym testem
adb shell getconf PAGE_SIZE
Nie idź dalej, dopóki wynik nie wynosi 16384.
Co właściwie trzeba przećwiczyć
Gdy środowisko jest już potwierdzone, użytecznym przebiegiem nie jest "czy się uruchamia". Awarie natywne skupiają się w funkcjach dotykających kodu natywnego, więc uruchom je świadomie: zimny start, nawigacja po aplikacji, aparat, odczyt i zapis w bazie danych, odtwarzanie i nagrywanie multimediów, logowanie, praca w tle, każda funkcja uczenia maszynowego albo rzeczywistości rozszerzonej, każda powierzchnia wtyczki natywnej i wszystko we własnym kodzie, co korzysta z mapowania pamięci. Jeśli jakaś funkcja stoi na jednej z bibliotek, które właśnie podniosłeś, to właśnie ta funkcja jest testem.
Tryb zgodności to nie zaliczenie
Android potrafi uruchomić część aplikacji wyrównanych do 4 KB na urządzeniu 16 KB przez ścieżkę zgodności i wtedy przy pierwszym starcie możesz zobaczyć ostrzeżenie. Google i tak zaleca prawidłowe wyrównanie do 16 KB dla najlepszej niezawodności i stabilności. Aplikacja, która działa tylko dlatego, że wkroczył tryb zgodności, nie jest aplikacją naprawioną, a publikowanie na tej podstawie oznacza, że prawdziwa awaria wciąż jest przed Tobą.
Dlaczego ostrzeżenie przeżywa podniesienie wersji
Niemal każdy przypadek "przecież już to naprawiłem" to jedna z trzynastu konkretnych sytuacji, a jedenaście z nich da się udowodnić z pliku leżącego przed Tobą. Wybierz pasujący objaw, a przyczynę zwykle poznasz, zanim skończysz go czytać.
Narzędzie 10
Triaż uporczywego ostrzeżenia
Dwie z tych pozycji zasługują na zastrzeżenie zamiast pewnej odpowiedzi. Żadne źródło pierwotne nie ustala, ile czasu zajmuje Google Play ponowna ocena przesłanego bundle'a, więc jeśli ostrzeżenie utrzymuje się tuż po przesłaniu, uczciwym ruchem jest potwierdzić, że nowy kod wersji pojawia się w sekcji najnowszych wersji i pakietów aplikacji, a potem sprawdzić jeszcze raz później, zamiast ufać jakiejkolwiek konkretnej liczbie przeczytanej o czasach przetwarzania. A aplikacja, która działa wyłącznie dlatego, że wkroczył tryb zgodności, nie została naprawiona, tylko obsłużona wyrozumiale.
Biblioteki firm trzecich, które ciągle wracają
To zgłoszone przykłady, a nie ranking tego, jak częsty jest każdy z nich, ani obietnica, że dana wersja naprawi Twoją kompilację. Pakiet może w dowolnym wydaniu dodać, usunąć albo wymienić pliki natywne. Ostatnie słowo zawsze należy do pliku binarnego siedzącego w Twoim własnym bundle'u wydania.
Użyj tego jako punktu wyjścia, kiedy nazwa pliku wyda Ci się znajoma, a potem sprawdź to w bieżących wydaniach i otwartych zgłoszeniach danego projektu. Tam, gdzie dowodem jest system zgłoszeń opiekuna, a nie informacja o wydaniu, karta mówi to wprost.
Narzędzie 11
Indeks zgłoszonych bibliotek
libobjectbox-jni.so
Starsze natywne biblioteki Androida zawodziły w środowisku 16 KB. Konkretna naprawiona wersja nie została tu potwierdzona na tyle mocno, by ją opublikować. Sprawdź bieżące informacje o wydaniach ObjectBox pod kątem wersji, która dodała obsługę 16 KB, a potem potwierdź to plikiem binarnym w skompilowanym pliku APK, zamiast ufać samemu numerowi wersji.
dołączona biblioteka Androida
Pakiet SDK ObjectBox dla Darta niesie własną bibliotekę Androida. Konkretna naprawiona wersja nie została tu potwierdzona na tyle mocno, by ją opublikować. Sprawdź bieżące informacje o wydaniach ObjectBox, a potem zweryfikuj plik, który Twoja kompilacja faktycznie wybiera.
libsqlite3.so
Starsza zależność 3.43.0 pojawiła się w dotkniętych paczkach Fluttera i AWS Amplify. Dowody ze zgłoszeń wskazują 3.46.1+1 jako wersję, która dodała obsługę 16 KiB. Sprawdź rozwiązaną wersję zależności, a nie tylko tę, którą zadeklarowałeś, bo pakiet frameworka może przypiąć starszą.
sqlcipher-android
Starszy pakiet android-database-sqlcipher został przez autorów wycofany na rzecz utrzymywanego pakietu sqlcipher-android. Żadna konkretna wersja nie została potwierdzona na tyle mocno, by opublikować ją jako naprawione minimum, więc przejdź na obecny utrzymywany pakiet i sprawdź każde ABI w skompilowanej aplikacji, zamiast ufać numerowi wersji.
pliki binarne przetwarzania multimediów
Pierwotne repozytorium FFmpegKit zostało wycofane i nie ustalono żadnego wydania zgodnego w sposób uniwersalnie bezpieczny. Jakość forków bywa różna. Ustal dokładnie, który fork wybiera Twoja kompilacja, sprawdź bezpośrednio jego pliki dla każdego ABI i rozważ utrzymanie oraz pochodzenie, zanim przyjmiesz go jako rozwiązanie.
pliki binarne Realm i JNI
Zgłoszenia są sprzeczne. Wersja 20.1.0 została oznaczona, a późniejsze zgłoszenie mówiło, że 20.2.0 naprawiła jeden plik Realm, podczas gdy inny plik JNI dalej sprawiał problem. Nie da się odpowiedzialnie wskazać jednej bezpiecznej wersji, więc podnieś wersję, a potem sprawdź osobno każdą bibliotekę, którą wnosi Realm.
libmediapipe_tasks_vision_jni.so
Zgłoszony przy wyrównaniu 2**12. W przejrzanym zgłoszeniu nie ustalono naprawionego wydania, więc traktuj zgodność jako zależną od wersji: sprawdź bieżące informacje o wydaniu, podnieś wersję i zweryfikuj plik binarny we własnej kompilacji.
plik OpenCV dla Androida
Problemy z wyrównaniem zgłoszono przy pliku OpenCV 5.0.0 dla Androida. Zgłoszenie w repozytorium odsyła do poprawki w CI, ale nie ustalono bezpiecznie żadnego konkretnego wydanego pliku. Pobierz dokładnie ten plik AAR, od którego zależysz, rozpakuj go i sprawdź biblioteki samodzielnie.
lib_burst_generated.so
Własne wytyczne Unity mówią, by zaktualizować pakiet Burst do 1.8.21 lub nowszego, gdy ten plik zostanie oznaczony. To jedyna pozycja w indeksie oparta na oficjalnej dokumentacji dostawcy, a nie na zgłoszeniach.
libUnityARCore.so, libquack.so i inne
Zgłoszenia społeczności wymieniają je wśród plików, które przeżywają podniesienie wersji edytora. Nie da się podać jednej uniwersalnej wersji, bo każdy z nich należy do innego pakietu. Użyj dokładnej nazwy pliku, żeby zdecydować, który pakiet ścigać.
Żadna pozycja nie pasuje do tego filtra. To normalne: ten indeks obejmuje zgłoszone przykłady, a nie każdą bibliotekę w ekosystemie. Użyj wyszukiwarki właściciela biblioteki i prześledź plik we własnym projekcie.
Dlaczego ten indeks jest krótki: liczba zgłoszeń pokazuje, które projekty mają głośnych użytkowników, a nie które biblioteki są najczęściej instalowane. Opublikowanie rankingu "najczęstszych winowajców" byłoby wymyślaniem statystyki. Uniwersalna jest za to metoda: weź nazwę pliku, znajdź pakiet, sprawdź bieżące wydania tego pakietu, zweryfikuj plik binarny w swojej kompilacji.
Jak to się ma do terminu API 36 z 31 sierpnia 2026 r.
To dwa niezależne wymagania Google Play, które spotykają się tylko w jednym punkcie. Podniesienie docelowego poziomu API może ujawnić ostrzeżenie o 16 KB, ponieważ wymóg dotyczy aplikacji kierowanych na Androida 15 (poziom API 35) lub nowszego. Podniesienie poziomu nie tworzy błędnego wyrównania i nie potrafi go naprawić.
Google Play wymaga, aby nowe aplikacje i aktualizacje aplikacji były kierowane na Androida 16 (poziom API 36) od 31 sierpnia 2026 r., z możliwością przedłużenia do 1 listopada 2026 r. To zmiana w pliku manifestu i w zachowaniu aplikacji. Reguła 16 KB to natomiast zmiana zgodności binarnej. Deweloper, który w poniedziałek podnosi targetSdk, a we wtorek widzi ostrzeżenie o 16 KB, niczego nie zepsuł: biblioteki natywne były już skompilowane pod strony 4 KB, a wyższy poziom docelowy po prostu wprowadził aplikację w zakres kontroli, która i tak miała się pojawić.
Wymóg A
Kierowanie na API 36- Data 31 sierpnia 2026 r., przedłużenie do 1 listopada 2026 r.
- Zakres Nowe aplikacje i aktualizacje aplikacji
- Mieszka w Twoim pliku manifestu i konfiguracji kompilacji
- Naprawiane przez Podniesienie poziomu docelowego i obsłużenie zmian zachowania Androida 16
Wymóg B
Obsługa rozmiaru stron 16 KB- Data 1 lutego 2027 r.
- Zakres Aplikacje kierowane na API 35+ na urządzeniach 64-bitowych
- Mieszka w Plikach natywnych wewnątrz Twojego bundle'a
- Naprawiane przez Ponowną kompilację lub wymianę każdej niewyrównanej biblioteki
W praktyce potraktuj je jak jedną migrację z dwoma dowodami. Poziom docelowy i tak podniesiesz, więc zaplanuj audyt bibliotek natywnych w tej samej wersji, zamiast odkrywać go w biegu przy API 36. Pełną listę poziomów dla poszczególnych typów urządzeń, wyjątki i mechanikę przedłużenia znajdziesz w naszym artykule o terminie API 36 w Google Play, a całą sekwencję od konta do wersji produkcyjnej w artykule o wymaganiach publikacji w 2026 roku.
Bramka publikacji przed przesłaniem
Jedenaście kontroli, każda z konkretnym dowodem zaliczenia. Przejdź je przed przesłaniem, a nie po tym, jak Play powie Ci, że coś jest nie tak, a zamienisz nieokreśloną sesję debugowania w skończoną listę.
Narzędzie 12
Bramka publikacji
Zaliczone 0 z 11
Nic jeszcze nie udowodnione. Zacznij od tej kompilacji, którą naprawdę zamierzasz przesłać, a nie od ostatniej, która akurat była otwarta.
Twój postęp jest zapisywany wyłącznie w tej przeglądarce. Nic nigdzie nie jest wysyłane, a wyczyszczenie danych przeglądarki wyczyści także postęp.
Zaliczenie wszystkich jedenastu bramek dowodzi zgodności technicznej z kontrolami cytowanymi na tej stronie. To nie jest obietnica zatwierdzenia. Google Play wciąż może podnieść przy tym samym przesłaniu niezwiązane kwestie zasad, treści albo jakości, a żadna lista kontrolna na świecie nie może się w tych sprawach wypowiadać.
Gdzie to zderza się z testami zamkniętymi
Nic na tej stronie nie zmienia Twojego wymogu testerów, a nic po stronie testerów nie zmienia Twojej kompilacji. Oba problemy zderzają się tylko na jednej osi: czasu. 14-dniowy test zamknięty biegnie na zegarze, którego nie możesz zatrzymać, a dochodzenie w sprawie biblioteki natywnej biegnie na zegarze, którego nikt nie umie przewidzieć.
Bolesna kolejność wygląda tak. Osobiste konto dewelopera zaczyna test zamknięty, rusza 14-dniowe okno nieprzerwanego uczestnictwa, a gdzieś w jego środku podniesienie poziomu docelowego ujawnia ostrzeżenie o 16 KB. Teraz deweloper kompiluje od nowa natywne zależności, a wokół niego grupa testerów musi pozostać w całości. Wgranie nowej kompilacji na ścieżkę testów jest w porządku, a Google wręcz zachęca deweloperów do dalszych aktualizacji w trakcie testu. To, co psuje cały przebieg, to cisza po stronie testerów.
I właśnie tę część utrzymuje w ryzach PrimeTestLab. Dostarczamy 12 prawdziwych testerów na prawdziwych urządzeniach od Androida 7 do 17, którzy dołączyli do testu i zostają w nim przez pełne 14 dni, więc Twoja ponowna kompilacja odbywa się przy stabilnym teście, a nie przy rozsypującym się. Testy ruszają w 4-6 godzin, a przeprowadziliśmy je już dla ponad 7 400 aplikacji w 120+ krajach ze skutecznością 99,9%.
Samodzielne szukanie testerów a test z obsługą
| Wymóg Google | Szukanie samodzielnie | Test z obsługą |
|---|---|---|
| Co najmniej 12 testerów w teście | Znajdź prawdziwych ludzi, wytłumacz im wszystko, przypominaj się, a potem miej nadzieję, że nikt nie odejdzie | 12 testerów dostarczonych i utrzymanych przez całe okno |
| 14 dni bez przerwy | Jeden tester, który odejdzie w połowie, przerywa ciągłość okna | Grupa jest monitorowana, żeby okno pozostało nienaruszone |
| Prawdziwe urządzenia, prawdziwi ludzie | Emulatory i nieaktywne konta to typowa droga na skróty i typowy powód, dla którego test się nie udaje | Prawdziwe urządzenia od Androida 7 do 17 |
| Czas do pierwszego dołączenia | Kilka dni, zależnie od tego, kto Ci odpowie | Testy ruszają w 4-6 godzin |
| Koszt | Twój czas, dokładnie w tym tygodniu, w którym i tak kompilujesz biblioteki od nowa | Od $19.99, plus 5% opłaty serwisowej |
| Ponowna kompilacja w trakcie testu | Każde nowe wgranie to kolejna runda proszenia ludzi o aktualizację | Wgrywaj nowe kompilacje do woli; grupa zostaje w teście |
Żeby postawić granicę wprost: nie kompilujemy za Ciebie bibliotek natywnych i ten artykuł nie jest ofertą takiej usługi. Praca przy 16 KB należy do Ciebie, a wszystko powyżej tej sekcji napisano po to, by była jak najkrótsza. Zdejmujemy z Ciebie wymóg testerów biegnący równolegle, żeby oba problemy przestały walczyć o te same dwa tygodnie.
Wskazówka o kolejności
Jeśli jeszcze nie zacząłeś testu zamkniętego, a już wiesz, że masz biblioteki natywne, najpierw uruchom okno testerów, a pracę nad wyrównaniem wykonaj w jego trakcie. Google mierzy okres kwalifikacyjny ciągłością uczestnictwa testerów, a nie jedną zamrożoną kompilacją, i zachęca deweloperów do dalszych aktualizacji w trakcie testu, więc obie osie czasu mogą się nakładać zamiast układać jedna po drugiej. Zachowaj przy tym tę samą ścieżkę testów i tę samą grupę testerów. To często oszczędza cały tydzień.
Najczęstsze pytania
Czy Google Play odrzuca teraz aplikacje niezgodne z 16 KB?
Obecna dokumentacja Google mówi, że od 1 lutego 2027 r. nie opublikujesz aktualizacji kierowanych na Androida 15 (poziom API 35) lub nowszego bez obsługi 16 KB na urządzeniach 64-bitowych. Przed tą datą większość deweloperów widzi w Play Console ostrzeżenie o zgodności, a nie twardą blokadę. Udokumentowaną konsekwencją na cytowanej stronie Google jest brak możliwości opublikowania niezgodnych aktualizacji, a nie automatyczne usunięcie aplikacji, która już jest w sklepie.
Dlaczego Google podaje 1 lutego 2027 r., a inne artykuły mówią o 1 listopada 2025 r.?
1 listopada 2025 r. to termin, który Google ogłosiło pierwotnie, a 31 maja 2026 r. to późniejsze przedłużenie, dziś już tylko historyczne. Na dzień 5 sierpnia 2026 r. obecna strona Android Developers i obecny zrzut ekranu ostrzeżenia z Play Console pokazują 1 lutego 2027 r., więc rozstrzyga nowsze źródło pierwotne. Wiele wpisów na blogach i odpowiedzi AI wciąż cytuje stare daty, bo powstały przed tą zmianą.
Nigdy nie pisałem w C++. Dlaczego dotyczy to mojej aplikacji?
Framework, pakiet SDK, wtyczka, silnik gry, baza danych, komponent multimedialny albo kreator aplikacji może dodać natywne pliki .so nawet wtedy, gdy Twój własny kod to Dart, JavaScript, Python, Java albo Kotlin. Wytyczne Google wprost obejmują aplikacje korzystające z bibliotek NDK pośrednio, przez zależność. Otwórz plik APK w Android Studio przez Build, a potem Analyze APK; każdy plik .so w katalogu lib oznacza, że spakowana aplikacja używa kodu natywnego.
Czy aplikacja w czystym Kotlinie wymaga jakichkolwiek zmian?
Według Google aplikacja korzystająca wyłącznie z Javy lub Kotlina, wraz ze wszystkimi swoimi bibliotekami i pakietami SDK, obsługuje już urządzenia 16 KB. Google i tak zaleca test w środowisku 16 KB, żeby wychwycić nieoczekiwane regresje. Zanim nazwiesz swoją aplikację czystym Kotlinem, sprawdź, czy rzeczywisty plik APK wersji wydania nie ma katalogu lib, bo wystarczy jedna zależność analityczna albo bazodanowa, żeby taki katalog się pojawił.
Która wersja Fluttera naprawia ostrzeżenie o rozmiarze stron 16 KB?
Żadne oficjalne źródło nie wskazuje jednej wersji Fluttera, która gwarantowałaby zgodność każdej aplikacji i każdej wtyczki. Informacje o wydaniu Fluttera 3.27 są węższe, niż się wydaje: obejmują obsługę 16 KB konkretnie dla szablonów plugin_ffi, a nie dla całego silnika. Flutter 3.38 to najmocniej udokumentowany kamień milowy: Flutter wprost przedstawił przejście na tę wersję jako przygotowanie do wymogu 16 KB w Play i zmienił domyślne NDK na r28. Najbezpieczniej jest przejść na bieżące stabilne wydanie Fluttera, zaktualizować każdą wtyczkę natywną, skompilować bundle wydania od nowa i sprawdzić każdy powstały plik .so.
Która wersja React Native obsługuje strony 16 KB?
React Native 0.77 to jasny oficjalny próg. Zapowiedź tego wydania stwierdza, że React Native jest gotowy w pełni obsługiwać rozmiary stron 16 KB. Natywne moduły społecznościowe, lokalny kod C++ i pakiety SDK dostawców wciąż mogą zawierać niezgodne pliki, więc podnieś wersję obsługiwaną ścieżką migracji React Native albo Expo, a potem sprawdź wygenerowany plik APK.
Której wersji Unity potrzebuję do obsługi rozmiaru stron 16 KB?
Unity wymienia 6000.1 lub nowszą, 6000.0.38f1 lub nowszą, 2022.3.56f1 lub nowszą oraz 2021.3.48f1 lub nowszą w ramach przedłużonego LTS dla uprawnionych klientów Enterprise albo Industry. Zaktualizuj także wtyczki natywne i przejdź na Burst 1.8.21 lub nowszy, jeśli Play Console wskazuje lib_burst_generated.so. Obsługiwana wersja edytora jest konieczna, ale niewystarczająca, bo wtyczki firm trzecich niosą własne pliki binarne.
Jak znaleźć dokładnie ten plik .so, który zawodzi?
Otwórz plik APK przez Build, a potem Analyze APK w Android Studio, rozwiń lib/arm64-v8a oraz lib/x86_64 i przeczytaj kolumnę Alignment, która pokazuje ostrzeżenia dla plików z problemami wyrównania. Aby potwierdzić to z wiersza poleceń, uruchom skrypt check_elf_alignment.sh od Google na pliku APK albo sprawdź pojedynczą bibliotekę poleceniem llvm-objdump -p plik.so przepuszczonym przez grep LOAD. Każde wyrównanie LOAD poniżej 2**14 wymaga działania.
Dlaczego mój plik APK przechodzi, a app bundle wciąż nie?
Wyrównanie ELF wewnątrz biblioteki i wyrównanie ZIP wewnątrz spakowanego pliku wynikowego to dwie osobne kontrole. Uruchom bundletool dump config --bundle=app.aab i poszukaj przez grep słowa alignment: PAGE_ALIGNMENT_16K przechodzi, a PAGE_ALIGNMENT_4K oznacza, że generowane pliki APK wciąż są zamawiane z wyrównaniem 4 KB. Google wprost ostrzega, że Android Gradle Plugin od 8.3 do 8.5 może wyglądać poprawnie lokalnie, podczas gdy pliki APK budowane przez Play z Twojego bundle'a nie są prawidłowo wyrównane w ZIP, więc przejdź na 8.5.1 lub nowszy.
Czy podniesienie do NDK r28 wystarczy, żeby to naprawić?
Nie. NDK r28 i nowsze kompilują domyślnie z wyrównaniem 16 KB, ale dotyczy to tylko kodu natywnego kompilowanego w trakcie Twojej kompilacji. Nie przepisze pliku .so, który przychodzi już skompilowany wewnątrz pakietu AAR, wtyczki albo silnika gry firmy trzeciej. Każda gotowa zależność natywna musi sama zostać zaktualizowana, wymieniona albo skompilowana od nowa i ponownie zaimportowana.
Jak przetestować obsługę 16 KB bez odpowiedniego telefonu?
Zainstaluj przez SDK Manager jeden z obrazów systemu Android Emulator z 16 KB od Google albo zarezerwuj obsługiwane urządzenie w Samsung Remote Test Lab. Cokolwiek wybierzesz, najpierw potwierdź środowisko poleceniem adb shell getconf PAGE_SIZE; wynik musi wynosić 16384, zanim test cokolwiek znaczy. Sukces na emulatorze dowodzi zachowania w czasie działania, a nie sposobu pakowania, więc dalej sprawdzaj też bundle wydania.
Czy naprawa obsługi 16 KB resetuje albo zaburza moje trwające testy zamknięte?
Google mierzy okres kwalifikacyjny tym, że co najmniej 12 testerów nieprzerwanie uczestniczy w teście przez 14 dni, a nie jedną zamrożoną kompilacją, i zachęca deweloperów do dalszego aktualizowania kompilacji w trakcie testu. Google nie publikuje wyraźnej gwarancji obejmującej każdy scenariusz wymiany kompilacji, więc najbezpieczniej jest utrzymać stabilną grupę testerów, kiedy w trakcie testu wgrywasz przebudowany bundle zgodny z 16 KB. PrimeTestLab dostarcza 12 prawdziwych testerów na prawdziwych urządzeniach od $19.99, plus 5% opłaty serwisowej, i utrzymuje grupę przez pełne 14 dni.
Podsumowanie
Streszczenie
Google Play wymaga, aby aplikacje kierowane na Androida 15 (poziom API 35) lub nowszego obsługiwały rozmiar stron pamięci 16 KB na urządzeniach 64-bitowych, a od 1 lutego 2027 r. niezgodnych aktualizacji nie da się już opublikować. 1 listopada 2025 r. i 31 maja 2026 r. to martwe daty, które wciąż wysoko się pozycjonują. Aplikacje w czystej Javie lub Kotlinie już spełniają wymóg. Wszyscy pozostali wykonują te same trzy kroki: wskaż wadliwy plik .so, zaktualizuj pakiet, który go dostarcza, i udowodnij poprawność pliku wynikowego dwiema niezależnymi kontrolami, czyli każdy segment LOAD w ELF na poziomie 2**14 lub wyżej, a bundle raportujący PAGE_ALIGNMENT_16K. AGP 8.5.1+ z NDK r28+ to najbezpieczniejszy domyślny zestaw narzędzi, a żaden z nich nie naprawi pliku skompilowanego przez kogoś innego. Jeśli trafi Cię to w środku testu zamkniętego, strona testerska jest tą częścią, którą możesz oddać komuś innemu. Zobacz cennik →
Źródła pierwotne
Co na tej stronie zdezaktualizuje się najpierw
- Data 1 lutego 2027 r. Google przesuwał ten harmonogram już nieraz. Zanim zaplanujesz wydanie wokół tej daty, sprawdź stempel "Last updated" na dole przewodnika o rozmiarach stron.
- Napisy w Play Console. Teksty i nawigacja w Konsoli zmieniają się niezależnie od stron z zasadami, więc nagłówki, które zobaczysz, mogą różnić się od tych odtworzonych tutaj.
- Progi wersji frameworków. Flutter wydaje wersje stabilne często, zasady wsparcia React Native ewoluują, a uprawnienia do Unity LTS się zmieniają. Sprawdzaj to w bieżących informacjach o wydaniu, a nie w numerze wersji wydrukowanym w artykule.
- Indeks zgłoszonych bibliotek. Każdy pakiet może w dowolnym wydaniu dodać, wymienić albo pogorszyć plik natywny. Zawsze sprawdzaj plik wynikowy we własnym bundle'u.
- Nazwy obrazów emulatora. Obrazy oznaczone jako eksperymentalne mogą zmienić nazwę albo awansować, więc dokładny ciąg znaków w SDK Managerze może się nie zgadzać.
Zweryfikowano z dokumentacją Google 9 sierpnia 2026 r. Przegląd co miesiąc aż do co najmniej miesiąca po wejściu wymogu w życie.