Termin docelowego poziomu API 36 w Google Play: co zmienia się 31 sierpnia 2026 r.

Google podnosi próg docelowego poziomu API w Play Store raz w roku, a 2026 to cykl API 36. Liczba nie jest tu częścią kłopotliwą. Kłopotliwe jest to, że "wymóg docelowego poziomu API" to w rzeczywistości dwie reguły noszące jedną nazwę: jedna rządzi tym, co wolno Ci przesłać, a druga, niższa, rządzi tym, kto wciąż może zainstalować to, co już jest opublikowane. Niemal każda strona, która wyświetla się na to pytanie, zaciera różnicę między nimi, i tak właśnie deweloperzy przebudowują aplikację, która przebudowy nie potrzebowała, albo machają ręką na ostrzeżenie w Play Console, które akurat miało znaczenie.

Ten wpis je rozdziela, podaje liczby dla każdego typu urządzenia, a potem odpowiada na pytanie, które nasza skrzynka wsparcia naprawdę dostaje w sierpniu: co to robi z aplikacją będącą w połowie testu zamkniętego (closed testing) z 12 testerami przez 14 dni z rzędu? PrimeTestLab prowadzi tę stronę testową dla deweloperów, więc widzimy tę kolizję terminów bez przerwy, a wskazówki z tamtej sekcji obowiązują niezależnie od tego, czy korzystasz z usługi, czy sam szukasz testerów. Każdą datę i każdy poziom poniżej sprawdzono na stronach samego Google 9 sierpnia 2026 r., a wszystko, czego Google faktycznie nie udokumentował, jest oznaczone, a nie uzupełnione pewnym siebie domysłem.

Reguła w jednym zdaniu

Od 31 sierpnia 2026 r. zwykła aplikacja na telefon, tablet, urządzenie składane lub Android Auto musi celować w Androida 16, poziom API 36 lub wyższy, żeby dało się ją przesłać do Google Play, niezależnie od tego, czy to zupełnie nowa aplikacja, czy aktualizacja już opublikowanej. To jedno zdanie wystarcza większości czytelników. Wyjątki i osobny, niższy próg dla aplikacji, których nie ruszasz, to temat całej reszty tego wpisu.

Jedna nazwa, dwie różne reguły

Google używa określenia "wymóg docelowego poziomu API" na dwie rzeczy, które zachowują się zupełnie inaczej. Trzymanie ich osobno to najbardziej wartościowa rzecz, jaką możesz zrobić z tą stroną.

Aplikacja siedząca spokojnie na API 35 bez planowanych aktualizacji spełnia więc 31 sierpnia regułę 2, a przestaje spełniać wymóg w chwili, gdy spróbujesz cokolwiek wydać zgodnie z regułą 1. To nie sprzeczność, tylko projekt: Google podnosi poprzeczkę dla tego, co wchodzi do sklepu, szybciej niż dla tego, co w nim zostaje.

Trzy pojęcia, które Google definiuje precyzyjnie

Zasady opierają się na trzech terminach, a każdy ma konkretne znaczenie decydujące o tym, pod którą regułę podpadasz:

• Nowa aplikacja: aplikacja "jeszcze nieopublikowana w Google Play". Pierwsze przesłanie danej nazwy pakietu.
• Istniejąca aplikacja: aplikacja już opublikowana w Google Play.
• Aktualizacja: nowa wersja istniejącej aplikacji zgłoszona do weryfikacji, żeby zastąpić bieżącą. Aktualizację ocenia się według reguły przesyłania, nie według reguły dostępności.

Wymagania według typu urządzenia

"Aplikacja na Androida" to nie jeden wiersz. Telefony, tablety, urządzenia składane i Android Auto idą na API 36. Wear OS i Android Automotive OS zatrzymują się na API 35. Android TV i Android XR na API 34. Progi dla aplikacji, której nie aktualizujesz, są jeszcze niższe, a przełącznik poniżej przeskakuje między obydwoma zestawami.

Android Auto to nie Android Automotive OS

Te dwie nazwy kosztują deweloperów realny czas każdego roku. Android Auto wyświetla aplikację z telefonu na ekranie samochodu, więc ta aplikacja jest aplikacją na telefon i podlega regule telefonów: API 36. Android Automotive OS to system operacyjny działający w samym pojeździe i jest jednym z wymienionych wyjątków z niższym poziomem docelowym: API 35. Jeśli budujesz aplikację multimedialną lub nawigacyjną wydawaną na oba, potrzebujesz wyższego z tych dwóch poziomów.

