Google Play: 12 testerów przez 14 dni — jak opublikować aplikację na Androida w 2026

Aktualizacja z 1 października 2026: test zamknięty dobiegł końca i Council jest już dostępny w Google Play.

A tak to wygląda naprawdę: Council w Google Play w chwili, gdy piszę ten tekst.

Aplikacja jest zbudowana, podpisana, sprawdzona, zatwierdzona i działa na torze zamkniętym w 177 krajach. Przycisk, który pozwoliłby ją opublikować, jest szary i pozostanie szary jeszcze co najmniej przez dwa tygodnie. Dołączyło dziesięciu testerów. Potrzebuję dwunastu, a wtedy dwutygodniowy zegar ruszy od zera.

Ta sama aplikacja jest w App Store od miesięcy. Proces Apple wyglądał tak: wgraj, uzupełnij metadane, poczekaj na recenzję, wydaj. Proces Google dla konta takiego jak moje to zupełnie inna kategoria zjawiska — i prawie żadna z trudności nie leży tam, gdzie deweloper spodziewa się trudności.

Mur przed murem

26 sierpnia zacząłem od prostego pytania: na czym właściwie stoimy z Androidem? Odpowiedź brzmiała: nie mogę utworzyć aplikacji. Nie „aplikację odrzucono” — w Play Console nie było w ogóle wpisu o aplikacji, a przycisk „Create app” był zamknięty kłódką z podpisem „Complete account verifications to create new apps”.

Dwa otwarte zadania, połączone łańcuchem:

1. Potwierdź, że masz dostęp do urządzenia mobilnego z Androidem. Trzeba zalogować się do mobilnej aplikacji Play Console na prawdziwym sprzęcie.
2. Potwierdź kontaktowy numer telefonu — to odblokowuje się dopiero po zadaniu pierwszym i po zatwierdzeniu przez Google dokumentów tożsamości.

Ciekawsze jest pierwsze. Wymaga fizycznego urządzenia bez roota na Androidzie 10 lub nowszym, a aplikacja Play Console sprawdza integralność urządzenia, więc emulatory nie przechodzą. Nie miałem urządzenia z Androidem: pracuję na Macu i wydaję na iPhone’a.

Nie ma sprytnego obejścia. Chmurowe farmy urządzeń oznaczają wpisywanie hasła do konta Google na wynajętym sprzęcie. Pożyczony telefon załatwia bramkę w niecałą minutę, ale zostawia cię w sytuacji, w której wydajesz build Androida nigdy nieuruchomiony na Androidzie. Czyli: kup tani używany telefon u normalnego sprzedawcy, żeby był certyfikowany przez Play Protect i nie miał własnego ROM-u. To cała odpowiedź — i kosztuje mniej więcej tydzień kalendarza, zanim napiszesz pierwszą linijkę kodu specyficznego dla Androida.

Objazd, który wygląda jak skrót

Wyjątek istnieje. Konta organizacyjne omijają zarówno weryfikację urządzenia, jak i wymóg testu zamkniętego opisany niżej. Mam zarejestrowaną w Polsce JDG, więc poświęciłem na ten trop jeden wieczór.

Zaprowadził dalej, niż się spodziewałem — firma faktycznie ma wpis w Dun & Bradstreet, a właśnie tego potrzebuje konto organizacyjne. Potem dogoniły mnie szczegóły:

• To nowe konto, a nie konwersja. Google nie zmienia konta osobistego w organizacyjne. Rejestrujesz drugie konto dewelopera, weryfikujesz je i przenosisz aplikację.
• Weryfikacja wymaga, by nazwa prawna zgadzała się z D&B dokładnie. Moja jest zarejestrowana na moje własne imię i nazwisko, a nie na nazwę handlową, której faktycznie używam.
• Zasady Google wykluczają „DBA, fikcyjne firmy, nazwy handlowe”, a w społeczności regularnie pojawiają się relacje o jednoosobowych działalnościach odsyłanych z powrotem na konto osobiste.

Bilans: mniej więcej ten sam czas kalendarzowy co zwykłe przeprowadzenie testu zamkniętego, plus realne ryzyko odmowy na końcu. Zakładanie firmy po to, żeby ominąć czternastodniowy licznik, to myślenie na opak. Jeśli zakładasz firmę, rób to dla odpowiedzialności albo podatków. Odpuściłem i kupiłem telefon.

Build był łatwą częścią i i tak nie był łatwy

Weryfikacja przeszła 2 września. Tego samego wieczoru utworzyłem aplikację i uruchomiłem pierwszy produkcyjny build na Androida. Mobilny Council jest w Expo, więc to jedna komenda.

