Weryfikacja dewelopera Androida 2026: terminy i kroki

Prawie wszystko, co napisano o weryfikacji dewelopera Androida w 2025 roku, jest dziś błędne w co najmniej jednym ważnym miejscu, a zaskakująco duża część tekstów z początku 2026 roku też. Konstrukcja programu zmieniła się po pierwotnym ogłoszeniu, dokładna data egzekwowania pojawiła się dopiero w czerwcu 2026 r., a zakres zawężono na piśmie 22 lipca 2026 r. Tymczasem pytanie, które deweloperzy naprawdę wpisują w wyszukiwarkę, nie brzmi "czym jest weryfikacja dewelopera?". Brzmi ono: Google mówi, że mi się nie udało, co dokładnie jest nie tak, co teraz się dzieje i czy ja już tego przypadkiem nie zrobiłem?

Dlatego ten wpis napisano jak reagowanie na incydent, a nie jak komentarz do polityki platformy. Najpierw odpowiada na pytanie "czy już mam to z głowy?", daje dokładną nawigację w Play Console zamiast ogólników, rozdziela dwie warstwy egzekwowania, które każda inna strona skleja w jedno straszne zdanie, i mówi wprost, gdzie Google nie opublikował niczego. Stawia też twardą granicę między weryfikacją a osobną zasadą 12 testerów w teście zamkniętym (closed testing), bo to pomylenie trafia do skrzynki PrimeTestLab niemal co tydzień. Każdą datę i liczbę poniżej sprawdzono na stronach samego Google 9 sierpnia 2026 r.

Weryfikacja dewelopera Androida to dwa zadania, nie jedno

Jeśli publikujesz w Google Play, weryfikacja dewelopera Androida wymaga od Ciebie dwóch osobnych rzeczy: potwierdzenia tożsamości i zarejestrowania nazw pakietów Twoich aplikacji. Większość obecnych deweloperów Play ma pierwsze już za sobą, a w zdecydowanej większości przypadków drugie wydarzyło się automatycznie. Dla wielu kont cała pozostała praca to sprawdzenie dwóch ekranów, choć Google nie publikuje żadnego uniwersalnego czasu realizacji, a problem z dokumentem albo z kontem potrafi zająć znacznie dłużej.

Co tak naprawdę ustala każda z bram

Te dwa zadania odpowiadają na dwa różne pytania, a przejście jednego nie mówi Google nic o drugim. Trzymanie ich osobno to najbardziej wartościowa rzecz, jaką możesz zrobić z tą stroną, bo tryby awarii, sposoby naprawy, a nawet ekrany Play Console są inne.

Konto może więc mieć w pełni potwierdzoną tożsamość i wciąż mieć niezarejestrowany pakiet leżący spokojnie na liście. To dokładnie ta kombinacja, która psuje się na terminie, bo deweloper sprawdził ekran mówiący "zweryfikowano" i nigdy nie otworzył ekranu z listą aplikacji.

Jednominutowa odpowiedź dla deweloperów już obecnych w Play Console

Jeśli publikujesz już w Google Play, oto cała ścieżka zgodności w kolejności, w jakiej należy ją sprawdzać. Większość czytelników kończy na kroku drugim.

1. 01

   Potwierdź status swojej tożsamości

   Otwórz Konto dewelopera w Play Console. Przewodnik Google po weryfikacji opisuje to jako Ustawienia › Konto dewelopera, a nowsza dokumentacja zarządzania kontem używa formy Konto dewelopera › Informacje o Tobie. Tak czy inaczej Google mówi, że jeśli pomyślnie przeszedłeś już potwierdzenie tożsamości, nie będziesz musiał robić tego kroku ponownie. Zweryfikowane

2. 02

   Potwierdź, że każdy pakiet jest zarejestrowany

   Otwórz stronę weryfikacji dewelopera Androida w Play Console i sprawdź stan rejestracji każdej aplikacji. Strona główna Play Console również może pokazywać informacje o rejestracji aplikacji. Jeśli wszystkie Twoje nazwy pakietów zarejestrowały się automatycznie, Google mówi, że dla tych aplikacji nie jest potrzebne już żadne działanie rejestracyjne. Zweryfikowane

3. 03

   Zgłoś resztę przed 30 września

   Dla pakietu, który nie zarejestrował się automatycznie, wykonaj ręczną rejestrację według Google. Jej postać zależy od nazwy pakietu: nazwa, której Android nigdy nie widział, wymaga tylko danych pakietu i twojego publicznego certyfikatu podpisywania, a nazwa, która ma już instalacje, wymaga podpisanego weryfikacyjnego pliku APK dowodzącego, że masz klucz prywatny. Obie procedury są w sekcji 05.

Jeśli publikujesz w Google Play, używaj Play Console

To pułapka, która wysyła deweloperów na godzinne objazdy. W tym programie są dwie konsole. Play Console to miejsce, w którym deweloperzy Google Play wykonują oba zadania. Android Developer Console to osobna powierzchnia dla deweloperów dystrybuujących poza Google Play, a jej strony pomocy opisują inny przebieg, w tym weryfikację witryny organizacji przez Google Search Console. Oba zestawy instrukcji pojawiają się w wynikach na te same zapytania.

Cztery ścieżki dystrybucji, cztery odpowiedzi. Znajdź swój wiersz, zanim przeczytasz kolejne słowo dokumentacji Google, bo zły wiersz kosztuje całe popołudnie:

