W skrócie
Czy emulator może liczyć się do 12 testerów?Wymaganie mówi o testerach i nieprzerwanym udziale w teście, nie o typie urządzenia
Używaj emulatora do testowania swojej aplikacji. Nie używaj emulatorów do fabrykowania uczestników testu zamkniętego. Opublikowane wymaganie Google to 12 testerów zapisanych do testu nieprzerwanie przez 14 dni, a wymagania i dokumentacja techniczna sprawdzone na potrzeby tego poradnika nie określają, czy udział z emulatora liczy się do tego minimum. Nasza własna rekomendacja, wynikająca z prowadzenia takich testów dla deweloperów, jest bardziej stanowcza, niż musi być dokumentacja: uruchamianie własnej kompilacji na emulatorze to zwykła praca programistyczna i nie ma w tym nic złego; podstawianie instancji emulatora w miejsce dwunastu osób to skrót, którego my byśmy nie wybrali; a zakładanie fałszywych kont Google, żeby dołączać z nich do testu, to manipulacja i z naszego doświadczenia właśnie taki test wraca do dalszych testów albo zostaje odrzucony. Sprawdzaj postępy w Konsoli Play i rekrutuj osoby, które będą używać aplikacji i powiedzą ci, co w niej znalazły.
| Pytanie | Co o tym decyduje | Gdzie znaleźć odpowiedź |
|---|---|---|
| Czy emulator uruchomi moją aplikację i pomoże ją przetestować? | Wybrany obraz systemu i sama aplikacja. | Dokumentacja emulatora Android Studio. Dokładnie do tego służy to narzędzie. |
| Czy tester może otworzyć na nim moją zamkniętą kompilację? | Konto Google, to, czy dołączenie do testu zostało zaakceptowane, opublikowana wersja i ograniczenia, które ustawisz. | Konfiguracja testu w Konsoli Play. Uprawnienia konta, dostępność wersji, zgodność i skonfigurowane przez ciebie kontrole urządzeń. |
| Co Play Integrity zgłasza dla takiego urządzenia? | Stan urządzenia, wersja Androida i pola, które odczytuje twoja aplikacja lub backend. | Dokumentacja Play Integrity. Odpowiada twojej aplikacji i backendowi; Konsola Play raportuje to osobno. |
| Czy ta osoba liczy się do 12? | To, czy tester jest zapisany do twojego testu zamkniętego nieprzerwanie przez 14 dni. | Wymaganie dotyczące testów, które nie mówi nic o typie urządzenia ani o integralności. |
W tym poradniku
Czego wymaga Google i kogo to dotyczy
Wymaganie GooglePomoc Konsoli Play mówi, że deweloper z kontem osobistym utworzonym po 13 listopada 2023 r. musi przeprowadzić test zamknięty, zanim opublikuje aplikację w wersji produkcyjnej, z udziałem co najmniej 12 testerów zapisanych do testu nieprzerwanie przez co najmniej 14 dni (wymagania dotyczące testowania aplikacji). Dopóki ten warunek nie jest spełniony, ścieżka produkcyjna i rejestracja wstępna pozostają zablokowane. Spełnienie go daje prawo do złożenia prośby; jej zaakceptowanie to osobna weryfikacja. Kont organizacji zasada nie dotyczy. Samo wymaganie rozkładamy na czynniki pierwsze w tekście wymaganie 12 testerów wyjaśnione.
W przypadku osobistego konta dewelopera utworzonego po 13 listopada 2023 r. aplikacja potrzebuje testu zamkniętego z co najmniej 12 testerami zapisanymi do testu nieprzerwanie przez 14 dni, zanim deweloper będzie mógł poprosić o udostępnienie wersji produkcyjnej.
Google wyjaśnia też, co znaczy nieprzerwanie. Testerzy, którzy dołączą do testu, testują krócej niż 14 dni i potem z niego wystąpią, nie liczą się do wymagania, a jeśli ktoś dołączy ponownie później, 14 dni nadal musi być ciągłe. Minimum wynosiło 20, dopóki Google nie obniżyło go do 12 w dniu 11 grudnia 2024 r., o czym dopisało w swoim ogłoszeniu z 2023 r. Czas trwania, czyli 14 dni, nie zmienił się.
Czytaj wymaganie tak, jak jest napisane: chodzi o status udziału w teście
Zwróć uwagę, jakich rzeczowników wymaganie używa, a jakich nie. Mówi o testerach i nieprzerwanym udziale w teście, nie o modelu urządzenia, stanie certyfikacji ani werdykcie integralności. Wynikają z tego dwa błędne odczytania. Odinstalowanie aplikacji to nie to samo, co wystąpienie z testu, więc odinstalowanie nie przerywa automatycznie okresu. A odejście jednej osoby nie zeruje pozostałych: ciągłość jest liczona osobno dla każdego zapisu.
Weryfikacja urządzenia dewelopera to inne zadanie
Google w jednym miejscu rzeczywiście wymaga fizycznego urządzenia z Androidem i łatwo pomylić to z zasadą dotyczącą testerów. Nowe osobiste konta dewelopera muszą przejść weryfikację urządzenia na fizycznym urządzeniu z Androidem 10 lub nowszym, bez roota, z zalogowanym właścicielem konta (wymagania dotyczące weryfikacji urządzenia). Google zaznacza, że może później poprosić o ponowną weryfikację, niekoniecznie na tym samym urządzeniu. Tak czy inaczej to właściciel konta potwierdza dostęp do urządzenia, a wymaganie nie mówi nic o tym, z czego korzystają twoi testerzy.
Czy to wymaganie w ogóle cię dotyczy?
Dotyczy kont osobistych utworzonych po 13 listopada 2023 r. Starsze konta osobiste i konta organizacji są poza nim, więc „załóż konto organizacji” to różnica w zakresie obowiązywania, a nie sprytne obejście. Konto organizacji wymaga zarejestrowanej organizacji, którą Google weryfikuje, zwykle na podstawie numeru D-U-N-S, o który można wystąpić bezpłatnie. Oba typy kont porównujemy w tekście konto osobiste a konto organizacji w Google Play.
Czy emulatory liczą się do 12 testerów?
Nic w przejrzanej tu dokumentacji nie odpowiada na to prostym tak lub nie, i dlatego reszta tego poradnika oddziela to, co zostało stwierdzone, od tego, co jest wnioskiem. Każde twierdzenie należy do jednego z czterech koszyków, a typowy błąd polega na cichym awansowaniu go z niższego koszyka do wyższego.
Zasada, którą musisz spełnić: 12 testerów, 14 dni bez przerwy, data graniczna 13 listopada 2023 r. i to, że jej spełnienie pozwala złożyć prośbę.
Dokładne opisy działania: werdykty integralności, obrazy systemu, konfiguracja testu. Napisane w innym celu niż rozstrzyganie, kto się liczy.
Wątki w społeczności deweloperów Google Play i na Reddicie. Rekomendowana odpowiedź w wątku, który cytujemy, radzi korzystać z innych osób na fizycznych urządzeniach z Androidem zamiast z emulatorów. Warto to przeczytać, ale strona ostrzega, że treści mogą być niezweryfikowane, a domena Google to jeszcze nie zasady.
Nasz własny osąd: rekrutuj powyżej minimum i nie fabrykuj udziału w teście emulatorami ani fałszywymi kontami. To rada wynikająca z tej pracy, nie zasada, a my sprzedajemy pomoc w testach.
Udokumentowane i można to bezpiecznie cytować
Zapisane w zasadach, na stronach pomocy lub w dokumentacji dla deweloperów Google.
- Samo wymaganie: 12 testerów zapisanych do testu przez 14 dni bez przerwy, dla kont osobistych utworzonych po 13 listopada 2023 r.
- Wniosek o dostęp do wersji produkcyjnej pyta, jak przebiegł test, czym jest aplikacja i co zmieniono w wyniku testów.
- Zasady programu dla deweloperów zabraniają manipulowania pozycją w sklepie, ocenami, opiniami lub liczbą instalacji nieuczciwymi metodami.
- Google zaleca testowanie na fizycznym sprzęcie przed publikacją i dokumentuje testowanie na emulatorze na różnych wersjach i rozmiarach ekranu.
Nieokreślone: nie zakładaj
Brzmi wiarygodnie, ale nie ma tego w przejrzanej tu dokumentacji.
- Że werdykt Play Integrity decyduje, czy tester liczy się do 12.
- Jakikolwiek nazwany sygnał wykrywania: szum akcelerometru, wahania temperatury baterii, dryf GPS, telemetria dotyku, grupowanie adresów IP albo wiek konta.
- Jakakolwiek konkretna liczba typu „X% emulatorów zostaje wykrytych”. Dokładne odsetki traktuj jako niepoparte, a nie jako pomiary.
- Uniwersalne opóźnienie raportowania, wymagana liczba sesji dziennie albo wymagana liczba aktualizacji w trakcie okresu testów.
Testerzy w teście, odbiorcy z zainstalowaną aplikacją i dostęp do wersji produkcyjnej
Większość tego sporu tak naprawdę dotyczy trzech liczb w Konsoli Play, które traktuje się wymiennie. A wymienne nie są.
| Na co patrzysz | Co to znaczy | Czego ci to nie powie |
|---|---|---|
| Testerzy zapisani do testu | Konta, które zaakceptowały link przystąpienia do tej ścieżki testów. To rzeczownik, wokół którego napisano wymaganie, razem z tym, jak długo pozostają zapisane. | Czy ktokolwiek zainstalował aplikację, otworzył ją albo przekazał ci przydatne opinie. |
| Odbiorcy z zainstalowaną aplikacją | Google definiuje ich jako użytkowników, którzy mają twoją aplikację zainstalowaną na co najmniej jednym urządzeniu używanym w ciągu ostatnich 30 dni. Używane musiało być urządzenie, niekoniecznie aplikacja. | To wskaźnik zasięgu, a nie licznik dostępu do wersji produkcyjnej ani liczba urządzeń, które przeszły kontrolę bezpieczeństwa. |
| Lista kontrolna dostępu do wersji produkcyjnej | Pozycja w panelu informująca, ilu testerów jest zapisanych do testu i od ilu dni bez przerwy. Właśnie na tej podstawie mierzy się wymaganie. | Dlaczego konkretna osoba jest na niej albo jej nie ma. To sprawdzisz w zapisach do testu. |
Spełnienie minimum to nie to samo, co przekonujący test. Google może poprosić o dalsze testy, gdy zaangażowanie testerów jest niewystarczające, nawet jeśli 12 testerów było zapisanych do testu przez 14 dni bez przerwy. Nie publikuje żadnego dziennego limitu sesji, więc celem jest test, który dał prawdziwe użycie i prawdziwe opinie, a nie aktywność wyprodukowana po to, żeby wyglądało na ruch.
Instalacja poza Google Play to osobna ścieżka i nikogo nie zapisuje do testu. Android App Bundle to format publikacji, a nie plik do instalacji, więc w ten sposób instalowany jest wygenerowany z niego plik APK. I niezależnie od tego, jak plik trafia na urządzenie (ręczna instalacja, udostępniony link, wewnętrzne udostępnianie aplikacji), nie akceptuje on za nikogo linku przystąpienia do testu.
Rozjazd między dwiema z tych liczb to objaw, a nie diagnoza. Dwanaście osób w teście przy niskiej liczbie odbiorców z zainstalowaną aplikacją ma zwyczajne wyjaśnienia: ludzie dołączyli do testu i nigdy nie zainstalowali aplikacji, zainstalowali ją na urządzeniu, którego ostatnio nie używali, raportowanie ma opóźnienie albo wersja nie jest dla nich dostępna.
Co możemy, a czego nie możemy ci tu powiedzieć
Google publikuje wymaganie dotyczące testów i definicje tych wskaźników, ale nie wyjaśnienie każdego pojedynczego wyniku liczenia ani żadnego uniwersalnego opóźnienia raportowania. Czytaj dokumentację konkretnego wskaźnika, odróżniaj zaobserwowane opóźnienie od opublikowanej gwarancji i przejdź przez poniższą listę kontrolną.
Jeśli tester nie może znaleźć lub zainstalować twojej zamkniętej kompilacji
Zanim zrzucisz winę na środowisko, sprawdź te problemy z konfiguracją. Dotyczą w równym stopniu urządzeń fizycznych i emulatorów.
-
01
Niewłaściwe konto Google
Konto, które zaakceptowało link przystąpienia do testu, musi być tym samym kontem, które jest zalogowane na urządzeniu i wybrane w Play Store. Na telefonie z kilkoma kontami Google sprawdź to jako pierwsze, gdy ktoś zgłasza, że aplikacja jest niedostępna.
-
02
Dołączenie do testu nigdy nie zostało dokończone
Twoja lista e-mailowa lub połączona Grupa dyskusyjna Google daje komuś uprawnienie, ale nie zapisuje go do testu. Ta osoba nadal musi otworzyć link przystąpienia do testu i go zaakceptować, a członkostwo w grupie może zacząć działać z niewielkim opóźnieniem. Zamkniętej kompilacji nie ma też w wyszukiwarce Play Store, więc testerzy docierają do niej przez link przystąpienia do testu i link do sklepu, które im przekażesz.
-
03
Kolidująca ścieżka testów
Jeśli to konto uczestniczy też w twoim teście wewnętrznym, poproś, żeby najpierw opuściło ten test, a dopiero potem dołączyło do zamkniętego. Tam, gdzie ścieżki się nakładają, uprawniony użytkownik dostaje najwyższy zgodny kod wersji, jaki jest dla niego dostępny, a to może nie być wersja, którą obserwujesz (konfiguracja testu).
-
04
Brak aktywnej wersji na tej ścieżce
Ścieżka zamknięta potrzebuje opublikowanej wersji, która faktycznie została wdrożona, w tym kodzie wersji i z tym procentem, o których myślisz. Wersja robocza nie trafia do nikogo. Wstrzymane wdrożenie zatrzymuje dalszą dystrybucję, ale testerzy, którzy już otrzymali tę wersję, mogą nadal mieć ją zainstalowaną, więc sprawdź, która wersja jest wydawana. Google zaznacza też, że nowy link do testu, a także jego późniejsze zmiany, mogą stać się dostępne dopiero po kilku godzinach.
-
05
Twoje własne ustawienia dostępności
Dostępność w krajach i ograniczenia dotyczące urządzeń ustawiasz samodzielnie. W przypadku krajów Google odczytuje kraj konta Google Play testera, który nie zawsze pokrywa się z miejscem, w którym ta osoba siedzi. A jeśli masz włączone oparte na integralności kontrole urządzeń dla strony aplikacji w sklepie, mogą one uniemożliwić niektórym urządzeniom zobaczenie lub zainstalowanie aplikacji: to ograniczenie dostępu skonfigurowane po twojej stronie, a nie dowód na to, którzy testerzy się liczą.
-
06
Środowisko albo sama kompilacja
Dopiero po pięciu powyższych. Emulator z niewłaściwym obrazem systemu w ogóle nie zaloguje się do Play Store, a Android Studio publikuje znane problemy konkretnych obrazów.
-
07
Blokuje to twoja aplikacja, nie sklep
Jeśli pobieranie działa, a aplikacja potem odmawia uruchomienia, to twoje własne egzekwowanie, a nie dostępność w Google Play. Sprawdź, co twoja aplikacja lub backend robi z odpowiedzią Play Integrity, zanim uznasz, że tester nie może dostać twojej kompilacji.
Jeśli liczba nadal wygląda źle, mamy osobne poradniki: testerzy dodani, ale zero w teście, aplikacja niedostępna dla testera oraz dostęp testerów przez Grupę dyskusyjną Google. Każdy omawia typowe przyczyny konfiguracyjne i dalsze kontrole do wykonania.
Kiedy testowanie na emulatorze pomaga
Emulatory są dobre, a Google samo je tworzy. Emulator jest częścią Android Studio, a Google zaleca testowanie na różnych wersjach Androida i rozmiarach ekranu. Błędem nie jest używanie emulatora, tylko oczekiwanie, że zrobi coś, do czego nigdy nie był przeznaczony.
Rekomendacja PrimeTestLabSzybka iteracja w trakcie pracy. Wersje Androida i rozmiary ekranu, których nie masz pod ręką. Tablety, lokalizacje językowe, tryb ciemny, układy od prawej do lewej. Odtwarzanie awarii na żądanie.
Nie da ci niezależnego osądu. Jedna maszyna z pięcioma urządzeniami wirtualnymi to wciąż opinia jednej osoby.
Jak aplikacja zachowuje się na sprzęcie, który ludzie mają w kieszeni: wydajność, bateria, aparat, powiadomienia, zmiany sieci, własna kompilacja Androida od producenta. Google zaleca testowanie na sprzęcie przed publikacją.
Nie da ci gwarancji spełnienia wymagania. Dobre telefony nie spełnią wymagania napisanego o testerach.
To, czego narzędzia nie dostarczą: ktoś, kto dołączy do testu, zostawi aplikację zainstalowaną, wypróbuje ścieżki, o których nie pomyślisz, i powie ci, co go zdezorientowało.
Nie da ci pokrycia urządzeń. Dwunastu testerów może mieć podobne telefony i właśnie dlatego testy na emulatorze wciąż mają swoje miejsce.
Obrazy Android Studio, obrazy z Google Play i BlueStacks
Nie wszystkie emulatory są takie same, a różnica tkwi w obrazie systemu. Obraz AOSP nie ma aplikacji Google. Obraz Google APIs dodaje usługi Google, ale bez Play Store. Obraz Google Play zawiera sklep, a Android Studio oznacza profile urządzeń, które go obsługują, logo Play i dokumentuje te profile telefonów jako zgodne z CTS. Profil i obraz systemu to dwa osobne wybory podczas tworzenia urządzenia wirtualnego, a do zalogowania się i instalowania w jego wnętrzu potrzebujesz obrazu Google Play. BlueStacks również dokumentuje logowanie do Play Store. Nic z tego nie rozstrzyga o uprawnieniach: dotarcie do sklepu i policzenie jako tester to dwa różne wyniki.
Jeśli nie masz telefonu z Androidem, ale chcesz komuś pomóc w testach
To zupełnie inna sytuacja niż deweloper fabrykujący grupę testerów i zasługuje na prostą odpowiedź, a nie na oskarżenie. Pomaganie znajomemu w testach na komputerze, który masz, nie jest oszustwem. Nikt nie może ci jednak obiecać wyniku, bo Google nie publikuje, jak liczony jest każdy uczestnik. Jeśli to ma znaczenie, pożycz telefon z Androidem albo użyj starszego, ale zgodnego urządzenia. Jeśli zamiast tego użyjesz emulatora, powiedz o tym deweloperowi, żeby mógł odpowiednio zaplanować test.
Chmurowe laboratoria urządzeń i raporty przedpremierowe
Firebase Test Lab uruchamia twoją aplikację na urządzeniach w infrastrukturze Google, a raport przedpremierowy w Konsoli Play automatycznie przechodzi przez twoją kompilację. Oba to w pełni uprawnione formy automatycznego QA. Żadne z nich nie jest jednak uczestnikiem: automatyczne uruchomienie nie dołącza do testu, nie pozostaje w nim przez 14 dni i nie powie ci, że ekran wprowadzający był niezrozumiały.
Co Play Integrity ustala, a czego nie
Dokumentacja techniczna GooglePlay Integrity to technologia, na której opiera się większość tego sporu, więc warto wiedzieć, do czego służy. Według developer.android.com interfejs API „helps you check that user actions and server requests are coming from your genuine app, installed by Google Play, running on a genuine and certified Android device” (werdykty integralności). Odbiorcą tej odpowiedzi jest twoja aplikacja i twój własny backend. Konsola Play również raportuje ci odpowiedzi dotyczące integralności, a osobne ustawienie strony aplikacji w sklepie może ograniczać, które urządzenia mogą ją instalować. Nic z tego nie jest wymaganiem dotyczącym testów zamkniętych i niczego z tego nie należy tak odczytywać.
„The app is running on a genuine and certified Android device.” Na Androidzie 13 i nowszym towarzyszy temu sprzętowe poświadczenie, że program rozruchowy jest zablokowany, a system to certyfikowany obraz producenta; wcześniejsze wersje mogą opierać się na ocenie programowej.
Jak urządzenie wygląda z perspektywy API. Nie jest to stwierdzenie o zapisie do testu.Udokumentowany jako urządzenie z „signs of attack (such as API hooking) or system compromise (such as being rooted)” albo aplikacja „not running on a physical device (such as an emulator that does not pass Google Play integrity checks)”. Pole może zawierać kilka etykiet, więc to brak etykiety, a nie wartość o nazwie „blank”.
Obejmuje kilka różnych sytuacji, więc nie da się go odczytać wstecz do jednej przyczyny.„The app is running on a device that passes basic system integrity checks. The device may not be certified.” Opcjonalna znaczy tu, że deweloper decyduje, czy chce otrzymywać tę etykietę, co nie ma nic wspólnego z dołączaniem testera do testu.
Ustawienie odpowiedzi, nie zapis do testu.„The app is running on a genuine and certified Android device with a recent security update.” Na Androidzie 13 i nowszym oznacza to integralność urządzenia plus aktualne poprawki zabezpieczeń na odpowiednich partycjach; Android 12 i starsze są oceniane na podstawie sprzętowo poświadczonej integralności rozruchu, bez tego samego testu aktualności poprawek.
Wysoka poprzeczka dla twojego backendu. Nie jest to próg testów zamkniętych.Udokumentowany dla „Android-powered emulator with Google Play services” w kontekście Google Play Games on PC, czyli kanału dystrybucji z własnymi wymaganiami.
To nie werdykt o emulatorach testowych Android Studio, w żadną stronę.Urządzenie, rozpoznawanie aplikacji i licencja to osobne pola
Trzy pola cytuje się tak, jakby były jednym, a ich mieszanie to źródło większości nieporozumień. Pole urządzenia opisuje środowisko. Pole rozpoznawania aplikacji opisuje, czy uruchomiony plik binarny odpowiada temu, co dystrybuowało Google Play. Pole licencji opisuje uprawnienie i może zgłosić brak licencji, gdy konto nie ma w Google Play uprawnienia do aplikacji. Kompilacja zainstalowana poza Google Play to historia o licencji i dystrybucji, a nie werdykt o sprzęcie.
Te przykłady wyjaśniają terminologię. Nic tutaj nie łączy się z Google, nie mierzy twojego urządzenia, nie weryfikuje udziału w teście ani nie przewiduje dostępu do wersji produkcyjnej. Prawdziwe odpowiedzi zależą od aplikacji, jej konfiguracji i środowiska.
| Środowisko | Co może pokazać odpowiedź | Co to mówi, a czego nie |
|---|---|---|
| Certyfikowany telefon, zablokowany program rozruchowy | Pole urządzenia może zawierać MEETS_DEVICE_INTEGRITY, a przy aktualnych poprawkach zabezpieczeń także MEETS_STRONG_INTEGRITY. | Że urządzenie spełnia wymagania API. Nie mówi, czy ta osoba zaakceptowała twój link przystąpienia do testu. |
| Standardowy emulator Android Studio | Google dokumentuje emulator, który nie przechodzi kontroli Play, jako jeden z powodów, dla których nie jest zwracana żadna etykieta rozpoznania urządzenia. | Że twój backend może zareagować na ten wynik. Brak etykiety sam w sobie nie identyfikuje emulatora i nie mówi nic o czyimkolwiek zapisie do testu. |
| Kompilacja zainstalowana poza Google Play | Odpowiadają na to inne pola: rozpoznawanie aplikacji dla zgodności pakietu i certyfikatu oraz licencja, która może zgłosić brak licencji, gdy konto nie ma uprawnienia w Google Play. | Te pola opisują rozpoznanie aplikacji i uprawnienie konta. Czytaj je osobno: nie są pełnym zapisem tego, jak zainstalowano bieżącą kopię, i nikogo nie zapisują do testu. |
Podsumowanie jest więc wąskie: Play Integrity mówi twojemu backendowi wiele o środowisku, w którym działa aplikacja, a nic w tej dokumentacji nie mówi, że te werdykty decydują o tym, którzy testerzy się liczą.
Praktyczna ścieżka i wyjście z sytuacji po emulatorach
Potraktuj te 14 dni jak prawdziwą betę, a nie jak przeszkodę do przeskoczenia. Poniższe kroki łączą opublikowany proces Google z naszymi własnymi rekomendacjami: rekrutowanie powyżej minimum i takie organizowanie opinii to sugestie, a nie dodatkowe limity Google. Celem jest prawdziwy test, a nie czekanie, aż kalendarz się przesunie.
Rekomendacja PrimeTestLabPrześlij podpisany pakiet App Bundle, utwórz ścieżkę testów zamkniętych i opublikuj na niej wersję. Nic innego nie zadziała, dopóki na tej ścieżce nie będzie aktywnej wersji.
Lista e-mailowa sprawdza się przy małej, znanej grupie; połączona Grupa dyskusyjna Google łatwiej się skaluje. Tak czy inaczej każda osoba nadal sama akceptuje link przystąpienia do testu.
Rada, nie zasada. Ludzie tracą zainteresowanie, zmieniają telefony albo występują z testu, a osoba na zastępstwo nie dziedziczy niczyjej historii: jej 14 dni zaczyna się w chwili zapisu. Rekrutacja od 15 do 30 osób daje ci zapas.
Daj testerom coś konkretnego do wypróbowania i łatwe miejsce do zgłaszania uwag. Google nie publikuje limitu sesji dziennie ani zrzutów ekranu, więc nie fabrykuj aktywności.
Opublikuj zmiany, które uzasadniły testy, i prowadź krótki zapis tego, co zgłoszono i co z tym zrobiono. Google nie publikuje wymaganej liczby aktualizacji, więc nie wydawaj zmian tylko po to, żeby spełnić domniemany limit aktualizacji.
Formularz pyta, jak przeprowadzono test i angażowano testerów, czym jest aplikacja i dla kogo, oraz co zmieniono w jego wyniku. Odpowiadaj na podstawie swoich notatek. Weryfikacja trwa zwykle do siedmiu dni, ale może potrwać dłużej.
Jeśli test przeprowadzono już na emulatorach
-
Otwórz listę kontrolną dostępu do wersji produkcyjnej w swoim panelu i przeczytaj, co mówi: ilu testerów, ile dni bez przerwy. To rzeczywisty stan twojego testu.
-
Przejdź powyższą listę diagnostyczną dla każdego, kto jest zapisany do testu, ale nie pokazuje tego, czego oczekujesz. Napraw konfigurację, zanim wyciągniesz jakiekolwiek wnioski o urządzeniach.
-
Zachowaj postęp, który masz w sposób uprawniony. Nic, co publikuje Google, nie mówi, że test zeruje się z powodu środowiska, z którego korzystał tester.
-
Dodaj prawdziwych uczestników i pozwól każdemu nowemu testerowi przejść własne 14 kolejnych dni udziału w teście. Ich czas nie dziedziczy niczyjego, więc test może musieć potrwać dłużej niż data końcowa, którą masz w planach. Jeśli twoja aplikacja ma prawdziwe problemy, to także ten etap je wykryje.
Jeśli najtrudniejsza jest rekrutacja ludzi, zacznij od bezpłatnych opcji w tekście siedem uczciwych sposobów na znalezienie 12 testerów. Dalej: jak zaprosić testerów, zasada 14 kolejnych dni, aktualizowanie aplikacji w trakcie testów oraz kwestionariusz dostępu do wersji produkcyjnej.
Prawdziwy udział w teście i to, co łamie zasady
Znaczna część obaw bierze się tu ze zlewania trzech bardzo różnych działań w jedno. Nie są tym samym, a ich konsekwencje też nie.
Instalowanie własnej kompilacji na emulatorze, żeby sprawdzić, czy się kompiluje, działa i dobrze wygląda, to zwykła praca inżynierska, na narzędziu, które Google dostarcza właśnie w tym celu. Nie ma w tym oszustwa i nie w to jest wymierzone egzekwowanie zasad.
To właśnie ten przypadek, po którym deweloperzy proszą nas o ratunek, gdy coś poszło nie tak. Google nie publikuje żadnej zasady liczenia emulatorów, więc nie możemy ci powiedzieć, że to wbrew zasadom. Możemy powiedzieć, co robimy my: nie budujemy testu w ten sposób i odradzamy to. Dostęp do wersji produkcyjnej ocenia się na podstawie dowodów prawdziwego testu, a z naszego doświadczenia grupa złożona z urządzeń wirtualnych to taka, która wraca do dalszych testów albo zostaje odrzucona.
Zakładanie fałszywych kont Google i dołączanie z nich do testu, na emulatorach czy na czymkolwiek innym, to zupełnie inny czyn. Zasady Google dotyczące ocen, opinii i instalacji zabraniają prób manipulowania pozycją w sklepie, ocenami, opiniami lub liczbą instalacji nieuczciwymi metodami.
Praktyczna granica przebiega więc na oszustwie, a nie na wirtualizacji: nie zakładaj kont ani nie automatyzuj aktywności, żeby fałszywie przedstawiać, kto bierze udział. Google zabrania nieuczciwego manipulowania liczbą instalacji i innymi wskaźnikami sklepu. Te zasady same w sobie nie ustanawiają jednak żadnej reguły liczenia dotyczącej konkretnie emulatorów.
Jedno sprostowanie warte zrobienia: odpowiedź „wymagane są dalsze testy” sama w sobie nie oznacza działania egzekucyjnego wobec twojego konta. Przeczytaj konkretny komunikat i testuj dalej zgodnie z jego wskazówkami, zamiast zakładać automatyczne kary przy przyszłych weryfikacjach. Tekst co robić po takiej odmowie rozkłada to na czynniki pierwsze.
Praktyczny wniosek jest taki sam dla wszystkich trzech przypadków. Emulator nie daje ci dodatkowej osoby, więc jedyne pytanie warte twojego czasu brzmi: jak sprawnie znaleźć prawdziwych ludzi.
Gdzie w tym wszystkim jest PrimeTestLab
Ujawnienie interesu handlowegoSprzedajemy pomoc w testach zamkniętych, więc czytaj tę sekcję ze świadomością tego. Deweloperzy sięgają po emulatory, bo znalezienie tuzina osób, które pozostaną w teście przez dwa tygodnie, jest naprawdę trudne, a nie dlatego, że chcą oszukiwać. I właśnie tę część robimy my.
Co robimy
Rekrutujemy i koordynujemy 12 lub więcej prawdziwych testerów, utrzymujemy ich w teście przez pełne 14 dni i zastępujemy każdego, kto z niego wypadnie. Do startu testu mija zwykle od 4 do 6 godzin.
Czego nie będziemy twierdzić
Że jakakolwiek usługa może zagwarantować decyzję Google albo że wynajęcie testerów zdejmuje weryfikację. Dostęp do wersji produkcyjnej ocenia się na podstawie twojego testu i twojej aplikacji.
Jeśli wolisz nie płacić
To całkowicie rozsądny wybór, a bezpłatne drogi opisane w tekście siedem uczciwych sposobów na zdobycie 12 testerów działają. Kosztują czas zamiast pieniędzy.
Każdy pakiet obejmuje gwarancję zwrotu pieniędzy. Przed podjęciem decyzji możesz też przeczytać opis procesu krok po kroku.
Najczęściej zadawane pytania
Czy mogę użyć emulatora do testu zamkniętego Google Play?
Użyj go do testowania swojej aplikacji: właśnie po to Google go tworzy. Opublikowane wymaganie to 12 testerów zapisanych do testu przez 14 dni bez przerwy, a żadna przejrzana tu dokumentacja nie mówi, czy uczestnik korzystający z emulatora się do niego liczy. Nasza własna rekomendacja idzie dalej niż dokumentacja: testowanie swojej kompilacji na emulatorze jest w porządku, używanie instancji emulatora jako zastępczych testerów to coś, czego my byśmy nie zrobili, a dołączanie do testu z fałszywych kont Google to manipulacja, przez którą prośba o dostęp do wersji produkcyjnej może zostać odrzucona.
Czy niepowodzenie w Play Integrity oznacza, że tester się nie liczy?
Dokumentacja przejrzana na potrzeby tego poradnika tego nie mówi. Play Integrity odpowiada twojej aplikacji i backendowi na pytanie o środowisko, w którym działa aplikacja, a Google dokumentuje je oddzielnie od wymagania dotyczącego testów zamkniętych. Łańcuch od werdyktu integralności do liczby testerów traktuj jako wniosek, a nie opublikowany proces.
Czy potrzebuję 12 osób, 12 kont czy 12 telefonów?
Wymaganie mówi o testerach zapisanych do testu nieprzerwanie przez 14 dni, co w praktyce oznacza 12 osób z własnymi kontami Google, które zaakceptują twój link przystąpienia do testu. Nie musisz mieć dwunastu telefonów, a żadna dokumentacja Google nie wymaga sprzętu z wyższej półki ani urządzeń różnych producentów. To, czy możesz być jedną z dwunastu osób, omawiamy w tekście używanie własnych kont jako testerów.
Nie mam telefonu z Androidem. Czy mimo to mogę komuś pomóc w testach aplikacji?
Chęć pomocy to nie oszustwo i coś innego niż deweloper fabrykujący grupę testerów. Nikt nie może ci uczciwie obiecać, jak zostanie policzony twój udział. Pożyczenie urządzenia z Androidem to droga niskiego ryzyka; jeśli zamiast tego użyjesz emulatora, powiedz o tym deweloperowi, żeby mógł to uwzględnić w planach.
Czy mogę użyć BlueStacks do testu zamkniętego Google Play?
BlueStacks dokumentuje logowanie do Play Store, a obraz Android Studio z Google Play również może dotrzeć do sklepu. Potwierdza to, że dostęp do Play Store jest możliwy, a nie że twoja konkretna zamknięta kompilacja będzie dostępna: to nadal zależy od konta, ścieżki testów i wersji. Nie rozstrzyga to też niczego o uprawnieniach, bo żadna dokumentacja Google nie stwierdza, czy taki uczestnik się liczy. Stronę producenta traktuj jako autorytet w sprawie tego produktu i niczego więcej, w żadną stronę.
Czy weryfikacja urządzenia dewelopera to to samo, co test zamknięty?
Nie. Weryfikacja urządzenia polega na tym, że właściciel konta potwierdza dostęp do fizycznego urządzenia z Androidem 10 lub nowszym bez roota, przy zakładaniu konta, a Google może o nią poprosić ponownie później. Test zamknięty dotyczy osób dołączających do ścieżki testów. Inny wykonawca, inny cel, inna strona pomocy.
Czy odinstalowanie aplikacji oznacza, że tester opuścił test?
Odinstalowanie i wystąpienie z testu to różne działania. Wymaganie mówi o nieprzerwanym statusie udziału w teście, więc nie zakładaj, że odinstalowanie przerywa okres ani że odejście jednej osoby zeruje pozostałych. Jeśli postęp wygląda źle, najpierw sprawdź listę kontrolną dostępu do wersji produkcyjnej i zapisy do testu.
Podsumowanie
Podsumowanie
Emulatory to pełnoprawne narzędzie testowe i kiepski zamiennik uczestników. Wymaganie to 12 testerów zapisanych do testu przez 14 dni bez przerwy, a przejrzana tu dokumentacja nie określa, czy uczestnik korzystający z emulatora się liczy. Otwórz więc listę kontrolną dostępu do wersji produkcyjnej, przejdź kontrole konfiguracji, zanim obwinisz sprzęt, i resztę okresu poświęć na rekrutację osób, które naprawdę będą używać aplikacji. Nasza własna rekomendacja, której dokumentacja nie musi za nas formułować: fabrykowanie udziału w teście emulatorami lub fałszywymi kontami nie jest warte ryzyka odrzucenia. Zacznij od bezpłatnych sposobów na znalezienie 12 testerów →
Oficjalna dokumentacja Google
Dyskusja społeczności, nie dokumentacja
Rekomendowana odpowiedź w tym wątku radzi korzystać z innych osób na fizycznych urządzeniach z Androidem zamiast z emulatorów, a poparł ją ekspert produktu Google, co warto wiedzieć. To jednak nadal dyskusja społeczności: nie cytuje żadnych zasad, a strona ostrzega, że treści mogą być niezweryfikowane.