Czy to dotyczy Ciebie? Odpowiedz na trzy pytania

To, czy 31 sierpnia jest Twoim problemem, zależy od trzech rzeczy: co zamierzasz zrobić, na jaki typ urządzenia wydajesz i w co naprawdę celuje Twój obecny build. Narzędzie poniżej nakłada opublikowane progi Google na tę kombinację i mówi, pod którą z dwóch reguł podpadasz.

Jeśli werdykt mówi, że jesteś w porządku, i tak przyda Ci się lista kontrolna przed terminem na końcu, bo "mój kod źródłowy ustawia target 36" i "artefakt, który ocenił Google, deklaruje 36" to nie to samo twierdzenie. Najczęstsze fałszywe poczucie bezpieczeństwa w całym tym cyklu to deweloper czytający swój plik Gradle zamiast przesłanego bundle.

Co naprawdę się dzieje, gdy przegapisz 31 sierpnia

Dwie różne rzeczy, zależnie od tego, pod którą regułę podpadasz. Jeśli spróbujesz przesłać build poniżej progu, przesyłka nie spełnia wymogu. Jeśli po prostu zostawisz opublikowaną aplikację poniżej progu dostępności, przestaje ona być wyszukiwalna i instalowalna dla nowych użytkowników na urządzeniach z wersją Androida wyższą niż jej poziom docelowy. Żaden z tych skutków nie jest usunięciem.

Jeśli spróbujesz przesłać

Zwróć uwagę, do czego ta konsekwencja jest przypięta: do czynności przesyłania. Sam kalendarz nie robi nic buildowi, który już działa. Dlatego aplikacja może 1 września w pełni spełniać wymóg, a 2 września być zablokowana, wyłącznie dlatego, że postanowiłeś wydać poprawkę błędu.

Jeśli zostawisz opublikowaną aplikację poniżej progu

To ten scenariusz, który konkurenci opisują jako "Twoja aplikacja znika", i jest to błędne w sposób, który ma znaczenie. Sformułowanie Google brzmi, że aplikacja "stop being discoverable" dla konkretnej grupy użytkowników. Konkretnie:

• Nowi użytkownicy na nowszych urządzeniach tracą dostęp. Jeśli urządzenie użytkownika ma wersję Androida wyższą niż poziom docelowy Twojej aplikacji, Google Play przestaje mu ją pokazywać i instalować.
• Nowi użytkownicy na starszych urządzeniach nic nie tracą. Urządzenie z tym samym lub niższym poziomem API niż poziom docelowy aplikacji nadal może ją otrzymać.
• Ci, którzy zainstalowali wcześniej, nic nie tracą. Każdy, kto już zainstalował aplikację, wciąż ją znajdzie, zainstaluje ponownie i użyje na wspieranych wersjach Androida.
• Linki bezpośrednie mówią prawdę. Użytkownik na niekwalifikującym się nowszym urządzeniu, który otworzy Twój link do Play Store, dostaje informację, że aplikacja została zrobiona "made for an older version of Android".

Co nie następuje

Każdego sierpnia te zasady wywołują te same cztery obawy na forach wsparcia Google. Żadna z nich nie jest tym, co opisuje strona o docelowym poziomie API.

Czy celowanie w API 36 zabije obsługę starszych telefonów?

Nie, nie samo z siebie. targetSdk deklaruje poziom działania Androida, pod który aplikacja jest zbudowana i przetestowana. minSdk decyduje, na jakiej najstarszej wersji Androida da się ją zainstalować. To osobne liczby, a podniesienie poziomu docelowego do 36 samo w sobie nie podnosi minimum: Twoja aplikacja może dalej obsługiwać starsze wersje Androida aż do tego minimum, o ile Twój kod i ewentualnie podniesione zależności pozostaną zgodne.

To nieporozumienie wywołuje najwięcej alarmu w każdym cyklu. Deweloper czyta "musi celować w Androida 16", zakłada, że to znaczy "działa tylko na Androidzie 16", i wnioskuje, że Google właśnie skasował mu większość osiągalnych urządzeń. Przesuń minimum poniżej i zobacz, co naprawdę się zmienia.