Przypisanie ścieżek z przewodnika weryfikacji dla Play Console i przewodnika dystrybucji ograniczonej Google, sprawdzone 13 sierpnia 2026 r. Zweryfikowane

Kalendarium weryfikacji z 2026 roku i ta jedna data, którą artykuły wciąż podają źle

Weryfikacja nie przyszła w jednym ogłoszeniu. Przyszła w pięciu, a każde kolejne zawężało albo poprawiało poprzednie. Kalendarium poniżej bierze za źródło rozstrzygające materiały samego Google z czerwca i lipca 2026 r., co ma znaczenie, bo szeroko cytowana prognoza z marca została zastąpiona.

Jak program naprawdę się pojawiał, kamień milowy po kamieniu

Każdy wpis zestawia to, co Google opublikował, z tym, co deweloper Play powinien z tego wziąć, bo kilka z tych dat cytuje się gdzie indziej w oderwaniu, a w widocznej sekwencji czytają się zupełnie inaczej.

1. listopad 2025 r.

   Otwarcie wczesnego dostępu

   Deweloperzy zaproszeni do wczesnego dostępu mogli zacząć weryfikować aplikacje dystrybuowane poza Google Play.

   Co z tego wynika: tylko kamień milowy historyczny. Nic tutaj nie tworzy dziś obowiązku dla dewelopera Play.

2. 30 marca 2026 r.

   Start wdrożenia dla wszystkich deweloperów

   Google ogłosił, że zaczyna udostępniać weryfikację dewelopera Androida wszystkim deweloperom, zarówno w Play Console, jak i w Android Developer Console, i powiedział deweloperom Play, żeby wypatrywali dostępu w ciągu kolejnych kilku tygodni. Zweryfikowane

   Co z tego wynika: nie czytaj tego jako "każde konto Play dostało weryfikację 30 marca". Sam Google napisał, że wdrożenie ruszyło tamtego dnia.

3. czerwiec 2026 r.

   Wdrożenie usługi systemowej Android Developer Verifier

   Zaktualizowane kalendarium Google umieszcza wdrożenie tej usługi systemowej w czerwcu 2026 r. Zweryfikowane

   Co z tego wynika: używaj czerwca. Wpis blogowy z 30 marca zapowiadał kwiecień, a kilka bieżących artykułów zewnętrznych wciąż powtarza tę zapowiedź, jakby była historią.

4. 18 czerwca 2026 r.

   Pojawia się dokładna data egzekwowania

   Google ogłosił 30 września 2026 r. jako pierwszy termin egzekwowania, wymienił siedem sklepów uczestniczących w programie i podał, że ponad 99% aplikacji deweloperów Play zostało już zarejestrowanych. Zweryfikowane

   Co z tego wynika: to najmocniejsze pojedyncze źródło zarówno dla daty, jak i dla liczby o automatycznej rejestracji. Wszystko opublikowane wcześniej zgaduje datę.

5. lipiec 2026 r.

   Narzędzia: ID Status API i Console API

   Android Developer ID Status API zostało udostępnione globalnie, a Console API i dystrybucja ograniczona weszły do wczesnego dostępu.

   Co z tego wynika: to sprawa dla zespołów od automatyzacji i narzędzi, nie dla osoby publikującej po raz pierwszy i przechodzącej Play Console ręcznie.

6. 15 lipca 2026 r.

   Publikacja obecnych przewodników

   Ogólny przewodnik Google po weryfikacji i przewodnik dla Play Console zostały zaktualizowane, razem z początkowym zakresem sklepów i instrukcją rejestrowania pakietów Play. Zweryfikowane

   Co z tego wynika: traktuj te dwie strony jako obowiązującą bieżącą dokumentację we wszystkim, co operacyjne.

7. 22 lipca 2026 r.

   FAQ zawęża zakres na piśmie

   FAQ Google wyjaśniło, że sklepy spoza listy uczestników i bezpośrednia instalacja plików APK nie podlegają etapowi z 30 września. Zweryfikowane

   Co z tego wynika: to zdanie, które odsyła do lamusa narrację z 2025 roku o tym, że "Google kończy z instalacją bezpośrednią tego dnia". To ograniczenie pierwszego etapu, nie trwałe wyłączenie.

8. sierpień 2026 r.

   Zaplanowane na globalną dostępność: dystrybucja ograniczona i procedura zaawansowana

   Strona weryfikacji Google wymienia konta dystrybucji ograniczonej, API Android Developer Console i zaawansowaną procedurę instalacji jako premiery z sierpnia 2026 r. Na 13 sierpnia 2026 r. jej własny przewodnik po dystrybucji ograniczonej wciąż mówi, że zapisy do wczesnego dostępu są zamknięte, a więcej informacji pojawi się w sierpniu 2026 r., więc ten wiersz narysowano jako zaplanowany, a nie dostarczony. Częściowe, start niepotwierdzony

   Co z tego wynika: to najszybciej zmieniający się punkt na tej stronie, a wejście kalendarza w sierpień nie jest dowodem, że coś wyszło. Sprawdź stronę weryfikacji Google, zamiast ufać jakiemukolwiek tekstowi opublikowanemu w połowie miesiąca, łącznie z tym.

