Docelowe API 36 w Google Play: przedłużenie do 1 listopada 2026 i poprawka dla Expo, Flutter, React Native

Wymóg docelowego poziomu API 36 w Google Play oznacza, że wersji zbudowanej dla czegokolwiek poniżej Androida 16 nie da się opublikować. Według stanu na październik 2026 Play odrzuca każdą nową aplikację i każdą aktualizację kierowaną na niższy poziom, często z komunikatem Target SDK of artifact is too low. Aplikacje, które otrzymały ostrzeżenie dotyczące zasad, mogły poprosić o więcej czasu, ale przedłużenie kończy się 1 listopada 2026. Ten przewodnik wyjaśnia, co jeszcze daje przedłużenie, jak przenieść Expo, Flutter i React Native na API 36 oraz co zwykle się psuje po tej zmianie.

Co właściwie blokuje wymóg docelowego poziomu API 36?

Blokuje przesyłanie. Od 31 sierpnia 2026 nie można przesłać nowej aplikacji na telefony ani aktualizacji, jeśli nie jest kierowana na API 36. Aplikacje już opublikowane, kierowane na API 35 lub wyższe, pozostają w pełni dostępne, także dla nowych użytkowników.

Zgodnie z wymaganiami Google dotyczącymi docelowego poziomu API „nowe aplikacje i aktualizacje aplikacji muszą być kierowane na Androida 16 (poziom API 36) lub wyższy, aby można je było przesłać do Google Play”. Wymagania różnią się w zależności od typu urządzenia, a jedyny pełny wyjątek dotyczy trwale prywatnych aplikacji przeznaczonych do wewnętrznej dystrybucji w jednej organizacji.

Istniejąca aplikacja poniżej tych poziomów „będzie dostępna tylko na urządzeniach z Androidem w wersji takiej samej lub niższej niż docelowy poziom API aplikacji”. Osoby, które już ją zainstalowały, korzystają z niej jak wcześniej. Ktoś z nowszym telefonem zobaczy jednak informację, że aplikacja „została utworzona dla starszej wersji Androida”.

Czy nadal można uzyskać przedłużenie przed 1 listopada 2026?

Tylko jeśli Play wysłał Twojej aplikacji ostrzeżenie dotyczące zasad, a formularz wniosku nadal jest przy nim widoczny. Nawet wtedy przedłużenie trwa najpóźniej do 1 listopada 2026, więc to kilka dodatkowych dni na niemal gotową poprawkę, a nie nowy plan.

Google informuje, że wysyła objętym wymogiem aplikacjom „link do formularza wniosku o przedłużenie w Powiadomieniach” oraz że formularz jest „dostępny na stronie szczegółów ostrzeżenia lub problemu na stronie Stan zasad”. Aplikacjom, które już spełniają wymóg, Google nie pokazuje formularza.

1. Otwórz Play Console i wybierz aplikację.
2. Poszukaj w Skrzynce odbiorczej lub Powiadomieniach wiadomości o docelowym poziomie API. Jeśli tam jest, kliknij jej link.
3. Jeśli nie, przejdź do sekcji Stan zasad, otwórz ostrzeżenie lub problem dotyczący docelowego poziomu API i poszukaj formularza wniosku o przedłużenie na stronie szczegółów.
4. Wypełnij formularz dla każdej objętej aplikacji. Każda aplikacja ma własne ostrzeżenie.
5. Niezależnie od tego, czy przedłużenie zostanie przyznane, zaplanuj przesłanie kompilacji z API 36 przed 1 listopada 2026. Po tej dacie aktualizacje wymagają API 36.

Jak podnieść Expo, Flutter i React Native do API 36?

Najczystsza droga to aktualizacja do wersji frameworka, która już kieruje na API 36: Expo SDK 54, React Native 0.81 lub Flutter 3.38. Jeśli nie możesz jeszcze zaktualizować, możesz podnieść numer ręcznie, ale wtedy musisz samodzielnie obsłużyć zmiany zachowania w Androidzie 16.

Expo. Lista zmian SDK 54 mówi, że SDK 54 i React Native 0.81 „kierują teraz na Androida 16”. Zaktualizuj poleceniem npx expo install expo@^54.0.0 --fix, uruchom npx expo-doctor@latest, a jeśli korzystasz z Continuous Native Generation, „usuń katalogi android i ios, jeśli zostały wygenerowane dla poprzedniej wersji SDK”. Na SDK 53 możesz spróbować ustawić targetSdkVersion: 36 przez wtyczkę expo-build-properties, ale React Native 0.79 nadal obsługuje cofanie przez onBackPressed, więc przed publikacją przeczytaj następną sekcję.

Flutter. Informacje o wydaniu Flutter 3.38 podają jako wartości domyślne flutter.compileSdkVersion (API 36) i flutter.targetSdkVersion (API 36) oraz „zdecydowanie zachęcają do używania w plikach kompilacji zmiennych poziomu API udostępnianych przez Flutter SDK”. Wersja 3.38 wymaga też co najmniej Javy 17. Jeśli w module aplikacji masz na sztywno targetSdk = 35, aktualizacja Fluttera tego nie zmieni, więc sprawdź plik.

Bare React Native. Ustaw compileSdkVersion i targetSdkVersion na 36 w android/build.gradle. Na wersji 0.81 i nowszych to w zasadzie wszystko. W starszych wersjach dodaj też android:enableOnBackInvokedCallback="false" do <application> w AndroidManifest.xml. Bez tego sprzętowy przycisk wstecz i gest cofania omijają nawigację w JavaScripcie.

Co się psuje, gdy aplikacja zaczyna być kierowana na Androida 16?