Trzy liczby i ta, którą pilnuje Google Play

Co to znaczy, jeśli Twoja aplikacja jest właśnie w teście zamkniętym

Jeśli jesteś nowym osobistym kontem dewelopera prowadzącym obowiązkowy test zamknięty z 12 testerami przez 14 dni z rzędu, termin wypada w środku Twojego okna. Bezpieczny ruch to wprowadzić build z API 36 na tę samą ścieżkę zamkniętą przed 31 sierpnia, utrzymać wszystkich testerów zapisanych i nigdy nie pozwolić, by termin zmusił Cię do zmiany ścieżki albo restartu testerów.

Strona Google o docelowym poziomie API i strona Google o testach zamkniętych są pisane przez różne zespoły w różnych celach i żadna nie odnosi się do drugiej. Zostawia to prawdziwą lukę, a uczciwie jest pokazać Ci dokładnie, gdzie kończy się udokumentowany grunt.

Co jest zweryfikowane

• Kwalifikujące się nowe konto osobiste "musi przeprowadzić test zamknięty" z co najmniej 12 testerami nieprzerwanie uczestniczącymi przez ostatnie 14 dni, zanim będzie mogło poprosić o dostęp do wersji produkcyjnej. Dotyczy to kont osobistych utworzonych po 13 listopada 2023 r. Zweryfikowane
• Dokumentacja Google dla deweloperów mówi, że przesłany plik APK musi spełniać wymagania docelowego API w Play, i nie publikuje żadnego wyjątku dla ścieżek testowych. To sformułowanie jest neutralne wobec ścieżki, a nie właściwe testom, więc nowe przesłanie na ścieżkę zamkniętą po terminie planuj tak, jakby wymagało API 36: to mocny wniosek, a nie udokumentowana reguła dla ścieżek testowych. Częściowe
• Własne wskazówki Google zachęcają deweloperów, by w trakcie testu zamkniętego dalej aktualizowali aplikację przy naprawianiu problemów, i definiują okres kwalifikujący wokół ciągłości zapisania testerów, a nie wokół jednego zamrożonego artefaktu. Zweryfikowane
• Test wewnętrzny jest ograniczony do 100 testerów i nie zastępuje kwalifikującego testu zamkniętego. Zweryfikowane

Czego Google nie udokumentował

Ponieważ odpowiedź jest nieznana, właściwa strategia nie polega na jej przewidywaniu. Polega na uczynieniu pytania nieistotnym: mieć zgodny build na ścieżce jeszcze przed tą datą. To bezpieczne przy obu wynikach i nic Cię nie kosztuje, jeśli stary artefakt i tak działałby dalej.

Kolejność bezpieczna w obie strony

1. Zachowaj tę samą ścieżkę zamkniętą i tę samą grupę testerów

   Nie twórz świeżej ścieżki na build z API 36 i nie usuwaj zapisanych testerów. Ciągłość 14 dni, którą liczy Google, dotyczy tego, że testerzy pozostają zapisani, więc to właśnie zapis jest zasobem, który chronisz.

2. Zbuduj i przetestuj API 36 przed terminem, nie w jego dniu

   Potraktuj migrację jako osobne zadanie z własną turą testów. Odkrycie 30 sierpnia, że rozjeżdża się układ edge-to-edge, to zupełnie inny dzień niż odkrycie tego 10 sierpnia.

3. Prześlij go na istniejącą ścieżkę zamkniętą z wyższym kodem wersji

   Każdy zastępujący bundle potrzebuje podniesionego kodu wersji. Google definiuje okres kwalifikujący wokół ciągłości zapisania testerów i wyraźnie zachęca do naprawiania problemów w trakcie testów, ale nie publikuje bezwzględnej gwarancji obejmującej każdy scenariusz podmiany builda. Zachowaj tę samą ścieżkę i tych samych zapisanych testerów, a potem sprawdź licznik w Play Console. Pełna mechanika aktualizacji w trakcie testu jest warta lektury, jeśli to Twój pierwszy cykl.

4. Potwierdź, że wydanie faktycznie dotarło do testerów

   Opublikowane wydanie to nie to samo co dostarczone. Sprawdź, czy wersja zamknięta jest aktywna, czy kod wersji jest wyższy i czy testerzy z listy zapisanych widzą aktualizację.