9. 30 września 2026 r.

   Tego samego dnia dzieją się dwie rzeczy

   Rejestracja aplikacji staje się wymagana przy instalacjach przez siedem sklepów uczestniczących w programie w Brazylii, Indonezji, Singapurze i Tajlandii. Osobno, zgodnie z wymaganiami Play Console, wszystkie pakiety Play muszą być zarejestrowane, a Google mówi, że aplikacje niezarejestrowane zostaną usunięte z Google Play. Zweryfikowane

   Co z tego wynika: jedna data, dwie niezależne konsekwencje. Sekcja 03 rozdziela je jak trzeba.

10. 2027 rok i dalej

    Rozszerzenie globalne, data nieogłoszona

    Google mówi, że zabezpieczenia rozszerzą się globalnie w 2027 roku. Na 9 sierpnia 2026 r. nie ogłoszono dokładnej daty światowej ani dalszego harmonogramu krajów. Zweryfikowane

    Co z tego wynika: każdy termin "1 stycznia 2027 r." albo "na początku 2027 r.", który czytasz gdzie indziej, traktuj jako przewidywanie. Google żadnego nie opublikował.

Czy 30 września 2026 r. to termin ogólnoświatowy?

Nie dla egzekwowania na poziomie urządzenia z Androidem, a tak dla terminu rejestracji pakietów w Google Play. To dwie różne zasady, które przypadkiem mają wspólną datę, a niemal każdy artykuł o tym programie je zlepia. Zasada na poziomie urządzenia startuje w czterech krajach przez siedem sklepów. Zasada Play dotyczy Twojego wpisu w Play, a konsekwencję jej przegapienia Google opisuje jako globalne usunięcie z Google Play.

Cztery kraje i siedem sklepów

Google podaje obie listy dokładnie, więc nie trzeba tu niczego interpretować. Pierwszy etap egzekwowania obejmuje instalacje aplikacji w tych czterech krajach:

I dotyczy instalacji przez te siedem sklepów uczestniczących w programie:

Obie listy zacytowano z ogłoszenia Google z 18 czerwca 2026 r. i z przewodnika po weryfikacji z 15 lipca 2026 r., sprawdzonych 9 sierpnia 2026 r. Google może dodać sklepy albo regiony, więc sprawdź źródło ponownie, zanim zadziałasz na podstawie tej listy blisko terminu.

Czy 30 września dotyczy Ciebie? Rozstrzygnij własną drogę

Odpowiedz na dwa pytania, a narzędzie poniżej nałoży obie warstwy na Twoją konkretną drogę dystrybucji. Jest celowo bezpośrednie w przypadkach, w których odpowiedź Google brzmi "jeszcze nie", bo "jeszcze nie" to nie to samo co "nigdy".

Jak sprawdzić, czy już masz weryfikację

Całe pytanie zamykają dwa ekrany. Konto dewelopera niesie Twoje dane tożsamości i informacje o koncie. Strona weryfikacji dewelopera Androida niesie stan rejestracji każdej aplikacji. Jeśli otwierasz tylko ten pierwszy, możesz uznać, że przeszedłeś kontrolę, której faktycznie nie przeszedłeś.

Cztery miejsca, w których może pojawić się status

Od statusu do działania, bez wymyślania etykiet

Google publikuje, gdzie patrzeć i co zrobić. Nie publikuje wyczerpującego słownika etykiet statusu tożsamości w Play, więc ten wpis takiego słownika nie wymyśla. Tabela poniżej jest ułożona według tego, co sprawdzasz i jak wygląda zrobione, czyli według tej części, którą Google faktycznie dokumentuje.

Nawigacja i definicje "zrobione" pochodzą z pomocy Play Console odpowiedź 16984799, z przewodnika Google po weryfikacji w Play Console i ze strony pomocy o informacjach konta dewelopera; wiersz o teście zamkniętym z pomocy Play Console odpowiedź 14151465. Wszystko sprawdzone 9 sierpnia 2026 r. Pozycje nawigacji podano po polsku, bo Play Console jest faktycznie lokalizowane: Twoja konsola może pokazywać nieco inne brzmienie, a strony Google używają obecnie dwóch różnych sformułowań dla ścieżki tożsamości. Nawigacja Play Console często się zmienia, więc traktuj każdą ścieżkę tutaj jako aktualną na dziś, a nie na zawsze.

Co naprawdę znaczy "zarejestrowany automatycznie"

Automatyczna rejestracja dotyczy jednej wąskiej relacji: powiązania między nazwą pakietu aplikacji a danymi podpisywania, które dowodzą, kto ją kontroluje. Google mówi, że kwalifikujące się aplikacje korzystające z Play App Signing są objęte procesem automatycznej rejestracji, bo Google ma już potrzebne informacje o własności i o podpisywaniu.

Jeśli wszystkie Twoje nazwy pakietów zarejestrowały się automatycznie, Google mówi, że dla odpowiadających im aplikacji Play nie jest potrzebne już żadne działanie rejestracyjne. To zdanie robi dokładnie tyle, ile mówi, i ani trochę więcej.

Przy tym ostatnim punkcie warto się zatrzymać. Rejestracja liczy się per pakiet, więc konto z sześcioma aplikacjami może mieć zrobione cztery szóste i nie pokazywać nic niepokojącego nigdzie poza tą jedną stroną, która je wylicza. Google ujmuje też weryfikację jako potwierdzenie tego, kim jest deweloper, i opisuje ją jako oddzieloną od kontroli bezpieczeństwa stosowanej wobec treści aplikacji, więc nic tutaj nie mówi o tym, czy Twoja aplikacja jest zgodna z zasadami Play.

Co zrobić, gdy aplikacja nie zarejestrowała się automatycznie

