Die Kurzfassung
Kann ein Emulator zu den 12 Testern zählen?Die Anforderung nennt Testpersonen und eine fortlaufende Anmeldung, keinen Gerätetyp
Nutzen Sie einen Emulator, um Ihre App zu testen. Nutzen Sie Emulatoren nicht, um die Teilnehmer Ihres geschlossenen Tests künstlich zu erzeugen. Die veröffentlichte Anforderung von Google lautet: 12 Testpersonen, die 14 Tage lang fortlaufend angemeldet bleiben. Die für diesen Leitfaden geprüften Anforderungen und technischen Dokumentationen legen nicht fest, ob eine Teilnahme über einen Emulator zu diesem Minimum zählt. Unsere eigene Empfehlung, aus der Erfahrung mit diesen Tests für Entwickler, ist klarer, als es die Dokumentation sein muss: Den eigenen Build auf einem Emulator laufen zu lassen, ist normale Entwicklung und völlig in Ordnung. Emulator-Instanzen an die Stelle der zwölf Personen zu setzen, ist keine Abkürzung, die wir nehmen würden. Und gefälschte Google-Konten anzulegen, um sich damit anzumelden, ist Manipulation, und nach unserer Erfahrung genau die Art von Test, die zurückgeschickt oder abgelehnt wird. Prüfen Sie Ihren Fortschritt in der Play Console und rekrutieren Sie Menschen, die die App nutzen und Ihnen sagen, was ihnen aufgefallen ist.
| Die Frage | Was darüber entscheidet | Wo sie beantwortet wird |
|---|---|---|
| Kann ein Emulator meine App ausführen und beim Testen helfen? | Das gewählte System-Image und die App selbst. | Die Emulator-Dokumentation von Android Studio. Genau dafür ist das Werkzeug gedacht. |
| Kann ein Tester meinen geschlossenen Build darauf öffnen? | Das Google-Konto, ob die Anmeldung angenommen wurde, das veröffentlichte Release und die Einschränkungen, die Sie gesetzt haben. | Die Testeinrichtung in der Play Console. Kontoberechtigung, Verfügbarkeit des Release, Kompatibilität und alle Geräteprüfungen, die Sie konfiguriert haben. |
| Was meldet Play Integrity dafür? | Gerätezustand, Android-Version und die Felder, die Ihre eigene App oder Ihr Backend ausliest. | Die Play Integrity-Dokumentation. Sie antwortet Ihrer eigenen App und Ihrem Backend; die Play Console berichtet separat darüber. |
| Zählt diese Person zu den 12? | Ob ein Tester 14 Tage lang fortlaufend bei Ihrem geschlossenen Test angemeldet ist. | Die Testanforderung, die nichts über den Gerätetyp oder die Integrität sagt. |
In diesem Leitfaden
Was Google verlangt und für wen es gilt
Google-AnforderungLaut der Play Console-Hilfe von Google muss ein Entwickler mit einem privaten Konto, das nach dem 13. November 2023 erstellt wurde, vor der Veröffentlichung in der Produktion einen geschlossenen Test durchführen, mit mindestens 12 Testpersonen, die mindestens 14 Tage lang fortlaufend angemeldet sind (Anforderungen für App-Tests). Bis das erfüllt ist, bleiben Produktion und Vorregistrierung gesperrt. Wer die Anforderung erfüllt, darf den Antrag stellen; die Genehmigung ist eine eigene Überprüfung. Organisationskonten unterliegen der Regel nicht. Die Anforderung selbst nehmen wir in die 12-Tester-Anforderung erklärt auseinander.
Für ein privates Entwicklerkonto, das nach dem 13. November 2023 erstellt wurde, braucht die App einen geschlossenen Test mit mindestens 12 Testpersonen, die 14 Tage lang fortlaufend angemeldet sind, bevor der Entwickler Produktionszugriff beantragen kann.
Google erklärt auch, was fortlaufend bedeutet. Testpersonen, die sich anmelden, weniger als 14 Tage lang testen und sich dann wieder abmelden, zählen nicht für die Anforderung, und wer sich später erneut anmeldet, muss die 14 Tage trotzdem am Stück erreichen. Das Minimum lag bei 20, bis Google es am 11. Dezember 2024 auf 12 gesenkt hat; diese Änderung hat Google in seiner Ankündigung von 2023 ergänzt. Die Dauer von 14 Tagen blieb unverändert.
Lesen Sie die Anforderung, wie sie geschrieben ist: Es geht um den Anmeldestatus
Achten Sie darauf, welche Begriffe die Anforderung verwendet und welche nicht. Sie nennt Testpersonen und eine fortlaufende Anmeldung, kein Gerätemodell, keinen Zertifizierungsstatus und kein Integritätsurteil. Daraus folgen zwei Fehldeutungen. Deinstallieren ist nicht dieselbe Handlung wie Abmelden, also unterbricht eine Deinstallation nicht automatisch das Zeitfenster. Und wenn eine Person aussteigt, setzt das die anderen nicht zurück: Die Kontinuität wird pro Anmeldung erfasst.
Die Geräteüberprüfung für Entwickler ist eine andere Aufgabe
An einer Stelle verlangt Google tatsächlich ein physisches Android-Gerät, und das lässt sich leicht mit einer Regel für Tester verwechseln. Neue private Entwicklerkonten müssen eine Geräteüberprüfung auf einem nicht gerooteten physischen Android-Gerät mit Android 10 oder höher abschließen, angemeldet als Kontoinhaber (Anforderungen an die Geräteüberprüfung). Laut Google werden Sie möglicherweise später erneut zur Überprüfung aufgefordert, nicht unbedingt auf demselben Gerät. In jedem Fall weist hier der Kontoinhaber den Zugriff auf ein Gerät nach, und das sagt nichts darüber aus, was Ihre Tester verwenden.
Gilt die Anforderung überhaupt für Sie?
Sie gilt für private Konten, die nach dem 13. November 2023 erstellt wurden. Ältere private Konten und Organisationskonten fallen nicht darunter; „ein Organisationskonto anlegen“ ist also ein Unterschied in der Berechtigung und kein cleverer Umweg. Ein Organisationskonto braucht eine registrierte Organisation, die Google überprüft, in der Regel über eine D-U-N-S-Nummer, die kostenlos beantragt werden kann. Beide vergleichen wir in privates vs. Organisationskonto bei Google Play.
Zählen Emulatoren zu den 12 Testern?
Nichts in der hier geprüften Dokumentation beantwortet das mit Ja oder Nein, und deshalb trennt der Rest dieses Leitfadens, was ausdrücklich gesagt wird, von dem, was daraus geschlossen wird. Behauptungen fallen in eine von vier Kategorien, und der übliche Fehler besteht darin, eine stillschweigend von einer niedrigeren in eine höhere Kategorie zu befördern.
Eine Regel, die Sie erfüllen müssen: 12 Testpersonen, 14 fortlaufende Tage, der Stichtag 13. November 2023, und dass die Erfüllung Sie zur Antragstellung berechtigt.
Zutreffende Beschreibungen von Verhalten: Integritätsurteile, System-Images, Testeinrichtung. Für einen anderen Zweck geschrieben als für die Entscheidung, wer zählt.
Threads in der Google Play Developer Community und auf Reddit. Die empfohlene Antwort in dem von uns zitierten Thread rät dazu, andere Personen auf physischen Android-Geräten einzusetzen statt Emulatoren. Lesenswert, aber die Seite warnt, dass Inhalte ungeprüft sein können, und ein Google-Hostname ist keine Richtlinie.
Unser eigenes Urteil: Rekrutieren Sie über das Minimum hinaus, und erzeugen Sie keine Teilnahme mit Emulatoren oder gefälschten Konten. Ein Rat aus der Praxis, keine Regel, und wir verkaufen Hilfe beim Testen.
Dokumentiert und sicher zitierbar
In den Richtlinien, Hilfeseiten oder der Entwicklerdokumentation von Google festgehalten.
- Die Anforderung selbst: 12 Testpersonen, 14 Tage lang fortlaufend angemeldet, für private Konten, die nach dem 13. November 2023 erstellt wurden.
- Der Antrag auf Produktionszugriff fragt, wie der Test gelaufen ist, was die App ist und was Sie aufgrund der Tests geändert haben.
- Die Richtlinien für das Entwicklerprogramm verbieten es, Platzierung, Bewertungen, Rezensionen oder Installationszahlen mit unzulässigen Mitteln zu manipulieren.
- Google empfiehlt, vor dem Release auf physischer Hardware zu testen, und dokumentiert Emulator-Tests über Versionen und Bildschirmgrößen hinweg.
Nicht festgelegt: nichts annehmen
Klingt plausibel und fehlt in der hier geprüften Dokumentation.
- Dass ein Play Integrity-Urteil entscheidet, ob ein Tester zu den 12 zählt.
- Jedes namentlich genannte Erkennungssignal: Rauschen des Beschleunigungssensors, Schwankungen der Akkutemperatur, GPS-Drift, Touch-Telemetrie, IP-Häufung oder Kontoalter.
- Jede konkrete Zahl wie „X % der Emulatoren werden erkannt“. Behandeln Sie exakte Prozentwerte als unbelegt, nicht als Messungen.
- Eine allgemeingültige Berichtsverzögerung, eine vorgeschriebene Zahl täglicher Sitzungen oder eine vorgeschriebene Zahl von Updates im Zeitfenster.
Angemeldete Tester, Zielgruppe mit installierter App und Produktionszugriff
Ein Großteil dieser Diskussion dreht sich in Wirklichkeit um drei Zahlen in der Play Console, die behandelt werden, als wären sie austauschbar. Das sind sie nicht.
| Was Sie sehen | Was es bedeutet | Was es Ihnen nicht sagt |
|---|---|---|
| Angemeldete Tester | Konten, die den Teilnahmelink für diesen Track angenommen haben. Um diesen Begriff ist die Anforderung formuliert, zusammen mit der Dauer, die sie angemeldet bleiben. | Ob jemand installiert, die App geöffnet oder Ihnen brauchbares Feedback gegeben hat. |
| Zielgruppe mit installierter App | Google definiert sie als Nutzer, die Ihre App auf mindestens einem Gerät installiert haben, das sie in den letzten 30 Tagen verwendet haben. Das Gerät muss verwendet worden sein; die App nicht. | Es ist eine Zielgruppenkennzahl, nicht der Zähler für den Produktionszugriff und keine Zahl von Geräten, die eine Sicherheitsprüfung bestanden haben. |
| Die Checkliste für den Produktionszugriff | Der Punkt im Dashboard, der angibt, wie viele Tester angemeldet sind und seit wie vielen fortlaufenden Tagen. Daran wird die Anforderung gemessen. | Warum eine bestimmte Person darin enthalten ist oder nicht. Prüfen Sie dafür die Anmeldung. |
Das Minimum zu erfüllen ist nicht dasselbe wie ein überzeugender Test. Google kann weitere Tests verlangen, wenn das Engagement der Tester nicht ausreicht, selbst wenn 12 Tester 14 Tage lang fortlaufend angemeldet waren. Eine Vorgabe für tägliche Sitzungen veröffentlicht Google nicht; das Ziel ist also ein Test mit echter Nutzung und echtem Feedback, keine Aktivität, die nur beschäftigt aussehen soll.
Eine Installation außerhalb von Google Play ist ein eigener Weg, und er meldet niemanden an. Ein Android App Bundle ist ein Veröffentlichungsformat, keine installierbare Datei; was auf diesem Weg installiert wird, ist ein daraus erzeugtes APK. Und wie auch immer die Datei ankommt, per manueller Installation, geteiltem Link oder interner App-Freigabe: Sie nimmt für niemanden Ihren Teilnahmelink an.
Eine Lücke zwischen zwei dieser Zahlen ist ein Symptom, keine Diagnose. Zwölf Anmeldungen bei einer kleinen Zielgruppe mit installierter App haben ganz gewöhnliche Erklärungen: Leute haben sich angemeldet und nie installiert, sie haben auf einem Gerät installiert, das sie zuletzt nicht genutzt haben, die Berichte hinken nach, oder das Release ist für sie nicht verfügbar.
Was wir Ihnen hier sagen können und was nicht
Google veröffentlicht die Testanforderung und Definitionen für diese Kennzahlen, aber keine Erklärung für jedes einzelne Zählergebnis und keine allgemeingültige Berichtsverzögerung. Lesen Sie die Dokumentation zur jeweiligen Kennzahl, halten Sie eine beobachtete Verzögerung von einer veröffentlichten Zusage getrennt und arbeiten Sie die Checkliste unten durch.
Wenn ein Tester Ihren geschlossenen Build nicht findet oder nicht installieren kann
Prüfen Sie diese Konfigurationsprobleme, bevor Sie das Problem der Umgebung zuschreiben. Sie gelten für physische Geräte und Emulatoren gleichermaßen.
-
01
Das falsche Google-Konto
Das Konto, das den Teilnahmelink angenommen hat, muss das Konto sein, das auf dem Gerät angemeldet und im Play Store ausgewählt ist. Auf einem Smartphone mit mehreren Google-Konten prüfen Sie das zuerst, wenn jemand „App nicht verfügbar“ meldet.
-
02
Die Anmeldung wurde nie abgeschlossen
Ihre E-Mail-Liste oder verknüpfte Google-Gruppe macht jemanden berechtigt; sie meldet ihn nicht an. Die Person muss den Teilnahmelink trotzdem öffnen und annehmen, und eine Gruppenmitgliedschaft kann etwas Zeit brauchen, bis sie wirksam wird. Ein geschlossener Build erscheint auch nicht in der Suche des Play Store; Tester erreichen ihn über den Teilnahmelink und den Store-Link, den Sie ihnen geben.
-
03
Ein kollidierender Track
Wenn das Konto auch in Ihrem internen Test ist, bitten Sie die Person, diesen Test zu verlassen, bevor sie sich für den geschlossenen anmeldet. Wo sich Tracks überschneiden, erhält ein berechtigter Nutzer den höchsten kompatiblen Versionscode, der ihm zur Verfügung steht, und das ist nicht unbedingt das Release, das Sie beobachten (Testeinrichtung).
-
04
Kein aktives Release auf diesem Track
Ein geschlossener Track braucht ein veröffentlichtes Release, das tatsächlich ausgerollt wurde, in der Version und mit dem Prozentsatz, die Sie annehmen. Ein Entwurf wird an niemanden verteilt. Ein angehaltener Rollout stoppt die weitere Verteilung, aber Tester, die diese Version bereits erhalten haben, können sie weiterhin installiert haben; prüfen Sie also, welche Version ausgeliefert wird. Google weist außerdem darauf hin, dass ein neuer Testlink und spätere Änderungen daran einige Stunden brauchen können, bis sie verfügbar sind.
-
05
Ihre eigenen Verfügbarkeitseinstellungen
Länderverfügbarkeit und Geräteeinschränkungen legen Sie selbst fest. Bei Ländern wertet Google das Land des Google Play-Kontos des Testers aus, und das ist nicht immer der Ort, an dem er gerade sitzt. Und wenn Sie integritätsbasierte Geräteprüfungen für den Store-Eintrag aktiviert haben, können diese manche Geräte daran hindern, die App zu sehen oder zu installieren: eine Zugriffsbeschränkung, die Sie konfiguriert haben, kein Beleg dafür, welche Tester zählen.
-
06
Die Umgebung oder der Build selbst
Erst nach den fünf Punkten oben. Ein Emulator mit dem falschen System-Image kann sich gar nicht erst im Play Store anmelden, und Android Studio veröffentlicht bekannte Probleme einzelner Images.
-
07
Ihre App blockiert, nicht der Store
Wenn der Download funktioniert und die App danach den Start verweigert, ist das Ihre eigene Durchsetzung, nicht die Verfügbarkeit bei Google Play. Prüfen Sie, was Ihre App oder Ihr Backend mit der Play Integrity-Antwort macht, bevor Sie schließen, dass der Tester Ihren Build nicht bekommen kann.
Wenn die Zahl weiterhin falsch aussieht, haben wir eigene Anleitungen dafür: Tester hinzugefügt, aber null angemeldet, die App ist für einen Tester nicht verfügbar und Testerzugriff über Google-Gruppen. Jede behandelt die häufigen Konfigurationsursachen und die weiteren Prüfungen, die Sie durchführen sollten.
Wann Tests im Emulator helfen
Emulatoren sind gut, und Google baut selbst einen. Er ist Teil von Android Studio, und Google empfiehlt, über verschiedene Android-Versionen und Bildschirmgrößen hinweg zu testen. Der Fehler ist nicht, einen Emulator zu nutzen, sondern von ihm eine Aufgabe zu erwarten, für die er nie gedacht war.
PrimeTestLab-EmpfehlungSchnelles Iterieren während der Entwicklung. Android-Versionen und Bildschirmgrößen, die Sie nicht besitzen. Tablets, Sprachen, Dunkelmodus, Layouts von rechts nach links. Einen Absturz gezielt reproduzieren.
Ein unabhängiges Urteil. Eine Maschine mit fünf virtuellen Geräten bleibt die Meinung einer einzigen Person.
Wie sich die App auf Hardware verhält, die Menschen tatsächlich besitzen: Leistung, Akku, Kamera, Benachrichtigungen, Netzwerkwechsel, der herstellereigene Android-Build. Google empfiehlt, vor dem Release auf Hardware zu testen.
Eine Garantie für die Berechtigung. Gute Smartphones erfüllen keine Anforderung, die um Testpersonen herum formuliert ist.
Der Teil, den kein Werkzeug liefern kann: jemand, der sich anmeldet, die App installiert lässt, die Abläufe ausprobiert, an die Sie nicht gedacht haben, und Ihnen sagt, was verwirrend war.
Geräteabdeckung. Zwölf Tester besitzen womöglich ähnliche Smartphones, weshalb Prüfungen im Emulator weiterhin ihren Platz haben.
Android Studio-Images, Images mit Google Play und BlueStacks
Nicht alle Emulatoren sind gleich, und der Unterschied liegt im System-Image. Ein AOSP-Image enthält keine Google-Apps. Ein Google APIs-Image ergänzt Google-Dienste, aber keinen Play Store. Ein Google Play-Image enthält den Store, und Android Studio kennzeichnet die Geräteprofile, die ihn unterstützen, mit dem Play-Logo und dokumentiert diese Smartphone-Profile als CTS-konform. Profil und System-Image sind beim Anlegen des virtuellen Geräts zwei getrennte Entscheidungen, und Sie brauchen das Play-Image, um sich darin anzumelden und zu installieren. BlueStacks dokumentiert die Anmeldung im Play Store ebenfalls. Nichts davon klärt die Berechtigung: Den Store zu erreichen und als Tester gezählt zu werden, sind zwei verschiedene Ergebnisse.
Wenn Sie kein Android-Smartphone besitzen, aber jemandem beim Testen helfen möchten
Das ist eine andere Situation als ein Entwickler, der eine Kohorte künstlich erzeugt, und sie verdient eine klare Antwort statt eines Vorwurfs. Einem Freund auf dem eigenen Rechner beim Testen zu helfen, ist keine Täuschung. Was Ihnen niemand versprechen kann, ist das Ergebnis, denn Google veröffentlicht nicht, wie jeder einzelne Teilnehmer gezählt wird. Wenn es darauf ankommt, leihen Sie sich ein Android-Smartphone oder nutzen Sie ein älteres kompatibles Gerät. Wenn Sie stattdessen einen Emulator verwenden, sagen Sie es dem Entwickler, damit er seinen Test entsprechend planen kann.
Cloud-Gerätelabore und Pre-Launch-Berichte
Firebase Test Lab führt Ihre App auf Geräten in der Infrastruktur von Google aus, und der Pre-Launch-Bericht der Play Console durchläuft Ihren Build automatisch. Beides ist legitime automatisierte Qualitätssicherung. Keines von beiden ist ein Teilnehmer: Ein automatisierter Durchlauf meldet sich nicht an, bleibt nicht 14 Tage lang angemeldet und sagt Ihnen nicht, dass der Onboarding-Bildschirm keinen Sinn ergab.
Was Play Integrity belegt und was nicht
Technische Google-DokumentationPlay Integrity ist die Technologie, auf der ein Großteil dieser Diskussion beruht, deshalb lohnt sich ein Blick darauf, wofür sie gedacht ist. developer.android.com beschreibt den Zweck der API im englischen Original so: Sie „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“ (Integritätsurteile). Auf Deutsch: Die API hilft Ihnen zu prüfen, ob Nutzeraktionen und Serveranfragen von Ihrer echten, über Google Play installierten App auf einem echten, zertifizierten Android-Gerät stammen. Der Adressat dieser Antwort sind Ihre App und Ihr eigenes Backend. Die Play Console meldet Ihnen die Integritätsantworten ebenfalls zurück, und eine separate Einstellung im Store-Eintrag kann einschränken, welche Geräte installieren dürfen. Nichts davon ist die Anforderung für den geschlossenen Test, und nichts davon sollte als solche gelesen werden.
„The app is running on a genuine and certified Android device.“ Auf Android 13 und höher kommt das mit einem hardwaregestützten Nachweis, dass der Bootloader gesperrt und das Betriebssystem ein zertifiziertes Hersteller-Image ist; frühere Versionen können auf einer softwaregestützten Bewertung beruhen.
Wie das Gerät für die API aussieht. Keine Aussage über die Anmeldung.Dokumentiert für ein Gerät mit „signs of attack (such as API hooking) or system compromise (such as being rooted)“ oder eine App „not running on a physical device (such as an emulator that does not pass Google Play integrity checks)“. Das Feld kann mehrere Labels enthalten; es handelt sich also um ein fehlendes Label, nicht um einen Wert namens „leer“.
Es deckt mehrere verschiedene Situationen ab und lässt sich deshalb nicht auf eine einzige Ursache zurückrechnen.„The app is running on a device that passes basic system integrity checks. The device may not be certified.“ Optional bedeutet hier, dass der Entwickler entscheidet, ob er das Label erhält; mit der Anmeldung eines Testers hat das nichts zu tun.
Eine Antworteinstellung, keine Anmeldung.„The app is running on a genuine and certified Android device with a recent security update.“ Auf Android 13 und höher bedeutet das Geräteintegrität plus aktuelle Sicherheitsupdates in den relevanten Partitionen; Android 12 und niedriger wird anhand der hardwaregestützten Boot-Integrität bewertet, ohne dieselbe Prüfung auf aktuelle Updates.
Eine hohe Hürde für Ihr eigenes Backend. Kein Schwellenwert für den geschlossenen Test.Dokumentiert für einen „Android-powered emulator with Google Play services“ im Kontext von Google Play Games on PC, einer Vertriebsplattform mit eigenen Anforderungen.
Kein Urteil über Test-Emulatoren aus Android Studio, in keine Richtung.Gerät, App-Erkennung und Lizenzierung sind getrennte Felder
Drei Felder werden zitiert, als wären sie eines, und ihre Vermischung ist der Punkt, an dem die meiste Verwirrung beginnt. Das Feld Gerät beschreibt die Umgebung. Das Feld App-Erkennung beschreibt, ob die laufende Binärdatei dem entspricht, was Google Play ausgeliefert hat. Das Feld Lizenzierung beschreibt die Berechtigung und kann „unlicensed“ melden, wenn das Konto keine Play-Berechtigung für die App hat. Ein außerhalb von Google Play installierter Build ist eine Frage von Lizenzierung und Vertrieb, kein Hardware-Urteil.
Diese Beispiele erklären Begriffe. Nichts hier kontaktiert Google, misst Ihr Gerät, überprüft eine Teilnahme oder sagt den Produktionszugriff voraus. Echte Antworten hängen von der App, ihrer Konfiguration und der Umgebung ab.
| Umgebung | Was eine Antwort zeigen kann | Was das sagt und was nicht |
|---|---|---|
| Zertifiziertes Smartphone, gesperrter Bootloader | Das Gerätefeld kann MEETS_DEVICE_INTEGRITY enthalten, und mit einem aktuellen Sicherheitsupdate auch MEETS_STRONG_INTEGRITY. | Dass das Gerät die API zufriedenstellt. Nicht, ob diese Person Ihren Teilnahmelink angenommen hat. |
| Standard-Emulator aus Android Studio | Google dokumentiert einen Emulator, der die Play-Prüfungen nicht besteht, als einen der Gründe dafür, dass kein Label zur Geräteerkennung zurückgegeben wird. | Dass Ihr eigenes Backend auf das Ergebnis reagieren kann. Ein fehlendes Label identifiziert für sich genommen keinen Emulator, und es sagt nichts über die Anmeldung von irgendjemandem aus. |
| Außerhalb von Google Play installierter Build | Darauf antworten andere Felder: die App-Erkennung für den Abgleich von Paket und Zertifikat sowie die Lizenzierung, die „unlicensed“ melden kann, wenn das Konto keine Play-Berechtigung hat. | Diese Felder beschreiben App-Erkennung und Kontoberechtigung. Lesen Sie sie getrennt: Sie sind keine vollständige Aufzeichnung davon, wie die aktuelle Kopie installiert wurde, und sie melden niemanden an. |
Das Fazit ist also eng gefasst: Play Integrity sagt Ihrem eigenen Backend viel über die Umgebung, in der Ihre App läuft, und nichts in dieser Dokumentation besagt, dass diese Urteile darüber entscheiden, welche Tester zählen.
Ein praktischer Weg, und die Rettung nach Emulatoren
Behandeln Sie die 14 Tage als echten Betatest und nicht als Hürde. Die Schritte unten verbinden den veröffentlichten Ablauf von Google mit unseren eigenen Empfehlungen: Über das Minimum hinaus zu rekrutieren und Feedback auf diese Weise zu organisieren, sind Vorschläge, keine zusätzlichen Vorgaben von Google. Das Ziel ist ein echter Test, nicht das Warten darauf, dass der Kalender weiterrückt.
PrimeTestLab-EmpfehlungLaden Sie ein signiertes App Bundle hoch, erstellen Sie einen geschlossenen Test-Track und veröffentlichen Sie ein Release darauf. Nichts anderes funktioniert, bevor auf diesem Track ein Release live ist.
Eine E-Mail-Liste passt zu einer kleinen, bekannten Gruppe; eine verknüpfte Google-Gruppe lässt sich leichter skalieren. In beiden Fällen nimmt jede Person den Teilnahmelink weiterhin selbst an.
Ein Rat, keine Regel. Menschen verlieren das Interesse, wechseln das Smartphone oder melden sich ab, und ein Ersatz erbt niemandes Verlauf: Seine 14 Tage beginnen mit seiner Anmeldung. Mit 15 bis 30 Personen haben Sie Spielraum.
Geben Sie den Testern etwas Konkretes zum Ausprobieren und einen einfachen Weg, sich zurückzumelden. Es gibt keine veröffentlichte Vorgabe für tägliche Sitzungen oder Screenshots, also erzeugen Sie keine künstliche Aktivität.
Veröffentlichen Sie die Änderungen, die der Test gerechtfertigt hat, und halten Sie kurz fest, was gemeldet wurde und was Sie getan haben. Eine vorgeschriebene Zahl von Updates ist nicht veröffentlicht; veröffentlichen Sie also keine Änderungen nur, um eine vermutete Update-Quote zu erfüllen.
Das Formular fragt, wie Sie den Test durchgeführt und die Tester eingebunden haben, was die App ist und für wen sie gedacht ist und was Sie daraufhin geändert haben. Beantworten Sie es anhand Ihrer Notizen. Die Überprüfung dauert in der Regel höchstens sieben Tage, kann aber auch länger dauern.
Wenn Sie Ihren Test bereits auf Emulatoren durchgeführt haben
-
Öffnen Sie die Checkliste für den Produktionszugriff in Ihrem Dashboard und lesen Sie, was dort steht: wie viele Tester, wie viele fortlaufende Tage. Das ist der tatsächliche Stand Ihres Tests.
-
Arbeiten Sie die Diagnoseliste oben für jede Person durch, die angemeldet ist, aber nicht das zeigt, was Sie erwarten. Beheben Sie die Konfiguration, bevor Sie irgendetwas über Geräte schließen.
-
Behalten Sie den Fortschritt, den Sie rechtmäßig haben. Nichts, was Google veröffentlicht, besagt, dass ein Test wegen der Umgebung zurückgesetzt wird, die ein Tester verwendet hat.
-
Nehmen Sie echte Teilnehmer auf und lassen Sie jeden neuen Tester seine eigenen 14 aufeinanderfolgenden Tage der Anmeldung abschließen. Seine Zeit erbt nichts von anderen, der Test muss also womöglich über das Enddatum hinauslaufen, das Sie im Kopf hatten. Wenn Ihre App echte Probleme hat, ist das auch der Teil, der sie findet.
Wenn das Rekrutieren der schwierige Teil ist, beginnen Sie mit den kostenlosen Möglichkeiten in sieben legitime Wege zu 12 Testern. Von dort aus: Tester einladen, die Regel der 14 aufeinanderfolgenden Tage, die App während des Tests aktualisieren und der Fragebogen zum Produktionszugriff.
Echte Teilnahme und was gegen die Regeln verstößt
Ein Großteil der Angst hier entsteht, weil drei sehr verschiedene Handlungen miteinander verschwimmen. Sie sind nicht dasselbe, und ihre Folgen auch nicht.
Den eigenen Build auf einem Emulator zu installieren, um zu prüfen, dass er kompiliert, läuft und richtig aussieht, ist normale Entwicklungsarbeit, auf dem Werkzeug, das Google dafür ausliefert. Das ist keine Täuschung, und darauf zielt die Durchsetzung nicht ab.
Das ist der Fall, bei dem Entwickler uns um Rettung bitten, nachdem er schiefgegangen ist. Google veröffentlicht keine Zählregel für Emulatoren, wir können Ihnen also nicht sagen, dass es gegen die Regeln verstößt. Wir können Ihnen sagen, was wir tun: Wir bauen einen Test nicht auf diese Weise, und wir raten davon ab. Der Produktionszugriff wird anhand von Belegen für einen echten Test beurteilt, und nach unserer Erfahrung ist eine aus virtuellen Geräten zusammengestellte Kohorte genau die Art, die zu weiteren Tests zurückgeschickt oder abgelehnt wird.
Gefälschte Google-Konten anzulegen und sich damit anzumelden, auf Emulatoren oder irgendetwas anderem, ist eine völlig andere Handlung. Die Richtlinie zu Bewertungen, Rezensionen und Installationen von Google verbietet den Versuch, Platzierung, Bewertungen, Rezensionen oder Installationszahlen mit unzulässigen Mitteln zu manipulieren.
Die praktische Grenze verläuft also bei der Täuschung, nicht bei der Virtualisierung: Legen Sie keine Konten an und automatisieren Sie keine Aktivität, um falsch darzustellen, wer teilnimmt. Google verbietet die unzulässige Manipulation von Installationen und anderen Store-Kennzahlen. Diese Richtlinie begründet für sich genommen keine emulatorspezifische Zählregel.
Eine Richtigstellung, die sich lohnt: Eine Antwort „weitere Tests erforderlich“ begründet für sich genommen keine Durchsetzungsmaßnahme gegen Ihr Konto. Lesen Sie die konkrete Meldung und testen Sie weiter, wie sie es vorgibt, statt automatische Nachteile für künftige Überprüfungen abzuleiten. Was nach dieser Ablehnung zu tun ist nimmt das im Einzelnen auseinander.
Die praktische Schlussfolgerung ist bei allen dreien dieselbe. Ein Emulator verschafft Ihnen keine zusätzliche Person, die einzige Frage, die Ihre Zeit wert ist, lautet also, wie Sie echte Menschen effizient finden.
Wo PrimeTestLab ins Bild passt
Kommerzieller HinweisWir verkaufen Hilfe beim geschlossenen Test, lesen Sie diesen Abschnitt also mit diesem Wissen. Entwickler greifen zu Emulatoren, weil es wirklich schwer ist, ein Dutzend Menschen zu finden, die zwei Wochen lang angemeldet bleiben, und nicht, weil sie betrügen wollen. Genau diesen Teil übernehmen wir.
Was wir tun
Wir rekrutieren und koordinieren 12 oder mehr echte Tester, halten sie die vollen 14 Tage angemeldet und ersetzen jeden, der aussteigt. Der Test beginnt innerhalb von etwa 4 bis 6 Stunden.
Was wir nicht behaupten
Dass irgendein Dienst die Entscheidung von Google garantieren kann oder dass gemietete Tester die Überprüfung überflüssig machen. Der Produktionszugriff wird anhand Ihres Tests und Ihrer App beurteilt.
Wenn Sie lieber nicht zahlen möchten
Das ist eine völlig vernünftige Entscheidung, und die kostenlosen Wege in sieben legitime Wege zu 12 Testern funktionieren. Sie kosten Zeit statt Geld.
Jeder Plan enthält eine Geld-zurück-Garantie. Sie können vor der Entscheidung auch den Ablauf Schritt für Schritt lesen.
Häufig gestellte Fragen
Kann ich einen Emulator für den geschlossenen Test bei Google Play nutzen?
Nutzen Sie einen, um Ihre App zu testen: Dafür baut Google ihn. Die veröffentlichte Anforderung lautet 12 Testpersonen, die 14 Tage lang fortlaufend angemeldet sind, und keine hier geprüfte Dokumentation sagt, ob ein Teilnehmer auf Emulatorbasis dazu zählt. Unsere eigene Empfehlung geht über die Dokumentation hinaus: Den eigenen Build auf einem Emulator zu testen ist in Ordnung, Emulator-Instanzen als Ersatz für Tester einzusetzen würden wir nicht tun, und die Anmeldung über gefälschte Google-Konten ist Manipulation, die zur Ablehnung des Produktionszugriffs führen kann.
Bedeutet ein fehlgeschlagenes Play Integrity-Urteil, dass ein Tester nicht zählt?
Die für diesen Leitfaden geprüfte Dokumentation sagt das nicht. Play Integrity gibt Ihrer eigenen App und Ihrem Backend Auskunft über die Umgebung, in der die App läuft, und Google dokumentiert es getrennt von der Anforderung für den geschlossenen Test. Behandeln Sie die Kette vom Integritätsurteil zur Zählung der Tester als Schlussfolgerung, nicht als veröffentlichten Ablauf.
Brauche ich 12 Personen, 12 Konten oder 12 Smartphones?
Die Anforderung ist um Testpersonen herum formuliert, die 14 Tage lang fortlaufend angemeldet sind; in der Praxis heißt das 12 Personen mit eigenem Google-Konto, die Ihren Teilnahmelink annehmen. Sie müssen keine zwölf Smartphones besitzen, und keine Google-Dokumentation verlangt Premium-Hardware oder eine Streuung über mehrere Hersteller. Ob Sie selbst eine der zwölf Personen sein können, behandelt eigene Konten als Tester nutzen.
Ich besitze kein Android-Smartphone. Kann ich trotzdem jemandem beim Testen seiner App helfen?
Helfen zu wollen ist keine Täuschung, und es ist etwas anderes als ein Entwickler, der eine Kohorte künstlich erzeugt. Niemand kann Ihnen ehrlich versprechen, wie Ihre Teilnahme gezählt wird. Ein geliehenes Android-Gerät ist der risikoarme Weg; wenn Sie stattdessen einen Emulator verwenden, sagen Sie es dem Entwickler, damit er das einplanen kann.
Kann ich BlueStacks für den geschlossenen Test bei Google Play nutzen?
BlueStacks dokumentiert die Anmeldung im Play Store, und ein Android Studio-Image mit Google Play erreicht den Store ebenfalls. Das bestätigt, dass der Zugriff auf den Play Store möglich ist, nicht, dass Ihr konkreter geschlossener Build verfügbar sein wird: Das hängt weiterhin von Konto, Track und Release ab. Über die Berechtigung sagt es ebenfalls nichts, weil keine Google-Dokumentation festlegt, ob ein solcher Teilnehmer zählt. Behandeln Sie eine Herstellerseite als Autorität für dieses Produkt und für nichts weiter, in keine Richtung.
Ist die Geräteüberprüfung für Entwickler dasselbe wie der geschlossene Test?
Nein. Bei der Geräteüberprüfung weist der Kontoinhaber bei der Kontoeinrichtung den Zugriff auf ein nicht gerootetes physisches Android-Gerät mit Android 10 oder höher nach, und Google kann sie später erneut verlangen. Beim geschlossenen Test geht es um Personen, die sich für einen Test-Track anmelden. Anderer Akteur, anderer Zweck, andere Hilfeseite.
Bedeutet das Deinstallieren der App, dass ein Tester den Test verlassen hat?
Deinstallieren und Abmelden sind verschiedene Handlungen. Die Anforderung ist um den fortlaufenden Anmeldestatus herum formuliert; gehen Sie also nicht davon aus, dass eine Deinstallation das Zeitfenster unterbricht oder dass der Ausstieg einer Person die anderen zurücksetzt. Wenn der Fortschritt falsch aussieht, prüfen Sie zuerst die Checkliste für den Produktionszugriff und die Anmeldung.
Fazit
Zusammenfassung
Emulatoren sind ein legitimes Testwerkzeug und ein schlechter Ersatz für Teilnehmer. Die Anforderung lautet 12 Testpersonen, die 14 Tage lang fortlaufend angemeldet sind, und die hier geprüfte Dokumentation legt nicht fest, ob ein Teilnehmer auf Emulatorbasis zählt. Öffnen Sie also Ihre Checkliste für den Produktionszugriff, arbeiten Sie die Konfigurationsprüfungen durch, bevor Sie die Hardware verantwortlich machen, und nutzen Sie den Rest des Zeitfensters, um Menschen zu rekrutieren, die die App tatsächlich verwenden. Unsere eigene Empfehlung, die die Dokumentation nicht für uns aussprechen muss: Teilnahme mit Emulatoren oder gefälschten Konten zu erzeugen, ist das Ablehnungsrisiko nicht wert. Beginnen Sie mit den kostenlosen Wegen zu 12 Testern →
Offizielle Google-Dokumentation
Community-Diskussion, keine Dokumentation
Die dort empfohlene Antwort rät dazu, andere Personen auf physischen Android-Geräten einzusetzen statt Emulatoren, und ein Produktexperte hat sie bestätigt, was man wissen sollte. Es bleibt trotzdem Community-Diskussion: Es wird keine Richtlinie zitiert, und die Seite warnt, dass Inhalte ungeprüft sein können.