5. Sprawdź ponownie status zasad po przetworzeniu

   Daj bundle czas na przetworzenie, a potem otwórz ponownie stronę statusu zasad aplikacji. Jeśli ostrzeżenie o docelowym poziomie API nie znika, przejdź listę diagnostyczną, zamiast losowo usuwać wydania.

6. Poproś o przedłużenie tylko wtedy, gdy migracja naprawdę nie zdąży

   Kupuje czas do 1 listopada 2026 r. i jest przyznawane dla każdej dotkniętej aplikacji osobno. To nie powód, żeby wstrzymać pracę techniczną.

Jak poprosić o przedłużenie do 1 listopada 2026 r.

Dotknięci deweloperzy mogą poprosić o przedłużenie, które utrzymuje dystrybucję do 1 listopada 2026 r. Prosi się o nie osobno dla każdej aplikacji, z poziomu ostrzeżenia o zasadach tej aplikacji w Play Console. Google nie opisuje go jako automatycznego, gwarantowanego ani jako trwałego zwolnienia, więc migruj dalej, dopóki wniosek jest otwarty.

Google Play Console · prawdziwy zrzut ekranu Kliknij, aby powiększyć

1. Otwórz dotkniętą aplikację w Play Console

   Dostęp do przedłużenia jest przypisany do aplikacji, nie do całego konta. Jeśli publikujesz kilka aplikacji, licz się z powtarzaniem tego dla każdej dotkniętej.

   Zweryfikowane
2. Wejdź w Status zasad

   Tylko aplikacje, które Google uznaje za niespełniające wymogu, powinny nieść pozycję o docelowym API. Jeśli aplikacja już spełnia wymóg, nie ma tu czego przedłużać ani żadnego formularza do znalezienia.

   Zweryfikowane
3. Otwórz ostrzeżenie albo szczegóły problemu o docelowym API

   Tytuł widoczny na zrzucie powyżej to App must target Android 16 (API level 36) or higher. Brzmienie wciąż może się różnić w zależności od aplikacji i stanu wdrożenia, więc traktuj je jako to, co zobaczyło jedno prawdziwe konto, a nie jako gwarantowany uniwersalny ciąg.

   Zweryfikowane
4. Skorzystaj z linku do przedłużenia w tej pozycji albo w Powiadomieniach

   Google prowadzi część dotkniętych deweloperów przez powiadomienie aplikacji, a nie przez panel z pozycją. Sprawdź oba, zanim uznasz, że ta opcja u Ciebie nie istnieje.

   Zweryfikowane
5. Prześlij żądane informacje

   Google nie publikuje dokładnych pytań na swojej publicznej stronie pomocy, więc każdą listę "o co pytają" traktuj jako niezweryfikowaną. Odpowiadaj na podstawie swojego prawdziwego planu migracji.

   Częściowe
6. Traktuj 1 listopada 2026 r. jako twardy koniec

   Przedłużenie przesuwa datę, nie znosi wymogu. Cokolwiek nie zdążyłeś skończyć do 31 sierpnia, musi być skończone do 1 listopada.

   Zweryfikowane
7. Migruj dalej, dopóki wniosek jest otwarty

   Nic w sformułowaniach Google nie obiecuje zgody. Planowanie wokół przyznanego przedłużenia, którego jeszcze nie masz, to najdroższe założenie dostępne w tym cyklu.

   Częściowe

Jeszcze jedno rozróżnienie warto zapamiętać: Google przypina przypis o przedłużeniu do wymogu API 36, a jego tekst najczęściej opisuje przedłużenie jako coś, co podtrzymuje dystrybucję istniejącej aplikacji. Nie omawia z równą precyzją każdej kombinacji nowej aplikacji, aktualizacji i aplikacji istniejącej. Zanim założysz, że przedłużenie obejmuje konkretne planowane przesłanie, przeczytaj, co według ostrzeżenia Twojej własnej aplikacji ono obejmuje.

Jak przenieść aplikację na API 36

Cztery kroki: zainstaluj SDK API 36, podnieś compileSdk i targetSdk do 36, zaktualizuj zależności, które przez to pękną, i przetestuj zmiany działania Androida 16. Zmiana liczby to edycja jednej linijki. Udowodnienie, że aplikacja nadal działa, to właściwa migracja.

Krok 1: zainstaluj SDK Androida 16