Ręczna rejestracja ma dwie postacie, a to, która ciebie dotyczy, zależy od nazwy pakietu, nie od ciebie. Dla nazwy pakietu, której Android nigdy nie widział, podajesz dane pakietu i certyfikat publiczny swojego klucza podpisywania. Dla nazwy pakietu, która ma już instalacje, dodatkowo dowodzisz, że masz odpowiadający jej klucz prywatny, wysyłając plik APK zawierający ciąg znaków otrzymany od Google. Tylko drugi przypadek wymaga podpisanego weryfikacyjnego pliku APK, a żaden z nich nie wymaga twojego prawdziwego produkcyjnego pliku APK.

Najpierw ustal, w którym przypadku jesteś

Pięć wierszy, a dziś należysz dokładnie do jednego z nich. Pomyłka tutaj to najdroższy błąd tej sekcji, bo ścieżka z weryfikacyjnym plikiem APK to praca w środowisku kompilacji, a trzy z tych wierszy w ogóle jej nie potrzebują.

Podział przypadków z pomocy Play Console, "Registering Android package names" (odpowiedź 16761053), sprawdzone 13 sierpnia 2026 r. Zweryfikowane

A. Rejestracja nowej nazwy pakietu

Krótka ścieżka. Wszystko dzieje się w Play Console, nic nie zbliża się do twojego środowiska kompilacji i nie ma żadnego pliku APK do zbudowania.

1. 01

   Otwórz stronę Weryfikacja dewelopera Androida

   W Play Console otwórz stronę Weryfikacja dewelopera Androida i przejrzyj stan rejestracji każdej nazwy pakietu na koncie. Strona główna Play Console również może pokazywać informacje o rejestracji aplikacji.

2. 02

   Wybierz Zarejestruj nazwę pakietu

   To rozpoczyna nową rejestrację, a nie zgłoszenie praw do nazwy, która już istnieje.

3. 03

   Wpisz nazwę pakietu i nazwę przyjazną

   Nazwa przyjazna to wewnętrzna etykieta na twojej własnej liście. To nie jest to, co użytkownicy widzą na stronie aplikacji w sklepie.

4. 04

   Wybierz Dodaj klucz

   Tu zaczyna się powiązanie między kluczem podpisywania, który kontrolujesz, a rejestrowaną nazwą pakietu.

5. 05

   Podaj publiczny certyfikat podpisywania

   Przekaż certyfikat publiczny z pary kluczy podpisywania twojej aplikacji. Ponieważ Android nigdy nie widział tej nazwy pakietu, certyfikat to wszystko, czego Google potrzebuje. Twój klucz prywatny nigdy nie opuszcza twojego komputera.

6. 06

   Wyślij i poczekaj na potwierdzenie

   Google wysyła e-mail, gdy nazwa pakietu zostanie pomyślnie zarejestrowana, a zaktualizowany stan staje się widoczny w Play Console.

B. Rejestracja istniejącej nazwy pakietu

To dłuższa ścieżka i ta, którą każdy artykuł opisuje tak, jakby była jedyna. Dotyczy sytuacji, gdy nazwa pakietu ma już instalacje na Androidzie, bo wtedy Google nie wierzy ci na słowo: musisz wykazać kontrolę nad kluczem prywatnym. Dwa z tych kroków dzieją się poza Play Console, więc miej wcześniej otwarte środowisko kompilacji.

1. 01

   Wpisz dane pakietu

   Na stronie Weryfikacja dewelopera Androida rozpocznij rejestrację nazwy pakietu, do której zgłaszasz prawa.

2. 02

   Otwórz Wybierz klucz

   Google proponuje certyfikaty, które uznaje za kwalifikujące się dla tej nazwy pakietu, na podstawie danych o instalacjach.

3. 03

   Wybierz kwalifikujący się odcisk certyfikatu publicznego

   Weź odcisk klucza, który faktycznie masz. Jeśli nic kwalifikującego się się nie pojawi, zatrzymaj się tutaj i przeczytaj reguły kwalifikowalności poniżej, zanim spróbujesz czegokolwiek innego.

4. 04

   Rozpocznij procedurę własności i skopiuj ciąg znaków od Google

   Google generuje unikalny ciąg znaków dla tego zgłoszenia. Skopiuj go dokładnie. To wartość, która dowodzi, że plik APK, który zaraz zbudujesz, powstał na potrzeby dokładnie tej weryfikacji.

5. 05

   Utwórz assets/adi-registration.properties

   W folderze assets projektu APK utwórz plik o nazwie dokładnie adi-registration.properties. Ścieżka i nazwa pliku są dosłowne. Literówka w tym miejscu to najczęstszy sposób, w jaki ten krok się nie udaje.

6. 06

   Wklej ciąg znaków do tego pliku

   Nic więcej nie musi się w nim znaleźć. Plik istnieje wyłącznie po to, żeby przenieść ten ciąg.

7. 07

   Zbuduj produkcyjny plik APK

   Google podaje, że możesz zbudować go z prawdziwej aplikacji albo z pustego projektu używającego tej samej nazwy pakietu. Pusty projekt zwykle jest szybszy i bezpieczniejszy, bo nic z twojego kodu produkcyjnego nie bierze w tym udziału.

8. 08

   Podpisz go odpowiadającym kluczem prywatnym

   O to chodzi w całym ćwiczeniu. Dowodem jest podpis, nie zawartość.

