Limitazione di responsabilità: i riepiloghi delle norme sono solo delle panoramiche; fai sempre riferimento alle norme complete ai fini della conformità. Le norme complete hanno la precedenza in caso di conflitto
Google Play vieta alla tua app (o ad altri SDK di terze parti nella tua app) l'accesso non autorizzato o l'interferenza con il dispositivo dell'utente, altri dispositivi, reti, API o servizi, altre app sul dispositivo, qualsiasi servizio Google o la rete di un operatore autorizzato. Ciò comprende una serie di comportamenti dannosi, ad alto rischio o dirompenti, come l'esecuzione di aggiornamenti automatici al di fuori del Play Store, il download non autorizzato di codice eseguibile, lo sfruttamento delle vulnerabilità di sicurezza, l'agevolazione della pirateria informatica o la creazione di cheat di gioco che influiscono su altre app. Proteggere l'integrità del dispositivo dell'utente e dell'ecosistema più ampio è fondamentale. Consulta le norme complete per garantire la conformità.
Sono vietate le app che accedono senza autorizzazione al dispositivo dell'utente, ad altri dispositivi o computer, server, reti, API (interfaccia di programmazione di un'applicazione) o servizi, inclusi, a titolo esemplificativo, altre app sul dispositivo, servizi di Google o la rete di un operatore autorizzato, o che li interrompono, danneggiano o ostacolano..
Le app su Google Play devono rispettare i requisiti di ottimizzazione del sistema Android predefiniti e documentati nelle Norme fondamentali sulla qualità delle app per Google Play.
Un'app distribuita tramite Google Play non può essere modificata, sostituita o aggiornata utilizzando metodi diversi dal meccanismo di aggiornamento di Google Play. Analogamente, un'app non può scaricare codice eseguibile (ad esempio file dex, JAR e .so) da una fonte diversa da Google Play. Questa limitazione non riguarda il codice che viene eseguito su una macchina virtuale o un interprete che danno accesso indiretto alle API Android (ad esempio JavaScript in un componente WebView o in un browser).
App o codice di terze parti (ad esempio SDK) con linguaggi interpretati (JavaScript, Python, Lua e così via) caricati in fase di runtime (ad esempio non inclusi nell'app) non devono consentire potenziali violazioni delle norme di Google Play.
È vietato il codice che introduce o sfrutta vulnerabilità di sicurezza. Consulta il Programma App Security Improvement per scoprire i problemi di sicurezza più recenti segnalati agli sviluppatori.
Esempi di violazioni comuni relative all'utilizzo illecito di dispositivi e reti:
- App che bloccano o interferiscono con un'altra app mostrando annunci.
- App che alterano il gameplay di altre app consentendo di barare.
- App che facilitano la compromissione di servizi, software o hardware, l'elusione di misure di sicurezza o che forniscono istruzioni a riguardo.
- App che utilizzano o accedono a un servizio o a un'API con modalità che costituiscono una violazione dei relativi termini di servizio.
- App che non sono idonee all'inserimento in lista consentita e che tentano di aggirare le misure di gestione dell'alimentazione di sistema.
- App che agevolano servizi proxy verso terzi sono consentite solo laddove questo sia lo scopo principale dell'app proposto all'utente.
- App o codice di terze parti (ad esempio, SDK) che scaricano codice eseguibile, ad esempio file dex o codice nativo, da una fonte diversa da Google Play.
- App che installano altre app su un dispositivo senza previo consenso dell'utente.
- App che agevolano o rimandano alla distribuzione o all'installazione di software dannoso.
- App o codice di terze parti (ad esempio SDK) contenenti un componente WebView con interfaccia JavaScript aggiunta che carica contenuti web non attendibili (ad esempio, URL http://) oppure URL non verificati derivanti da fonti non attendibili (ad esempio, URL derivanti da intent non attendibili).
- App che usano l'autorizzazione per intent a schermo intero per forzare l'interazione dell'utente con notifiche o annunci improvvisi.
- App che aggirano le protezioni sandbox di Android per ricavare l'attività o l'identità dell'utente da altre app.
Considerazioni principali
| Cosa fare | Cosa non fare |
| Assicurati che la tua app e gli eventuali SDK integrati siano conformi ai requisiti di ottimizzazione del sistema Android illustrati nelle Norme fondamentali sulla qualità delle app. | Non installare altre app su un dispositivo senza il consenso esplicito dell'utente. |
Rispetta l'impostazione FLAG_SECURE; i contenitori on-device devono rispettare REQUIRE_SECURE_ENV. |
Non agevolare servizi di proxy verso terze parti a meno che questo non sia lo scopo principale dell'app proposto all'utente. |
| Usa User-Initiated Data Transfer Jobs esclusivamente per i trasferimenti di dati di rete avviati dall'utente che vengono eseguiti solo per il tempo necessario. | Nella tua app, non usare SDK di terze parti che scaricano codice eseguibile (come file .dex o .so) da fonti esterne a Google Play (ad eccezione di VMs/interpreters). |
| Consulta il Programma App Security Improvement per scoprire i problemi di sicurezza più recenti segnalati agli sviluppatori. | Non aggirare le misure di gestione dell'alimentazione di sistema a meno che non siano idonee. |
| Rispetta le norme relative ai servizi in primo piano. | Non bloccare o interferire con un'altra app che mostra annunci. |
Non usare l'autorizzazione FULL-SCREEN INTENT per forzare l'interazione con notifiche e annunci improvvisi. |
Utilizzo del servizio in primo piano
Le norme relative all'autorizzazione per i servizi in primo piano garantiscono all'utente trasparenza, privacy e prestazioni ottimali del dispositivo. Per le app che hanno come target Android 14 e versioni successive, devi dichiarare tipi di servizi in primo piano (FGS) validi nel manifest e in Play Console, fornendo descrizioni, impatto sull'utente e una demo video che ne giustifichi l'utilizzo in base ad azioni percepibili avviate dall'utente. Consulta le norme complete per garantire la conformità.
L'autorizzazione del servizio in primo piano garantisce che i servizi in primo piano rivolti agli utenti siano utilizzati in modo appropriato. Per le app che hanno come target Android 14 e versioni successive, devi specificare un tipo di servizio in primo piano valido per ogni servizio in primo piano utilizzato nell'app e dichiarare la relativa autorizzazione appropriata per quel tipo. Ad esempio, se il caso d'uso della tua app richiede la geolocalizzazione sulla mappa, devi dichiarare l'autorizzazione FOREGROUND_SERVICE_LOCATION nel file manifest dell'app.
Le app possono dichiarare un'autorizzazione per i servizi in primo piano solo se l'utilizzo:
- fornisce una funzionalità vantaggiosa per l'utente e pertinente alla funzionalità di base dell'app
- viene avviato o può essere percepito dall'utente (ad esempio, l'audio di una canzone in riproduzione, la trasmissione di contenuti multimediali a un altro dispositivo, una notifica per l'utente chiara e precisa, la richiesta dell'utente di caricare una foto sul cloud)
- può essere risolto o interrotto dall'utente
- non può essere interrotto o differito dal sistema senza causare un'esperienza utente negativa o malfunzionamenti della funzionalità attesa dall'utente (ad esempio, una chiamata deve essere avviata immediatamente e non può essere differita dal sistema)
- dura solo il tempo necessario al completamento dell'attività
I seguenti casi d'uso dei servizi in primo piano sono esenti dai criteri di cui sopra:
- tipi di servizi in primo piano systemExempted o shortService
- tipo di servizio in primo piano dataSync solo quando si utilizzano le funzionalità Play Asset Delivery
L'utilizzo del servizio in primo piano è spiegato più approfonditamente in questa pagina.
Considerazioni principali
| Cosa fare | Cosa non fare |
| Esegui gli FGS solo per il tempo necessario a completare l'attività. | Non utilizzare FGS se la gestione di sistema delle tue attività non compromette l'esperienza utente nella tua app. Valuta alternative come WorkManager. |
| Assicurati che gli FGS forniscano una funzionalità principale dell'app che sia vantaggiosa per l'utente, che vengano avviati dall'utente, che siano visibili nelle notifiche o che siano percepibili dall'utente (ad esempio, l'audio di un brano in riproduzione). | Non dichiarare tipi di FGS non validi o errati nel manifest dell'app. |
| Invia un modulo di dichiarazione in Play Console se hai come target Android 14 e versioni successive e descrivi il caso d'uso per ogni autorizzazione per i servizi in primo piano (FGS) utilizzata. Assicurati di selezionare il tipo di FGS appropriato. |
User-Initiated Data Transfer Jobs
Per fare in modo che l'utente mantenga il controllo e impedire attività prolungate in background, Google Play fornisce linee guida rigorose per le app che utilizzano l'API User-Initiated Data Transfer Jobs. I trasferimenti di dati devono essere richiesti direttamente dall'utente, in modo che l'app esegua un comando anziché avviare i trasferimenti in modo indipendente. Questi trasferimenti sono destinati esclusivamente ad attività di trasferimento di dati di rete e devono essere eseguiti solo per la durata necessaria a completare l'azione richiesta. Consulta le norme complete per garantire la conformità.
Le app sono autorizzate a utilizzare l'API User-Initiated Data Transfer Jobs solo se l'utilizzo:
- è avviato dall'utente;
- è volto all'attività di trasferimento di dati di rete;
- dura solo il tempo necessario al completamento del trasferimento di dati.
L'utilizzo delle API User-Initiated Data Transfer è spiegato più approfonditamente in questa pagina.
Considerazioni principali
| Cosa fare | Cosa non fare |
| Avvia i trasferimenti con l'azione da parte dell'utente. | Non avviare i trasferimenti automaticamente. |
| Limita l'uso alle attività di trasferimento di dati di rete. | Non utilizzare l'API per attività non di rete. |
| Interrompi al termine del trasferimento. | Non lasciare in esecuzione più a lungo del necessario. |
Requisiti di Flag Secure
FLAG_SECURE è un flag di visualizzazione dichiarato dall'app che indica che i dati sensibili nell'UI dovrebbero essere limitati a piattaforme sicure, impedendo screenshot nonché la visualizzazione e l'acquisizione in schermate non sicure. Gli sviluppatori utilizzano questa opzione quando i contenuti non devono essere trasmessi o visualizzati al di fuori dell'app/del dispositivo. Google Play richiede che tutte le app rispettino e non bypassino le dichiarazioni di FLAG_SECURE delle altre app per motivi di sicurezza e privacy. Consulta le norme complete per garantire la conformità.
FLAG_SECURE è un flag di visualizzazione dichiarato nel codice di un'app e indica che la sua UI contiene dati sensibili che devono essere limitati a una piattaforma sicura durante l'utilizzo dell'app. Questo flag è progettato per impedire che i dati vengano mostrati in screenshot o in visualizzazioni non sicure. Gli sviluppatori dichiarano questo flag quando i contenuti dell'app non devono essere trasmessi, visualizzati né altrimenti inviati al di fuori dell'app o del dispositivo dell'utente.
Per ragioni di sicurezza e privacy, tutte le app distribuite su Google Play devono rispettare la dichiarazione di FLAG_SECURE delle altre app. In altre parole, le app non devono agevolare o creare soluzioni alternative per bypassare le impostazioni di FLAG_SECURE in altre app.
Le app che si qualificano come Strumenti di accessibilità non sono tenute a rispettare questo requisito, purché non trasmettano, salvino o memorizzino nella cache contenuti protetti da FLAG_SECURE per l'accesso al di fuori del dispositivo dell'utente. Considerazioni principali
| Cosa fare | Cosa non fare |
Dichiara FLAG_SECURE per i dati sensibili nell'UI che necessitano di protezione dall'acquisizione. |
Non bypassare o creare soluzioni alternative per le impostazioni di |
Rispetta le dichiarazioni di FLAG_SECURE delle altre app per motivi di sicurezza e privacy. |
Non trasmettere, salvare o memorizzare nella cache contenuti protetti da FLAG_SECURE all'esterno del dispositivo, anche se si tratta di uno strumento di accessibilità. |
App che vengono eseguite in contenitori per Android sul dispositivo
Per prevenire problemi di sicurezza e privacy, gli sviluppatori possono utilizzare un flag `REQUIRE_SECURE_ENV` nel manifest dell'app quando le app con contenitore Android on-device non dispongono di tutte le funzionalità di sicurezza del sistema operativo Android. Il flag indica che l'app non deve essere eseguita in un ambiente simulato. Le app che forniscono questi contenitori devono rispettare questo flag non caricando le app che lo dichiarano e non possono bypassare questa misura di sicurezza. Consulta le norme complete per garantire la conformità.
Le app di contenitori per Android sul dispositivo offrono ambienti che simulano interamente o parzialmente porzioni di un sistema operativo Android. L'esperienza all'interno di questi ambienti potrebbe non riflettere la suite completa delle funzionalità di sicurezza Android, per questo motivo gli sviluppatori possono scegliere di aggiungere un flag del manifest relativo all'ambiente sicuro per comunicare ai contenitori per Android sul dispositivo che non devono operare negli ambienti Android simulati.
Flag del manifest relativo all'ambiente sicuro
- Rivedere i file manifest delle app che intendono caricare nel loro contenitore per Android sul dispositivo per questo flag.
- Non caricare le app che hanno dichiarato questo flag nel loro contenitore per Android sul dispositivo.
- Non funzionare da proxy intercettando o chiamando le API sul dispositivo in modo da sembrare installate nel contenitore.
- Non agevolare o creare soluzioni alternative per bypassare il flag (ad esempio, caricando una versione precedente di un'app per bypassare l'attuale flag dell'app REQUIRE_SECURE_ENV).
Considerazioni principali
| Cosa fare | Cosa non fare |
Le app che forniscono contenitori on-device devono verificare la presenza del flag REQUIRE_SECURE_ENV nei manifest di altre app e non procedere con il caricamento. |
Non ignorare il flag. Non puoi caricare un'app nel tuo contenitore se dichiara il flag REQUIRE_SECURE_ENV. |
| Evita soluzioni alternative. È vietato aggirare il flag, ad esempio caricando versioni precedenti di un'app. | Non aggirare le misure di sicurezza. Non creare soluzioni alternative per ignorare la preferenza di sicurezza di un'app. |
| Evita il proxy delle API. Non funzionare da proxy intercettando o chiamando le API al di fuori del contenitore. | Non far sembrare che le app siano eseguite in un ambiente sicuro quando in realtà non è così. |
| Rivedi i requisiti previsti dalle norme per i contenitori Android on-device. |