Twoja aplikacja zniknęła z Google Play dla nowych użytkowników? Nie zostałeś zbanowany — minął termin API 36

Nie, nie zostałeś zbanowany

Jeśli w ostatnich dniach zobaczyłeś w Google Play Console czerwone ostrzeżenie, spadek instalacji albo klient zadzwonił z pretensją, że „aplikacji nie ma w sklepie" — spokojnie. Nie dostałeś bana, nie złamałeś regulaminu i nikt Cię nie zgłosił.

31 sierpnia 2026 upłynął coroczny termin Google Play dotyczący target API level. Dotyczy on wszystkich aplikacji na Androida i co roku odcina od sklepu te, które nie nadążyły za wymaganą wersją systemu. W tym roku próg jest szczególnie dotkliwy, bo obejmuje dwie różne rzeczy naraz.

Poniżej: co dokładnie się stało, jak w pięć minut sprawdzić, czy to dotyczy Twojej aplikacji, ile realnie masz czasu i co trzeba zrobić.

Co dokładnie zmieniło się 31 sierpnia 2026

Wymogi są dwa i łatwo je pomylić — a to od nich zależy, w jakiej jesteś sytuacji.

1. Nowe aplikacje i wszystkie aktualizacje muszą celować w Android 16 (API 36) lub wyżej. Od tego dnia nie wgrasz do Play Console nowej wersji aplikacji, która celuje niżej. Nawet jeśli poprawka dotyczy jednej literówki.

2. Istniejące aplikacje muszą celować w Android 15 (API 35) lub wyżej, żeby pozostać dostępne dla nowych użytkowników na urządzeniach z nowszym Androidem niż target aplikacji.

Innymi słowy: jeden próg blokuje wydania, drugi blokuje dystrybucję. Można spełniać pierwszy i nie spełniać drugiego, i odwrotnie.

Dla wybranych kategorii urządzeń progi są łagodniejsze:

Z wymogu zwolnione są wyłącznie aplikacje trwale prywatne — dystrybuowane tylko wewnątrz jednej organizacji.

„Zniknęła ze sklepu" — co to znaczy naprawdę

Tu jest najczęstsze nieporozumienie, przez które ludzie panikują bardziej, niż powinni — albo mniej, niż powinni. Aplikacja nie została usunięta z Google Play. Nie znikają też recenzje, oceny ani historia instalacji.

Co się faktycznie dzieje z aplikacją poniżej progu dostępności:

• Pozostaje widoczna i instalowalna tylko na urządzeniach z wersją Androida równą lub niższą niż target API aplikacji.
• Nowi użytkownicy z nowszymi telefonami jej nie zobaczą w wyszukiwarce Play ani nie zainstalują z linku. Dla nich aplikacja praktycznie nie istnieje — a to najczęściej ci użytkownicy, którzy kupili telefon w ostatnich dwóch latach.
• Dotychczasowi użytkownicy nie tracą aplikacji. Zainstalowana wersja działa dalej, nikt jej nikomu nie kasuje.

Praktyczny skutek jest więc taki: aplikacja nadal działa, ale przestała się rozwijać jako kanał pozyskania. Nie zobaczysz komunikatu o awarii — zobaczysz spadek nowych instalacji, którego nikt nie umie wyjaśnić. Jeśli macie kampanie kierujące na Play, część budżetu idzie od kilku dni w próżnię.

Zdiagnozuj się w pięć minut

Wszystko sprowadza się do jednej liczby: jaki jest targetSdk w wersji, którą ostatnio opublikowaliście.

Metoda 1 — Play Console (nie wymaga programisty)

Zaloguj się do Google Play Console i sprawdź dwa miejsca:

1. Powiadomienia i sekcja zgodności z polityką — jeśli aplikacja nie spełnia wymogu, Google wyświetla tam ostrzeżenie z konkretnym terminem i wskazaniem, którego progu dotyczy. To najszybsza odpowiedź.
2. App bundle explorer → wybrany release → szczegóły pakietu. Znajdziesz tam poziom target API dla każdej wgranej wersji.

Metoda 2 — kod źródłowy

Jeśli macie dostęp do repozytorium, otwórzcie app/build.gradle.kts (albo app/build.gradle) i poszukajcie:

android {
    compileSdk = 36
    defaultConfig {
        minSdk = 24
        targetSdk = 36   // ← ta liczba
    }
}

W projektach Flutter plik jest w android/app/build.gradle.kts, w React Native — w android/app/build.gradle lub w android/build.gradle jako targetSdkVersion.

Metoda 3 — z gotowego pliku APK/AAB

Jeśli macie tylko zbudowany plik, a nie kod:

# z Android SDK build-tools
aapt2 dump badging aplikacja.apk | grep targetSdkVersion

