Czy testerzy nadal zainstalują Twój plik APK po weryfikacji dewelopera Androida?

Historia, która rozeszła się w 2025 roku, była prosta: Android kończy z instalacją bezpośrednią. Stanowisko, które Google faktycznie ma udokumentowane w sierpniu 2026 roku, jest węższe, precyzyjniejsze i o wiele mniej przydatne jako nagłówek. W czerwcu i lipcu 2026 r. Google doprecyzował i zawęził pierwszą fazę egzekwowania, a 15 lipca 2026 r. zapisał to zawężenie w jednym zdaniu: termin 30 września "dotyczy tylko konkretnych uczestniczących sklepów". Duża część wciąż krążących materiałów z 2025 i początku 2026 roku powstała, zanim to zdanie istniało, i opisuje szersze pierwsze wdrożenie niż to, które Google faktycznie prowadzi.

Dlatego ten wpis jest zbudowany wokół decyzji, którą naprawdę musisz podjąć, a nie wokół sporu. Masz dwunastu znajomych, współpracowników albo testerów i kompilację, którą trzeba wgrać na ich telefony. Czy nadal możesz wysłać plik APK mailem? Czy potrzebujesz ADB? Czy Firebase App Distribution wystarczy? I pytanie, które niemal co tydzień trafia do skrzynki PrimeTestLab: czy cokolwiek z tego liczy się do testu zamkniętego z 12 testerami, którego Google wymaga przed dostępem do wersji produkcyjnej? Każda data, liczba i mechanizm poniżej zostały sprawdzone na własnych stronach Google 13 sierpnia 2026 r., a tam, gdzie Google nie opublikował nic, ten wpis oznacza lukę, zamiast ją wypełniać.

Czy po 30 września 2026 r. testerzy nadal zainstalują Twój plik APK?

Tak. Zgodnie z obecnymi zasadami Google także po 30 września 2026 r. tester nadal może zainstalować plik APK, który wyślesz mu bezpośrednio. Data jest prawdziwa, cztery kraje są prawdziwe, egzekwowanie też jest prawdziwe, ale aktualne odpowiedzi Google mówią, że termin "dotyczy tylko konkretnych uczestniczących sklepów". Przy bezpośredniej instalacji te same odpowiedzi mówią, że "jeszcze nie dotyczy Twojej aplikacji".

Czego dotyczy 30 września, a czego nie

Trzy wiersze rozstrzygają sprawę dla niemal każdego czytelnika. Środkowy jest tym, który różni się od wielu wcześniejszych publikacji o tej dacie.

Zakres z odpowiedzi Google o weryfikacji dewelopera Androida (aktualizacja z 10 sierpnia 2026 r.) i z ogłoszenia z 18 czerwca 2026 r., w którym padły data, cztery kraje i siedem sklepów. Wymóg testu zamkniętego w Play z odpowiedzi 14151465 w pomocy Play Console. Wszystko sprawdzone 13 sierpnia 2026 r.

Co naprawdę zmienia się 30 września 2026 r.

Google ustalił datę 18 czerwca 2026 r., a potem zawęził ją na piśmie 15 lipca. Od 30 września instalacja przez jeden z siedmiu wymienionych sklepów w czterech wymienionych krajach jest sprawdzana: aplikacja musi być zarejestrowana na zweryfikowanego dewelopera. Aktualne odpowiedzi Google mówią, że ta pierwsza faza dotyczy wymienionych uczestniczących sklepów, a instalacja bezpośrednia i sklepy spoza listy nie są jeszcze objęte.

To dwa odrębne obowiązki z 30 września, a ich mieszanie to najczęstszy sposób błędnego odczytania tej daty. Rejestracja pakietów w Play jest globalna i decyduje o tym, czy Twoja pozycja zostaje w sklepie; egzekwowanie przy instalacji jest regionalne i decyduje o tym, co dzieje się na telefonie użytkownika. Zweryfikowane

Siedem uczestniczących sklepów

Wymieniaj je dokładnie. Opisywanie tego jako ograniczenia dla wszystkich sklepów z aplikacjami jest zbyt szerokie wobec obecnego brzmienia pierwszej fazy u Google: według opublikowanej przez Google listy sklep, którego tu nie ma, jest poza wdrożeniem z 30 września.