9. 09

   Wyślij go przez Play Console

   Wyślij podpisany weryfikacyjny plik APK w procedurze własności. To nie jest wydanie, nie trafia do żadnego użytkownika, a twój prawdziwy artefakt produkcyjny pozostaje poza tym.

10. 10

    Obserwuj stan i e-mail z potwierdzeniem

    Google wysyła e-mail, gdy nazwa pakietu zostanie pomyślnie zarejestrowana, a zaktualizowany stan staje się widoczny w Play Console.

C. Jeśli twój klucz podpisywania trzyma inny sklep z aplikacjami

Niektóre sklepy podpisują w imieniu dewelopera, więc nie zbudujesz sam poprawnie podpisanego weryfikacyjnego pliku APK. Google dokumentuje na to osobną ścieżkę i jest ona krótka:

1. 01

   Zbuduj wydanie i wyślij je do tego sklepu

   Przeprowadź kompilację zawierającą ciąg znaków przez normalny proces wydawniczy tamtej platformy.

2. 02

   Pobierz z tego sklepu gotowy podpisany plik APK

   Potrzebujesz pliku w takiej postaci, w jakiej podpisał go sklep, a nie tego, który wysłałeś.

3. 03

   Wyślij ten podpisany przez sklep plik APK do Play Console

   To podpis sklepu spełnia kontrolę własności.

Kroki procedury z pomocy Play Console, "Registering Android package names" (odpowiedź 16761053), sprawdzone 13 sierpnia 2026 r. Zweryfikowane

Dodawanie kolejnych kluczy później

Jedna nazwa pakietu może mieć powiązany więcej niż jeden klucz podpisywania. Google podaje, że konsola pozwala dodawać i weryfikować wiele kluczy podpisywania dla jednego pakietu, a procedura odwzorowuje ścieżkę B: utwórz assets/adi-registration.properties z ciągiem znaków dla tego klucza, zbuduj i podpisz produkcyjny plik APK odpowiadającym kluczem prywatnym, a potem go wyślij. Najpierw zarejestruj nazwę pakietu, potem dodawaj kolejne klucze.

Jeśli nie zaproponowano żadnego kwalifikującego się klucza: reguły pierwszeństwa

Większość deweloperów nigdy tego nie zobaczy. Ma znaczenie, gdy nazwa pakietu była w swoim życiu podpisywana więcej niż jednym kluczem albo gdy więcej niż jedna strona ma wiarygodne roszczenie. Google rozstrzyga to hierarchią opartą na instalacjach.

Hierarchia kwalifikowalności z pomocy Play Console odpowiedź 16761053, sprawdzone 13 sierpnia 2026 r. Zweryfikowane

Praktyczny wniosek, sformułowany starannie: jeśli twój klucz podpisywania wyraźnie spełnia powyższą hierarchię, powinien pojawić się jako bezpośrednio kwalifikujący się do zgłoszenia. To rozstrzyga, czy Google pozwoli ci zarejestrować od razu, zamiast przez rozpatrywany wniosek. Nie kończy to rejestracji za ciebie. Pakiet pominięty przy automatycznej rejestracji i tak musi przejść ścieżkę B ręcznie. Poziom "kto pierwszy, ten lepszy" to ten, na którym trzeba działać szybko, bo rozstrzyga o nim to, kto działa, a nie kto ma rację.

Co muszą wysłać osobiste konta dewelopera

Dwie warstwy: informacje uniwersalne i dokumenty zależne od kraju. Część uniwersalna jest taka, że Twoje dane tożsamości prawnej i adresu muszą zgadzać się dokładnie z profilem Google Payments powiązanym z kontem. Część dokumentowa zależy w całości od kraju albo regionu w tym profilu, i właśnie dlatego żaden uczciwy artykuł nie poda Ci jednej ogólnoświatowej listy.

Część, która jest wszędzie taka sama

Konta osobiste podają dane tożsamości prawnej i informacje o koncie, a bieżąca pomoc Play wymienia wśród nich nazwisko prawne i adres prawny. Proces weryfikacji korzysta z powiązanego profilu Google Payments, a strona Google o wymaganiach dotyczących dokumentów mówi, że dane tożsamości osobowej, nazwa organizacji tam, gdzie ma to zastosowanie, oraz dane adresowe muszą dokładnie odpowiadać informacjom w Twoim profilu płatności.

Słowo "dokładnie" jest nośnym elementem całej tej sekcji i to jest powód, dla którego istnieje kolejne narzędzie.

Część, która nie jest wszędzie taka sama

Strona samego Google mówi, że akceptowane dokumenty zależą od Twojej lokalizacji geograficznej. Autorytetem dla Twojego przypadku jest wybierak kraju na tamtej stronie, a nie żadna lista przepisana gdzie indziej. Żeby pokazać kształt wymogu konkretnie, ale bez udawania, że jest uniwersalny, oto czego strona Google dla Stanów Zjednoczonych wymaga obecnie od osób fizycznych:

Wymagania dotyczące zdjęcia, które Google podaje wprost

Dotyczą samego dokumentu tożsamości ze zdjęciem i są jednoznaczne, co czyni je najtańszymi do wyeliminowania niepowodzeniami, zanim cokolwiek wyślesz:

• Państwowy dokument tożsamości ze zdjęciem musi być ważny i nieprzeterminowany.
• Zdjęcie musi być kolorowe.
• Zdjęcie musi być wyraźne i dobrze doświetlone.
• Zdjęcie nie może być kserokopią.

