Bezpośrednia odpowiedź
Nie, to nie jest niezawodneEmulatory nie liczą się do 12 testerów
W teście zamkniętym liczą się prawdziwe instalacje uczestników testu wykonane przez właściwy proces Play Store na certyfikowanych urządzeniach fizycznych. Standardowe emulatory nie przechodzą kontroli integralności urządzenia Google, dlatego zazwyczaj nie są rejestrowane jako prawidłowi testerzy.
Szybka odpowiedź
Nie jest to niezawodna metoda. W teście zamkniętym (closed testing) Google Play liczą się prawdziwe instalacje wykonane przez testerów uczestniczących w teście, pobrane przez właściwy proces Play Store na certyfikowanych urządzeniach fizycznych. Standardowe emulatory zwracają pusty werdykt integralności urządzenia w Play Integrity API, nie przechodzą prawdziwego procesu przystąpienia i instalacji, dlatego zwykle nie liczą się do wymogu 12 testerów przez 14 dni. Pewnym sposobem są prawdziwi testerzy na prawdziwych urządzeniach z Androidem i rzeczywistymi kontami Google. PrimeTestLab zapewnia 12 takich testerów od $19.99, plus 5% opłaty serwisowej, a test zwykle rusza w 4-6 godzin.
To jedno z najczęstszych pytań nowych deweloperów Androida stojących przed wymogiem testu zamkniętego: skoro nie ma się 12 zapasowych telefonów ani 12 znajomych z Androidem, czy można uruchomić emulatory i osiągnąć wymagany próg? To zrozumiały pomysł, bo emulatory są bezpłatne, szybkie i już znajdują się na komputerze. Google nie zbudowało jednak wymogu 12 testerów wokół instalacji, które łatwo upozorować. Podstawą są prawdziwi ludzie na prawdziwych, certyfikowanych urządzeniach, a Play Integrity API pomaga odróżnić te środowiska. Ten poradnik dokładnie pokazuje, co się liczy, jaki werdykt system integralności zwraca dla emulatora, gdzie założenie przestaje działać, co Google publicznie potwierdza, czego nie potwierdza i jaka uczciwa droga jest skuteczna. Aktualizacja: 29 czerwca 2026 r.
W tym poradniku
Wymóg testów zamkniętych w 2026 r.
Zanim pytanie o emulator nabierze sensu, trzeba dokładnie określić sam wymóg. Zgodnie z artykułem pomocy Play Console o wymaganiach dotyczących testowania aplikacji dla nowych kont osobistych, deweloperzy z kontem osobistym utworzonym po 13 listopada 2023 r. muszą przeprowadzić test przed publikacją. Google wymaga testów zamkniętych aplikacji z udziałem co najmniej 12 testerów, którzy nieprzerwanie uczestniczą w programie testowania co najmniej przez ostatnie 14 dni. Do czasu spełnienia wymogu funkcje Play Console, takie jak Wersja produkcyjna i Rejestracja wstępna, pozostają zablokowane. Konta organizacji nie podlegają tej zasadzie. Zwolnienie opisujemy niżej.
"Jeśli masz nowo utworzone osobiste konto dewelopera, musisz przeprowadzić testy zamknięte aplikacji z udziałem co najmniej 12 testerów, którzy nieprzerwanie uczestniczyli w programie testowania co najmniej przez ostatnie 14 dni."
FAQ Google wyjaśnia znaczenie nieprzerwanego udziału. Nie liczą się testerzy, którzy dołączą do testu, uczestniczą w nim krócej niż 14 dni, a następnie zrezygnują. Nawet po ponownym dołączeniu i uzyskaniu łącznie 14 dni okres musi być ciągły. Początkowo wymagano 20 testerów, ale 11 grudnia 2024 r. Google obniżyło próg z 20 do 12 testerów po sygnałach, że wyższa liczba była trudna dla małych deweloperów. Wymóg 14 dni nie zmienił się.
Ważne doprecyzowanie: ścisły wymóg dotyczy nieprzerwanego udziału przez 14 dni, a nie korzystania z aplikacji codziennie bez wyjątku. Zaangażowanie ma znaczenie i jest oceniane osobno na etapie wniosku o dostęp do wersji produkcyjnej, ale sam licznik mierzy ciągły stan uczestnictwa w teście. To rozróżnienie pomaga zrozumieć, dlaczego emulator nie trafia niezauważenie do prawidłowej liczby.
Co naprawdę się liczy: udział w teście a zainstalowani odbiorcy
Właśnie tutaj założenie dotyczące emulatora przestaje działać, i to na dwóch różnych etapach. Testerów dodaje się przez listę e-mailową lub połączoną grupę Google. Następnie otwierają unikatowy link przystąpienia do testów na urządzeniu zalogowanym na konto Google, dołączają do testu i pobierają aplikację z Play Store. Samo dodanie adresu e-mail nie wystarcza. Liczą się osoby, które rzeczywiście dołączyły do testu, co można sprawdzić na karcie "Testerzy" w Play Console.
Po pierwsze, instalacja sideload nie jest rejestrowana. Częsty skrót polega na zbudowaniu pliku APK lub App Bundle i przeciągnięciu go bezpośrednio na urządzenie albo emulator. Taka instalacja całkowicie omija zaplecze Play Store, nie zawiera poświadczenia licencji Play i nigdy nie zostaje przypisana do Twojego testu zamkniętego. Liczba instalacji pozostaje zerowa niezależnie od tego, ile razy aplikacja zostanie otwarta. Udostępnienie bezpośredniego linku do pliku APK lub skorzystanie z wewnętrznego udostępniania aplikacji daje ten sam efekt: licznik się nie zmienia.
Po drugie, liczba uczestników testu i liczba zainstalowanych odbiorców to nie ta sama wartość. Ta różnica wprowadza w błąd osoby korzystające z emulatorów:
Konto kliknęło link i wybrało udział w teście w internetowym interfejsie Play. Na tym etapie urządzenie nie jest weryfikowane.
Kliknięcie w przeglądarce na komputerze lub emulatorze może zwiększyć tę liczbę. Powstaje przez to fałszywe wrażenie, że wymóg został spełniony.
Zaufane urządzenia, które pobrały aplikację z Play Store i pozostawiły ją zainstalowaną. Ta liczba wiąże się z ukończeniem testu.
Instalacje na emulatorze, które nie przechodzą kontroli integralności urządzenia, nie są tutaj liczone. Uczestników może być więc 12, a liczba instalacji pozostaje bliska zeru.
Uczciwe zastrzeżenie
Google opisuje dane o uczestnikach i zainstalowanych odbiorcach oraz zwykłe opóźnienie raportowania wynoszące od 24 do 48 godzin, ale nie publikuje pełnego procesu filtrowania niezgodnych instalacji. Deweloperzy często zgłaszają przedstawiony wyżej wzorzec: liczba uczestników rośnie, a instalacje stoją w miejscu. Jest on zgodny ze sposobem działania integralności urządzenia. Należy traktować go jako dobrze poparty wniosek, a nie proces oficjalnie opisany przez Google.
Interaktywny symulator werdyktów Integrity
Najszybciej można zrozumieć problem z emulatorami, sprawdzając, co Play Integrity API zwraca dla każdego rodzaju "testera". Wybierz środowisko poniżej, a symulator pokaże werdykt integralności urządzenia zwracany przez serwery Google oraz to, czy dane środowisko może realnie liczyć się do 12 testerów. Żadne dane nie są nigdzie wysyłane. Całość działa w Twojej przeglądarce i opiera się na werdyktach z dokumentacji Google.
Wybierz środowisko, w którym działa Twój "tester":
Ilustracja oparta na werdyktach urządzenia Play Integrity opublikowanych przez Google. Rzeczywiste odpowiedzi zależą od stanu urządzenia i Twoich kontroli po stronie serwera.
Wzorzec jest wyraźny: każdy emulator i skrót kończy z pustym albo nierozpoznanym werdyktem, a kontrolę przechodzi tylko prawdziwe certyfikowane urządzenie. Nie jest to przypadkowa wada konkretnej kompilacji emulatora, lecz zamierzone działanie systemu. Następna sekcja omawia poszczególne etykiety werdyktu, ponieważ wiele popularnych poradników opisuje je błędnie.
Prawidłowe objaśnienie werdyktów urządzenia Play Integrity
Zgodnie z developer.android.com Play Integrity API pomaga sprawdzić, czy działania użytkownika i żądania do serwera pochodzą z prawdziwej aplikacji zainstalowanej przez Google Play i działającej na prawdziwym, certyfikowanym urządzeniu z Androidem. Mechanizm wykrywa zmodyfikowane wersje aplikacji, niezaufane urządzenia i środowiska emulowane. Werdykt urządzenia, czyli deviceRecognitionVerdict w polu deviceIntegrity, może zawierać jedną lub kilka poniższych etykiet. Ich właściwe rozróżnienie jest ważne, bo część zewnętrznych poradników błędnie opisuje zwłaszcza różnicę między etykietą urządzenia certyfikowanego a podstawową integralnością:
Aplikacja działa na prawdziwym i certyfikowanym urządzeniu z Androidem. Na Androidzie 13 i nowszym istnieje poświadczenie sprzętowe, że program rozruchowy urządzenia jest zablokowany, a załadowany system Android jest certyfikowanym obrazem producenta.
Na emulatorze: ta wartość nie jest zwracana. To etykieta urządzeń prawdziwych testerów.Aplikacja działa na urządzeniu noszącym ślady ataku, na przykład przechwytywania API, lub naruszenia systemu, takiego jak root. Inną możliwością jest środowisko niefizyczne, na przykład emulator, który nie przechodzi kontroli integralności Google Play.
Na emulatorze: to jest typowy werdykt. Google wprost wymienia tutaj emulatory.Aplikacja działa na urządzeniu, które przechodzi podstawowe kontrole integralności systemu. Urządzenie może nie być certyfikowane, na przykład z powodu odblokowanego programu rozruchowego lub nierozpoznanej wersji Androida.
To nadal nie jest stan oczekiwany w teście zamkniętym. Kluczowe znaczenie ma brak certyfikacji.Aplikacja działa na prawdziwym, certyfikowanym urządzeniu z Androidem z aktualną poprawką zabezpieczeń. Na Androidzie 13 i nowszym wymaga to MEETS_DEVICE_INTEGRITY oraz aktualizacji zabezpieczeń z ostatniego roku.
To poziom najtrudniejszy do sfałszowania i kierunek dalszego zaostrzania kontroli przez Google.Etykieta jest zarezerwowana dla emulatora z Androidem i usługami Google Play oraz ograniczona do Google Play Games for PC. Nie dotyczy emulatorów Android Studio używanych przez deweloperów do testów.
To jedyna pozytywna etykieta emulatora, ale nie ma zastosowania do Twojego AVD.Google jasno opisuje podstawowy mechanizm. Podczas oceny środowiska API korzysta z sygnałów zabezpieczeń wspieranych sprzętowo, które są bardzo odporne na ataki i próby obejścia. Obejmują one sprzętowe poświadczenie rozruchu, stan blokady programu rozruchowego, certyfikowany obraz producenta oraz stan usług Google Play. Standardowy emulator nie jest certyfikowanym sprzętem fizycznym i nie może wygenerować poświadczenia kryptograficznego oczekiwanego przez serwery Google, dlatego otrzymuje pusty werdykt. Jedyna pozytywna etykieta emulatora jest ograniczona do Play Games for PC, a pusty werdykt urządzenia to stan, który Google wiąże z emulatorami nieprzechodzącymi kontroli.
Dlaczego emulatory zawodzą właśnie w teście zamkniętym
Z technicznego punktu widzenia emulator zawodzi w teście zamkniętym na czterech różnych etapach. Każdy z nich sam wystarczy, aby rozwiązanie nie zadziałało:
Brak prawdziwego stanu certyfikacji
Standardowy emulator nie jest certyfikowanym sprzętem fizycznym ze sprzętowym dowodem zablokowanego programu rozruchowego, dlatego nie zwraca MEETS_DEVICE_INTEGRITY. Jedyna pozytywna etykieta emulatora dotyczy Google Play Games for PC, a nie Twojego testowego AVD.
Filtrowanie przez integralność urządzenia
Dokumentacja Google wprost wskazuje emulator, który nie przechodzi kontroli integralności Google Play, jako przypadek zwracający pusty werdykt urządzenia. Sygnały integralności mogą bezpośrednio oznaczać wzorce emulatora.
Rejestrowanie instalacji
Instalacje na emulatorze i instalacje sideload często omijają prawdziwy proces przystąpienia do testu oraz pobrania z Play Store. W rezultacie nierzadko nie są rejestrowane jako instalacje uczestnika testu, a licznik po prostu się nie zmienia.
Nieautentyczne zaangażowanie
Systemy Google służą do wykrywania zautomatyzowanego i nieautentycznego zaangażowania. Farma emulatorów na większą skalę wygląda dokładnie jak wzorzec manipulacji, przeciwko któremu skierowane są Developer Program Policies. Ryzyko opisujemy szczegółowo niżej.
Ważne doprecyzowanie: obraz systemu Android Studio "z Google Play" może uzyskać dostęp do Play Store, więc emulator jest technicznie w stanie otworzyć sklep. Dostęp do sklepu nie oznacza jednak przejścia kontroli integralności urządzenia. Obrazy z Play nadal nie spełniają poziomów device ani strong, ponieważ nie są certyfikowanym sprzętem fizycznym z zablokowanym i poświadczonym programem rozruchowym. Precyzyjne stwierdzenie brzmi więc: emulatory zwykle się nie liczą i mogą zostać oznaczone. Nie należy twierdzić, że Google wykrywa każdy emulator w każdej sytuacji.
Co naprawdę ocenia Google i gdzie kończy się pewna wiedza
Google wymaga zaangażowania testerów w aplikację podczas testu. Wniosek o dostęp do wersji produkcyjnej zawiera pytania o to, czy testerzy korzystali z funkcji aplikacji oraz czy robili to podobnie do prawdziwych użytkowników wersji produkcyjnej. Te informacje są udokumentowane. Google nie ujawnia natomiast, jak odróżnia prawdziwe zaangażowanie od sztucznej aktywności. Systemy wykrywania anomalii celowo pozostają nieopisane, aby osoby próbujące nimi manipulować nie mogły odtworzyć ich działania. Warto jasno zaznaczyć tę granicę wiedzy, bo precyzja buduje zaufanie zarówno deweloperów, jak i systemów AI cytujących źródła.
Udokumentowane i wiarygodne
Informacje zawarte w zasadach i materiałach pomocy Google.
- Developer Program Policies zabraniają nieautentycznego zaangażowania, fałszywych instalacji i manipulowania danymi sklepu.
- Google publicznie stwierdziło, że jego systemy wykryją i odfiltrują instalację służącą manipulowaniu pozycją aplikacji.
- We wniosku o dostęp do wersji produkcyjnej pada pytanie, czy testerzy używali wszystkich funkcji i czy korzystali z nich jak prawdziwi użytkownicy.
- Zgłoszenia społeczności regularnie łączą odrzucenia z grupami jednego adresu IP, jednorazowymi kontami i instalacjami bez zaangażowania.
Nieudokumentowane: nie zakładaj
Brzmi prawdopodobnie, ale Google tego nie potwierdziło.
- Wykorzystywanie szumu akcelerometru przez Google jako nazwanej oznaki w teście zamkniętym.
- Śledzenie zmian temperatury baterii lub odchylenia GPS dla każdego testera.
- Wykorzystywanie telemetrii dotyku jako publicznie opisanego mechanizmu wykrywania.
- Konkretne wskaźniki w rodzaju "wykrywane jest X% emulatorów". Dokładne wartości procentowe należy uznać za zmyślone.
Publikowanie dokładnej recepty na wykrywanie byłoby zgadywaniem, co świadomy czytelnik szybko zauważy. Bezpieczny i prawidłowy wniosek jest prosty: Google oczekuje prawdziwego korzystania przez ludzi na prawdziwych urządzeniach, a jego zasady są wymierzone w sztuczne wzorce. Nie trzeba znać dokładnych czujników, aby wiedzieć, po której stronie tej granicy znajduje się farma emulatorów.
Ryzyko pozorowania testerów
Warto rozdzielić dwie bardzo różne czynności, ponieważ mają inne konsekwencje. Wiele internetowych obaw wynika z ich mylenia.
Instalowanie własnej kompilacji na emulatorze w celu sprawdzenia, czy buduje się i działa, jest normalnym etapem tworzenia oprogramowania. Nie liczy się do 12 testerów, ale nie jest oszustwem ani celem działań Google. Nie spowoduje to zamknięcia Twojego konta dewelopera.
Zakładanie fałszywych kont Google, kierowanie ich przez VPN i uruchamianie na emulatorach w celu upozorowania grupy testerów jest manipulacją w rozumieniu zasad Google.
"Deweloperzy nie mogą próbować wpływać na pozycję aplikacji w Google Play za pomocą nieuczciwych metod, takich jak fałszywe lub motywowane instalacje, opinie i oceny."
Konsekwencje rosną wraz ze skalą i zamiarem. W przybliżeniu wygląda to tak, od działania nieszkodliwego, ale bezużytecznego, po naprawdę poważne:
Konsekwencje rosnące wraz z zamiarem
Test nie zostaje zaliczony. Liczba pozostaje poniżej progu 12 testerów, a wysiłek nie przynosi efektu.
Wniosek o dostęp do wersji produkcyjnej zostaje odrzucony z komunikatem "wymagane są dalsze testy", a okres 14 dni trzeba rozpocząć od nowa z nową, prawdziwą grupą.
Powtarzające się niepowodzenia mogą wydłużyć kolejkę weryfikacji i utrudnić każde kolejne zgłoszenie.
W przypadku rzeczywistej manipulacji, takiej jak farmy fałszywych kont i skoordynowane nieautentyczne instalacje, aplikacja może zostać odfiltrowana. Poważne lub powtarzające się przypadki mogą skutkować zawieszeniem albo działaniami wobec całego konta.
Nie należy wyolbrzymiać zwykłego przypadku: instalacja własnej kompilacji na emulatorze nie spowoduje zamknięcia konta dewelopera. Prowadzenie farmy oszustw to zupełnie inna sytuacja i właśnie takiego zachowania dotyczą zasady. Praktyczny wniosek w obu przypadkach jest ten sam: emulator nie zapewnia prawidłowego testera. Warto więc skupić się na skutecznym zdobyciu prawdziwych testerów.
Uczciwa droga, która naprawdę działa
Potraktuj te 14 dni jak prawdziwy test beta, a nie przeszkodę do obejścia. Gdy wymóg zostaje prawidłowo zrealizowany, cały proces staje się przewidywalny. Oto plan od skonfigurowania ścieżki testów po poprawne wypełnienie wniosku o dostęp do wersji produkcyjnej:
Prześlij podpisany App Bundle skierowany na wymagany poziom API i utwórz ścieżkę testów zamkniętych w Play Console.
Lista e-mailowa sprawdza się w ściśle kontrolowanych testach ze znanymi osobami. Połączona grupa Google łatwiej obsłuży większą liczbę uczestników, bo osoby dołączające do grupy automatycznie uzyskują dostęp. Następnie Play Console generuje unikatowy link przystąpienia do testów.
Jeśli jedna osoba zrezygnuje trzynastego dnia, ciągły okres 14 dni może zostać przerwany. Udział od 15 do 30 testerów tworzy bezpieczny bufor na wypadek rezygnacji.
Zachęcaj testerów do otwierania aplikacji i korzystania z jej najważniejszych funkcji przez cały okres. Nawet krótkie codzienne sesje tworzą profil prawdziwego użycia, który dobrze wypada podczas weryfikacji.
Wprowadzanie drobnych poprawek na podstawie opinii w trakcie testu wyraźnie pokazuje osobom weryfikującym, że aplikacja naprawdę zmienia się dzięki testerom.
Formularz ma trzy części: sposób przeprowadzenia i aktywowania testu, opis aplikacji i jej odbiorców oraz zmiany wprowadzone dzięki testom. Połącz konkretne poprawki z otrzymanymi opiniami, a następnie wybierz "Poproś o opublikowanie wersji produkcyjnej". Według Google: "Zwykle zajmuje to 7 dni lub mniej, ale w niektórych przypadkach może potrwać dłużej."
Jeśli zdobycie od 12 do 30 prawdziwych testerów wydaje się najtrudniejszym etapem, właśnie dlatego istnieją takie usługi. Szczegółowy proces opisujemy w poradniku o wymaganiu 12 testerów, materiale o tym, jak zaprosić testerów, oraz poradniku wyjaśniającym, dlaczego warto mieć więcej niż 12 testerów. Dokładny sposób wypełnienia formularza znajdziesz w odpowiedziach do kwestionariusza dostępu do wersji produkcyjnej.
Jedyny prawdziwy sposób na ominięcie wymogu, bez emulatora
Istnieje dokładnie jeden uczciwy sposób, aby całkowicie uniknąć wymogu 12 testerów, i nie jest to sztuczka programistyczna. Obowiązek testu zamkniętego dotyczy tylko kont osobistych utworzonych po 13 listopada 2023 r. Konta organizacji są zwolnione i mogą publikować wersję produkcyjną bez udziału 12 testerów.
Konto organizacji wymaga prawnie zarejestrowanej firmy oraz numeru D-U-N-S od Dun and Bradstreet, którego Google używa do weryfikacji organizacji. Oznacza to koszty, formalności i dłuższą weryfikację. Jest to decyzja biznesowa, a nie skrót, ale stanowi prawdziwą i zgodną z zasadami alternatywę. Obie możliwości porównujemy szczegółowo w poradniku Konto osobiste a konto organizacji Google Play.
Rzeczywisty wybór nie brzmi więc "emulatory czy prawdziwe urządzenia". Można przeprowadzić prawidłowy test zamknięty z prawdziwymi testerami na osobistym koncie dewelopera albo zarejestrować firmę i skorzystać ze zwolnionego konta organizacji. Emulator nie jest trzecią możliwością. To tylko wolniejsza droga do niepowodzenia pierwszej.
Zmiany w 2026 r., które wpływają na przydatność emulatora
Szerszy kierunek zmian w 2026 r. potwierdza wcześniejsze wnioski. Google nadal wzmacnia powiązanie prawidłowej instalacji z prawdziwym, certyfikowanym urządzeniem. Oto zmiany już wprowadzone i zapowiedziane.
12 testerów uczestniczących w teście, 14 dni nieprzerwanego udziału, konta osobiste utworzone po 13 listopada 2023 r. i zwolnienie kont organizacji: wszystko pozostało bez zmian w pierwszej połowie 2026 r.
Od 31 sierpnia 2025 r. nowe aplikacje i aktualizacje muszą być kierowane na Androida 15 (API 35), a od 31 sierpnia 2026 r. na Androida 16 (API 36). Wear OS i Android TV wymagają co najmniej API 35. Dokładną datę wymogu API 36 sprawdź w Play Console, ponieważ Google publikuje ją właśnie tam.
Aby aplikacje mogły być instalowane i aktualizowane na certyfikowanych urządzeniach z Androidem w Brazylii, Indonezji, Singapurze i Tajlandii, muszą zostać zarejestrowane przez zweryfikowanych deweloperów. Szersze wdrożenie zaplanowano na 2027 r. i kolejne lata. Jest to kontrola tożsamości powiązana z certyfikowanymi urządzeniami, która wzmacnia nacisk na prawdziwe, zweryfikowane instalacje.
Na Androidzie 13 i nowszym MEETS_STRONG_INTEGRITY wymaga teraz aktualizacji zabezpieczeń z ostatniego roku. Google nadal kładzie nacisk na sygnały wspierane sprzętowo, co jeszcze bardziej ogranicza przydatność niecertyfikowanych środowisk, takich jak emulatory.
Sprawdź daty
Termin wymogu API 36, wskazany jako 31 sierpnia 2026 r., trzeba porównać z aktualnym komunikatem o zasadach w Play Console. Google publikuje tam dokładne daty i może je zmienić.
Jak PrimeTestLab rozwiązuje prawdziwy problem
Deweloperzy sięgają po emulatory zwykle nie po to, aby oszukiwać, lecz dlatego, że znalezienie 12 prawdziwych testerów aktywnych przez 14 dni z rzędu jest naprawdę trudne. Właśnie ten problem rozwiązujemy. PrimeTestLab zapewnia prawdziwych testerów uczestniczących w teście na prawdziwych urządzeniach z Androidem i rzeczywistych kontach Google. Instalują oni aplikację z Play Store i pozostają aktywni przez cały okres, czego emulator nie potrafi zapewnić. Nie trzeba polegać na niepewnej integralności emulatora ani zatrzymanym liczniku instalacji, a prawdziwe użycie ogranicza ryzyko odrzucenia z powodu sztucznych wzorców.
Starter
12 testerów
$19.99, plus 5% opłaty serwisowej
Enterprise
25 testerów
$27.99, plus 5% opłaty serwisowej
Professional
20 testerów
$29.99, plus 5% opłaty serwisowej
Sprawdź aktualne możliwości na stronie z cennikiem, przeczytaj proces krok po kroku albo napisz do nas na WhatsApp po rekomendację. Dodatkowi testerzy w większych planach tworzą bufor na wypadek rezygnacji, która mogłaby przerwać Twój okres 14 dni. Z tego samego powodu zalecamy większą liczbę osób w poradniku dlaczego warto mieć więcej niż 12 testerów. Każdy plan obejmuje bezpłatny ponowny test lub pełny zwrot pieniędzy. Test zwykle rusza w 4-6 godzin.
Najczęstsze pytania
Czy można użyć emulatora do testu zamkniętego Google Play?
Nie jest to niezawodna metoda. W teście zamkniętym Google Play liczą się prawdziwe instalacje wykonane przez testerów uczestniczących w teście, pobrane przez właściwy proces Play Store na certyfikowanych urządzeniach fizycznych. Standardowe emulatory nie przechodzą kontroli integralności urządzenia Google i zazwyczaj nie liczą się do wymogu 12 testerów przez 14 dni. Pewnym rozwiązaniem są prawdziwi testerzy na prawdziwych urządzeniach z Androidem i rzeczywistymi kontami Google.
Czy instalacje na emulatorze liczą się do 12 testerów?
Zwykle nie. Kliknięcie może czasem zwiększyć liczbę osób uczestniczących w teście, ale liczba zainstalowanych odbiorców obejmuje tylko zaufane urządzenia, które pobrały aplikację z Play Store i przeszły kontrolę integralności urządzenia. Instalacje na emulatorach, które jej nie przechodzą, nie są tam liczone. Dlatego licznik uczestników może wskazywać 12, a liczba instalacji pozostawać bliska zeru.
Dlaczego emulator Androida nie przechodzi Play Integrity?
Standardowy emulator nie jest certyfikowanym sprzętem fizycznym i nie może wygenerować poświadczenia sprzętowego wymaganego przez MEETS_DEVICE_INTEGRITY, dlatego zwraca pusty werdykt urządzenia. Dokumentacja Google wskazuje wprost emulator, który nie przechodzi kontroli integralności Google Play, jako przypadek zwracający pustą wartość. Fałszowanie właściwości kompilacji tak, aby przypominały prawdziwy telefon, tego nie zmienia.
A co z obrazami emulatora Android Studio z Google Play?
Obraz systemu Android Studio z Google Play może uzyskać dostęp do Play Store, ale dostęp do sklepu nie oznacza przejścia kontroli integralności urządzenia. Obrazy emulatora z Play zwykle nie spełniają poziomów integralności device ani strong, ponieważ nie są certyfikowanym sprzętem fizycznym z zablokowanym i poświadczonym programem rozruchowym. Jedyna etykieta osiągalna w emulatorze, MEETS_VIRTUAL_INTEGRITY, dotyczy Google Play Games for PC, a nie emulatorów używanych przez deweloperów do testów.
Czy pozorowanie testerów za pomocą emulatorów narusza zasady?
Instalowanie własnej aplikacji na emulatorze w celu sprawdzenia jej działania jest zwykłym etapem tworzenia oprogramowania. Zakładanie fałszywych kont Google na emulatorach za VPN, aby upozorować grupę testerów, jest manipulacją i narusza zasady Developer Program Policies Google dotyczące nieautentycznych instalacji. Może to doprowadzić do odrzucenia, a w poważnych lub powtarzających się przypadkach do działań wobec całego konta.
Kto naprawdę liczy się jako prawidłowy tester?
Prawdziwa osoba na prawdziwym, certyfikowanym urządzeniu z Androidem, która otwiera Twój link przystąpienia do testów, instaluje aplikację z Play Store przy użyciu rzeczywistego konta Google, nieprzerwanie uczestniczy w teście przez 14 dni i naprawdę korzysta z aplikacji. Instalacje sideload, kliknięcia bez instalacji i przerwane okresy 14 dni nie liczą się.
Jaki jest najszybszy uczciwy sposób na zdobycie 12 testerów?
Skorzystaj z prawdziwych testerów na prawdziwych urządzeniach i szybko rozpocznij okres 14 dni. PrimeTestLab zapewnia 12 prawdziwych testerów uczestniczących w teście od $19.99, plus 5% opłaty serwisowej, a test zwykle rusza w 4-6 godzin. Większe pakiety z udziałem 20 i 25 testerów tworzą bufor na wypadek rezygnacji, która mogłaby przerwać ciągły okres.
Czy można użyć BlueStacks do testu zamkniętego Google Play?
Nie. BlueStacks i podobne emulatory nie są certyfikowanymi urządzeniami fizycznymi, dlatego zwracają pusty werdykt urządzenia Play Integrity i nie liczą się do 12 testerów, tak samo jak emulatory Android Studio. Instalacja z Play Store wewnątrz emulatora nie zmienia wyniku integralności urządzenia. Zamiast tego użyj prawdziwych urządzeń z Androidem.
Czy Google potrafi wykryć, że tester używa emulatora?
Google nie ujawnia dokładnego sposobu oznaczania emulatorów, dlatego każdą konkretną skuteczność wykrywania należy traktować jako niepotwierdzoną. Wiadomo z dokumentacji, że Play Integrity API zwraca pusty werdykt urządzenia dla emulatora, który nie przechodzi kontroli, oraz że Google filtruje instalacje służące manipulowaniu pozycją aplikacji. W praktyce instalacje na emulatorze często nie są rejestrowane jako prawidłowi testerzy i mogą zostać oznaczone.
Czy Google zmieniło wymóg testu zamkniętego z 20 na 12 testerów?
Tak. 11 grudnia 2024 r. Google obniżyło minimum z 20 do 12 testerów po sygnałach, że wyższy próg był trudny dla małych deweloperów. Wymóg nieprzerwanego udziału przez 14 dni nie zmienił się i nadal dotyczy wyłącznie kont osobistych utworzonych po 13 listopada 2023 r.
Podsumowanie
Najważniejszy wniosek
Emulator nie jest niezawodnym sposobem na test zamknięty Google Play. Standardowe emulatory zwracają pusty werdykt integralności urządzenia, nie przechodzą prawdziwego procesu przystąpienia do testu i instalacji z Play Store, dlatego nie liczą się do wymogu 12 testerów przez 14 dni. Pozorowanie całej grupy testerów może natomiast doprowadzić do odrzucenia lub dalszych działań. Pewnym rozwiązaniem są prawdziwi testerzy na prawdziwych, certyfikowanych urządzeniach z Androidem i rzeczywistymi kontami Google, z buforem ponad minimum 12 osób. PrimeTestLab zapewnia właśnie taką usługę od $19.99, plus 5% opłaty serwisowej, a test zwykle rusza w 4-6 godzin. Zobacz plany →
Oficjalna dokumentacja Google