Lista sklepów i kraje z ogłoszenia Google z 18 czerwca 2026 r.; wyłączenie instalacji bezpośredniej i sklepów spoza listy z odpowiedzi Google o weryfikacji w wersji zaktualizowanej 10 sierpnia 2026 r. Sprawdzone 13 sierpnia 2026 r. Sprawdzone

Cztery kraje i formy urządzeń w ich obrębie

Dwa szczegóły zawężają to jeszcze bardziej i warto mieć je z tyłu głowy. Przy dystrybucji poza Google Play odpowiedzi Google o weryfikacji podają, że egzekwowanie w wybranych regionach dotyczy początkowo telefonów i tabletów. Te same odpowiedzi mówią, że zabezpieczenia dostarczane są przez Usługi Google Play na certyfikowanych urządzeniach z Androidem 7 lub nowszym, i to jest docelowy zakres urządzeń, a nie ograniczenie tylko na wrzesień.

Co się we wrześniu nie zmienia

Poniższa lista jest krótka, ale obejmuje to, jak większość małych zespołów naprawdę przerzuca kompilację. Żadnej z tych rzeczy faza z 30 września nie dotyczy.

Co się stanie, gdy weryfikacja rozszerzy się globalnie w 2027 roku

Google mówi, że wymóg rozszerzy się globalnie w 2027 roku i dalej, na aplikacje na certyfikowanych urządzeniach z Androidem 7 lub nowszym, przez Usługi Google Play. Nie ogłosił dokładnej daty ogólnoświatowej ani harmonogramu kraj po kraju. Każdą konkretną datę z 2027 roku traktuj jako nieoficjalną, dopóki Google jej nie opublikuje.

Harmonogram i to, co każda data robi z udostępnionym plikiem APK

1. 30 marca 2026 r.

   Weryfikacja zaczyna być wdrażana u wszystkich deweloperów

   Google zaczął udostępniać weryfikację dewelopera Androida każdemu deweloperowi w Play Console i w Android Developer Console.

   Surowy APK Sama ta data niczego nie zmienia w instalacji po stronie użytkownika. Niezweryfikowana aplikacja Nadal instalowalna zgodnie z dotychczasowym działaniem Androida.
2. Sierpień 2026 r.

   Ścieżka zaawansowana i konta z dystrybucją ograniczoną wchodzą globalnie

   Google zaplanował globalny start zaawansowanej ścieżki instalacji i kont z dystrybucją ograniczoną na ten miesiąc. Na dzień 13 sierpnia 2026 r. przejrzane źródła podają miesiąc, ale nie dokładny dzień, i nie potwierdzają, że ścieżka dotarła już do każdego użytkownika. Częściowe

   Surowy APK Nadal dostępny. Niezweryfikowana aplikacja Ścieżka zaawansowana to mechanizm, który ma zachować możliwość ich instalowania.
3. 30 września 2026 r.

   Egzekwowanie rejestracji rusza w siedmiu sklepach i czterech krajach

   Instalacje przez Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore i Xiaomi GetApps w Brazylii, Indonezji, Singapurze i Tajlandii wymagają, żeby aplikacja była zarejestrowana na zweryfikowanego dewelopera. Sprawdzone

   Surowy APK Jeszcze nieobjęty tą początkową fazą. Niezweryfikowana aplikacja Instalacja z uczestniczącego sklepu może zostać ograniczona; droga bezpośrednia w tej fazie zostaje nietknięta.
4. Rok 2027 i dalej

   Rozszerzenie globalne na certyfikowane urządzenia z Androidem

   Weryfikacja rozszerza się na cały świat dla aplikacji na certyfikowanych urządzeniach z Androidem 7 lub nowszym. To jest ta faza, w której zmienia się odpowiedź o instalacji bezpośredniej. Sprawdzone

   Surowy APK Aplikacja zarejestrowana: zwykła droga instalacji. Aplikacja niezarejestrowana: ścieżka zaawansowana albo ADB, według ogłoszonego modelu. Niezweryfikowana aplikacja Ścieżka zaawansowana albo ADB pozostają ogłoszoną drogą.
