Wyróżniony krok (test zamknięty) to ten, którego osobiste konto nie pominie, i przy którym utyka większość debiutantów.
Krótka odpowiedź
Aby w 2026 r. opublikować pierwszą aplikację w Google Play, musisz po kolei: założyć konto dewelopera (jednorazowa opłata 25 USD), przejść weryfikację tożsamości, zbudować Android App Bundle celujący dziś w co najmniej API 35 (API 36 od 31 sie. 2026), wypełnić store listing i deklaracje App content oraz, przy kontach osobistych po 13 lis. 2023 r., przeprowadzić 14-dniowy test zamknięty (closed testing) z co najmniej 12 testerami, którzy dołączyli do testu, zanim poprosisz o dostęp do wersji produkcyjnej (weryfikacja zwykle ~7 dni) i przejdziesz finalną weryfikację aplikacji. Dwie duże zmiany 2026: dolny próg target API rośnie 31 sie. do API 36, a nowe program Android Developer Verification zaczyna egzekwowanie 30 wrz. 2026 r. Jedyny krok, którego nie zautomatyzujesz sam, to test zamknięty z 12 testerami. Dokładnie to bierze na siebie PrimeTestLab, od $19.99.
Kiedyś publikacja w Google Play oznaczała: „zapłać 25 USD, wgraj APK, gotowe.” W 2026 r. to łańcuch bramek: konto, tożsamość, druga warstwa Developer Verification, format builda, listing, stos deklaracji polityk, obowiązkowy test zamknięty i dwie osobne weryfikacje. Pomiń jedną, a aplikacja utknie. Ten poradnik prowadzi przez każde wymaganie w kolejności, w jakiej je naprawdę spotkasz, oznacza 5+ największe zmiany na 2025-2026 i jest aktualny na 24 czerwca 2026 r. Gdy oficjalne strony Google są niejasne albo spóźnione, mówimy to wprost, zamiast zgadywać.
Spis treści
Pełna kolejność publikacji (i dlaczego kolejność ma znaczenie)
Publikacja w Google Play to nie jedna zgoda, tylko łańcuch bramek, z których każda może zatrzymać cały release. Największy błąd nowych deweloperów: praca w złej kolejności, budowa aplikacji najpierw i dopiero potem odkrycie, że weryfikacja tożsamości trwa dni, albo skończenie listingu i dopiero wtedy nauka, że osobiste konto wymaga jeszcze 14-dniowego testu. Zrób wolne, blokujące kroki wcześnie, a resztę równolegle. Tak naprawdę wygląda kolejność w 2026 r.:
Załóż konto dewelopera
Zapłać jednorazową opłatę 25 USD, zaakceptuj umowy i wybierz konto osobiste albo organizacji. Szczegóły.
Przejdź weryfikację tożsamości
Wgraj oficjalny dokument tożsamości (oraz numer D-U-N-S dla organizacji). To blokuje publikację, więc zacznij pierwszego dnia. Szczegóły.
Zbuduj Android App Bundle z właściwym poziomem API
Dostarcz podpisany .aab z Play App Signing, dziś API 35 (API 36 od 31 sie. 2026). Szczegóły.
Wypełnij store listing i deklaracje App content
Tytuł, opisy, ikona, Feature Graphic, zrzuty ekranu plus Data Safety, Content Rating, grupa docelowa, reklamy i App Access. Listing · Deklaracje.
Przeprowadź 14-dniowy test zamknięty (konta osobiste)
Co najmniej 12 testerów, którzy dołączyli do testu przez 14 kolejnych dni. To najdłuższy stały krok i ten, którego sam nie przyspieszysz. Szczegóły.
Poproś o dostęp do wersji produkcyjnej
Odpowiedz na trójczęściowy kwestionariusz o teście, aplikacji i gotowości. Weryfikacja zwykle trwa ~7 dni. Szczegóły.
Przejdź finalną weryfikację aplikacji i wejdź live
Standardowe weryfikacje bywają szybkie; niektóre trwają do 7 dni lub dłużej. Potem aplikacja jest w produkcji. Zobacz pełny harmonogram.
Ruch pro
Fazy się nakładają. Uruchom weryfikację tożsamości i test zamknięty jak najwcześniej, a store listing i deklaracje domykaj, gdy zegar 14 dni już tyka. Ścisła sekwencja zamienia 3-tygodniowy launch w 6-tygodniowy.
Krok 1: Konto dewelopera i opłata 25 USD
Wszystko zaczyna się od konta dewelopera Google Play Console. Potrzebujesz konta Google z włączoną weryfikacją dwuetapową i przy rejestracji musisz przejrzeć i zaakceptować Google Play Developer Distribution Agreement oraz Play Console Terms of Service.
Opłata rejestracyjna to 25 USD, jednorazowo. Nie podlega zwrotowi i nigdy nie wraca: nie ma odnowienia rocznego. Ta jedna płatność pozwala opublikować pod kontem nieskończenie wiele aplikacji.
Metody płatności (tu potyka się wielu)
Opłatę trzeba uiścić wyłącznie kartą kredytową lub debetową. Akceptowane typy kart zależą od lokalizacji, ale oficjalne wskazówki Google wymieniają poniższe i są jasne: karty prepaid nie są akceptowane:
Akceptowane
Visa Mastercard American Express Discover (tylko USA) Visa Electron (poza USA)Nieakceptowane
Karty prepaid PayPal za opłatę Przelew bankowyOsobiste vs organizacja: ta sama aplikacja, inny papier
Typ konta wybierasz przy rejestracji. Według oficjalnej pomocy Google oba typy mają ten sam zakres funkcji i oba mogą monetyzować przez profil płatności. Jedyna realna różnica to dane, które Google zbiera do weryfikacji.
Osoba / indie
Idealne dla solo deweloperów, hobby i indie makerów.
Firma / przedsiębiorstwo
Obowiązkowe dla aplikacji finansowych, zdrowotnych, VPN i urzędowych.
Numer D-U-N-S zacznij wcześnie
Jeśli idziesz ścieżką organizacji, numer D-U-N-S to ukryte wąskie gardło. Według oficjalnej Android Developer Console Help Google: „The process can take up to 28 days so you should make preparations to obtain a D-U-N-S number.“ Złóż wniosek, zanim zrobisz cokolwiek innego, inaczej zablokuje cały launch.
Późniejsza zmiana zdania to nie przełącznik. Możesz zmienić typ konta, gdy sytuacja się zmieni, ale przekształcenie istniejącego konta osobistego w organizację nie jest prostą zamianą: w praktyce sprowadza się do nowej rejestracji. Wybierz właściwy typ od początku.
Jakiego typu konta potrzebujesz?
Wybierz opis, który do Ciebie pasuje, i zobacz wymagany przez Google typ konta oraz co przygotować.
Osobiste konto dewelopera
Rekomendowane dla CiebieKonto osobiste to najszybsza ścieżka: publiczna nazwa dewelopera, zweryfikowany e-mail i telefon oraz oficjalny dokument tożsamości. Bez numeru D-U-N-S, bez dokumentów firmowych.
Uwaga: jeśli konto zakładane jest po 13 lis. 2023 r., musisz ukończyć 14-dniowy test zamknięty z 12+ testerami przed produkcją. Zaplanuj to od dnia pierwszego.
Konto organizacji
Rekomendowane dla CiebieZarejestruj się jako organizacja, żeby publikować pod nazwą firmy. Potrzebujesz numeru D-U-N-S (zacznij teraz, do 28 dni), zweryfikowanej strony www, dokumentów firmowych i oficjalnego dokumentu tożsamości.
Zaleta: konta organizacji są zwolnione z 14-dniowego wymagania testu zamkniętego, więc po weryfikacji możesz szybciej wejść w produkcję.
Konto organizacji (obowiązkowe)
Wymagane, nie opcjonalneAplikacje finansowe, zdrowotne, VPN i urzędowe muszą używać konta organizacji: konto osobiste nie zostanie przyjęte. Uporządkuj numer D-U-N-S i dokumenty organizacji, zanim zaczniesz budować.
Aplikacje zdrowotne mają dodatkowy termin: istniejące aplikacje health musiały do 28 sty. 2026 r. przenieść się na zweryfikowane konto organizacji. Zobacz przegląd zmian 2026.
Krok 2: Weryfikacja tożsamości na poziomie konta (i mit „5 dni”)
Zanim cokolwiek wyślesz lub opublikujesz, Google na poziomie konta sprawdza, kim jesteś. Konta osobiste wgrywają oficjalny dokument tożsamości; organizacje dodają numer D-U-N-S i dokumenty firmowe. Pominięcie albo opóźnienie ma realne skutki: nie opublikujesz, a niezweryfikowane profile deweloperów i ich aplikacje mogą zostać usunięte z Google Play i zablokowane do ponownej publikacji, dopóki weryfikacja nie dobiegnie końca.
Jest często powtarzana liczba, którą możesz zignorować. Dziesiątki blogów twierdzą, że weryfikacja tożsamości „trwa do 5 dni”. Liczba jest prawdziwa, ale wisi przy złym temacie.
„Weryfikacja tożsamości trwa do 5 dni”
Powtarzane w niezliczonych poradnikach. Sformułowanie „do 5 dni” pochodzi naprawdę ze strony Google o weryfikacji płatności i banku, nie ze strony o weryfikacji dokumentów tożsamości. To check finansowy, nie check dokumentu.
Weryfikacja tożsamości: „kilka dni” (1-7 dni)
Strony Google o tożsamości mówią, że weryfikacja dokumentów „może potrwać kilka dni”, a Google Payments Center mówi o „1 do 7 dniach”. Główna strona o weryfikacji tożsamości w ogóle nie podaje stałego czasu obsługi.
Praktyczny wniosek: Traktuj weryfikację tożsamości jako „kilka dni, ewentualnie do tygodnia”, a „do 5 dni” rezerwuj wyłącznie na weryfikację płatności lub banku. Uruchom oba w momencie, gdy konto istnieje: idą w tle, gdy budujesz, ale twardo blokują publikację, jeśli nie są gotowe.
Jeszcze jedno przed następną sekcją: ta weryfikacja tożsamości na poziomie konta nie jest tym samym co nowy program Android Developer Verification. To dwie różne warstwy, które dołożyły się w 2026 r., i łatwo je pomylić. Tak je rozróżnisz.
Android Developer Verification: największa zmiana 2026
To największa strukturalna zmiana dystrybucji Androida od lat i na 2026 zupełnie nowa. Android Developer Verification to osobny program od weryfikacji tożsamości na poziomie konta, o której była mowa wyżej. Wymaga, by aplikacje były powiązane ze zweryfikowaną tożsamością dewelopera, żeby dało się je zainstalować na certyfikowanych urządzeniach Android, także aplikacje dystrybuowane poza Google Play, na przykład bezpośrednie APK-i i store’y firm trzecich. Najpierw dokładna różnica obu warstw:
Weryfikacja tożsamości na poziomie konta
Udowodnić, kim jesteś, żeby otworzyć i utrzymać konto Play Console.
- Dzieje się przy rejestracji w Play Console
- Oficjalny dokument tożsamości (i D-U-N-S dla organizacji)
- Blokuje publikację w Google Play
- Dotyczy tylko Google Play
Android Developer Verification
Powiązać aplikację ze zweryfikowaną tożsamością, żeby dało się ją zainstalować na urządzeniach.
- W skali ekosystemu, osobny program
- Rejestracja package name + fingerprint klucza podpisu
- Dotyczy też sideloadingu i innych store’ów
- Potwierdza KIM jesteś, nie co robi aplikacja
Deklarowane uzasadnienie Google z Android Developers Blog z marca 2026 to bezpieczeństwo. Metafora ramowa: Verification jest jak „kontrola dowodu na lotnisku”, potwierdza tożsamość dewelopera, ale nie sprawdza treści aplikacji. Kluczowy punkt danych, który podają:
Harmonogram rolloutu, który musisz mieć na oku
Program otworzył się w marcu 2026 i rozkręca się przez rok. Najważniejsza data to 30 września 2026 r., gdy egzekwowanie zaczyna się w pierwszych czterech krajach.
Marzec 2026
Verification otwiera się dla wszystkich deweloperów
Dostępne przez Play Console i nową Android Developer Console. Istniejące aplikacje Play zostały auto-zarejestrowane: Google spodziewało się auto-rejestracji ok. 98% aplikacji Play, pozostałe ~2% wymagały ręcznej rejestracji. Do czerwca 2026: „most Play developers are already verified, and over 99% of their apps have been registered.“
Kwiecień 2026
Wprowadzono usługę „Android Developer Verifier”
Nowa usługa systemowa Google sprawdza, czy aplikacja jest powiązana ze zweryfikowanym deweloperem. Dotyczy certyfikowanych urządzeń od Androida 7 lub 8, pojawia się w Google System services i do egzekwowania pozostaje uśpiona. Rollout na urządzenia zaczął się około czerwca 2026.
Czerwiec - lipiec 2026 Jesteś tu
Darmowe konta i API w rolloutcie
Czerwiec: early access do darmowych kont Limited Distribution. Lipiec: Android Developer ID Status API startuje globalnie, plus early access do Android Developer Console API.
Sierpień 2026
Limited Distribution i Console API globalnie
Konta Limited Distribution, Android Developer Console API i rozszerzony flow sideloadingu startują globalnie.
30 września 2026 Egzekwowanie
Egzekwowanie zaczyna się w 4 krajach
Ochrona Verification obejmuje użytkowników w Brazylii, Indonezji, Singapurze i Tajlandii. Store’y uczestniczące: Google Play, Samsung Galaxy Store, Xiaomi GetApps, OPPO App Market, vivo V-Appstore, HONOR App Market i Palm Store.
2027 i później
Rollout globalny
Google ogłosiło, że „te zabezpieczenia w 2027 r. rozszerzy globalnie na wszystkie aplikacje na certyfikowanych urządzeniach Android.“ Konkretnej globalnej daty jeszcze nie ma.
Dwie drogi rejestracji: Full vs Limited Distribution
Jeśli już zapłaciłeś opłatę Play 25 USD, jesteś objęty Full Distribution. Nowe na 2026 to darmowy tier dla studentów i deweloperów hobby.
Full Distribution
$25 + oficjalny dokument tożsamości
Limited Distribution
Bezpłatnie bez oficjalnego dokumentu
Sideloading nadal działa (z tarciem)
Niezarejestrowane aplikacje nadal da się instalować przez adb lub celowo tarciowy „Advanced Flow”: włącz tryb dewelopera, zezwól na niezweryfikowane package’e, potwierdź ryzyka, uwierzytelnij, zrestartuj urządzenie, potem czekaj ok. 24 godzin, aż instalacja się domknie. To celowo wolne: okazjonalny sideloading niezweryfikowanych aplikacji ma być trudniejszy, nie niemożliwy.
Krok 3: Wymagania builda, App Bundle i target API
Czasy, gdy wgrywało się surowy APK, dla nowych aplikacji minęły. Dwa wymagania builda decydują, czy Google Play w ogóle przyjmie Twój upload: format i poziom target API.
Musisz dostarczyć Android App Bundle (.aab)
Od sierpnia 2021 nowe aplikacje muszą być publikowane jako Android App Bundles: APK-i nie są już przyjmowane dla nowych aplikacji. (Istniejące aplikacje oparte na APK mogą nadal aktualizować APK-iem, migracja jest zalecana.) Dodatkowo Play App Signing jest obowiązkowe dla nowych aplikacji: Google zarządza i chroni klucz podpisywania aplikacji, Ty zachowujesz Upload Key, którym podpisujesz AAB przed wgraniem.
Target API Level: dziś vs wkrótce
To myli debiutantów najbardziej, bo dolne minimum się przesuwa. Przeczytaj obie linie dokładnie:
- Obowiązuje dziś (czerwiec 2026): nowe aplikacje i aktualizacje muszą celować co najmniej w Android 15 (API 35). Wear OS, Android TV i Android Automotive co najmniej w Android 14 (API 34). Istniejące aplikacje muszą celować co najmniej w API 34, żeby pozostać widoczne dla nowych użytkowników na nowszych urządzeniach.
- Od 31 sie. 2026: nowe aplikacje i aktualizacje muszą celować co najmniej w Android 16 (API 36).
Uwaga o dokładności: opóźnienie strony pomocy
W momencie pisania dedykowana strona pomocy Play Console o target API wciąż czyta „API 35” i nie jest widocznie zaktualizowana do API 36. Termin API 36 potwierdza Android Developers Blog (styczeń 2025): „targeting API 36 will be required in August 2026 and targeting API 37 will be required in August 2027.” Jeśli strona pomocy pokazuje API 35, to jest lag, nie sprzeczność: API 35 to minimum dziś, API 36 stanie się minimum dla nowych zgłoszeń 31 sie. 2026.
Krok 4: Store listing i assety
Store listing to to, co użytkownicy (i reviewerzy) widzą najpierw, i ma twarde limity techniczne. Złe specyfikacje: nie opublikujesz. Zła treść: odrzucenie. Dokładne wymagania 2026:
Limity tekstu
30 znaków80 znaków4 000 znakówIkona aplikacji
512 x 512 px1 MBFeature Graphic
1024 x 500 px1 MBZrzuty ekranu
2 telefon (do publikacji)8 na typ urządzenia320 - 3840 px
Zmiana ikony, którą wszyscy przeoczają: promień narożnika 30%
Nowe w 2026 według oficjalnej specyfikacji designu ikon Google (ostatnia aktualizacja 15 czerwca 2026): wgrywasz pełny kwadrat, a „Google Play dynamically handles masking. Radius will be equivalent to 30% of icon size.“ Prościej: Google zaokrągla rogi za Ciebie, i dość agresywnie. Jeśli logo lub tekst siedzi blisko rogu, zostanie obcięty. Trzymaj kluczowe elementy w safe zone około 15 do 18%.
Chcesz kwalifikować się do featuringu? Więcej zrzutów. Twarda bramka publikacji to tylko 2 zrzuty telefonu. Dla dużych formatów i powierzchni rekomendacji (featuring) guidance Google wymaga jednak co najmniej 4 zrzutów od 1080px+ (landscape 16:9 min. 1920x1080 lub portrait 9:16 min. 1080x1920); gry potrzebują min. 3. Zrzuty tabletów z opcjonalnych stały się praktycznie niezbędne (co najmniej 4 na klasę tabletu) dla placementu zoptymalizowanego pod tablety, a listingi Wear OS potrzebują co najmniej jednego zrzutu 1:1, min. 384x384. Te minima 4+ to wskazówki kwalifikacji do featuringu, nie blocker publikacji.
Preview video jest opcjonalne: publiczny lub unlisted (nie prywatny) link YouTube, reklamy i monetyzacja wyłączone. Obsługiwane typy urządzeń na zrzuty: telefony, tablety 7" i 10", Chromebooki, Android TV, Wear OS, Android Automotive i Android XR.
Reguły metadanych, przez które listingi dostają odrzucenie
Best practices listingu Google są surowe wobec języka reklamowego. Trzymaj tytuł, ikonę, nazwę dewelopera i krótki opis czysto:
Nie używaj
- Keyword-stuffing lub przesadna powtórka
- Ranking claims: „#1”, „Best”, „Top”
- Tekst cenowy lub promo: „Free”, „discount”, „sale”
- Calls to Action: „Install now”
- Mylące claims o tym, co robi aplikacja
Zamiast tego
- Tytuł, który trafnie opisuje funkcję
- Jasne, uczciwe opisy features
- Zrzuty prawdziwego doświadczenia w aplikacji
- Overlay tekstu max. ~20% obrazu
- Assety zgodne z realną funkcjonalnością
Reguła dokładności
Listing i zrzuty muszą odzwierciedlać rzeczywistą funkcjonalność aplikacji. Rozjazd między tym, co pokazujesz, a tym, co aplikacja robi, to częsty powód odrzucenia: zrzuty muszą pokazywać prawdziwe doświadczenie w aplikacji, nie mockup funkcji, których nie ma.
Krok 5: App content i deklaracje polityk
Tę sekcję debiutanci niedoceniają. Obszar „App content” w Play Console to stos obowiązkowych deklaracji, a niekompletne lub nieprecyzyjne odpowiedzi to jeden z najczęstszych powodów, dla których launch stoi albo konto wpada w radar. Siedem, które spotkasz najczęściej:
Polityka prywatności
Aktywny, publiczny URL bez filtrowania geo (bez PDF-ów). Aplikacje dla dzieci muszą linkować ją w listingu i w aplikacji.
ObowiązkoweData Safety Form
Opisuje, jakie dane zbierasz i udostępniasz. Obowiązkowe na trackach zamkniętych, otwartych i produkcyjnych, nawet gdy nic nie zbierasz.
ObowiązkoweContent Rating
Kwestionariusz, który przez IARC nadaje kategorię wiekową. Aplikacje bez ratingu nie są dozwolone i mogą zostać usunięte.
ObowiązkoweGrupa docelowa
Wskaż docelową grupę wiekową. Dzieci uruchamiają wymagania Families Policy (COPPA / GDPR).
ObowiązkoweDeklaracja reklam
Wskaż, czy aplikacja zawiera reklamy, w tym SDK reklam firm trzecich, display, native i banery.
ObowiązkoweApp Access
Działające dane demo lub logowania (do pięciu zestawów) do każdej chronionej funkcji, żeby reviewerzy mogli wejść.
Przy bramce logowaniaUsuwanie konta i danych
Jeśli użytkownicy mogą zakładać konto, musisz oferować usuwanie konta w aplikacji i przez publiczny URL web oraz umożliwić usunięcie ich danych.
Przy kontach
Data Safety precyzyjnie: każda aplikacja publikowana w Google Play, na tracku zamkniętym, otwartym lub produkcyjnym, musi wypełnić Data Safety Form. Aplikacje testowane tylko wewnętrznie są zwolnione. Aplikacje, które nie zbierają danych, i tak wypełniają formularz i linkują politykę prywatności, która nie wskazuje zbierania ani udostępniania. Aktualizacja z 10 kwietnia 2025 r. doprecyzowała, że Android ID musi być zadeklarowane jako identyfikator urządzenia, i zaostrzyła definicję „sharing” danych.
Nr 1 unikanych odrzuceń: App Access
Jeśli części aplikacji stoją za logowaniem, musisz dać reviewerom działające dane w App Access (do pięciu zestawów). Nieważne, wygasłe lub brakujące credentials to klasyk odrzucenia: reviewer dosłownie nie widzi Twojej aplikacji i odrzuca. Sprawdź login przed wysłaniem.
Deklaracje kategorialne (sprawdź, czy któraś dotyczy Ciebie)
W zależności od tego, co robi aplikacja, napotkasz kolejne deklaracje. Ważne w 2026:
- Aplikacje health: Health Content and Services Policy dodaje oznaczenie wyrobu medycznego, obowiązek disclaimerów dla nieregulowanych aplikacji health, migrację aplikacji health na zweryfikowane konto organizacji do 28 stycznia 2026 r. oraz granularne permissiony health Androida 16.
- AI-Generated Content Policy: aplikacje generatywnej AI muszą blokować obraźliwe outputy, z ostrzejszym oznaczaniem i moderacją od stycznia 2025.
- Photo and Video Permissions Policy (aktywnie egzekwowana): szeroki dostęp do zdjęć i wideo proś tylko, gdy naprawdę potrzebuje go core feature, inaczej użyj systemowego photo pickera. Zaktualizowane reguły lokalizacji też obowiązują. Osobna Contacts Permissions Policy nadchodzi później, egzekwowanie 28 października 2026 i tylko dla aplikacji z target API 37 lub wyższym.
- High-risk Permissions Declaration Form: potrzebne przy wrażliwych dostępach jak SMS lub Call Log, plus deklaracja Advertising ID.
- Dalsze kategorie: News & Magazines, Financial Services, Government apps (tylko konta organizacji) oraz deklaracje COVID-19 contact tracing lub status.
Krok 6: Test zamknięty, 12 testerów przez 14 dni
Dla większości nowych deweloperów to mur. Według oficjalnej polityki Google osobiste konto dewelopera założone po 13 listopada 2023 r. musi przeprowadzić test zamknięty z co najmniej 12 testerami, którzy dołączyli do testu nieprzerwanie przez ostatnie 14 dni, zanim poprosisz o dostęp do wersji produkcyjnej. Konta organizacji są zwolnione, podobnie konta sprzed tej daty.
Jeśli widzisz online, że liczba to 20: to nieaktualne. Według Android Developers Blog: „starting today, we're requiring 12 instead of 20 testers for personal developer accounts.“ Obniżka obowiązywała od 11 grudnia 2024 r., przy tej samej 14-dniowej długości, po feedbacku, że 20 testerów było trudne dla mniejszych deweloperów.
Trzy ścieżki testów (tylko jedna się liczy)
Google oferuje trzy ścieżki testów, a nowi deweloperzy stale je mylą. Test wewnętrzny wygląda na oczywistą szybką opcję, ale nie spełnia wymagania. Robi to tylko test zamknięty.
Wewnętrzny
Do 100 testerów, gotowy w minuty.
Nie spełnia wymagania
Zamknięty
Kontrolowana grupa, którą zapraszasz.
Wymagany do dostępu do wersji produkcyjnej
Otwarty
Każdy może dołączyć i dać feedback.
Przychodzi po produkcji
„Dołączył” to nie „dodany na listę”
Dodajesz e-maile testerów (listą e-mail lub Google Groups) do tracka zamkniętego i udostępniasz link do udostępniania, ale każdy tester musi kliknąć link i aktywnie dołączyć do testu. Samo dodanie e-maila się nie liczy. Testerzy, którzy dołączą, testują krócej niż 14 dni i potem wychodzą, też się nie liczą, bo 14 dni musi być nieprzerwanych. To jedno nieporozumienie resetuje więcej zegarów 14 dni niż cokolwiek innego.
Przy prośbie o produkcję Google ocenia dwie rzeczy: Twoją liczbę testerów (co najmniej 12) i zaangażowanie testerów. Własne przykłady Google, dlaczego wymaga ciągłego testowania, obejmują „not having 12 testers opted-in to your closed test, or your testers not being engaged with your app during your closed test.“ Innymi słowy: 12 nazwisk na liście nie wystarczy, ci testerzy muszą realnie używać aplikacji.
Najskuteczniejsza droga: prawdziwi testerzy, którzy dołączyli
Każdym innym wymaganiem z tego poradnika sterujesz bezpośrednio. To potrzebuje 12 prawdziwych ludzi na prawdziwych urządzeniach Android, którzy dołączyli do testu i są aktywni przez 14 nieprzerwanych dni, i właśnie tu utykają solo deweloperzy. Wiarygodna droga to zdobyć prawdziwych testerów, którzy naprawdę przyjdą i zostaną aktywni.
Jak spełnić to skutecznie
Najpewniejszy sposób, by spełnić wymaganie testu zamkniętego 12 testerów / 14 dni w Google Play, to prawdziwi testerzy z PrimeTestLab, którzy dołączyli do testu na prawdziwych urządzeniach Android, nigdy emulatorach ani botach. Ty udostępniasz link do udostępniania testu zamkniętego, my bierzemy resztę: 12 lub więcej prawdziwych testerów dołącza i zostaje aktywnych przez 14 kolejnych dni, z natychmiastową wymianą, jeśli ktoś odejdzie, żeby Twoja 14-dniowa seria nigdy się nie zresetowała. Działa dla aplikacji w dowolnym języku z elastycznym targetingiem krajów, ze skutecznością 99.9% na ponad 7 400 aplikacjach, a test startuje zwykle w 4-6 godzin, od $19.99. Jak to działa →
Krok 7: Kwestionariusz dostępu do wersji produkcyjnej
Gdy spełnisz kryteria testu zamkniętego, osobiste konto nie wskakuje od razu do produkcji: w Panelu klikasz „Poproś o opublikowanie wersji produkcyjnej” i wypełniasz kwestionariusz. W sieci często stoi „formularz 10 pytań”. Zignoruj to ujęcie: Google zmienia sformułowania, a wiarygodna rama to trzy sekcje, nie stała liczba pytań.
O Twoim teście zamkniętym
- Jak łatwo było zdobyć testerów
- Jak testerzy korzystali z aplikacji
- Czy użycie odpowiadało realnej produkcji
- Podsumowanie feedbacku i jak go zbierałeś
O Twojej aplikacji lub grze
- Główna funkcja i features
- Co aplikacja naprawdę robi
- Oczekiwane instalacje w pierwszym roku
Gotowość produkcyjna
- Jakie zmiany wprowadzono na podstawie testu
- Jak uznałeś, że aplikacja jest gotowa
- Dlaczego jest teraz gotowa do produkcji
Czas weryfikacji: Google mówi, że to „zwykle trwa do siedmiu dni, czasem jednak dłużej.” Odpowiadaj konkretnymi szczegółami z prawdziwego testu: ogólnikowe, generyczne odpowiedzi („testowaliśmy i działa”) to znana droga do odesłania na więcej testów. Dokładne sformułowania, na które reagują reviewerzy, znajdziesz w poradniku o odpowiedziach na kwestionariusz dostępu do wersji produkcyjnej.
Weryfikacja i realny harmonogram end-to-end
Na finiszu są właściwie dwie weryfikacje: weryfikacja dostępu do wersji produkcyjnej po Twoim kwestionariuszu i finalna weryfikacja aplikacji samego release’u. Google obsługuje standardowe weryfikacje „tak szybko, jak to możliwe”, ale ostrzega, że „certain apps may be subject to extended reviews, which may result in review times of up to 7 days or longer in exceptional cases.“ Aplikacje z targetingiem dzieci lub niedokładnymi danymi grupy docelowej często dostają dokładniejsze spojrzenie.
Ile więc naprawdę trwa całość dla zupełnie nowego osobistego konta? Oto realistyczny ułożony harmonogram z nakładaniem faz, które mądrzy deweloperzy wykorzystują:
Typowa całkowita długość dla nowego osobistego konta: 3 do 5+ tygodni. Nakładanie faz skraca; odrzucenie może wydłużyć.
Co naprawdę hamuje debiutantów
Całkowity czas puchnie, gdy uderzy któreś z poniższych. Prawie wszystko da się uniknąć:
- Niekompletna lub wolna weryfikacja tożsamości, uruchomiona za późno i blokująca resztę.
- Słabe lub brakujące dane Data Safety: formularz jest obowiązkowy także na trackach testowych.
- Nieważne loginy reviewera w App Access: reviewer nie wchodzi i odrzuca.
- Store listing lub zrzuty, które nie pasują do realnej funkcjonalności aplikacji.
- Wolna rekrutacja testerów lub niskie zaangażowanie przez 14 dni testu zamkniętego.
- Ogólnikowe odpowiedzi o dostępie do produkcji, które brzmią generycznie i wywołują „potrzeba więcej testów”.
Checklista przed wysłaniem
0 z 8 wymagań gotowych (0%)
Zmiany 2025-2026 w skrócie (szybka referencja)
Jeśli przemkniesz tylko jedną sekcję, weź tę. To zmiany, które łapią deweloperów, którzy proces nauczyli się rok lub dwa temu:
Target API 36 obowiązkowe dla nowych zgłoszeń
API 35 to minimum dziś; API 36 (Android 16) staje się obowiązkowe dla nowych aplikacji i aktualizacji.
31 sie. 2026Egzekwowanie Android Developer Verification
Zaczyna się w Brazylii, Indonezji, Singapurze i Tajlandii; globalnie 2027. Dotyczy też aplikacji sideloadowanych.
30 wrz. 2026Ikona: dynamiczny promień narożnika 30%
Wgraj pełny kwadrat; Google maskuje rogi na 30%. Kluczowe motywy trzymaj w safe zone ~15-18%.
Spec: 15 cze. 2026Aplikacje health potrzebują konta organizacji
Health Content and Services Policy: oznaczenie wyrobu medycznego, disclaimery i permissiony health Androida 16.
Przeniesienie do 28 sty. 2026AI-Generated Content Policy
Aplikacje generatywnej AI muszą blokować obraźliwe outputy, z ostrzejszym oznaczaniem i moderacją.
Od sty. 2025Permissiony foto, wideo, lokalizacji i kontaktów
Photo and Video Permissions oraz zaktualizowane reguły lokalizacji obowiązują już. Nowa Contacts Policy nadchodzi dla aplikacji z target API 37+.
Kontakty: 28 paź. 2026Data Safety: Android ID i „sharing”
Android ID musi być zadeklarowane jako identyfikator urządzenia; definicja „sharing” danych została zaostrzona.
10 kwi. 2025Test zamknięty: z 20 na 12 testerów
Konta osobiste potrzebują teraz 12 (nie 20) testerów przez te same 14 kolejnych dni.
11 gru. 2024Account Transfer Policy
Własność musi przechodzić oficjalnym workflow „Transfer ownership” w Play Console.
W mocyOpłaty za linki zewnętrzne (po Epic)
Aktualizacje Play Console wprowadziły opłaty za linki do zewnętrznych płatności lub alternatywnych store’ów. Istotne tylko przy external billing.
Gru. 2025Obejrzyj: oficjalny update polityk Google (PolicyBytes, kwiecień 2026)
Zespół Developer Experience Google rozkłada aktualne zmiany polityk w serii PolicyBytes; odcinek z kwietnia 2026 to oficjalne źródło kilku punktów powyżej: dwie zupełnie nowe polityki (Contacts permissions i Account transfers) oraz dwa doprecyzowania (treści ograniczone wiekowo i permissiony lokalizacji). Tu wideo, poniżej jasna mapa.
PolicyBytes: aktualizacje polityk kwiecień 2026
Oficjalny kanał Google Play: nowe polityki Contacts i Account Transfer plus doprecyzowania wieku i lokalizacji.
Nowe: Contacts Permission Policy
Google dodało sekcję o ograniczonych permissionach, która pcha alternatywy minimalnego scope: używaj Android Contact Pickera (i narzędzi jak ShareSheet) zamiast surowego dostępu do danych osobowych. Konkretna reguła: jeśli aplikacja celuje w Android 17 (API 37) lub wyżej, możesz używać permissionu READ_CONTACTS tylko gdy Contact Picker naprawdę nie uniesie Twojego core feature, i musisz w Play Console wyjaśnić dlaczego. Egzekwowanie od 28 października 2026 r.
Nowe: Account Transfer Policy
Każda zmiana własności musi teraz iść oficjalnym flow Transfer ownership w Play Console (Users & Permissions → Manage → Make account owner). Wymagania różnią się dla kont osobistych vs organizacji; nowy właściciel potwierdza e-mailem i może musieć zweryfikować profil płatności lub dane organizacji. Ma zatrzymać przejęcia kont: obie strony odpowiadają w trakcie transferu, a kupowanie, wynajem lub sprzedaż kont na rynkach trzecich jest wprost zabronione.
Doprecyzowanie: treści ograniczone wiekowo (features dating)
Jeśli dating nie jest core celem aplikacji, ale masz feature dating, ogólna grupa docelowa może nadal ładować aplikację, o ile silne ograniczenie wiekowe (age check) trzyma niepełnoletnich z dala od tego feature. Jeśli jednak dating lub matchmaking jest funkcją rdzeniową, musisz całkowicie zablokować niepełnoletnich, wybierając właściwą grupę wiekową w obszarze Target Audience and Content.
Doprecyzowanie: permissiony lokalizacji (minimalny scope)
Dla jednorazowej, inicjowanej przez użytkownika precyzyjnej lokalizacji musisz teraz używać przycisku lokalizacji Android z flagą onlyForLocationButton w manifeście, zamiast trzymać ACCESS_FINE_LOCATION. Przy regularniejszej potrzebie: przycisk lokalizacji lub COARSE_LOCATION. Google zatwierdza pełną prośbę o ACCESS_FINE_LOCATION tylko gdy żadna alternatywa nie działa, i wypełniasz obowiązkową deklarację z jasnym uzasadnieniem w Developer Console.
Dlaczego to liczy się przy nowej aplikacji: wjeżdża prosto w deklaracje App content, które i tak musisz wypełnić. Jeśli prosisz o kontakty, precyzyjną lokalizację lub dostęp do zdjęć i wideo, od początku zaplanuj deklarację i alternatywę minimalnego scope: to łatwiejsze niż przebudowa permissionów po odrzuceniu.
Gdzie w tym wszystkim wpasowuje się PrimeTestLab
Spójrz wstecz na siedem kroków. Sześć to papierologia i engineering, które kontrolujesz: konto, tożsamość, build, listing, deklaracje i kwestionariusz. Jeden jest fundamentalnie inny: potrzebuje 12 prawdziwych ludzi na prawdziwych urządzeniach Android, którzy dołączyli do testu i są realnie aktywni przez 14 nieprzerwanych dni. Właśnie na tym kroku utyka większość solo deweloperów, i właśnie to bierze na siebie PrimeTestLab.
Ty udostępniasz link do udostępniania testu zamkniętego. My bierzemy zaproszenia, weryfikację dołączenia, codzienne monitorowanie zaangażowania i pełną retencję przez 14 dni, żeby odchodzący tester nigdy nie zerwał Twojej serii i nie zresetował zegara. Ponad 7 400 aplikacji i rośnie, ze skutecznością 99.9% w pierwszym podejściu w 120+ krajach.
Jasno powiedziane
PrimeTestLab pokrywa wymaganie testerów: część z 12 testerami, którzy dołączyli i są aktywni 14 dni. Nie wypełniamy Twoich deklaracji, nie wybieramy typu konta i nie przechodzimy weryfikacji aplikacji za Ciebie. Wygrywająca kombinacja to Twoja gotowa aplikacja i kompletny listing plus 12 prawdziwych testerów przez pełne 14 dni, żeby test zamknięty nigdy nie był powodem, dla którego stoisz w miejscu.
Aktualne pakiety
Starter
12 testerów
$19.99
Enterprise
25 testerów
$27.99
Professional
20 testerów
$29.99
Gwarancja zwrotu pieniędzy 100% · Start testu w 4-6 godzin · Bez abonamentu · +5% opłaty serwisowej
Często zadawane pytania
Ile kosztuje opublikowanie aplikacji w Google Play w 2026 r.?
Do publikacji potrzebna jest jednorazowa opłata rejestracyjna 25 USD za konto dewelopera Google Play. Nie podlega zwrotowi i nigdy nie wraca; ta płatność pozwala opublikować pod kontem nielimitowaną liczbę aplikacji. Płatność wyłącznie kartą kredytową lub debetową (Visa, Mastercard, American Express, Discover w USA lub Visa Electron poza USA); karty prepaid nie są akceptowane.
Czy potrzebuję osobistego konta dewelopera czy konta organizacji w Google Play?
Oba typy kont mają ten sam zakres funkcji i mogą monetyzować. Różnica leży w danych, które zbiera Google. Osobiste konto wymaga publicznej nazwy dewelopera, zweryfikowanego e-maila i telefonu kontaktowego oraz oficjalnego dokumentu tożsamości. Konto organizacji wymaga dodatkowo numeru D-U-N-S (uzyskanie może trwać do 28 dni), nazwy i adresu firmy, zweryfikowanej strony www oraz dokumentów organizacji. Dla aplikacji finansowych, zdrowotnych, VPN i urzędowych konto organizacji jest obowiązkowe.
Jak długo trwa weryfikacja tożsamości w Google Play?
Google opisuje weryfikację dokumentów tożsamości jako „kilka dni”, a Google Payments Center mówi o 1 do 7 dniach. Często cytowany termin do 5 dni nie dotyczy tożsamości, tylko weryfikacji płatności i banku. Bez ukończonej weryfikacji nie opublikujesz, więc zacznij wcześnie.
Czym jest Android Developer Verification i kiedy startuje?
To osobna, ekosystemowa warstwa, oddzielna od otwarcia konta Play Console i od testu zamkniętego, która wymaga, by aplikacje były powiązane ze zweryfikowaną tożsamością dewelopera, żeby dało się je zainstalować na certyfikowanych urządzeniach Android, także poza Google Play. Otworzyła się w marcu 2026 dla wszystkich deweloperów; egzekwowanie zaczyna się 30 września 2026 r. w Brazylii, Indonezji, Singapurze i Tajlandii i rozszerza się globalnie w 2027. Bezpłatne konto Limited Distribution pozwala wysyłać na do 20 urządzeń bez opłaty i bez oficjalnego dokumentu tożsamości.
Czy nowi deweloperzy naprawdę potrzebują 12 testerów przez 14 dni?
Tak, jeśli używasz osobistego konta dewelopera założonego po 13 listopada 2023 r. Musisz przeprowadzić test zamknięty z co najmniej 12 testerami, którzy dołączyli do testu nieprzerwanie przez ostatnie 14 kolejnych dni, zanim poprosisz o dostęp do wersji produkcyjnej. Konta organizacji i konta sprzed tej daty są zwolnione. Wymaganie spadło 11 grudnia 2024 r. z 20 do 12 testerów.
Jakiego poziomu target API potrzebują nowe aplikacje w Google Play w 2026 r.?
W połowie 2026 r. dolnym minimum jest Android 15 (API level 35) dla nowych aplikacji i aktualizacji; Wear OS, Android TV i Android Automotive leżą na Android 14 (API 34). Od 31 sierpnia 2026 r. nowe aplikacje i aktualizacje muszą celować w Android 16 (API level 36) lub wyżej. Nowe aplikacje muszą też być publikowane jako Android App Bundle (.aab) z Play App Signing.
Jakie są wymagania ikony i zrzutów ekranu w Google Play?
Ikona aplikacji to 512 na 512 px, 32-bit PNG z Alpha, do 1 MB; w 2026 r. Google renderuje ikony jako pełny kwadrat i stosuje dynamiczny promień narożnika 30%, trzymaj kluczowe elementy w safe zone około 15 do 18 procent. Feature Graphic to 1024 na 500 px. Do publikacji potrzebujesz co najmniej 2 zrzutów telefonu (do 8 na typ urządzenia); 4 lub więcej od 1080px to wskazówka kwalifikacji do featuringu, nie twarda bramka publikacji.
Jak długo trwa opublikowanie aplikacji w Google Play od zera?
Realistyczny harmonogram end-to-end dla zupełnie nowego osobistego konta często wynosi 3 do 5 tygodni lub więcej: weryfikacja tożsamości (kilka dni), budowa aplikacji oraz wypełnienie listingu i deklaracji, obowiązkowy 14-dniowy test zamknięty, weryfikacja dostępu do wersji produkcyjnej (zwykle do siedmiu dni) i finalna weryfikacja aplikacji (do 7 dni). Fazy mogą iść równolegle; odrzucenie może wydłużyć całość.
Czym jest kwestionariusz dostępu do wersji produkcyjnej w Google Play?
Gdy spełnisz kryteria testu zamkniętego, klikasz Poproś o opublikowanie wersji produkcyjnej i odpowiadasz na pytania w trzech sekcjach: o teście zamkniętym (rekrutacja i zaangażowanie), o aplikacji lub grze (funkcja i oczekiwane instalacje) oraz o gotowości produkcyjnej (jakie zmiany wprowadzono i dlaczego aplikacja jest gotowa). Weryfikacja zwykle trwa do siedmiu dni. Lepiej niż „formularz 10 pytań”: trzy sekcje, bez stałej liczby pytań.
Dlaczego aplikacje debiutantów są najczęściej odrzucane?
Najczęstsze problemy przy pierwszym razie: niekompletna lub wolna weryfikacja tożsamości, słabe lub brakujące dane Data Safety, nieważne loginy reviewera w App Access, store listing lub zrzuty, które nie pasują do prawdziwej aplikacji, wolna rekrutacja testerów lub niskie zaangażowanie w teście zamkniętym oraz ogólnikowe odpowiedzi o dostępie do wersji produkcyjnej.
Czy PrimeTestLab może pomóc spełnić wymaganie testu zamkniętego?
Tak. PrimeTestLab dostarcza zweryfikowanych testerów, którzy dołączyli do testu na prawdziwych urządzeniach Android i zostają aktywni przez pełne 14 kolejnych dni. To jedyny krok, którego osobiste konto nie pominie. Ceny od $19.99 za 12 testerów, start testu zwykle w 4-6 godzin, skuteczność 99.9% na ponad 7 400 aplikacjach. Do ceny dolicza się 5% opłaty serwisowej. Jeśli dostęp do wersji produkcyjnej nadal nie zostanie przyznany, wybierasz: bezpłatny ponowny test lub pełny zwrot.
Podsumowanie
Najważniejsze
Publikacja pierwszej aplikacji Android w 2026 r. to sekwencja: założenie konta (25 USD jednorazowo), weryfikacja tożsamości, podpisany AAB z API 35 dziś (API 36 od 31 sie. 2026), wypełnienie listingu i deklaracji App content oraz, przy osobistym koncie, 14-dniowy test zamknięty z 12 testerami przed kwestionariuszem i finalną weryfikacją. Zaplanuj 3 do 5+ tygodni, najpierw uruchom wolne kroki (tożsamość, D-U-N-S, test zamknięty) i trzymaj na radarze dwie zmiany 2026: API 36 oraz Android Developer Verification. Jedyny krok, którego nie dźwigniesz sam, to test zamknięty: dokładnie to bierze na siebie PrimeTestLab, żeby testowanie nigdy nie było Twoim wąskim gardłem. Zobacz plany cenowe →
Oficjalna dokumentacja Google