Risposta rapida
Un rifiuto per Broken Functionality significa che il revisore di Google ha rilevato che la versione che hai inviato si è arrestata, si è chiusa forzatamente, si è bloccata o ha funzionato in modo anomalo; gli esempi di Google sono app che non si installano, che si installano ma non si caricano, o che si caricano ma non rispondono. È una decisione sulle norme relativa a una versione, non un rifiuto dell’accesso in produzione, e Google afferma che un rifiuto di per sé non incide sullo stato del tuo account sviluppatore. Riproduci il problema sulla build distribuita da Play, verifica che i revisori possano accedere tramite i Dettagli di accesso (prima Accesso all’app), correggi ogni canale interessato, poi invia per la revisione la versione corretta. Presenta ricorso solo quando puoi dimostrare che la valutazione era sbagliata.
Aggiornato al 16 ottobre 2026. Ogni regola di questa pagina è stata verificata in quella data sulle pagine delle norme di Google Play e nel Centro assistenza di Play Console, e ognuna ha un link dove viene usata. Le segnalazioni degli sviluppatori citate più avanti documentano ciò che gli sviluppatori hanno visto nel 2026, non la diagnosi di Google sulle loro app, e non viene proposta alcuna classifica delle cause perché nessun dataset pubblico la supporta.
Questa guida tratta i rifiuti di una versione in base alla norma Broken Functionality. Se Google ha negato l’accesso in produzione dopo il tuo test chiuso, o ti ha detto che sono necessari altri test, si tratta di una decisione diversa con una soluzione diversa: leggi piuttosto cosa fare quando Google Play dice che sono necessari altri test e perché le richieste dopo il test chiuso vengono rifiutate.
Cosa trovi in questa guida
Cosa significa Broken Functionality su Google Play?
È una delle due sezioni della norma di Google Functionality, Content, and User Experience (funzionalità, contenuti ed esperienza utente). L’altra sezione, Limited Functionality and Content, riguarda le app con uno scopo troppo limitato. Broken Functionality riguarda un’app che non funziona così come è stata inviata.
Non consentiamo app che si arrestano in modo anomalo, si chiudono forzatamente, si bloccano o comunque funzionano in modo anomalo.
Sotto quella frase Google elenca tre esempi di violazioni comuni: app che non si installano, app che si installano ma non si caricano, e app che si caricano ma non rispondono. Leggili come tre punti in cui cercare. Un revisore che non riesce a installare la build, che vede una schermata vuota o un caricamento infinito, o che tocca un controllo senza che succeda nulla può generare lo stesso avviso.
Nei link meno recenti del Centro assistenza e nelle discussioni dei forum potresti ancora trovare il nome Minimum Functionality. La sezione attuale delle norme si chiama Limited Functionality and Content e riguarda le app di solo testo statico o PDF, le app con pochissimi contenuti e le app progettate per non fare nulla. Un avviso può citare l’una o l’altra sezione, e le soluzioni sono diverse, quindi leggi quale nomina il tuo avviso prima di cambiare qualsiasi cosa.
Quattro decisioni che vengono confuse tra loro
| Decisione | Di cosa si tratta | Da dove iniziare |
|---|---|---|
| Broken Functionality | Di cosa si trattaPer il revisore la versione inviata si è arrestata, si è bloccata, non si è caricata o non ha risposto. | Da dove iniziareRiproduci il problema sulla build distribuita da Play, correggilo su ogni canale interessato, invia di nuovo. |
| Limited Functionality and Content | Di cosa si trattaL’app funziona ma offre troppo poco in termini di scopo o contenuti specifici. | Da dove iniziareAggiungi funzionalità reali. La sola correzione di un bug non risolve questo caso. |
| Dettagli di accesso mancanti o non funzionanti | Di cosa si trattaI revisori non sono riusciti a superare un login, un abbonamento, un paywall, un codice monouso o un controllo geografico. | Da dove iniziareAggiorna i Dettagli di accesso in Contenuti dell’app, poi invia la modifica per la revisione. |
| Accesso in produzione non concesso | Di cosa si trattaDopo il test chiuso, Google ha deciso che l’app ha bisogno di altri test o non è pronta per la produzione. | Da dove iniziareUn processo separato, senza un avviso a livello di codice. Vedi sono necessari altri test. |
Dove mostra Google cosa non ha funzionato?
Inizia dall’email di Google sulla violazione e dalla pagina Stato delle norme in Play Console. Insieme indicano la norma e la versione interessata, e Google afferma che Stato delle norme mostra anche eventuali informazioni aggiuntive disponibili. Screenshot, dettagli del dispositivo e stack trace non sono garantiti, quindi non aspettarli.
Apri Play Console, seleziona l’app e apri la sua pagina Stato delle norme. Annota quattro cose prima di toccare il codice: la sezione delle norme citata, il codice di versione e il canale esaminati, la data e qualsiasi prova allegata. Controlla anche l’email e le notifiche di Play Console, perché è lì che Google indica quale norma ha violato la versione.
Come sono davvero gli avvisi del 2026
Non esiste un’unica email per Broken Functionality che ricevono tutti, e qualsiasi pagina che ne pubblica una come modello esatto sta tirando a indovinare. Gli sviluppatori che hanno pubblicato i loro avvisi nel 2026 descrivono livelli di dettaglio molto diversi:
- Un’etichetta dell’avviso che recita "Broken Functionality: Unresponsive UI elements" (elementi dell’interfaccia che non rispondono), pubblicata il 2 settembre 2026 da uno sviluppatore la cui app mostrava una schermata offline con un pulsante per riprovare durante la prima sincronizzazione dei dati (Community di assistenza di Play Console).
- Un esempio del revisore che recita "For example, your app does not open or load." (ad esempio, la tua app non si apre o non si carica), citato a giugno 2026 da uno sviluppatore di giochi la cui schermata del titolo in realtà si caricava. L’autore ha poi riferito che il gioco è stato pubblicato dopo aver cambiato il modo in cui il pulsante Indietro di Android lo chiudeva.
- Un avviso che uno sviluppatore ha descritto ad agosto 2026 come composto da sole due parole, "Broken functionality", senza nient’altro.
Sono estratti riportati dagli sviluppatori, non email di Google autenticate, e ognuno è un singolo caso. Mostrano la gamma di dettagli che potresti ricevere, non cosa dirà il tuo avviso né perché la tua app non ha superato la revisione.
Se il tuo avviso è vago
Considera la norma citata come un sintomo da riprodurre, non come una diagnosi. I cinque controlli della prossima sezione sono ordinati in modo che ognuno escluda un punto diverso in cui il problema può nascondersi.
Cosa controllare per primo dopo un rifiuto per Broken Functionality?
Fai cinque controlli sulla versione esatta esaminata da Google. Sono ordinati dal più economico da escludere al più difficile, non in base a quanto spesso si verifica ogni causa, perché nessun dato pubblico indica la frequenza di ciascuna.
Cinque controlli, in ordine
Installa la build distribuita da Play, non la tua build di debug
Installa dal tuo canale di test su un dispositivo pulito, con un account Google che non ha mai usato l’app, poi aprila come farebbe un revisore. Google Play firma le build che distribuisce con la tua chiave di firma dell’app (Utilizzare la firma dell’app di Play), quindi qualsiasi servizio che verifica l’impronta di un certificato, come Google Sign-In, Maps o una chiave API limitata per nome del pacchetto e SHA-1, può funzionare nella build di debug e fallire in quella dello store. Nel 2025 uno sviluppatore ha ricondotto un errore presente solo nella release a un’autorizzazione Internet mancante nel manifest di produzione.
Verifica che il revisore riesca a entrare
Se una parte dell’app si trova dietro un login, un abbonamento, una posizione o un altro blocco, Google ti chiede di fornire i dettagli di accesso. Controlla che i Dettagli di accesso (prima Accesso all’app) contengano credenziali che funzionano oggi, da qualsiasi paese, senza un codice monouso. La prossima sezione spiega come fare.
Testa il backend dall’esterno della tua rete
Le schermate di login e quelle con i dati falliscono quando il server non è raggiungibile dalla rete del revisore. Nel 2026 alcuni sviluppatori hanno ricondotto gli errori a una regola del firewall involontaria che bloccava la richiesta di un codice di accesso, e hanno segnalato un errore di attendibilità del certificato mostrato in una schermata di accesso. Testa con la rete dati mobile e con un’altra rete, e da un altro paese se il tuo server filtra il traffico per area geografica.
Tocca ogni controllo visibile e apri ogni schermata vuota
Ogni pulsante e ogni link deve rispondere con contenuti appropriati. La checklist di Google per Broken Functionality nella Community di assistenza di Play Console dice: “Assicurati che la tua app non abbia pagine vuote o bianche prive di avvisi o messaggi di errore appropriati.” Rimuovi le funzioni incomplete invece di pubblicare un pulsante che non fa nulla, e verifica che ogni funzione promessa dalla tua scheda dello store funzioni davvero nella build. Per un elenco legittimamente vuoto, ad esempio quando non ci sono ancora elementi salvati, aggiungi una frase che lo spieghi e un’azione successiva. Se la tua navigazione è insolita, ad esempio toccare in un punto qualsiasi per continuare, aggiungi un indizio visibile che un utente alla prima apertura non possa perdere.
Controlla l’avvio, il tasto Indietro e i report che Play ha già
Apri l’app a freddo, ruotala, mandala in background e riportala in primo piano, e premi Indietro in ogni schermata. Poi leggi il rapporto pre-lancio e Android vitals per la versione esaminata. Un arresto anomalo registrato lì è la prova più solida che otterrai, mentre un report pulito ha dei limiti che spiega la sezione dopo la prossima.
Come fornire i dettagli di accesso ai revisori di Google?
In Play Console vai su Norme e programmi, poi Contenuti dell’app, poi Dettagli di accesso. La sezione si chiamava Accesso all’app, quindi i post meno recenti e alcune pagine tradotte del Centro assistenza usano ancora quel nome.
Se l’intera app o parti di essa sono soggette a restrizioni in base a credenziali di accesso, dettagli di accesso, abbonamenti, posizione o altre forme di autenticazione, devi fornire tutti i dettagli necessari per consentire l’accesso alla tua app.
Aggiungi o aggiorna le istruzioni
- Apri Play Console e vai alla pagina Contenuti dell’app (Norme e programmi > Contenuti dell’app).
- In Dettagli di accesso, seleziona Inizia, oppure Gestisci se hai già aggiunto delle istruzioni.
- Seleziona + Aggiungi nuove istruzioni e inserisci i dettagli di accesso. Usa il campo Altre istruzioni per qualsiasi cosa insolita, come una password monouso, l’autenticazione a più fattori o un login con più di due campi.
- Salva le modifiche. Puoi aggiungere fino a cinque set di istruzioni.
- Vai a Panoramica della pubblicazione, trova la modifica in Modifiche pronte per essere inviate per la revisione e seleziona Invia per la revisione. Il solo salvataggio non invia nulla.
Cosa conta come accesso funzionante
I Requisiti di Play Console di Google chiedono di “fornire un account demo attivo, le informazioni di accesso e tutte le altre risorse necessarie a Google Play per esaminare la tua app”. I requisiti di Google per i dettagli di accesso spiegano cosa significa:
- Un account attivo e riutilizzabile, non un invito monouso né una prova gratuita che scade durante la revisione.
- Credenziali che superano i codici monouso e la verifica in due passaggi, perché il revisore non può ricevere il codice che invii a un telefono o a una casella email.
- Un accesso che funziona da qualsiasi luogo se l’app applica restrizioni geografiche, e l’accesso completo alle funzioni a pagamento o riservate che il revisore deve vedere, senza alcun addebito.
- Dettagli scritti in inglese e tenuti aggiornati. Se cambi la password o elimini l’account di test, aggiorna i Dettagli di accesso il giorno stesso.
- Se l’accesso richiede qualcosa che non è testo, come un codice QR o un codice a barre, genera un URL statico e aggiungilo ai Dettagli di accesso. Se l’app chiede agli utenti di impostare un proprio PIN o usa un login tramite social, spiega nelle istruzioni come può superarlo un revisore.
Un accesso mancante non è la stessa cosa di un login che non funziona
Se l’avviso cita i Dettagli di accesso, nessuna modifica al codice serve finché i dettagli di accesso non vengono corretti e inviati per la revisione. Se le credenziali erano corrette ed è stato il login stesso a fallire, si tratta di un problema di Broken Functionality, e il controllo del backend descritto sopra è il punto da cui partire.
E se l’app funziona sul tuo telefono e Google non ha inviato screenshot?
Allora non è il tuo telefono l’ambiente in cui si è verificato il problema. Riproducilo sulla build dello store, su un dispositivo pulito e su un’altra rete, e leggi i due report che Play Console ha già per quella versione prima di decidere qualsiasi cosa.
Il rapporto pre-lancio
Lo trovi in Test e release > Test > Rapporto pre-lancio. Google lo genera automaticamente quando carichi un app bundle o un APK, compatibilmente con la capacità disponibile, eseguendo l’app su dispositivi di test. Controlla quali schermate ha effettivamente raggiunto la scansione: se si è fermata alla schermata di login, non ha mai visto il resto dell’app. Google aggiunge un limite che vale la pena conoscere: “Le credenziali possono essere inserite automaticamente solo nelle app Android che utilizzano widget Android standard.” (Usare un rapporto pre-lancio per individuare i problemi). Un report pulito è una prova, non una promozione. Google dice lo stesso dei suoi controlli pre-revisione: “Superare tutti i controlli pre-revisione non garantisce il superamento del processo formale di revisione dell’app”.
Android vitals
Lo trovi in Monitora e migliora > Android vitals > Arresti anomali e ANR. Google raccoglie questi dati solo dagli utenti che hanno scelto di condividere i dati di utilizzo e diagnostica (Monitorare la qualità tecnica con Android vitals), quindi una nuova app in un piccolo test potrebbe non mostrare nulla. Una pagina di Android vitals vuota non dimostra che l’app non si sia mai arrestata.
Persone reali su dispositivi reali
Un test chiuso esiste proprio per trovare questo tipo di problema prima di una release pubblica. Tester con telefoni, versioni di Android e reti diverse raggiungono le schermate che raggiunge un revisore, e i loro feedback ti dicono dove qualcosa si rompe. Questo ti aiuta a trovare e correggere i difetti; non cambia il modo in cui Google esamina l’app. Se ti servono le basi sul canale in sé, vedi come funziona il test chiuso di Google Play.
Conviene correggere e reinviare, o presentare ricorso?
Correggi e reinvia quando riesci a riprodurre un errore o a trovare una causa plausibile. Presenta ricorso quando hai prove che la valutazione citata è sbagliata. Non reinviare mai la stessa build senza modifiche: Google chiede agli sviluppatori di non ripubblicare un’app rifiutata finché non avranno risolto la violazione.
Correggere, chiarire o presentare ricorso?
Rispondi a tre domande sul tuo avviso e sui tuoi test. Nulla di ciò che scegli esce da questa pagina.
Rispondi alle domande per vedere un consiglio. Se non riesci a riprodurre un errore, decide la terza domanda.
Correggi, poi reinvia su ogni canale
Correggi e reinviaHai un errore riproducibile, che è la situazione migliore in cui trovarsi. Correggilo, testa la correzione sulla build dello store, poi segui i passaggi di reinvio qui sotto, così nessun bundle non conforme resta attivo su alcun canale.
Testa la build dello store prima di decidere
Prima testaUna build di debug non è ciò che ha eseguito il revisore. Installa dal tuo canale di test su un dispositivo pulito con un account nuovo, su una rete che non controlli, e fai i cinque controlli. Decidi solo dopo.
Correggi i Dettagli di accesso, poi invia per la revisione
Correzione dell’accessoAggiorna le istruzioni con credenziali riutilizzabili che aggirano i codici monouso, salva, poi invia la modifica per la revisione da Panoramica della pubblicazione. Google afferma che puoi farlo senza contattare il team di assistenza per le norme né attenderne la risposta.
Aggiungi uno scopo, non solo correzioni
RielaboraLimited Functionality and Content riguarda quanto fa l’app. Aggiungi funzioni o contenuti reali e specifici dell’app prima di reinviare; una correzione di stabilità non risponde a questa valutazione.
Rendi evidente il design, poi decidi
ChiarisciAnche se una schermata offline, uno stato vuoto o un gesto insolito sono voluti, un revisore potrebbe comunque considerarli un malfunzionamento. Aggiungi un indizio visibile, una spiegazione e un’azione successiva. Puoi presentare ricorso con delle prove, ma una schermata più chiara elimina il dubbio anche per il prossimo revisore.
Presenta ricorso con delle prove
RicorsoHai testato la build dello store su un dispositivo pulito e su un’altra rete e non hai trovato nulla che non vada. Presenta ricorso una volta, con il codice di versione, il dispositivo e la versione di Android, i passaggi esatti e una registrazione dello schermo del flusso citato nell’avviso.
Reinviare una versione corretta
I passaggi di reinvio di Google sono più che caricare un nuovo codice di versione:
- Leggi la norma citata nell’email e nelle notifiche, e verifica l’app anche rispetto alle altre norme; Google avverte che ulteriori violazioni possono portare a ulteriori provvedimenti.
- Aggiorna ogni tipo di release che contiene la versione interessata, non solo la produzione: inclusi i canali di test aperto, chiuso e interno.
- Carica l’app bundle corretto e disattiva quelli non conformi. Google avverte che, se non li disattivi, il reinvio non va a buon fine e le versioni pubblicate potrebbero essere rimosse.
- In ogni canale interessato, seleziona Gestisci canale e Crea nuova release, aggiungi il bundle corretto (o elimina una bozza che contiene quello in violazione) e assicurati che la versione non conforme sia elencata in Non incluse.
- Salva, seleziona Rivedi release e avvia l’implementazione.
Dopodiché la modifica resta in attesa di elaborazione. Google afferma: “L’elaborazione può richiedere da qualche ora fino a sette giorni (o più in casi eccezionali)” (Controllare quando le modifiche all’app vengono esaminate e pubblicate).
Corretta, ma l’avviso è ancora lì
Se una versione corretta è pubblicata e Stato delle norme mostra ancora il problema, confronta i codici di versione e i canali citati nell’avviso con ciò che è attivo adesso: un bundle non conforme rimasto su un canale di test è la prima cosa da escludere. Una versione più recente non elimina automaticamente ogni voce relativa ai provvedimenti. Se tutto corrisponde, contatta l’assistenza di Play Console indicando i codici di versione, i canali interessati e l’eventuale riferimento di una richiesta precedente.
Presentare ricorso contro la decisione
Google ripristina le app quando ha commesso un errore e verifica che l’app non viola le sue norme. Per presentare ricorso, segui le istruzioni nell’email di notifica oppure usa il modulo di ricorso di Google. Puoi presentare un ricorso per ogni provvedimento (Gestire le violazioni delle norme e i ricorsi), e Google risponde ai ricorsi in cinese, inglese, giapponese e coreano. Google non pubblica alcun tempo di risposta per i ricorsi, e le segnalazioni degli sviluppatori mescolano le risposte ai ricorsi con le revisioni successive delle versioni, quindi pianifica senza una data.
Scrivi il ricorso come una raccolta di prove, non come uno sfogo: il codice di versione esaminato, il dispositivo e la versione di Android su cui hai testato, i passaggi esatti, una registrazione dello schermo del flusso citato nell’avviso e cosa hai cambiato, se hai cambiato qualcosa.
Un rifiuto per Broken Functionality danneggia il tuo account o il tuo test chiuso?
Un rifiuto di per sé non incide sullo stato del tuo account sviluppatore. Rifiuti ripetuti possono portare alla sospensione, e le sospensioni contano come strike, quindi correggi prima di reinviare. Cosa comporti un rifiuto per un test chiuso in corso non è documentato.
La pagina Procedura di applicazione delle norme di Google spiega la differenza:
- “I rifiuti non influiscono sullo stato del tuo account sviluppatore Google Play.”
- “Se un aggiornamento di un’app esistente viene rifiutato, la versione dell’app pubblicata prima dell’aggiornamento resterà disponibile su Google Play.”
- “La sospensione può verificarsi a seguito di violazioni delle norme gravi o multiple, nonché di ripetuti rifiuti o rimozioni di app.”
Google non pubblica alcun numero di rifiuti che sia sicuro. Reinviare lo stesso errore è esattamente lo schema descritto dalla terza frase.
E il test chiuso di 14 giorni?
Il requisito di test di Google chiede agli account personali creati dopo il 13 novembre 2023 almeno 12 tester che abbiano attivato il test continuamente per almeno 14 giorni prima di richiedere l’accesso in produzione. Non dice se il rifiuto per le norme di una versione sul canale chiuso azzeri, sospenda o mantenga quel periodo, e le affermazioni dei forum in un senso o nell’altro sono supposizioni. Cosa puoi verificare: se i tuoi tester hanno ancora una versione approvata sul canale, e cosa mostra la Dashboard sull’accesso in produzione. Mantieni i tester attivi mentre correggi, e chiedi all’assistenza di Play Console del tuo caso se la Dashboard cambia. La regola in sé è spiegata in cosa significano 14 giorni consecutivi.
Google rifiuterà un’app WebView o TWA come non funzionante?
Non per la tecnologia. Google documenta sia le Trusted Web Activity sia WebView per le app Android, e nessuna norma vieta questa architettura. Le domande sono se l’app funziona, se ha uno scopo sufficiente e se hai il diritto di incapsulare il sito web.
Non consentiamo app il cui scopo principale è indirizzare traffico di affiliazione verso un sito web o fornire una webview di un sito web senza l’autorizzazione del proprietario o dell’amministratore del sito.
Per un’app basata sul web i controlli per Broken Functionality sono gli stessi di qualsiasi altra app: il sito deve caricarsi all’interno dell’app dopo un’installazione pulita, gli stati offline e di errore devono spiegarsi da soli e ogni link deve portare da qualche parte. Se l’app è per lo più una semplice vista di un sito web, il rischio maggiore è la sezione Limited Functionality and Content. Non è stato dimostrato che passare da una TWA a una WebView, o viceversa, risolva di per sé un rifiuto.
Come ti aiuta PrimeTestLab prima della prossima revisione?
Non possiamo correggere il tuo codice né cambiare la decisione di Google. Ciò che forniamo è la parte dei test: persone reali su dispositivi reali che usano la tua app tramite il tuo test chiuso, così problemi come quelli descritti sopra emergono nei loro feedback prima che li trovi un revisore.
PrimeTestLab fornisce 12 o più tester reali su dispositivi reali da Android 7 a 17, attivi per tutti i 14 giorni, con l’avvio dei test entro 4-6 ore. Abbiamo gestito test per 12.100+ app con tester in 120+ paesi.
Test fai da te o test gestiti
| Attività | Fai da te | Con PrimeTestLab |
|---|---|---|
| Trovare i tester | Fai da teAmici, gruppi e forum, di solito con telefoni simili | Con PrimeTestLabTester reali su dispositivi reali, assegnati alla tua app |
| Varietà di dispositivi e versioni di Android | Fai da teQuello che possiedono i tuoi volontari | Con PrimeTestLabDispositivi da Android 7 a 17 |
| Uso quotidiano e feedback | Fai da teDipende dalla buona volontà | Con PrimeTestLabI tester usano l’app e segnalano cosa si rompe |
| Mantenerne 12 attivi per 14 giorni | Fai da teRincorri tu chi abbandona | Con PrimeTestLabChi abbandona viene sostituito, così il numero regge |
| Correggere il codice e l’avviso | Fai da teTu | Con PrimeTestLabSempre tu; noi ti riportiamo cosa hanno trovato i tester |
| La decisione di Google | Fai da teGoogle | Con PrimeTestLabSempre Google; nessuno può promettere l’approvazione |
Se Google non ha concesso l’accesso in produzione dopo il tuo test completo con PrimeTestLab, scegli tu tra un nuovo test gratuito o un rimborso completo; vedi la politica di rimborso e nuovo test gratuito. Questo copre il requisito di test, non un rifiuto per le norme del tuo codice. I piani partono da $19.99 più il 5% di commissione di servizio al checkout (minimo $1.50), e la quota di registrazione una tantum di 25 $ di Google è a parte. Confronta i piani nella pagina dei prezzi.
Domande frequenti
Cos’è la norma Broken Functionality su Google Play?
È una sezione della norma di Google Play Functionality, Content, and User Experience (funzionalità, contenuti ed esperienza utente). Google non consente app che si arrestano in modo anomalo, si chiudono forzatamente, si bloccano o comunque funzionano in modo anomalo, e indica come violazioni comuni le app che non si installano, le app che si installano ma non si caricano e le app che si caricano ma non rispondono.
Broken Functionality è la stessa cosa di Minimum Functionality?
No. Minimum Functionality è il nome precedente di quella che Google oggi chiama Limited Functionality and Content, che riguarda le app con uno scopo o contenuti troppo limitati. Broken Functionality riguarda le app che non funzionano così come sono state inviate. Entrambe fanno parte della stessa norma, ma richiedono soluzioni diverse.
Dove aggiungo le credenziali demo per la revisione di Google Play?
In Play Console vai su Norme e programmi, poi Contenuti dell’app, poi Dettagli di accesso (prima Accesso all’app). Seleziona Inizia o Gestisci, aggiungi le istruzioni e salva, poi invia la modifica per la revisione dalla pagina Panoramica della pubblicazione. Le credenziali devono essere riutilizzabili e non devono dipendere da un codice monouso inviato al tuo telefono.
Un rifiuto conta come strike sul mio account sviluppatore?
Google afferma che i rifiuti non influiscono sullo stato del tuo account sviluppatore. Le sospensioni contano come strike, e Google include i ripetuti rifiuti o rimozioni di app tra i motivi di sospensione, quindi correggi il problema citato prima di reinviare.
Quanto dura la revisione dopo aver reinviato un’app corretta?
Google afferma che l’elaborazione delle modifiche alle app può richiedere da qualche ora fino a sette giorni, o più in casi eccezionali. Questa è la revisione della versione corretta. Google non pubblica alcun tempo di risposta per i ricorsi.
Posso presentare ricorso contro un rifiuto per Broken Functionality?
Sì, se ritieni che la valutazione sia sbagliata. Segui le istruzioni nell’email di notifica oppure usa il modulo di ricorso di Google. Puoi presentare un ricorso per ogni provvedimento, quindi includi il codice di versione esaminato, il dispositivo e i passaggi che hai testato e una registrazione del flusso citato nell’avviso.
Un rifiuto per Broken Functionality azzera il mio test chiuso di 14 giorni?
Google non lo documenta. Il suo requisito è di almeno 12 tester che abbiano attivato il test continuamente per almeno 14 giorni prima di richiedere l’accesso in produzione. Mantieni i tester attivi mentre correggi la versione, tieni d’occhio la Dashboard e chiedi all’assistenza di Play Console se la tua idoneità cambia.
Perché la mia app è stata rifiutata se funziona sul mio telefono?
Il tuo telefono copre una build, un account, un insieme di dati e una rete. Installa la versione distribuita da Play su un dispositivo pulito con un account nuovo, poi testa i contenuti vuoti e le richieste di rete non riuscite. Una build dello store firmata con la chiave di firma dell’app può fallire dove la tua build di debug funziona, quindi testa la build che ha installato il revisore.
La mia app usa Google Sign-In o un codice monouso. Cosa devo fornire ai revisori?
Google richiede dettagli di accesso riutilizzabili, che funzionino da qualsiasi luogo e aggirino le password monouso o la verifica in due passaggi. Fornisci ai revisori un account di test e istruzioni che raggiungano ogni funzione riservata, comprese quelle a pagamento. Poi testa tu stesso esattamente i dettagli che hai fornito; spiegare come un utente normale riceve un codice non è un accesso funzionante.
Google non ha inviato screenshot né log degli arresti anomali. E adesso?
Controlla Stato delle norme e l’email di notifica per trovare la versione interessata ed eventuali dettagli aggiunti da Google. Poi riproduci il percorso principale sulla versione inviata e registra un tuo video e i tuoi log. Una pagina di Android vitals o un rapporto pre-lancio puliti non dimostrano che ogni schermata e ogni richiesta al backend abbiano funzionato per il revisore.
Le app TWA e WebView vengono rifiutate automaticamente?
No. Google documenta entrambe le tecnologie e nessuna norma le vieta. Google limita però le app che incapsulano un sito web senza l’autorizzazione del proprietario e le app con funzionalità o contenuti troppo scarsi. Individua il problema reale, come errori di login, di navigazione o di rete; passare da un tipo di wrapper all’altro non è una soluzione documentata.
In conclusione
In sintesi
Un rifiuto per Broken Functionality dice che la versione esaminata da Google non ha funzionato: si è arrestata, si è bloccata, non si è caricata o non ha risposto. Leggi quale norma cita l’avviso, riproduci il problema sulla build distribuita da Play, verifica che i revisori possano accedere tramite i Dettagli di accesso, testa il backend dall’esterno della tua rete e fai in modo che ogni controllo e ogni schermata vuota si spieghino da soli. Correggi ogni canale interessato e invia per la revisione la versione corretta. Presenta ricorso solo con prove che la valutazione era sbagliata. Un singolo rifiuto non è uno strike, ma reinvii ripetuti senza correzioni possono portare a uno strike.
Se vuoi che persone reali su dispositivi reali trovino la schermata che non funziona prima del prossimo revisore, PrimeTestLab si occupa della parte del test chiuso mentre tu correggi l’app.
Documentazione ufficiale di Google
Cosa può cambiare in questa pagina
- Le etichette di Play Console cambiano. Dettagli di accesso si chiamava Accesso all’app fino a poco tempo fa, e alcune pagine tradotte del Centro assistenza usano ancora il vecchio nome.
- Il testo degli avvisi non è pubblicato come modello e cambia da un caso all’altro; fidati della tua email e della tua pagina Stato delle norme più che di qualsiasi esempio riportato qui.
- Google non documenta cosa comporti un rifiuto per le norme per un test chiuso in corso. Se pubblicherà una regola, questa pagina la seguirà.
Fonti verificate il 16 ottobre 2026.