5. Dokładna data w 2027 r.

   Nieogłoszona na dzień 13 sierpnia 2026 r.

   Opublikowany przez Google harmonogram mówi o 2027 roku i dalej, i nic bardziej konkretnego. Kolejność krajów też nie została podana. Brak dokumentacji

   Surowy APK Nie planuj wokół konkretnego dnia. Niezweryfikowana aplikacja Nie planuj wokół konkretnego dnia.

Chronologia z wpisu Google o wdrożeniu z 30 marca 2026 r., ogłoszenia z 18 czerwca 2026 r. i odpowiedzi o weryfikacji dewelopera Androida w wersji zaktualizowanej 10 sierpnia 2026 r. Sprawdzone 13 sierpnia 2026 r.

Zweryfikowany APK kontra niezweryfikowany: co Android naprawdę sprawdza

Samo "czy jestem zweryfikowany?" to złe pytanie. Weryfikacja dewelopera Androida tworzy to, co Google nazywa formalnym, sprawdzalnym powiązaniem między tożsamością dewelopera, nazwą pakietu aplikacji i kluczem albo kluczami podpisu tego pakietu. Weryfikacja tożsamości to jedno ogniwo tego łańcucha, a nie cały łańcuch.

Łańcuch, ogniwo po ogniwie

Łańcuch z przewodników Google o weryfikacji dewelopera Androida, wraz z opisem potwierdzania własności, oraz obsługa wielu kluczy podpisu opisana w odpowiedziach o weryfikacji. Sprawdzone 13 sierpnia 2026 r. Sprawdzone

Google mówi wprost, że instalacja bezpośrednia jest fundamentem Androida i że zweryfikowani deweloperzy mogą dalej dystrybuować bezpośrednio. Niuans, który ta fraza ukrywa, jest taki, że gładka instalacja zależy od tego, czy aplikacja jest zarejestrowana, a nie tylko od tego, czy przeszedłeś kontrolę tożsamości. Dlatego ten wpis za każdym razem mówi "zarejestrowana na zweryfikowanego dewelopera", zamiast krótszego i luźniejszego "zweryfikowana aplikacja".

A co, jeśli używasz klucza debugowego albo osobnego klucza QA?

To miejsce, w którym prawdziwe zespoły QA wpadają w kłopoty, bo wysyłanie testerom wewnętrznym kompilacji podpisanej kluczem debugowym, a do sklepu kompilacji podpisanej kluczem produkcyjnym, jest zupełnie normalne. To różne certyfikaty na tej samej nazwie pakietu.

Pięć przypadków brzegowych, na które Google faktycznie odpowiedział

Te pięć pytań wraca bez przerwy i wszystkie mają opublikowane odpowiedzi, więc nie trzeba zgadywać.

ADB nadal dozwolone, ale to proces dla dewelopera

Najjaśniejsze zobowiązanie Google w całym tym programie, z odpowiedzi o weryfikacji: w działaniu ADB nic się nie zmienia. Deweloperzy i zaawansowani użytkownicy mogą dalej instalować w ten sposób aplikacje, a 24-godzinny czas oczekiwania ze ścieżki zaawansowanej nie dotyczy instalacji przez ADB. To najtrwalsza techniczna droga w tym wpisie i zarazem najmniej odpowiednia dla zwykłych testerów.

Co tester musi zrobić najpierw

Własna dokumentacja narzędziowa Google mówi o warunku wstępnym bez ogródek: żeby użyć ADB przez USB, musisz włączyć debugowanie USB w opcjach programisty urządzenia. Na współczesnym telefonie oznacza to znalezienie numeru kompilacji, siedmiokrotne stuknięcie w niego, żeby odblokować opcje programisty, a potem włączenie debugowania USB w ekranie ustawień z okienkiem ostrzegawczym. To wykonalne dla technicznego testera i uciążliwe dla kogoś, kto po prostu zgłosił się na ochotnika, żeby wypróbować Twoją aplikację.

Konfiguracji nie powtarza się przy każdej kompilacji i akurat to większość poradników opisuje źle. Gdy tester autoryzuje Twoją stację roboczą, ta autoryzacja zostaje, dopóki jej nie cofnie albo nie zapomni urządzenia. Nowa kompilacja kosztuje więc kolejne adb install -r i dostęp do telefonu, a nie ponowne przejście przez opcje programisty. Android 11 i nowszy obsługuje też debugowanie bezprzewodowe: tester paruje telefon ze stacją raz, kodem QR albo kodem parowania, a potem instalujesz przez sieć, dopóki oba urządzenia są w tej samej sieci, bez kabla. To znosi kabel, a nie wymóg techniczny.