# albo
apkanalyzer manifest target-sdk aplikacja.apk

Interpretacja wyniku

Ile masz czasu: przedłużenie do 1 listopada 2026

Google przewidział wentyl bezpieczeństwa. Jeśli potrzebujesz więcej czasu, możesz złożyć wniosek o jednorazowe przedłużenie terminu do 1 listopada 2026.

Co warto wiedzieć:

• Wniosek składa się w Google Play Console — formularz jest dostępny w kontekście aplikacji, której dotyczy ostrzeżenie o target API level.
• To przedłużenie jednorazowe. Nie ma kolejnego terminu po 1 listopada — po tej dacie sytuacja wraca do stanu sprzed wniosku.
• Wniosek nie zwalnia z pracy, tylko kupuje około dwóch miesięcy. Przy zaniedbanym projekcie to realistyczne minimum, przy utrzymywanym — zapas.
• Złóż go nawet jeśli myślisz, że zdążysz. Nic nie kosztuje, a zdejmuje presję z zespołu.

Jeśli nie masz dostępu do Play Console albo nie wiesz, kto go ma — to osobny, poważniejszy problem. Wrócimy do niego na końcu.

Co realnie trzeba zrobić, żeby podnieść target do API 36

Zła wiadomość: to nie jest zmiana jednej liczby w konfiguracji. Podniesienie targetSdk włącza nowe zachowania systemu, które wcześniej Twoja aplikacja mogła ignorować. Trzy zmiany w Androidzie 16 sprawiają najwięcej kłopotu:

1. Wymuszone edge-to-edge. Dla aplikacji celujących w API 36 możliwość rezygnacji z rysowania pod paskiem statusu i nawigacji została wyłączona — atrybut windowOptOutEdgeToEdgeEnforcement przestaje działać. Aplikacja musi poprawnie obsługiwać insets, czyli wiedzieć, gdzie kończy się bezpieczny obszar ekranu. Objaw przy zaniedbaniu: przyciski wchodzące pod pasek nawigacji, nagłówki pod zegarkiem, nieklikalne elementy przy krawędziach.

2. Koniec wymuszania orientacji i proporcji na dużych ekranach. Na wyświetlaczach o najmniejszej szerokości od 600dp (tablety, składane) system ignoruje deklaracje screenOrientation, resizableActivity i ograniczenia proporcji. Aplikacja wypełnia całe okno niezależnie od tego, czy była na to przygotowana. Aplikacja zaprojektowana wyłącznie pod pionowy telefon będzie na tablecie wyglądać źle — a nie da się już tego zablokować deklaracją w manifeście (tymczasowe wyjście awaryjne istnieje, ale jest przejściowe).

3. Ostrzejsze limity JobSchedulera. Limity są egzekwowane bardziej rygorystycznie, a setImportantWhileForeground przestaje cokolwiek robić. Jeśli aplikacja synchronizuje dane w tle, część zadań może przestać się wykonywać tak, jak dotąd.

Do tego dochodzi część, która zwykle zajmuje najwięcej czasu w zaniedbanych projektach: aktualizacja Gradle, wtyczki Androida, bibliotek i całego frameworka. W projektach Flutter i React Native podniesienie target API zwykle wymusza podniesienie wersji frameworka, a to pociąga migrację zależności. Jeśli projekt nie był aktualizowany dwa lata, to właśnie tu leży 80% pracy — nie w samym API 36.

Ile to trwa

Uczciwa odpowiedź: zależy prawie wyłącznie od tego, jak dawno aplikacja była aktualizowana.

Jeśli jesteś w dwóch dolnych wierszach — złóż wniosek o przedłużenie dzisiaj. Dwa miesiące to różnica między spokojną migracją a wersją wypuszczoną w pośpiechu, bez testów, na produkcję.

Więcej o tym, jak rozpoznać ostatni wiersz tej tabeli u siebie, piszemy w tekście 5 znaków, że aplikacja mobilna umiera po cichu.

Scenariusz najgorszy: nie ma kto tego zrobić

W wielu firmach ten alert trafia w próżnię organizacyjną. Aplikację robiła agencja, z którą kontakt się urwał. Programista, który się nią zajmował, odszedł rok temu. Nikt nie wie, gdzie jest repozytorium.

Kolejność ratunkowa w takiej sytuacji jest inna niż techniczna — najpierw odzyskaj kontrolę, potem kod:

1. Sprawdź, kto jest właścicielem konta Google Play Console (Users and permissions) i czy adres kontaktowy odbiera ktoś, kto nadal u Was pracuje. Bez dostępu do konsoli nie złożysz nawet wniosku o przedłużenie.
2. Ustal, gdzie jest klucz podpisujący. Jeśli aplikacja korzysta z Play App Signing, jesteś bezpieczny. Jeśli z lokalnego keystore'a, którego nikt nie widział — to problem większy niż target API, bo bez niego nie wypuścisz aktualizacji w ogóle.
3. Zlokalizuj repozytorium i sprawdź, czy projekt się buduje na czystej maszynie. To bywa osobne kilkudniowe zadanie.
4. Dopiero teraz planuj migrację do API 36.