Otwórz Android Studio, wejdź w SDK Manager i zainstaluj Android SDK Platform dla poziomu API 36 razem z bieżącymi narzędziami build tools 36.x.x. Bez zainstalowanej platformy podniesienie compileSdk daje tylko błąd builda, który wygląda na niezwiązany z niczym, co zrobiłeś.

Krok 2: podnieś poziomy w swoim buildzie

Wybierz swój stack. Ścieżka pliku i konkretne linie się różnią, cel nie: manifest wewnątrz przesyłanego bundle musi deklarować target 36.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Krok 3: zaktualizuj zależności i narzędzia frameworka

Podniesienie poziomu kompilacji to moment, w którym stare zależności padają. Licz się z ruszeniem Android Gradle Plugin, samego Gradle, Kotlina, bibliotek AndroidX, Google Play services oraz każdego SDK reklamowego lub analitycznego z kodem natywnym. Ten wpis celowo nie publikuje "właściwych wersji", bo zgodne wersje zmieniają się co tydzień, a sztywna lista byłaby myląca po dwóch tygodniach. Weź je z aktualnych informacji o wydaniu swojego frameworka w dniu migracji.

Krok 4: zbuduj, prześlij i sprawdź artefakt

• Wygeneruj podpisany Android App Bundle i podnieś kod wersji.
• Testuj artefakt release, a nie tylko build debug. Minifikacja i usuwanie zasobów psują rzeczy, które build debug ukrywa.
• Prześlij na docelową ścieżkę i potwierdź w Play Console, że artefakt raportuje docelowy poziom API 36.
• Po przetworzeniu przejrzyj każdą aktywną ścieżkę i otwórz ponownie Status zasad.

Zachowania Androida 16 do przetestowania przed wydaniem API 36

Celowanie w API 36 włącza dla Twojej aplikacji zachowania Androida 16 na urządzeniach z Androidem 16. Zachowania o wysokim priorytecie do przetestowania to układ edge-to-edge, przewidujące cofanie, swoboda orientacji na dużych ekranach, uprawnienia zdrowotne, harmonogram o stałej częstotliwości i skład tekstu. Zaznacz poniżej, co Cię dotyczy, a dostaniesz listę testów dla swojej aplikacji zamiast ogólnej.

Edge-to-edge i przewidujące cofanie: najszerszy zasięg rażenia

Edge-to-edge ma szeroki zasięg rażenia, bo nie wymaga od Twojej aplikacji żadnego egzotycznego API. Na Androidzie 16 aplikacja celująca w API 36 nie może już użyć wcześniejszego atrybutu rezygnacji, więc treść, która zakładała, że paski systemowe zostawią jej miejsce, przebiega teraz pod nimi. Objaw jest kosmetyczny dokładnie do chwili, gdy główny przycisk trafia pod pasek gestów i przestaje być klikalny.

Przewidujące cofanie ma podobnie szeroki zasięg. Jeśli Twoja aplikacja rejestruje starą obsługę cofania, ta ścieżka może po prostu nie zadziałać tak jak wcześniej, gdy przewidujące cofanie stanie się domyślne przy targecie 36. Przetestuj cofanie z każdej głębokości nawigacji, jaką masz: okna modalne, WebView, formularze z niezapisanymi danymi i ostatni ekran przed wyjściem.

Co nie jest uniwersalną awarią przy targecie 36

A co z wymogiem rozmiaru strony 16 KB?

Inny wymóg, inna data, te same aplikacje. Termin docelowego API dotyczy poziomu, który deklaruje Twój manifest. Wymóg rozmiaru strony 16 KB dotyczy tego, czy Twoje biblioteki natywne działają na urządzeniach ze stronami pamięci 16 KB. Aktualne wskazówki Google podają 1 lutego 2027 r. jako datę, od której dotknięte aktualizacje bez obsługi 16 KB nie mogą już być wydawane.

• Kogo dotyczy: wymóg Google obejmuje aplikacje celujące w API 35 lub wyżej na 64-bitowych urządzeniach Google Play. W tej grupie aplikacje pakujące natywne biblioteki .so, bezpośrednio albo przez SDK, najczęściej wymagają jawnej przebudowy i wyrównania. Jeśli Twoja aplikacja jest wyłącznie w Kotlinie albo Javie, zwykle jest już zgodna, ale i tak warto to przetestować, zamiast zakładać.
• Czym nie jest: nie jest częścią terminu docelowego API z 31 sierpnia 2026 r., a spełnienie jednego nie oznacza spełnienia drugiego.
• Dlaczego wypadają razem: każdy, kto podnosi w tym miesiącu poziom docelowy, i tak przebudowuje projekt, a właśnie wtedy wychodzi kontrola rozmiaru strony. Ta zbieżność w czasie jest powodem mylenia obu rzeczy.