adb devices

adb install app-release.apk

adb install -r app-release.apk

Czym jest zaawansowana ścieżka Androida dla niezweryfikowanych aplikacji?

Google zbudował świadomą drogę dla użytkowników, którzy mimo wszystko chcą zainstalować aplikację od niezweryfikowanego dewelopera. To jednorazowa konfiguracja z celowo uciążliwym krokiem w środku: włącz tryb dewelopera, potwierdź, że nikt Cię przez to nie prowadzi, uruchom ponownie, odczekaj jeden dzień, uwierzytelnij się, a potem zezwól na niezweryfikowane instalacje na 7 dni albo bezterminowo. 24 godziny oczekiwania są częścią tej konfiguracji, a nie opóźnieniem przed każdym plikiem APK.

Sekwencja, sformułowania i opcje czasu z odpowiedzi Google o weryfikacji dewelopera Androida, sprawdzonych 13 sierpnia 2026 r. Google publikuje uzasadnienie każdego kroku tej ścieżki, więc powyższe notki je przytaczają, zamiast się go domyślać. Sprawdzone

Trzy rzeczy, które ludzie tu mylą

Czy działa już teraz?

Praktyczny wniosek dla dewelopera: ścieżka zaawansowana to prawdziwa, udokumentowana odpowiedź na pytanie "czy użytkownik nadal zainstaluje moją niezweryfikowaną aplikację?" i kiepska odpowiedź na pytanie "jak dostarczyć kompilację dwunastu testerom w tym tygodniu". Jednodniowe opóźnienie bezpieczeństwa w środku wdrażania testerów tworzy realne tarcie dla osób niezaawansowanych albo pracujących zdalnie. Jeśli Twoi testerzy to zwykli użytkownicy, drogi, które szanują ich czas, porównuje sekcja 09.

Co dzieje się z plikami APK, które są już zainstalowane?

Dokumentacja Google mówi o instalowaniu i aktualizowaniu. Gdy egzekwowanie zacznie obowiązywać, niezarejestrowanej aplikacji nie da się zwyczajnie zainstalować ani zaktualizować, a Google mówi, że zwykła aktualizacja "się nie powiedzie" bez ścieżki zaawansowanej albo ADB. Przejrzana dokumentacja nie mówi natomiast, że kopie już obecne na telefonach zostaną usunięte albo zablokowane przy uruchamianiu.

Zachowanie z odpowiedzi Google o weryfikacji dewelopera Androida, sprawdzonych 13 sierpnia 2026 r. Pierwszy wiersz stwierdza brak ogłoszonego mechanizmu, co nie jest tym samym co obietnica, że zachowanie nigdy się nie zmieni.

To rozróżnienie zmienia to, co naprawdę powinieneś zrobić. Zablokowana aktualizacja to prawdziwy, udokumentowany problem operacyjny: dotknięty tester może zostać na starszej kompilacji, bo aktualizacja nie zainstaluje się zwykłą drogą, a może nigdy tego nie zgłosić, bo z jego strony po prostu nic się nie wydarzyło. Masowe odinstalowanie byłoby zupełnie innym rodzajem kryzysu i wymagałoby zupełnie innej komunikacji. Tylko jedna z tych dwóch rzeczy jest udokumentowana.

Gdzie mieści się Firebase App Distribution po weryfikacji

Firebase App Distribution to sposób na wgranie przedpremierowych kompilacji na urządzenia testerów. Nie jest systemem weryfikacji, nie jest ścieżką testów Google Play i nie zwalnia niczego z weryfikacji dewelopera Androida. To, co robi dobrze, to zdejmowanie ręcznej roboty z przekazywania podpisanej kompilacji liście osób.

Jak naprawdę przebiega ścieżka z plikiem APK

Przebieg, wymóg podpisu, 150 dni przechowywania kompilacji i 30 dni ważności zaproszenia z dokumentacji Firebase App Distribution dla Androida, sprawdzonej 13 sierpnia 2026 r. Sprawdzone