Google mówi też, że jego bieżąca strona o wymaganiach dotyczących dokumentów wskazuje nieobsługiwane dokumenty jako główny powód niepowodzeń weryfikacji dewelopera, oraz że fałszywe albo zmodyfikowane dokumenty mogą skutkować surowymi konsekwencjami, łącznie z usunięciem konta i aplikacji. Nic na tej stronie nie jest warte takiego ryzyka.

Kontrola, którą warto zrobić, zanim cokolwiek wyślesz

Google nie publikuje, ile prób weryfikacji Ci przysługuje, a deweloperzy regularnie zgłaszają dojście do stanu, w którym przycisk ponowienia po prostu przestaje być widoczny. Ta kombinacja sprawia, że nieuważne zgłoszenie potrafi naprawdę drogo kosztować. Zrób najpierw tę kontrolę.

Błąd do sprawdzenia, zanim cokolwiek wyślesz

Jeśli masz wziąć z tego wpisu tylko jedną instrukcję, weź tę: otwórz swój profil Google Payments i porównaj nazwisko prawne oraz adres z dokumentami, pole po polu, zanim dotkniesz przycisku wysyłki. Google wymaga, żeby informacje sobie odpowiadały; nie publikuje reguły co do znaku ani co do interpunkcji, więc traktuj "pole po polu" jako praktyczny sposób spełnienia wymogu, a nie jako osobną regułę.

Pierwsza połowa tego zdania to własny, wyrażony wprost wymóg Google. Druga połowa to treść forów wsparcia z 2026 roku. Wątki z kwietnia, czerwca, lipca i sierpnia 2026 r. mają ten sam kształt: deweloper jest pewien, że dokumenty są poprawne, weryfikacja kończy się niepowodzeniem bez konkretnego powodu, a odpowiedź społeczności wskazuje z powrotem na rozbieżność między wysłaną tożsamością a profilem Google Payments. W kilku z tych wątków deweloper odkrył problem z nazwiskiem w profilu dopiero po nieudanym odwołaniu.

Czego potrzebują konta organizacji

Organizacje weryfikują się danymi prawnymi organizacji, a nie tożsamością osobową, i zwykle potrzebują numeru D-U-N-S: unikalnego, dziewięciocyfrowego identyfikatora nadawanego przez Dun and Bradstreet. Dokumentacja Play Google podaje wyjątki dla niektórych podmiotów publicznych. Google mówi, że deweloperzy, którzy go nie mają, dostaną go za darmo, ale ostrzega, że może to potrwać tygodnie, co czyni z tego jedyną pozycję na tej stronie z realnym czasem oczekiwania. Strony samego Google nie zgadzają się co do liczby: FAQ o weryfikacji dewelopera Androida mówi o maksymalnie 28 dniach, a bieżąca pomoc dotycząca konta Play Console o maksymalnie 30. Ten wpis planuje według 30.

Co jeszcze przygotowuje organizacja

• Dane prawne organizacji zgodne z Twoimi dokumentami rejestrowymi, plus przedstawiciel upoważniony i informacje o koncie.
• Dziewięciocyfrowy numer D-U-N-S, darmowy do uzyskania od Dun and Bradstreet, z zastrzeżeniem wyjątków, które Google podaje dla niektórych organizacji publicznych. Te wyjątki są wąskie: nie znaczą, że organizacje publiczne pomijają weryfikację.
• Odpowiednią dokumentację organizacji i dokumenty tożsamości przedstawiciela, według tych samych zasad zależnych od kraju i dokładnej zgodności, które obowiązują konta osobiste.
• Zweryfikowaną witrynę, jeśli jesteś organizacją prowadzącą pełną dystrybucję poza Google Play. Przewodnik Google po weryfikacji mówi, że organizacje podają witrynę, którą trzeba zweryfikować przez Google Search Console. Ten krok należy do ścieżki Android Developer Console, a nie do Play Console.

Jednej rzeczy konto organizacji nie zmienia: jeśli publikujesz też w Google Play, to nadal jest praca w Play Console. A jeśli ważysz konto osobiste przeciwko organizacji przy nowym koncie, bilans wykracza daleko poza weryfikację. To decyzja porządnie rozłożona na części w porównaniu konta osobistego z kontem organizacji.

Co naprawdę się stanie, jeśli do 30 września nie masz weryfikacji

Cztery różne rzeczy, zależnie od tego, jak Twoja aplikacja trafia do użytkowników. Google dokumentuje ograniczenia dla nowych instalacji, dla aktualizacji tam, gdzie zasady zaczynają obowiązywać, oraz usunięcie z Google Play dla niezarejestrowanych pakietów Play. Google nie dokumentuje przymusowego usuwania aplikacji, które są już na urządzeniach użytkowników.

Konsekwencje z pomocy Play Console odpowiedź 16984799, przewodnika Google po weryfikacji w Play Console, wpisu o wdrożeniu z 30 marca, kalendarium na stronie pomocy Android Developer Console i FAQ z 22 lipca. Wszystko sprawdzone 9 sierpnia 2026 r.

Twierdzenie wymagające największej ostrożności

To rozróżnienie nie jest dzieleniem włosa na czworo. Zmienia to, co masz zrobić w tym miesiącu. Usunięcie z Play to incydent dystrybucyjny, który rozwiązujesz, rejestrując pakiet. Hipotetyczna fala usunięć byłaby incydentem w relacjach z klientami i wymagałaby zupełnie innej komunikacji. Udokumentowana jest tylko jedna z tych dwóch rzeczy.