Czterdzieści minut stał w kolejce na darmowym planie EAS, dwadzieścia dwie się kompilował, a potem zawiesił się na fazie configure w Gradle. Pierwszy build na Androida, więc nic nie było w cache: RevenueCat, PostHog, Google Sign-In i Hermes kompilowały się od zera na współdzielonym workerze, w kolejce za wszystkimi płatnymi buildami. Anulowałem go i zbudowałem lokalnie, co zajęło jakieś dwadzieścia pięć minut — i tak powstaje od tamtej pory każdy Android build Council. RevenueCat, warstwa subskrypcji z tej listy, ma teraz osobny krótki wpis o konfiguracji.

Potem Play Console zażądała reszty, a reszta to nie jedna wielka przeszkoda, lecz długi ogon formularzy: dziewięć deklaracji o zawartości aplikacji (polityka prywatności, reklamy, klasyfikacja treści, grupa docelowa, bezpieczeństwo danych, identyfikator reklamowy, aplikacje rządowe, funkcje finansowe, zdrowie), wpis w sklepie, grafika promocyjna 1024×500 i zrzuty ekranu wygenerowane od nowa pod proporcje Play, bo kadry z iOS nie pasują. Jedenaście z jedenastu zadań konfiguracyjnych, wszystko w jeden wieczór.

Przypis dla tych, którzy to automatyzują: gotowy AAB waży 78 MB, a narzędzia automatyzacji przeglądarki ograniczają wysyłkę plików do 10 MB. Każde wydanie Council wymagało, żebym osobiście przeciągnął plik z pulpitu do okna Chrome. To jedyny krok w całym procesie, którego żadne narzędzia nie usunęły.

Sama bramka

Testy wewnętrzne opublikowały się natychmiast. Produkcja była szara, a wymagania wypisane wprost:

Wymaganie	Szczegóły
Opublikować wydanie testu zamkniętego	Przechodzi pełną recenzję zasad, w odróżnieniu od testów wewnętrznych
Co najmniej 12 testerów, którzy dołączyli	Jednocześnie, na prawdziwych kontach Google
Prowadzić test zamknięty przez 14 dni z rzędu	Spadek licznika poniżej 12 przerywa odliczanie
Zgłosić się do produkcji	Ankieta o twoim teście zamkniętym, potem weryfikacja

Dotyczy to kont osobistych założonych 13 listopada 2023 roku lub później. Moje jest jednym z nich.

Rzecz warta zapamiętania: zegar mierzy dołączenia, nie buildy. Wydałem trzy wydania na torze zamkniętym w trzy dni, podczas gdy licznik stał w miejscu, i żadne z nich niczego nie zresetowało. Liczy się jedna liczba: ilu ludzi ma teraz twoją aplikację zainstalowaną na koncie Google, które dołączyło do testu.

Skąd naprawdę bierze się dwunastu testerów

Zacząłem tak, jak zaczynają wszyscy: zapytałem znajomych. Wyszły cztery adresy Gmail, w tym mój. Potem dowiedziałem się, że link do dołączenia — ten, który Play Console daje ci do udostępniania — działa wyłącznie dla osób już wpisanych na twoją listę testerów. Wszyscy inni dostają błąd. Czyli droga zawsze ma dwa kroki: ty dodajesz człowieka, potem on klika. A to znaczy, że rekrutacja przez link nie działa w ogóle.

Lekarstwem jest przełączenie toru z listy adresów na Google Group — a gdy już to wiesz, znajdujesz to, co ta zasada naprawdę zbudowała. Istnieje ekosystem grup na Telegramie, za którymi stoją grupy Google, gdzie deweloperzy zablokowani dokładnie na tej bramce instalują sobie nawzajem aplikacje. Dołączasz do grupy, zapisujesz się na cudze testy zamknięte, oni zapisują się na twój. Mój tor wskazuje teraz Google Group z kilkuset osobami, a droga od czterech testerów do dziesięciu to wiadomość po rosyjsku na kanale Telegrama z obietnicą rewanżu.

Rewanż to prawdziwa praca i odrobiłem ją: dołączyłem do czterech kolejnych grup Google, zapisałem się na osiem testów zamkniętych, pięć z nich zainstalowałem na emulatorze Pixela i każdy otworzyłem. (Trzy z ośmiu używają prywatnych list adresowych, więc tam nie dało się wejść.) Emulator z obrazem Play w zupełności do tego wystarcza — fizycznego sprzętu wymaga wyłącznie weryfikacja konta dewelopera.

Chcę tu uważnie dobrać słowa. Deklarowanym celem Google jest, by prawdziwi ludzie faktycznie używali aplikacji, zanim trafi ona do wszystkich, a we wniosku produkcyjnym pytają cię, jak poszedł test. W praktyce zasada wytworzyła rynek wymiany liczników: tuzin nieznajomych instaluje twoją aplikację, bo ty zainstalowałeś ich. To nie oszustwo i nikt niczego nie podrabia — instalacje są prawdziwe, konta są prawdziwe. Ale to też nie są testy z użytkownikami.