Czy Firebase nadal działa w fazie wrześniowej?

Niemal na pewno tak, a liczy się to, jak dochodzisz do tego wniosku. Ścieżka Firebase z plikiem APK to bezpośrednia dystrybucja podpisanego pliku APK do zaproszonych testerów. Odpowiedzi Google mówią, że instalacja bezpośrednia nie jest objęta fazą z 30 września. Złóż te dwa fakty i dystrybucja plików APK przez Firebase powinna pozostać używalna przez całą tę pierwszą fazę.

Dystrybucja APK i AAB przez Firebase to nie to samo

To niuans, który prawie każdy artykuł spłaszcza. Firebase obsługuje oba formaty, a każdy jedzie do telefonu testera inną drogą.

Zatem pytanie "czy Firebase nadal działa?" ma dwie odpowiedzi, zależnie od tego, jaki plik przesyłasz. Kiedy o tym piszesz albo pytasz kolegę z zespołu, mów wprost: dystrybucja APK przez Firebase albo dystrybucja AAB przez Firebase. Skrót myślowy ukrywa szczegół, który istotnie zmienia analizę.

Czy Firebase App Distribution liczy się do zasady 12 testerów?

Nie. Wymóg dostępu do wersji produkcyjnej dla objętych kont mówi o co najmniej 12 testerach, którzy dołączyli do testu zamkniętego w Google Play, nieprzerwanie, przez poprzednie 14 dni. Testerzy z Firebase nie uczestniczą w teście zamkniętym w Play, więc testowanie przez Firebase tego nie spełnia, niezależnie od tego, ile osób bierze udział i jak dokładnie testują.

Wymóg Play z odpowiedzi 14151465 w pomocy Play Console; zachowanie Firebase z dokumentacji Firebase App Distribution. Oba sprawdzone 13 sierpnia 2026 r. Te dwa produkty definiują różne procesy, które łączy jedynie słowo "rejestracja". Sprawdzone

Wzorzec, który się z tego bierze, wart jest nazwania, bo kosztuje ludzi dwa tygodnie. Deweloper przeprowadza naprawdę rzetelny test w Firebase z piętnastoma zaangażowanymi testerami, uznaje, że pole "testy" jest odhaczone, otwiera Play Console, żeby poprosić o opublikowanie wersji produkcyjnej, i odkrywa, że zegar 14 dni w ogóle nie ruszył. Sekcja 10 zestawia oba wymogi obok siebie, żeby Tobie się to nie przydarzyło.

Najlepszy sposób na dostarczenie kompilacji 12 testerom w 2026 roku

Nie ma jednego zwycięzcy, bo te drogi rozwiązują różne problemy. Surowy plik APK to najprostsza rzecz, która działa dzisiaj. ADB jest najtrwalsze i najmniej wygodne. Firebase to najlepszy czysto QA-owy kanał. A tylko jedna droga na tej stronie spełnia wymóg dostępu do wersji produkcyjnej w Google Play, czyli to, co naprawdę wyznacza datę Twojej premiery.

Wszystkie siedem dróg obok siebie

Narzędzie odpowiada na jedną sytuację. To odpowiada na wszystkie, łącznie z dwiema kolumnami, które ludzie pomijają, aż jest za późno: ogłoszone zachowanie w 2027 roku i to, czy dana droga w ogóle coś daje Twojemu wnioskowi o dostęp do wersji produkcyjnej w Play.

Źródła: odpowiedzi i przewodniki Google o weryfikacji, dokumentacja narzędzia ADB, dokumentacja Firebase App Distribution, strona o dystrybucji ograniczonej, pomoc Play Console o teście wewnętrznym i o wymaganiach testowych dla dostępu do wersji produkcyjnej. Wszystko sprawdzone 13 sierpnia 2026 r.

Uczciwa rekomendacja

Prowadź dwie ścieżki równolegle, bo odpowiadają na różne pytania. Do prawdziwego QA używaj tego, co najszybciej wgra kompilację na urządzenia: surowy plik APK dla jednego kolegi, Firebase dla grupy, ADB, gdy musisz ominąć wszystko. A potem, osobno i zaczynając jak najwcześniej, prowadź test zamknięty w Play, jeśli Twoje konto podlega wymogowi dostępu do wersji produkcyjnej, bo tamten mierzy się dniami na zegarze i nie skrócisz go cięższą pracą.

