Perché Google Play rifiuta le app
L'enforcement di Google Play è sempre più automatizzato. La maggior parte dei rifiuti e delle sospensioni deriva da una breve lista di problemi tecnici e di policy che puoi verificare prima di caricare.
1. Target API level troppo basso
Google Play richiede che le nuove app e gli aggiornamenti puntino a un API level Android recente (attualmente API 35 / Android 15). Se il tuo targetSdkVersion è sotto la soglia, la Play Console blocca direttamente il caricamento. Alza il target, poi ri-testa per eventuali cambiamenti di comportamento.
2. Build di release debuggable
Pubblicare una build con android:debuggable="true" viene rifiutato. Assicurati che il tuo build type di release non abiliti il debugging.
3. Permessi sensibili e con restrizioni
Permessi come posizione in background, SMS / Registro chiamate e accesso a tutti i file (MANAGE_EXTERNAL_STORAGE) richiedono un caso d'uso solido e spesso un Permissions Declaration Form. Richiederli senza giustificazione è una delle principali cause di rimozione.
- Richiedi solo i permessi necessari alle funzionalità attuali.
- Aggiungi una comunicazione in-context evidente prima di richiederli.
- Compila il modulo di dichiarazione dove richiesto.
4. Incongruenza nel modulo Data safety
La sezione Data safety della tua Play Console deve corrispondere a ciò che l'app e i suoi SDK raccolgono e condividono davvero. Le discrepanze — spesso introdotte da un SDK di analytics o di pubblicità — generano rifiuti e sospensioni. Controlla ogni dipendenza.
5. Broken Functionality contro Limited Functionality
Sono due sezioni distinte della stessa pagina di policy, e vengono confuse di continuo. Broken Functionality riguarda le app che crashano, si bloccano o non si caricano mai: la tua app ha fallito. Limited Functionality and Content riguarda i wrapper webview e i gusci vuoti: la tua app funziona, semplicemente non vale l'installazione. Le correzioni sono opposte. Se il rifiuto dice Broken Functionality, non metterti ad aggiungere funzioni.
Guida completa: decodificare un rifiuto Broken Functionality →
6. Comportamenti ingannevoli e impersonificazione
- Falsi avvisi di sistema o imitazione dell'interfaccia Android.
- Scheda dello store fuorviante, keyword stuffing o badge falsi.
- Copiare nome, icona o brand di un'altra app.
The most common hard block here is the target API level. Play rejects the upload outright when your bundle targets too low — check what your .aab/.apk targets vs Play's current floor.
7. Pagamenti ed eliminazione dell'account
I beni digitali devono generalmente usare Google Play Billing. E se gli utenti possono creare un account, devi offrire l'eliminazione di account e dati sia in-app sia tramite un URL raggiungibile esternamente.
Come aiuta App Review Checker
Carica il tuo .apk e leggiamo il manifest per controllare il tuo target API level, il flag debuggable, il traffico in chiaro, i permessi con restrizioni, il versioning e il formato di pubblicazione — poi ti guidiamo attraverso le voci di policy (Data safety, fatturazione, scheda dello store, eliminazione dell'account) che richiedono una risposta umana.
Checklist di invio per Android: la guida completa al Play Store →
Cross-referencing an Apple rejection too? The rejection reasons index lists every Play policy and Apple guideline side by side, searchable.
Controlla la tua build prima di inviarla
Fai passare il tuo .ipa o .apk attraverso App Review Checker e individua questi problemi in pochi secondi.
Controlla un'app