Przepaść między „Jesteś testerem” a zainstalowaną aplikacją

Załóż, że każdy tester trafi na co najmniej jedną z tych rzeczy, bo moi trafili:

• Tor korzysta albo z listy adresów, albo z Google Group, nigdy z obu naraz. W chwili przełączenia na grupę czworo moich znajomych przestało się kwalifikować, dopóki też do niej nie dołączyli.
• Wbudowana przeglądarka Telegrama jest zalogowana na inne konto Google niż Sklep Play na telefonie. Tester dołącza skutecznie — tylko nie na tym koncie. To była najczęstsza awaria.
• „Item not found” przez godzinę po dołączeniu to norma. Wygląda jak twarda porażka, a to zwykła propagacja. Wysyłaj ludziom link do wpisu w Sklepie Play, a nie webowy link do dołączenia: otwiera się w aplikacji Play na właściwym koncie i pokazuje kartę dołączenia.
• Play Console nigdy nie mówi, kto dołączył. Tylko ile osób. Skończyło się na tym, że odpytywałem własną tabelę autoryzacji w Supabase, żeby ustalić, którzy testerzy naprawdę się zalogowali.

Część, która broni tej zasady

Oto uczciwa przeciwwaga dla wszystkiego powyżej. Test zamknięty znalazł trzy błędy, wszystkie trzy specyficzne dla Androida, i żaden nie ujawniłby się ani na iOS, ani na moim komputerze:

Logowanie Google było zepsute na każdej instalacji z Play. Play App Signing podpisuje bundle kluczem Google, a nie twoim kluczem przesyłania, więc odcisk SHA-1 w moim kliencie OAuth dla Androida nie pasował do niczego. Aplikacja działała bez zarzutu, gdy instalowałem ją bezpośrednio, i padała każdemu, kto pobrał ją ze sklepu.

Pierwsze uruchomienie u każdego testera pokazywało błąd płatności. Aplikacja otwiera paywall przy pierwszym starcie; paywall poprosił Sklep Play o produkty; produktów nie było, bo subskrypcje w Play wymagają konta sprzedawcy, którego nie założyłem. Dowiedziałem się o tym ze zrzutu ekranu od testera. Z tego wyszło całe popołudnie: profil płatności, subskrypcja, siedmiodniowy trial, dane uwierzytelniające konta usługi i powiadomienia w czasie rzeczywistym — wszystko to, co inaczej odkryłbym w dniu premiery.

Wyścig przy logowaniu. Android dostarcza przekierowanie OAuth dwa razy: jako wynik przeglądarki i jako deep link. Oba handlery uruchomiły wymianę tokenu w odstępie około 50 ms; drugi zderzył się z ograniczeniem unikalności i zwrócił 500. Użytkownik zobaczył „Logowanie nie zostało ukończone”, będąc w rzeczywistości zalogowanym. To wyścig, więc trafił jednego testera, a poprzedniego nie.

Trzy prawdziwe błędy, od dziesięciu testerów, w trzy dni. Wszystkie trzy bym wydał. Cokolwiek myślę o tym, jak zasada dwunastu testerów działa w praktyce, wyłapała to, czego ja nie wyłapałem.

Co powiedziałbym sobie z 26 sierpnia

1. Najpierw kup telefon z Androidem. Cała reszta jest tego konsekwencją, łącznie z terminami.
2. Odpuść wyjątek dla konta organizacyjnego, chyba że masz już firmę zgadzającą się co do znaku z wpisem w D&B.
3. Utwórz wpis aplikacji tego samego dnia, w którym przejdzie weryfikacja, nawet jeśli nie masz jeszcze czego wgrać. Test zamknięty nie ruszy, dopóki wpisu nie ma.
4. Ustaw na torze Google Group od samego początku, nie listę adresów. Przełączanie później oznacza zapraszanie wszystkich od nowa.
5. Załóż konto sprzedawcy i produkty w sklepie zanim zainstaluje aplikację pierwszy tester, a nie po.
6. Rekrutuj, zanim będziesz gotowy. Dojście do dwunastu to najdłuższy odcinek i jest w całości społeczny, nie techniczny.
7. Spokojnie poprawiaj błędy w trakcie testu. Wydania nie resetują zegara; resetują go testerzy, którzy odinstalowują aplikację.

Build, wpis w sklepie, deklaracje, subskrypcje i trzy poprawki zajęły jakieś sześć godzin realnej pracy rozłożonej na cztery wieczory, w większości prowadzonej z terminala tym samym zestawem, którego używam do wszystkiego innego. Namówienie dwunastu osób, żeby nie odinstalowywały aplikacji przez dwa tygodnie, to część, która nie ma żadnego rozwiązania inżynierskiego.

Dwunastu testerów i czternaście dni później Council jest dostępny w Google Play.