Błąd, którego warto uniknąć, to traktowanie ich jako następujących po sobie. Ukończenie rzetelnego testu w Firebase nie przesuwa licznika 14 dni ani o jeden dzień.

Weryfikacja dewelopera nie zastępuje testu zamkniętego Google Play

To dwa niepowiązane wymogi, które ludzie zlewają w jedno myślowe pole do odhaczenia. Weryfikacja odpowiada na pytanie "kto zrobił i podpisał ten pakiet?" Test zamknięty odpowiada na pytanie "czy to konto ukończyło przedprodukcyjny test Google?" Ukończenie jednego nie daje absolutnie nic drugiemu.

Dlaczego "test wewnętrzny się liczy, przecież to nadal test w Play" jest błędne

Google dopuszcza w teście wewnętrznym do 100 testerów, przez co wydaje się on poważniejszą opcją. Ale wymóg dostępu do wersji produkcyjnej jest napisany wokół konkretnej ścieżki: liczeni testerzy muszą uczestniczyć w teście zamkniętym przez ostatnie 14 dni nieprzerwanie. Test wewnętrzny to inna ścieżka, więc tego zdania nie spełnia.

Liczby i skąd się wzięły

Dwa fakty historyczne rozwiewają pytania, które wracają bez przerwy. Google ogłosił ten wymóg 9 listopada 2023 r., a obecna zasada stosuje go do kont osobistych utworzonych po 13 listopada 2023 r.: dwie różne daty, które znaczą dwie różne rzeczy. Minimum wynosiło pierwotnie 20 osób przez co najmniej dwa tygodnie; własny przewodnik społecznościowy Google mówi, że obniżenie do 12 nastąpiło w grudniu 2024 r. Ówczesne relacje deweloperów umieszczają zmianę w Play Console 11 grudnia 2024 r., ale nie udało się znaleźć datowanego ogłoszenia Google na dokładnie ten dzień, więc traktuj ten dzień jako zgłoszony, a nie oficjalny. Częściowe

Konta organizacji są poza tą konkretną bramką: wymóg dotyczy objętych kont osobistych. A opłata jest w obu wypadkach ta sama, czyli jednorazowa opłata rejestracyjna w wysokości 25 USD w Google Play. Jeśli chcesz pełne porównanie typów kont, a nie jeden akapit, znajdziesz je we wpisie o koncie osobistym kontra koncie organizacji.

Dziesięć nieaktualnych twierdzeń na ten temat

Wiele publikacji o weryfikacji dewelopera Androida powstało, zanim Google zawęził pierwszą fazę w czerwcu i lipcu 2026 roku. Poniższe twierdzenia nie są kłamstwami; kilka było prawdziwych w chwili publikacji. Opisują po prostu wersję zasad, która nie pasuje już do aktualnych stron Google.

Gdzie dwie strony Google wyglądają na sprzeczne

Warto to nazwać, bo uważny czytelnik na to trafi. Ogólne sformułowanie w pomocy Google mówi, że aplikacje, których deweloperzy nie ukończyli wymogu, przestają być dostępne do nowych instalacji w objętych krajach, co brzmi szerzej niż wyłączenie ograniczone do sklepów. Bardziej szczegółowe odpowiedzi, zaktualizowane 10 sierpnia 2026 r., mówią, że termin 30 września dotyczy tylko uczestniczących sklepów i nie sięga jeszcze instalacji bezpośredniej.

Od objawu do rozwiązania: co jest naprawdę nie tak

Znajdź zdanie, które faktycznie padło u Ciebie albo u Twojego testera. Częstą przyczyną nieudanej instalacji albo aktualizacji u testera jest niezgodność certyfikatu podpisu, czyli zwykłe zachowanie Androida, które nie ma nic wspólnego z weryfikacją dewelopera i wyprzedza ją o dekadę.

Co naprawdę zrobić przed 30 września