Najczęściej psują się nawigacja wstecz i układy na dużych ekranach. Przy API 36 jako docelowym Android przestaje wywoływać onBackPressed, nie pozwala zrezygnować z trybu edge-to-edge i ignoruje blokady orientacji oraz zmiany rozmiaru na wyświetlaczach o szerokości co najmniej 600dp.

Zmiany najważniejsze dla aplikacji wieloplatformowych, według dokumentu Google Zmiany w działaniu Androida 16:

• Predictive back: „onBackPressed nie jest wywoływane, a KeyEvent.KEYCODE_BACK nie jest już wysyłane”. Ustawienie android:enableOnBackInvokedCallback="false" to tymczasowa rezygnacja.
• Edge-to-edge: windowOptOutEdgeToEdgeEnforcement jest „wycofane i wyłączone”, więc nagłówek lub dolny przycisk może trafić pod pasek stanu albo pasek gestów.
• Duże ekrany: na wyświetlaczach o szerokości 600dp i większej ignorowane są screenOrientation, resizableActivity i ograniczenia proporcji, co może rozciągać układy przeznaczone tylko do pionu. Gry są wyłączone z tej zmiany. PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY to tymczasowa rezygnacja, która „nie będzie działać przy kierowaniu na poziom API 37”.
• Tekst: elegantTextHeight jest ignorowane, co może zmienić wysokość wiersza dla pisma arabskiego, tajskiego, tamilskiego i kilku innych.
• Czujniki zdrowotne: BODY_SENSORS zostaje zastąpione szczegółowymi uprawnieniami zdrowotnymi, takimi jak READ_HEART_RATE.

Na co trafili inni deweloperzy przy przejściu na API 36?

Dotychczasowe publiczne zgłoszenia pokazują dwa rodzaje problemów: zachowanie przycisku wstecz, które zmienia się bez żadnego błędu, oraz biblioteki, przez które docelowy poziom w pakiecie odbieranym przez Play różni się od tego, co mówią pliki projektu.

Audius (React Native 0.79). W pull requeście #14635 zespół Audius pisze, że Google Play odrzucił oba przesłania wersji Androida 1.5.186 z komunikatem Target SDK of artifact is too low. Podnieśli compileSdk i targetSdk z 35 do 36, ustawili build tools na 36.0.0 i dodali android.suppressUnsupportedCompileSdk=36, ponieważ „RN 0.79 przypina AGP 8.8”. Ustawili też enableOnBackInvokedCallback="false", bo bez tego cofanie „omijałoby React Navigation”. Późniejszy PR usunął tę rezygnację po przejściu na React Native 0.81, który sam rejestruje OnBackPressedCallback.

Aplikacja na Flutter 3.35.2. W zgłoszeniu Fluttera #174516 deweloper ustawił targetSdk 36 w Gradle i manifeście, ale Play Console nadal zgłaszał „Your bundle targets SDK 34, but uses a Play Core library that cannot be used with that version”. Usunięcie starej biblioteki com.google.android.play:core:1.10.3 doprowadziło do błędów R8 „Missing classes”. Ich naprawa doprowadziła z kolei do komunikatu „You can't rollout this release because it doesn't allow any existing users to upgrade to the newly added app bundles”. Pakiet został ostatecznie zaakceptowany po dodaniu reguł keep w ProGuard, jawnym ustawieniu minSdk i wyłączeniu podziałów według języka, gęstości i ABI, kosztem większego rozmiaru pobierania.

Wspólna lekcja: zmiana numeru w Gradle nie kończy pracy. Audius musiał naprawić zachowanie w czasie działania, a deweloper Fluttera – zależność, która zmieniała to, co Play odczytywał z pakietu. Sprawdź zbudowany artefakt i przetestuj aplikację na urządzeniu z Androidem 16, a nie tylko plik konfiguracyjny.

Jak sprawdzić kompilację z API 36 przed przesłaniem?

Odczytaj docelowy poziom z samego pakietu wydania, a następnie umieść pakiet na ścieżce testów wewnętrznych lub zamkniętych i sprawdź na Androidzie 16 nawigację wstecz, wcięcia systemowe i układ na tablecie. Odrzucenie albo błąd w produkcji kosztuje znacznie więcej czasu niż te testy.

Przykład: aplikacja na Expo SDK 53, kierowana na API 35, która potrzebuje jeszcze jednej aktualizacji.

1. Uruchom npx expo install expo@^54.0.0 --fix, potem npx expo-doctor@latest, i napraw wszystko, co zgłosi.
2. Jeśli projekt korzysta z Continuous Native Generation, usuń stare foldery android i ios i zbuduj ponownie. W przeciwnym razie wprowadź natywne zmiany aktualizacji ręcznie.
3. Zbuduj wydanie AAB, na przykład poleceniem eas build -p android --profile production.
4. Potwierdź poziom docelowy poleceniem bundletool dump manifest --bundle app.aab --xpath /manifest/uses-sdk/@android:targetSdkVersion. Powinno wyświetlić 36.
5. Prześlij na ścieżkę testów wewnętrznych. Na telefonie z Androidem 16 naciśnij wstecz na każdym zagnieżdżonym ekranie, sprawdź, czy nagłówki i dolne przyciski nie chowają się pod paskami systemowymi, i obróć tablet lub emulator ze zmiennym rozmiarem.
6. Promuj wydanie do produkcji z informacjami o wersji, które wspominają poprawki dla Androida 16.

Aby przyspieszyć testy, skorzystaj z konfiguracji testerów z naszego przewodnika po testach zamkniętych w Google Play, a sformułowania do opisu aktualizacji zaczerpnij z naszych przykładów informacji o wersji. Jeśli wolisz zlecić wydanie, nasza usługa publikacji w App Store obejmuje Play Console i App Store Connect za $599 za oba sklepy. Opłaty za konta deweloperskie są osobne.