In breve
Un emulatore può contare tra i 12 tester?Il requisito parla di tester e di attivazione continua, non di un tipo di dispositivo
Usa un emulatore per testare la tua app. Non usare gli emulatori per fabbricare i partecipanti al tuo test chiuso. Il requisito pubblicato da Google è di 12 tester attivati per 14 giorni consecutivi, e né i requisiti né la documentazione tecnica esaminati per questa guida specificano se la partecipazione da emulatore conta ai fini di quel minimo. La nostra raccomandazione, maturata gestendo questi test per gli sviluppatori, è più netta di quanto la documentazione debba essere: eseguire la tua build su un emulatore è normale sviluppo ed è del tutto legittimo; mettere istanze di emulatore al posto delle dodici persone non è una scorciatoia che prenderemmo; creare account Google falsi per attivarli da lì è manipolazione e, nella nostra esperienza, il tipo di test che viene rimandato indietro o rifiutato. Controlla i tuoi progressi in Play Console e recluta persone che useranno l’app e ti diranno cosa hanno trovato.
| La domanda | Da cosa dipende | Dove trovi la risposta |
|---|---|---|
| Un emulatore può eseguire la mia app e aiutarmi a testarla? | Dall’immagine di sistema che scegli e dall’app stessa. | Documentazione dell’emulatore di Android Studio. È esattamente lo scopo dello strumento. |
| Un tester può aprire la mia build chiusa su un emulatore? | Dall’account Google, dal fatto che l’attivazione sia stata accettata, dalla release pubblicata e dalle restrizioni che hai impostato. | Configurazione del test in Play Console. Idoneità dell’account, disponibilità della release, compatibilità ed eventuali controlli sul dispositivo che hai configurato. |
| Cosa riporta Play Integrity per quell’emulatore? | Dallo stato del dispositivo, dalla versione di Android e dai campi che la tua app o il tuo backend leggono. | Documentazione di Play Integrity. Risponde alla tua app e al tuo backend; Play Console ne riporta i risultati separatamente. |
| Quella persona conta ai fini dei 12? | Dal fatto che un tester sia attivato nel tuo test chiuso, senza interruzioni, per 14 giorni. | Il requisito di test, che non dice nulla sul tipo di dispositivo o sull’integrità. |
In questa guida
Cosa richiede Google e a chi si applica
Requisito di GoogleLa Guida di Play Console indica che uno sviluppatore con un account personale creato dopo il 13 novembre 2023 deve eseguire un test chiuso prima di pubblicare in produzione, con un minimo di 12 tester attivati senza interruzioni per almeno 14 giorni (requisiti di test per le app). Finché il requisito non è soddisfatto, Produzione e Preregistrazione restano bloccate. Soddisfarlo ti rende idoneo a presentare la domanda; l’approvazione è una revisione a parte. Gli account dell’organizzazione non sono soggetti alla regola. Il requisito in sé è analizzato in il requisito dei 12 tester spiegato.
Per un account sviluppatore personale creato dopo il 13 novembre 2023, l’app ha bisogno di un test chiuso con almeno 12 tester attivati senza interruzioni per 14 giorni prima che lo sviluppatore possa richiedere l’accesso alla produzione.
Google spiega anche cosa intende per attivazione continua. I tester che si attivano, testano per meno di 14 giorni e poi si disattivano non contano ai fini del requisito, e se qualcuno si riattiva in seguito i 14 giorni devono comunque essere consecutivi. Il minimo era 20 finché Google non lo ha ridotto a 12 l’11 dicembre 2024, una modifica che ha aggiunto al suo annuncio del 2023. La durata di 14 giorni non è cambiata.
Leggi il requisito così com’è scritto: riguarda lo stato di attivazione
Osserva quali sostantivi usa il requisito e quali no. Parla di tester e di attivazione continua, non di un modello di dispositivo, di uno stato di certificazione o di un verdetto di integrità. Ne derivano due letture sbagliate. Disinstallare non è la stessa azione di disattivarsi, quindi una disinstallazione non interrompe automaticamente la finestra. E se una persona lascia il test, gli altri non ripartono da zero: la continuità viene tracciata per singola iscrizione.
La verifica del dispositivo dello sviluppatore è un’altra cosa
Google richiede effettivamente un dispositivo Android fisico in un punto preciso, ed è facile scambiarlo per una regola sui tester. I nuovi account sviluppatore personali devono completare la verifica del dispositivo su un dispositivo Android fisico non rootato con Android 10 o versioni successive, con l’accesso effettuato come proprietario dell’account (requisiti per la verifica del dispositivo). Google precisa che potrebbe chiederti di ripetere la verifica in seguito, non necessariamente sullo stesso dispositivo. In ogni caso è il proprietario dell’account che dimostra di avere accesso a un dispositivo, e non dice nulla su cosa usano i tuoi tester.
Il requisito si applica davvero a te?
Si applica agli account personali creati dopo il 13 novembre 2023. Gli account personali più vecchi e gli account dell’organizzazione ne restano fuori, quindi «apri un account dell’organizzazione» è una differenza di idoneità, non un trucco per aggirare la regola. Un account dell’organizzazione richiede un’organizzazione registrata che Google verifica, di norma tramite un numero D-U-N-S, che può essere richiesto gratuitamente. Confrontiamo le due opzioni in account Google Play personale o dell’organizzazione.
Gli emulatori contano tra i 12 tester?
Nulla nella documentazione esaminata qui risponde con un sì o con un no, ed è per questo che il resto della guida separa ciò che è dichiarato da ciò che è dedotto. Le affermazioni rientrano in una di quattro categorie, e l’errore tipico è promuoverne silenziosamente una da una categoria inferiore a una superiore.
Una regola che devi soddisfare: 12 tester, 14 giorni consecutivi, la data limite del 13 novembre 2023, e il fatto che soddisfarla ti permette di presentare la domanda.
Descrizioni accurate del comportamento: verdetti di integrità, immagini di sistema, configurazione del test. Scritte per uno scopo diverso dal decidere chi conta.
Thread sulla Google Play Developer Community e su Reddit. La risposta consigliata nel thread che citiamo suggerisce di ricorrere ad altre persone su dispositivi Android fisici anziché a emulatori. Vale la pena leggerla, ma la pagina avverte che i contenuti potrebbero non essere verificati, e un nome host di Google non è una norma.
Il nostro giudizio: recluta oltre il minimo e non fabbricare partecipazione con emulatori o account falsi. Un consiglio nato dal fare questo lavoro, non una regola, e noi vendiamo assistenza per i test.
Documentato e citabile senza rischi
Dichiarato nelle norme, nelle pagine della guida o nella documentazione per sviluppatori di Google.
- Il requisito in sé: 12 tester attivati per 14 giorni consecutivi, per gli account personali creati dopo il 13 novembre 2023.
- La domanda di accesso alla produzione chiede come si è svolto il test, cos’è l’app e cosa hai cambiato grazie ai test.
- Le Norme del programma per gli sviluppatori vietano di manipolare posizionamento, valutazioni, recensioni o numero di installazioni con mezzi illegittimi.
- Google consiglia di testare su hardware fisico prima del rilascio e documenta il test su emulatore su più versioni e dimensioni di schermo.
Non specificato: non darlo per scontato
Plausibile all’apparenza, e assente dalla documentazione esaminata qui.
- Che un verdetto di Play Integrity decida se un tester conta ai fini dei 12.
- Qualsiasi segnale di rilevamento specifico: rumore dell’accelerometro, variazioni della temperatura della batteria, deriva del GPS, telemetria del tocco, raggruppamento degli IP o età dell’account.
- Qualsiasi percentuale del tipo «X% degli emulatori viene individuato». Tratta le percentuali esatte come non dimostrate, non come misurazioni.
- Un ritardo di report universale, un numero obbligatorio di sessioni giornaliere o un numero obbligatorio di aggiornamenti durante la finestra.
Tester attivati, pubblico installato e accesso alla produzione
Gran parte di questa discussione ruota in realtà attorno a tre numeri di Play Console che vengono trattati come intercambiabili. Non lo sono.
| Cosa stai guardando | Cosa significa | Cosa non ti dice |
|---|---|---|
| Tester attivati | Gli account che hanno accettato il link di attivazione per questo canale. È il sostantivo attorno a cui è scritto il requisito, insieme a quanto a lungo restano attivati. | Se qualcuno ha installato l’app, l’ha aperta o ti ha dato un feedback utile. |
| Pubblico installato | Google lo definisce come gli utenti che hanno la tua app installata su almeno un dispositivo usato negli ultimi 30 giorni. Il dispositivo deve essere stato usato; l’app no. | È una metrica di pubblico, non il contatore dell’accesso alla produzione, e nemmeno un conteggio dei dispositivi che hanno superato un controllo di sicurezza. |
| La checklist per l’accesso alla produzione | La voce della Dashboard che indica quanti tester sono attivati e da quanti giorni consecutivi. È su questo che viene misurato il requisito. | Perché una determinata persona è o non è inclusa. Per quello, controlla l’iscrizione. |
Raggiungere il minimo non equivale a un test convincente. Google può chiedere ulteriori test quando il coinvolgimento dei tester non è sufficiente, anche dopo che 12 tester sono rimasti attivati per 14 giorni consecutivi. Non pubblica alcuna quota di sessioni giornaliere, quindi l’obiettivo è un test che abbia prodotto un uso reale e un feedback reale, non attività fabbricata per sembrare intensa.
Installare al di fuori di Play è un percorso a parte, e non iscrive nessuno. Un Android App Bundle è un formato di pubblicazione, non un file installabile, quindi ciò che viene installato in quel modo è un APK generato a partire da esso. E in qualunque modo arrivi il file (installazione manuale, link condiviso, condivisione interna delle app), non accetta il tuo link di attivazione per conto di nessuno.
Uno scarto tra due di questi numeri è un sintomo, non una diagnosi. Dodici attivazioni con un pubblico installato basso hanno spiegazioni ordinarie: persone che si sono attivate e non hanno mai installato, che hanno installato su un dispositivo che non usano da un po’, ritardi nei report, oppure una release che non è disponibile per loro.
Cosa possiamo e cosa non possiamo dirti qui
Google pubblica il requisito di test e le definizioni di queste metriche, ma non una spiegazione di ogni singolo esito di conteggio, e nessun ritardo di report universale. Leggi la documentazione della metrica specifica, tieni distinto un ritardo osservato da una garanzia pubblicata e segui la checklist qui sotto.
Se un tester non trova o non riesce a installare la tua build chiusa
Controlla questi problemi di configurazione prima di attribuire la colpa all’ambiente. Valgono allo stesso modo per dispositivi fisici ed emulatori.
-
01
L’account Google sbagliato
L’account che ha accettato il link di attivazione deve essere lo stesso con cui si è effettuato l’accesso sul dispositivo e che è selezionato nel Play Store. Su un telefono con più account Google, controlla prima questo quando qualcuno segnala «app non disponibile».
-
02
L’attivazione non è mai stata completata
Il tuo elenco email o il gruppo Google collegato rende una persona idonea; non la iscrive. Deve comunque aprire il link di attivazione e accettarlo, e l’appartenenza al gruppo può richiedere un po’ di tempo prima di avere effetto. Inoltre una build chiusa non compare nella ricerca del Play Store, quindi i tester la raggiungono tramite il link di attivazione e il link allo Store che fornisci loro.
-
03
Un canale in conflitto
Se l’account fa parte anche del tuo test interno, chiedi alla persona di uscire da quel test prima di attivarsi in quello chiuso. Dove i canali si sovrappongono, un utente idoneo riceve il codice versione compatibile più alto disponibile per lui, che potrebbe non essere la release che stai osservando (configurazione del test).
-
04
Nessuna release attiva su quel canale
Un canale chiuso ha bisogno di una release pubblicata ed effettivamente distribuita, alla versione e alla percentuale che pensi. Una bozza non viene distribuita a nessuno. Un’implementazione interrotta blocca la distribuzione successiva, ma i tester che hanno già ricevuto quella versione possono ancora averla installata, quindi controlla quale versione viene servita. Google segnala inoltre che un nuovo link di test, e le modifiche successive, possono richiedere alcune ore prima di diventare disponibili.
-
05
Le tue impostazioni di disponibilità
Disponibilità per Paese e restrizioni sui dispositivi le imposti tu. Per i Paesi, Google legge il Paese dell’account Google Play del tester, che non sempre coincide con il luogo in cui si trova. E se hai abilitato i controlli dei dispositivi nella scheda dello Store basati sull’integrità, questi possono impedire ad alcuni dispositivi di vedere o installare l’app: una restrizione di accesso che hai configurato tu, non una prova di quali tester contano.
-
06
L’ambiente o la build stessa
Solo dopo i cinque punti precedenti. Un emulatore con l’immagine di sistema sbagliata non può nemmeno accedere al Play Store, e Android Studio pubblica i problemi noti per immagini specifiche.
-
07
È la tua app a bloccarlo, non lo Store
Se il download funziona e poi l’app si rifiuta di avviarsi, si tratta di un blocco applicato da te, non della disponibilità su Play. Controlla cosa fa la tua app o il tuo backend con la risposta di Play Integrity prima di concludere che il tester non può ottenere la tua build.
Se il conteggio sembra ancora sbagliato, abbiamo guide dedicate: tester aggiunti ma zero attivati, l’app non è disponibile per un tester e accesso dei tester tramite gruppo Google. Ognuna copre le cause di configurazione più comuni e i controlli ulteriori da eseguire.
Quando il test su emulatore è utile
Gli emulatori sono utili, e Google ne realizza uno. È integrato in Android Studio, e Google consiglia di testare su più versioni di Android e dimensioni di schermo. L’errore non è usare un emulatore; è aspettarsi che faccia un lavoro per cui non è mai stato pensato.
Raccomandazione di PrimeTestLabIterazioni rapide mentre sviluppi. Versioni di Android e dimensioni di schermo che non possiedi. Tablet, lingue, modalità scura, layout da destra a sinistra. Riprodurre un arresto anomalo a comando.
Un giudizio indipendente. Una macchina che esegue cinque dispositivi virtuali è ancora l’opinione di una sola persona.
Come si comporta l’app sull’hardware che le persone possiedono davvero: prestazioni, batteria, fotocamera, notifiche, cambi di rete, la build Android del produttore. Google consiglia di testare su hardware prima del rilascio.
Una garanzia sull’idoneità. Dei buoni telefoni non soddisfano un requisito scritto in termini di tester.
La parte che gli strumenti non possono fornire: qualcuno che si attiva, tiene l’app installata, prova i percorsi a cui non avevi pensato e ti dice cosa lo ha confuso.
La copertura dei dispositivi. Dodici tester possono avere telefoni simili, ed è per questo che i controlli su emulatore restano utili.
Immagini di Android Studio, immagini con Google Play e BlueStacks
Non tutti gli emulatori sono uguali, e la differenza sta nell’immagine di sistema. Un’immagine AOSP non ha app Google. Un’immagine Google APIs aggiunge i servizi Google ma non il Play Store. Un’immagine Google Play include lo Store, e Android Studio contrassegna con il logo Play i profili di dispositivo che la supportano, documentando quei profili Phone come conformi al CTS. Il profilo e l’immagine di sistema sono scelte separate quando crei il dispositivo virtuale, e ti serve l’immagine Play per accedere e installare al suo interno. Anche BlueStacks documenta l’accesso al Play Store. Nulla di tutto questo risolve la questione dell’idoneità: raggiungere lo Store ed essere conteggiati come tester sono esiti distinti.
Se non hai un telefono Android ma vuoi aiutare qualcuno a testare
È una situazione diversa da quella di uno sviluppatore che fabbrica un gruppo di tester, e merita una risposta diretta invece di un’accusa. Aiutare un amico a testare sulla macchina che possiedi non è un inganno. Ciò che nessuno può prometterti è il risultato, perché Google non pubblica come viene conteggiato ciascun partecipante. Se conta, prendi in prestito un telefono Android o usane uno più vecchio ma compatibile. Se usi comunque un emulatore, dillo allo sviluppatore, così può pianificare il test di conseguenza.
Laboratori di dispositivi cloud e report pre-lancio
Firebase Test Lab esegue la tua app su dispositivi nell’infrastruttura di Google, e il report pre-lancio di Play Console esplora automaticamente la tua build. Entrambi sono QA automatizzati legittimi. Nessuno dei due è un partecipante: un’esecuzione automatica non si attiva, non resta attivata per 14 giorni e non ti dice che la schermata di onboarding non aveva senso.
Cosa stabilisce Play Integrity e cosa no
Documentazione tecnica di GooglePlay Integrity è la tecnologia su cui poggia gran parte di questa discussione, quindi vale la pena sapere a cosa serve. Secondo developer.android.com, l’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» (verdetti di integrità). I destinatari di quella risposta sono la tua app e il tuo backend. Anche Play Console ti riporta le risposte di integrità, e un’impostazione separata della scheda dello Store può limitare quali dispositivi possono installare l’app. Niente di tutto questo è il requisito del test chiuso, e niente va letto come se lo fosse.
«The app is running on a genuine and certified Android device.» Su Android 13 e versioni successive questo si accompagna a una prova basata sull’hardware che il bootloader è bloccato e che il sistema operativo è un’immagine certificata del produttore; le versioni precedenti possono basarsi su una valutazione software.
Come il dispositivo appare all’API. Non un’affermazione sull’iscrizione.Documentato come dispositivo con «signs of attack (such as API hooking) or system compromise (such as being rooted)», oppure come app «not running on a physical device (such as an emulator that does not pass Google Play integrity checks)». Il campo può contenere più etichette, quindi si tratta di un’etichetta mancante, non di un valore chiamato «vuoto».
Copre diverse situazioni distinte, quindi non si può risalire a ritroso a una sola causa.«The app is running on a device that passes basic system integrity checks. The device may not be certified.» Qui facoltativa significa che è lo sviluppatore a scegliere se ricevere l’etichetta, cosa che non ha nulla a che vedere con l’attivazione di un tester.
Un’impostazione della risposta, non un’iscrizione.«The app is running on a genuine and certified Android device with a recent security update.» Su Android 13 e versioni successive significa integrità del dispositivo più aggiornamenti di sicurezza recenti nelle partizioni rilevanti; Android 12 e versioni precedenti vengono valutati sull’integrità dell’avvio basata sull’hardware, senza lo stesso test sugli aggiornamenti recenti.
Una soglia alta per il tuo backend. Non una soglia del test chiuso.Documentata per un «Android-powered emulator with Google Play services», nel contesto di Google Play Games su PC, che è una superficie di distribuzione con requisiti propri.
Non è un verdetto sugli emulatori di test di Android Studio, in nessuna direzione.Dispositivo, riconoscimento dell’app e licenza sono campi separati
Tre campi vengono citati come se fossero uno solo, e mescolarli è il punto da cui nasce gran parte della confusione. Il campo dispositivo descrive l’ambiente. Il campo riconoscimento dell’app descrive se il binario in esecuzione corrisponde a ciò che Google Play ha distribuito. Il campo licenza descrive il diritto d’uso e può segnalare l’app come priva di licenza quando l’account non ha un diritto Play per quell’app. Una build installata al di fuori di Play è una questione di licenza e distribuzione, non un verdetto sull’hardware.
Questi esempi spiegano la terminologia. Nulla qui contatta Google, misura il tuo dispositivo, verifica la partecipazione o prevede l’accesso alla produzione. Le risposte reali dipendono dall’app, dalla sua configurazione e dall’ambiente.
| Ambiente | Cosa può mostrare una risposta | Cosa ti dice e cosa no |
|---|---|---|
| Telefono certificato, bootloader bloccato | Il campo dispositivo può includere MEETS_DEVICE_INTEGRITY e, con un aggiornamento di sicurezza recente, MEETS_STRONG_INTEGRITY. | Che il dispositivo soddisfa l’API. Non se quella persona ha accettato il tuo link di attivazione. |
| Emulatore standard di Android Studio | Google documenta un emulatore che non supera i controlli di Play come uno dei motivi per cui non viene restituita alcuna etichetta di riconoscimento del dispositivo. | Che il tuo backend può reagire al risultato. Un’etichetta assente non identifica di per sé un emulatore, e non dice nulla sull’iscrizione di nessuno. |
| Build installata al di fuori di Play | A questo rispondono campi diversi: il riconoscimento dell’app per la corrispondenza di pacchetto e certificato, e la licenza, che può segnalare l’assenza di licenza quando l’account non ha un diritto Play. | Questi campi descrivono il riconoscimento dell’app e il diritto d’uso dell’account. Leggili separatamente: non sono un registro completo di come è stata installata la copia corrente, e non iscrivono nessuno. |
Il riepilogo, quindi, è stretto: Play Integrity dice molto al tuo backend sull’ambiente in cui gira la tua app, e nulla in questa documentazione afferma che quei verdetti decidano quali tester contano.
Un percorso pratico, e come recuperare dopo gli emulatori
Tratta i 14 giorni come una vera beta anziché come un ostacolo. I passaggi qui sotto combinano il processo pubblicato da Google con le nostre raccomandazioni: reclutare oltre il minimo e organizzare il feedback in questo modo sono suggerimenti, non quote aggiuntive di Google. L’obiettivo è un test autentico, non aspettare che il calendario avanzi.
Raccomandazione di PrimeTestLabCarica un App Bundle firmato, crea un canale di test chiuso e pubblica una release al suo interno. Nient’altro funziona finché una release non è attiva su quel canale.
Un elenco email va bene per un gruppo piccolo e conosciuto; un gruppo Google collegato scala più facilmente. In entrambi i casi, ogni persona deve comunque accettare da sé il link di attivazione.
Un consiglio, non una regola. Le persone perdono interesse, cambiano telefono o si disattivano, e chi subentra non eredita la storia di nessuno: i suoi 14 giorni partono quando si iscrive. Reclutare da 15 a 30 persone ti dà margine.
Dai ai tester qualcosa di specifico da provare e un posto semplice in cui riferire. Non è pubblicata alcuna quota di sessioni giornaliere o di screenshot, quindi non fabbricare attività.
Rilascia le modifiche che i test hanno giustificato e tieni un breve registro di cosa è stato segnalato e di cosa hai fatto. Non è pubblicato alcun numero obbligatorio di aggiornamenti, quindi non pubblicare modifiche solo per rispettare una presunta quota di aggiornamenti.
Il modulo chiede come hai condotto il test e coinvolto i tester, cos’è l’app e a chi si rivolge, e cosa hai cambiato di conseguenza. Rispondi a partire dai tuoi appunti. La revisione richiede di solito sette giorni o meno, ma può durare di più.
Se hai già eseguito il test sugli emulatori
-
Apri la checklist per l’accesso alla produzione nella tua Dashboard e leggi cosa dice: quanti tester, quanti giorni consecutivi. Quello è lo stato reale del tuo test.
-
Segui la lista diagnostica qui sopra per chiunque sia iscritto ma non mostri ciò che ti aspetti. Sistema la configurazione prima di trarre conclusioni sui dispositivi.
-
Conserva i progressi che hai ottenuto legittimamente. Nulla di ciò che Google pubblica dice che un test si azzera a causa dell’ambiente usato da un tester.
-
Aggiungi partecipanti autentici e lascia che ogni nuovo tester completi i propri 14 giorni consecutivi di attivazione. Il suo tempo non eredita quello di nessun altro, quindi il test potrebbe dover proseguire oltre la data di fine che avevi in mente. Se la tua app ha problemi reali, questa è anche la fase che li fa emergere.
Se reclutare persone è la parte difficile, comincia dalle opzioni gratuite in sette modi legittimi per trovare 12 tester. Da lì: come invitare i tester, la regola dei 14 giorni consecutivi, aggiornare l’app durante il test e il questionario per l’accesso alla produzione.
Partecipazione autentica e cosa viola davvero le regole
Gran parte dei timori nasce dal confondere tre azioni molto diverse. Non sono la stessa cosa, e nemmeno le loro conseguenze lo sono.
Installare la tua build su un emulatore per verificare che compili, funzioni e abbia l’aspetto giusto è normale lavoro di sviluppo, sullo strumento che Google fornisce proprio per questo. Non è un inganno, e non è ciò a cui mirano i controlli.
Questo è il caso per cui gli sviluppatori ci chiedono aiuto dopo che è andato storto. Google non pubblica alcuna regola sul conteggio degli emulatori, quindi non possiamo dirti che è contro le regole. Possiamo dirti cosa facciamo noi: non costruiamo un test in questo modo, e lo sconsigliamo. L’accesso alla produzione viene giudicato sulle prove di un test reale, e nella nostra esperienza un gruppo assemblato con dispositivi virtuali è il tipo di test che viene rimandato indietro per ulteriori test, o rifiutato.
Creare account Google falsi e attivarli, su emulatori o su qualsiasi altra cosa, è un atto del tutto diverso. Le norme di Google su valutazioni, recensioni e installazioni vietano di tentare di manipolare posizionamento, valutazioni, recensioni o numero di installazioni con mezzi illegittimi.
Quindi la linea pratica riguarda l’inganno, non la virtualizzazione: non creare account né automatizzare attività per falsare chi sta partecipando. Google vieta la manipolazione illegittima delle installazioni e delle altre metriche dello Store. Quella norma, da sola, non stabilisce una regola di conteggio specifica per gli emulatori.
Una precisazione che vale la pena fare: una risposta «More testing required» (ulteriori test richiesti) non costituisce di per sé un provvedimento contro il tuo account. Leggi il messaggio specifico e continua a testare come indica, invece di dedurre penalità automatiche per le revisioni future. Cosa fare dopo quel rifiuto lo analizza punto per punto.
La conclusione pratica è la stessa in tutti e tre i casi. Un emulatore non ti dà una persona in più, quindi l’unica domanda che merita il tuo tempo è come trovare persone reali in modo efficiente.
Dove si colloca PrimeTestLab
Trasparenza commercialeVendiamo assistenza per il test chiuso, quindi leggi questa sezione tenendolo presente. Gli sviluppatori ricorrono agli emulatori perché trovare una dozzina di persone disposte a restare attivate per due settimane è davvero difficile, non perché vogliano imbrogliare. Quella è la parte di cui ci occupiamo noi.
Cosa facciamo
Reclutiamo e coordiniamo 12 o più tester reali, li teniamo iscritti per tutti i 14 giorni e sostituiamo chiunque abbandoni. Il test inizia entro circa da 4 a 6 ore.
Cosa non affermeremo mai
Che un servizio possa garantire la decisione di Google, o che assumere dei tester elimini la revisione. L’accesso alla produzione viene giudicato sul tuo test e sulla tua app.
Se preferisci non pagare
È una scelta del tutto ragionevole, e le vie gratuite descritte in sette modi legittimi per ottenere 12 tester funzionano. Costano tempo invece che denaro.
Ogni piano include una garanzia di rimborso. Puoi anche leggere la procedura passo dopo passo prima di decidere.
Domande frequenti
Posso usare un emulatore per il test chiuso di Google Play?
Usalo per testare la tua app: è per questo che Google lo realizza. Il requisito pubblicato è di 12 tester attivati per 14 giorni consecutivi, e nessuna documentazione esaminata qui dice se un partecipante da emulatore conta ai fini di quel numero. La nostra raccomandazione va oltre la documentazione: testare la tua build su un emulatore va benissimo, usare istanze di emulatore come tester sostitutivi non è qualcosa che faremmo, e attivarsi da account Google falsi è manipolazione che può portare al rifiuto dell’accesso alla produzione.
Un fallimento di Play Integrity significa che un tester non conta?
La documentazione esaminata per questa guida non lo afferma. Play Integrity risponde alla tua app e al tuo backend sull’ambiente in cui l’app è in esecuzione, e Google la documenta separatamente dal requisito del test chiuso. Considera la catena che va dal verdetto di integrità al conteggio dei tester come una deduzione, non come un processo pubblicato.
Mi servono 12 persone, 12 account o 12 telefoni?
Il requisito è scritto in termini di tester attivati senza interruzioni per 14 giorni, il che in pratica significa 12 persone con un proprio account Google che accettano il tuo link di attivazione. Non devi possedere dodici telefoni, e nessuna documentazione di Google richiede hardware di fascia alta o una varietà di produttori. Se puoi essere tu stesso uno dei dodici è spiegato in usare i propri account come tester.
Non ho un telefono Android. Posso comunque aiutare qualcuno a testare la sua app?
Voler aiutare non è un inganno, ed è diverso da uno sviluppatore che fabbrica un gruppo di tester. Nessuno può prometterti onestamente come verrà conteggiata la tua partecipazione. Prendere in prestito un dispositivo Android è la strada a basso rischio; se usi comunque un emulatore, dillo allo sviluppatore, così può tenerne conto nella pianificazione.
Posso usare BlueStacks per il test chiuso di Google Play?
BlueStacks documenta l’accesso al Play Store, e anche un’immagine di Android Studio con Google Play può raggiungere lo Store. Questo conferma che l’accesso al Play Store è possibile, non che la tua specifica build chiusa sarà disponibile: dipende comunque dall’account, dal canale e dalla release. E non risolve nulla nemmeno sul piano dell’idoneità, perché nessuna documentazione di Google dice se un partecipante di questo tipo conta. Considera la pagina di un fornitore come autorevole su quel prodotto e nient’altro, in nessuna direzione.
La verifica del dispositivo dello sviluppatore è la stessa cosa del test chiuso?
No. La verifica del dispositivo è il proprietario dell’account che dimostra di avere accesso a un dispositivo Android fisico non rootato con Android 10 o versioni successive, al momento della configurazione dell’account, e Google può richiederla di nuovo in seguito. Il test chiuso riguarda persone che si attivano in un canale di test. Attore diverso, scopo diverso, pagina della guida diversa.
Se un tester disinstalla l’app, significa che ha lasciato il test?
Disinstallare e disattivarsi sono azioni diverse. Il requisito è scritto in termini di stato di attivazione continua, quindi non dare per scontato che una disinstallazione interrompa la finestra o che l’uscita di una persona azzeri gli altri. Se i progressi sembrano sbagliati, controlla prima la checklist per l’accesso alla produzione e le iscrizioni.
Conclusione
In sintesi
Gli emulatori sono uno strumento di test legittimo e un pessimo sostituto dei partecipanti. Il requisito è di 12 tester attivati per 14 giorni consecutivi, e la documentazione esaminata qui non specifica se un partecipante da emulatore conta. Quindi apri la checklist per l’accesso alla produzione, esegui i controlli di configurazione prima di dare la colpa all’hardware e dedica il resto della finestra a reclutare persone che useranno davvero l’app. La nostra raccomandazione, che la documentazione non è tenuta a esprimere al posto nostro: fabbricare partecipazione con emulatori o account falsi non vale il rischio di un rifiuto. Comincia dai modi gratuiti per trovare 12 tester →
Documentazione ufficiale di Google
Discussione della community, non documentazione
La risposta consigliata in quel thread suggerisce di ricorrere ad altre persone su dispositivi Android fisici anziché a emulatori, e un Product Expert l’ha approvata, il che vale la pena sapere. Resta comunque una discussione della community: non viene citata alcuna norma, e la pagina avverte che i contenuti potrebbero non essere verificati.