Punkty 1–3 możesz odhaczyć samodzielnie w jeden dzień. Pełną listę kontrolną stanu aplikacji zebraliśmy w tekście Czy Twoja aplikacja przetrwa 2027? Checklista 15 punktów.

Jak nie wrócić tu za rok

Termin target API level to wydarzenie cykliczne, nie jednorazowy kryzys. Google podnosi próg co roku, z terminem przypadającym pod koniec sierpnia, a wymagany poziom odpowiada wersji Androida sprzed roku. Wiadomo więc z wielomiesięcznym wyprzedzeniem, co będzie wymagane.

Trzy rzeczy, które zamykają temat na dobre:

1. Wpis w kalendarzu na maj–czerwiec każdego roku. Wtedy nowa wersja Androida jest już w wersji zapoznawczej, a Wy macie trzy miesiące spokojnej pracy zamiast dwóch tygodni paniki.
2. Wydanie co kwartał, nawet bez nowych funkcji. Same aktualizacje zależności. To najtańsza polisa, jaka istnieje — a jednocześnie gwarancja, że build działa i ktoś umie go uruchomić.
3. Imiennie przypisana odpowiedzialność za skrzynkę Play Console i App Store Connect. Alert, którego nikt nie czyta, nie jest alertem.

Ten sam kalendarz warto prowadzić dla iOS — Apple co roku, zwykle na wiosnę, wymaga budowania aplikacji najnowszym publicznym SDK.

Krótkie FAQ

Czy moja aplikacja została usunięta z Play? Nie. Pozostaje dostępna na urządzeniach z Androidem w wersji nie wyższej niż jej target API. Nowi użytkownicy nowszych telefonów jej nie zobaczą.

Czy stracę oceny i recenzje? Nie. Pozycja w sklepie, oceny, recenzje i historia instalacji zostają nienaruszone. Po podniesieniu target API aplikacja wraca do pełnej dystrybucji.

Czy dotychczasowi użytkownicy stracą aplikację? Nie. Zainstalowana aplikacja działa dalej.

Mam target 35 — czy muszę cokolwiek robić? Aplikacja jest dostępna dla nowych użytkowników, ale nie wypuścisz żadnej aktualizacji, dopóki nie podniesiesz targetu do 36. Przy krytycznym błędzie będziesz bezradny, więc traktuj to jako pilne, nie jako opcjonalne.

Czy wniosek o przedłużenie czymś grozi? Nie. To przewidziany przez Google mechanizm, a nie przyznanie się do winy. Jednorazowo przesuwa termin na 1 listopada 2026.

Czy to dotyczy też aplikacji firmowych, wewnętrznych? Aplikacje trwale prywatne, dystrybuowane wyłącznie wewnątrz organizacji, są z wymogu zwolnione. Jeśli aplikacja jest publicznie dostępna w Play — dotyczy.

Podsumowanie

31 sierpnia 2026 nie był wyjątkiem — był kolejną odsłoną corocznego terminu, który dla części aplikacji kończy się cichym zniknięciem z zasięgu nowych użytkowników. Dobra wiadomość: nic nie jest stracone, nic nie zostało skasowane, a Google daje możliwość przedłużenia do 1 listopada 2026.

Trzy rzeczy do zrobienia dziś:

1. Sprawdź swój targetSdk — pięć minut w Play Console.
2. Jeśli jest poniżej 36, złóż wniosek o przedłużenie — nawet jeśli sądzisz, że zdążysz.
3. Oszacuj nakład uczciwie — jeśli aplikacja nie miała wydania od dwóch lat, praca to nie jest jedna liczba w konfiguracji.

W Mobilesoft robimy takie migracje regularnie, także w projektach, których nie pisaliśmy — łącznie z odzyskiwaniem dostępów, uruchamianiem środowiska i podnoszeniem zaległych zależności. Zobacz, jak podchodzimy do budowy i utrzymania aplikacji mobilnych, a jeśli najpierw potrzebujesz oceny stanu i wyceny nakładu — zajmujemy się tym w ramach audytów i konsultacji. Możesz też sprawdzić nasze realizacje albo od razu wycenić projekt.

Jeśli masz na ekranie czerwony alert i nie wiesz, jak duży to problem — napisz do nas. Sprawdzenie stanu aplikacji i oszacowanie nakładu zajmuje nam zwykle jeden dzień, a Ty przynajmniej będziesz wiedzieć, z czym masz do czynienia przed 1 listopada.