Jeśli rozprowadzasz pliki APK wyłącznie bezpośrednio, pierwsza faza z 30 września nie egzekwuje weryfikacji dewelopera na tej drodze. To stan przejściowy, nie trwały: Google zaleca ukończenie weryfikacji, zanim w 2027 roku ruszy globalne wdrożenie. Jeśli publikujesz w Google Play, wymaga jednego: każdy pakiet zarejestrowany. A niezależnie od obu tych spraw, jeśli Twoje konto stoi przed bramką dostępu do wersji produkcyjnej, to zegar 14 dni jest tą pozycją, która wyznacza datę Twojej premiery, więc powinien już chodzić.

Kiedy ten wpis się zdezaktualizuje

Ten artykuł starzeje się wyjątkowo szybko i nieuczciwie byłoby przedstawiać go jako ponadczasowy. Poniżej rzeczy, które najpewniej zmienią się pierwsze, i to, co uczyniłoby każdą z nich błędną.

Rytm odświeżania przyjęty dla tego wpisu: co tydzień do 30 września 2026 r., potem w dniu wejścia wymogu i mniej więcej tydzień po nim, na doprecyzowania wdrożeniowe, a następnie co miesiąc, aż Google opublikuje konkretny harmonogram na 2027 rok. Ten rytm to wybór redakcyjny oparty na tym, jak często Google poprawiał ten program w 2026 roku, a nie oficjalny harmonogram Google.

Gdzie PrimeTestLab pasuje, a gdzie nie

Najpierw granica, bo to uczciwa część. PrimeTestLab nie weryfikuje Twojej tożsamości, nie rejestruje nazw pakietów ani nie zamienia testu w Firebase w test zamknięty w Play. To należy do Ciebie, a ten wpis jest całym naszym wkładem w te sprawy. My pokrywamy jeden wymóg z tej strony, ten zbudowany z czasu kalendarzowego, a nie z papierologii: 12 prawdziwych testerów, uczestniczących nieprzerwanie przez 14 dni na ścieżce testu zamkniętego w Play. Google udostępnia wprawdzie API i delegowanie OAuth, dzięki którym autoryzowana platforma może pomóc deweloperowi w rejestracji, ale ten dostęp trzeba przyznać samodzielnie, a odpowiedzialność za konto i tożsamość aplikacji zostaje przy Tobie.

Ta różnica to dokładnie kształt problemu, dla którego powstał ten artykuł. Deweloper pięknie rozsyła kompilacje: grupy w Firebase, schludne informacje o wersji, zaangażowani testerzy, prawdziwe zgłoszenia błędów. Potem otwiera Play Console, żeby poprosić o opublikowanie wersji produkcyjnej, i odkrywa, że nic z tego się nie liczyło. Dystrybucja to rozwiązany problem. Okno 14 dni uczestnictwa jest tą częścią, której nie skrócisz lepszą organizacją.

Prowadzić test zamknięty samodzielnie czy oddać go w ręce kogoś innego

Trzy plany, jedna płatność

Każdy plan to prawdziwi testerzy na prawdziwych urządzeniach przez pełne 14 dni, testy zwykle ruszają w 4-6 godzin, a jeśli test nie przyniesie efektu, dostajesz bezpłatny ponowny test lub pełny zwrot pieniędzy. Nie obiecujemy zatwierdzenia przez Google, bo nikt nie może go obiecać.

Najczęstsze pytania

Podsumowanie

Ostatnie sprawdzenie zasad: 13 sierpnia 2026 r. Strona FAQ Google o weryfikacji deweloperów została ostatnio zaktualizowana 10 sierpnia 2026 r., zawarta na niej odpowiedź o bezpośrednim sideloadingu pochodzi z 15 lipca 2026 r., a dokumentacja Androida dla Firebase App Distribution została ostatnio zaktualizowana 11 sierpnia 2026 r. Weryfikacja dewelopera Androida jest właśnie wdrażana, więc zakres 30 września, listę uczestniczących sklepów, dostępność ścieżki zaawansowanej i harmonogram na 2027 rok warto sprawdzić na własnych stronach Google, zanim na nich oprzesz decyzje. Ten wpis ma być weryfikowany co tydzień do 30 września 2026 r., ponownie w dniu wejścia wymogu i mniej więcej tydzień po nim, a potem co miesiąc, aż Google poda konkretną geografię albo datę na 2027 rok.