Jak naprawdę działa procedura zaawansowana

Google opisuje procedurę zaawansowaną jako celowo powolną ścieżkę, a nie przełącznik, i o ten opór właśnie chodzi: każdy krok istnieje po to, żeby nikt nie przeprowadził przez niego ofiary przez telefon w trakcie trwającej rozmowy.

1. 01

   Włącz tryb dewelopera w ustawieniach systemu

   Świadomy pierwszy ruch, żeby nic tutaj nie uruchomiło się przypadkiem ani przez obejście jednym dotknięciem, jak w oszustwach.

2. 02

   Potwierdź, że nikt cię nie instruuje

   Szybkie sprawdzenie, czy ktoś nie naciska na ciebie, żebyś wyłączył zabezpieczenie.

3. 03

   Uruchom telefon ponownie i uwierzytelnij się jeszcze raz

   To odcina zdalny dostęp albo trwające połączenie, przez które ktoś mógłby obserwować twoje kolejne kroki.

4. 04

   Wróć po ochronnym okresie oczekiwania

   Google opisuje go jako jednorazowe oczekiwanie przez jeden dzień. Potem potwierdzasz uwierzytelnianiem biometrycznym albo kodem PIN urządzenia.

5. 05

   Zainstaluj od niezweryfikowanych deweloperów

   Możesz na to pozwolić na siedem dni albo bezterminowo. Ostrzeżenie nadal pojawia się przy każdej instalacji i sam je zatwierdzasz.

Kroki procedury zaawansowanej z FAQ Google o weryfikacji dewelopera Androida, sprawdzone 13 sierpnia 2026 r. Zweryfikowane

Historia instalacji bezpośredniej, zapakowana w jeden akapit

Etap z 30 września nie obejmuje jeszcze ani instalacji bezpośredniej, ani sklepów z aplikacjami spoza listy uczestników Google, a Google nadal wspiera instalację przez ADB oraz zaawansowaną procedurę dla użytkowników świadomie wybierających instalację od niezweryfikowanego dewelopera. To udokumentowane stanowisko bieżące na 9 sierpnia 2026 r. i różni się ono mocno od odczytania "Google kończy z instalacją bezpośrednią", które rozeszło się po pierwotnym ogłoszeniu z 2025 roku. Jest też wprost nazwane etapem pierwszym, więc uznanie tego za stan ostateczny byłoby błędem w drugą stronę. Jeśli tym, co Cię tu przywiodło, są konsekwencje dla instalacji bezpośredniej i dla otwartego ekosystemu, a nie termin w Play, ten temat zasługuje na własny wpis, a nie na akapit w tekście o zgodności.

Weryfikacja nie zastępuje testu zamkniętego z 12 testerami

To dwa niepowiązane wymogi, a oba trzeba spełnić, gdy oba Cię dotyczą. Weryfikacja dewelopera Androida odpowiada na pytanie "kto jest właścicielem tego konta i tego pakietu?". Zasada dostępu do wersji produkcyjnej odpowiada na pytanie "czy tę aplikację przetestowali prawdziwi ludzie?". Możesz przejść jedno bezbłędnie i wciąż być całkowicie zablokowanym przez drugie.

Wymóg Google wobec nowych osobistych kont dewelopera objętych tą zasadą nie zmienia się przez nic, co dzieje się w programie weryfikacji: co najmniej 12 testerów, którzy nieprzerwanie uczestniczyli w teście zamkniętym przez ostatnie 14 dni w momencie, w którym prosisz o opublikowanie wersji produkcyjnej.

Kolumny o weryfikacji z przewodnika Google po weryfikacji i z pomocy Play Console odpowiedź 16984799; kolumny o teście zamkniętym z pomocy Play Console odpowiedź 14151465 i ze strony pomocy o teście wewnętrznym. Wszystko sprawdzone 9 sierpnia 2026 r. Zweryfikowane

Dlaczego ludzie wpadają tu w pułapkę

Bo obie rzeczy nazywają się "wymaganiami", obie mieszkają w Play Console i obie stoją między deweloperem a opublikowaną aplikacją. Więc konto, które właśnie przeszło potwierdzenie tożsamości, ma poczucie, że sprawa zamknięta. Potem dostęp do wersji produkcyjnej zostaje odmówiony, a nic na ekranach weryfikacji nie tłumaczy dlaczego, bo to nie na ekranach weryfikacji mieszka ta odpowiedź.

Sekwencja, która naprawdę wyprowadza nowe konto osobiste na Play, wygląda tak: tożsamość potwierdzona, każdy pakiet zarejestrowany, i osobno test zamknięty z co najmniej 12 testerami nieprzerwanie uczestniczącymi przez 14 dni przed prośbą o opublikowanie wersji produkcyjnej. Zasada 14 dni z rzędu ma więcej przypadków brzegowych, niż większość deweloperów zakłada, i jest tą częścią sekwencji, której nie da się skrócić większym wysiłkiem.

Czy test wewnętrzny liczy się zamiast tego?

Nie, a warto być precyzyjnym co do powodu, bo zdanie "test wewnętrzny jest bezużyteczny" też jest błędne. Google dopuszcza test wewnętrzny z maksymalnie 100 testerami i jest to naprawdę dobry sposób na szybkie wyłapanie problemów. Ale wymóg dostępu do wersji produkcyjnej wskazuje wprost test zamknięty spełniający warunek 12 testerów przez 14 dni. Test wewnętrzny to osobna ścieżka, więc udział w nim nie jest kwalifikującym się testem dla tego konkretnego wymogu.