Jeśli Twoja aplikacja pakuje biblioteki natywne, potraktuj kontrolę rozmiaru strony jako osobne zadanie z własną turą testów, a nie coś, co w ostatniej chwili wciśniesz do builda z API 36. Te dwie zmiany dotykają różnych części builda, a debugowanie ich naraz to sposób, w jaki tygodniowa migracja zamienia się w trzytygodniową.

Przesłałeś API 36, a ostrzeżenie nadal wisi

Zwykle jedna z trzech rzeczy: bundle nie skończył się przetwarzać i Status zasad się nie odświeżył, starszy artefakt wciąż siedzi na innej aktywnej ścieżce, albo przesłany artefakt w rzeczywistości nie deklaruje 36, mimo że Twój projekt owszem. Przejdź listę od góry i nie zaczynaj usuwać wydań.

Tytuł pozycji, który zgłaszają obecnie deweloperzy, to Your app must target Android 16 (API level 36) or higher. Google nie publikuje kanonicznego pełnego komunikatu błędu dla każdego przepływu przesyłania, więc dokładne brzmienia znajdowane w sieci, łącznie z tym, traktuj jako zaobserwowane, a nie oficjalne.

Jeden nawyk rozwiązuje większość tego na stałe: po każdym przesłaniu odczytaj docelowy poziom API z artefaktu w Play Console i zapisz go obok kodu wersji. Zajmuje dziesięć sekund i usuwa z Twojego tygodnia całą kategorię "jestem pewien, że to naprawiłem".

Lista kontrolna przed terminem

Czternaście pozycji w kolejności, w jakiej faktycznie następują. Cztery ostatnie to te, które ludzie pomijają, i to właśnie one decydują, czy ostrzeżenie zniknie.

Gdzie w tym terminie mieści się PrimeTestLab

Żeby granica była jasna: nie migrujemy Twojego kodu. Podniesienie targetSdk, aktualizacja zależności i naprawa zmian działania Androida 16 to Twój build, a ten wpis jest całym naszym wkładem w niego. To, co bierzemy na siebie, to druga połowa zderzenia: 12 prawdziwych testerów zapisanych przez 14 kolejnych dni, których nowe osobiste konto dewelopera potrzebuje, zanim w ogóle dotrze do wersji produkcyjnej.

Problemem jest zbieg w czasie. Ktoś, kto publikuje po raz pierwszy w sierpniu 2026 r., ma zrobić w tym samym oknie dwie niepowiązane, trudne rzeczy: wydać build z API 36 i utrzymać kwalifikujący się test zamknięty przez dwa tygodnie z rzędu. Build to rozwiązywalne zadanie inżynierskie. Zebranie dwunastu prawdziwych ludzi, którzy pozostaną zapisani przez czternaście dni, na prawdziwych urządzeniach, to część, która po cichu zjada miesiąc.

Test zamknięty samemu kontra zlecony

W jakiej kolejności zrobić to w tym miesiącu

Jeśli mierzysz się z obydwoma problemami naraz, prowadź je równolegle, a nie po kolei. Zacznij test zamknięty teraz, bo jego 14 dni to czas zegarowy, którego nie skompresujesz, a migrację na API 36 rób obok. Wrzuć zgodny build na tę samą ścieżkę zamkniętą, gdy będzie gotowy, z wyższym kodem wersji i tymi samymi testerami wciąż zapisanymi. W ten sposób termin i okno testowe przestaną się bić o te same dwa tygodnie.

Najczęstsze pytania

W skrócie

Migawka zasad zweryfikowana 9 sierpnia 2026 r. Google aktualizuje te strony bez uprzedzenia, więc zanim zadziałasz na podstawie jakiejkolwiek daty, sprawdź źródła pierwotne powyżej. Ten wpis jest zaplanowany do ponownej weryfikacji zaraz po 31 sierpnia i ponownie po 1 listopada 2026 r.