Konta organizacji też zasługują tu na jedno wyjaśniające zdanie: wymóg testowania na potrzeby dostępu do wersji produkcyjnej jest napisany wprost dla nowych osobistych kont dewelopera, więc konta organizacji nie są tą klasą kont, którą obejmuje ta konkretna zasada 12 testerów. To pytanie osobne od weryfikacji, bo weryfikacja sięga obu typów kont.

Gdy weryfikacja się nie powiodła, sprawdź to, zanim spróbujesz ponownie

Deweloperzy często zgłaszają komunikaty odmowy bez konkretów, a Google nie dokumentuje przyczyny każdego pojedynczego odrzucenia. Więc sensownym ruchem nie jest zgadywanie, o co chodzi w komunikacie, tylko przejście przez wymogi, które Google faktycznie publikuje. Wybierz poniżej objaw, który widzisz. Każdy rozwija się w pierwszą rzecz do sprawdzenia, w siłę dowodów stojących za tą radą i w bezpieczne następne działanie.

Zacznij od objawu, który naprawdę widzisz

Dziesięć pozycji poniżej jest sformułowanych tak, jak formułują to deweloperzy na forach wsparcia Google, łącznie z tymi pisanymi o drugiej w nocy. Wybór jednej daje Ci jedną kontrolę o najwyższej wartości dla tego objawu, zamiast listy wszystkiego, co teoretycznie mogłoby być nie tak.

Za czym stoją dowody, a za czym nie

Wzorce niepowodzeń poniżej pochodzą z wątków Społeczności pomocy dla deweloperów Google Play z całego 2026 roku, w tym z przypadków z Brazylii, Indii i Uzbekistanu oraz z kilku wątków po portugalsku, a także ze starszych zgłoszeń na Reddicie i Stack Overflow. Są pogrupowane według rzeczywistej siły dowodów, bo to zmienia sposób, w jaki należy z nich korzystać.

Lista kontrolna przed terminem

Pięć stanów decyduje o tym, czy 30 września to data w Twoim kalendarzu, czy problem w Twojej skrzynce. Cztery dotyczą każdego dewelopera Play. Piąty dotyczy tylko sytuacji, gdy Twoje konto jest objęte zasadą testu zamkniętego, i to on zjada realny czas z kalendarza.

Cztery sprawy do zamknięcia

Odhaczaj je uczciwie, a nie optymistycznie. Każdy wiersz linkuje z powrotem do sekcji, która go rozwiązuje, więc nieodhaczone pole to dwuminutowy objazd, a nie ślepy zaułek. Dwie z nich są warunkowe, więc sformułowano je tak, żeby dało się je zaznaczyć, gdy nigdy cię nie dotyczyły: kto miał wszystkie aplikacje zarejestrowane automatycznie, nie ma ręcznego zgłoszenia do domknięcia, a kto był już zweryfikowany i nie dostał żadnego pytania o dokumenty, nie ma czego poprawiać.

Gdzie PrimeTestLab się mieści, a gdzie nie

Najpierw jasno o granicy: nikt nie potwierdzi Twojej tożsamości za Ciebie. Wysłanie dokumentów, uzgodnienie profilu Google Payments i zgłoszenie praw do nazw pakietów to rzeczy, które może zrobić tylko właściciel konta, a ten wpis jest całym naszym wkładem w nie. Zajmujemy się wymogiem stojącym bezpośrednio za weryfikacją dla nowego konta osobistego: 12 prawdziwych testerów uczestniczących nieprzerwanie przez 14 dni.

To ten podział, który trafia do naszej skrzynki wciąż w tym samym kształcie. Deweloper przechodzi potwierdzenie tożsamości, widzi zielony stan w Play Console, zakłada, że droga jest otwarta, a potem odkrywa, że dostęp do wersji produkcyjnej to zupełnie osobna brama z dwutygodniową dolną granicą. Weryfikacja to papierologia i to, ile trwa, zależy od Twoich dokumentów i Twojego konta. Test zamknięty to czas z zegara ściennego, którego nie da się ścisnąć.

Prowadzenie testu zamkniętego samodzielnie kontra oddanie go w ręce

Kolejność, która kosztuje najmniej czasu

Jeśli weryfikacja i test zamknięty stoją przed Tobą oba, prowadź je równolegle, a nie po kolei. 14 dni nieprzerwanego uczestnictwa testerów to czas rzeczywisty, który rusza dopiero, gdy naprawdę masz zapisanych 12 osób, więc to ta pozycja decyduje o Twojej realnej dacie premiery. Uruchom ten zegar w trakcie pracy nad dokumentami, a nie po niej.

Najczęstsze pytania

W skrócie

Ostatnie sprawdzenie zasad: 13 sierpnia 2026 r. Wdrożenie z 30 września i rozszerzenie na 2027 rok wciąż się u Google zmieniają, więc daty i zasięg krajów warto sprawdzić ponownie na stronie Google o weryfikacji dewelopera Androida, zanim na ich podstawie zadziałasz. Ten wpis ma zaplanowaną ponowną weryfikację na 30 września 2026 r. i zaraz po rozpoczęciu egzekwowania, a potem za każdym razem, gdy Google opublikuje jakąkolwiek geografię albo datę na 2027 rok.