Navigating multi-device quality & publishing beyond mobile on Google Play

Ciao a tutti.

Grazie per aver partecipato a questa sessione sulla gestione della qualità delle app multi-dispositivo e sulla pubblicazione su Google Play per fattori di forma diversi dai dispositivi mobili.

Sono Jan Kleinert, Developer Relations Engineer del team di Android for Cars.

E io sono Faustine Liao, Operations Lead del team di Trust & Safety di Google Play.

Siamo felici di avervi qui con noi oggi.

Per anni, quando parlavamo di sviluppo Android, la maggior parte di noi pensava solo a un dispositivo mobile, ma l'ecosistema Android si è espanso ben oltre gli smartphone.

Oggi gli utenti interagiscono con le app in Living Room su Android TV, magari mentre aspettano i figli a scuola o mentre ricaricano l'auto su Android Auto o Automotive OS, al polso con Wear OS e, sempre più spesso, in spazi 3D immersivi con Android XR.

Si tratta di un'enorme opportunità di crescita, ma l'espansione a questi fattori di forma comporta alcune considerazioni marginali da tenere in considerazione per la tua strategia di pubblicazione.

La procedura complessiva, dalla creazione dell'app alla sua pubblicazione e messa in produzione su Google Play, rimane generalmente la stessa a cui sei abituato per le release mobile.

Crea e prepara la tua app, quindi crea la tua scheda in Play Console, testa l'app, carica e invia la release di produzione, quindi attendi la revisione e l'approvazione.

Tuttavia, esistono alcune considerazioni uniche per la pubblicazione di app per fattori di forma diversi dai dispositivi mobili.

Oggi ti forniremo un framework chiaro per aiutarti a prepararti a un processo di rilascio multi-dispositivo più fluido e prevedibile.

Iniziamo dalle basi: come progettare e pacchettizzare la tua app.

Quindi, prima ancora di toccare Google Play Console, devi prendere un'importante decisione di architettura.

Crei un unico app bundle unificato contenente tutto per tutti i fattori di forma supportati o suddividi l'app in moduli specifici per i fattori di forma e generi Android App Bundle (AAB) per ciascuno?

Quindi, quando parlo di moduli o modularizzazione, mi riferisco semplicemente a un modo di strutturare il codebase per migliorare la manutenibilità.

Esistono molti approcci alla modularizzazione, ma, in generale, ciò che fai è organizzare il codebase in parti con basso accoppiamento e indipendenti, in cui ogni parte è un modulo.

Quindi, anche se un approccio unificato con Android App Bundle potrebbe sembrare più semplice da gestire, in realtà consigliamo l'approccio modulare.

Ecco un esempio che dimostra perché consigliamo questo approccio modulare.

Immaginiamo che tu abbia un'app che supporta sia i dispositivi mobili sia Android TV.

Se invii un singolo Android App Bundle nel canale di rilascio mobile standard e la tua app per Android TV non supera un controllo di revisione, l'intera release viene interrotta.

Questo influirà sia sulla release dell'app per Android TV sia su quella dell'app mobile.

Quindi, anche se non è stato riscontrato un problema specifico con la tua app mobile, dovrai risolvere i problemi che hanno causato l'esito negativo della revisione di Android TV e inviare nuovamente l'app per la revisione prima che la release possa essere resa disponibile per gli utenti.

D'altra parte, gli Android App Bundle modulari per ogni fattore di forma ti offriranno un controllo più granulare e ti aiuteranno a isolare le release per questi fattori di forma dalle release per dispositivi mobili.

In alternativa, se hai moduli app separati per l'app mobile e l'app TV, puoi generare Android App Bundle separati per ciascuna.

Se si verifica un problema con la revisione della tua app TV, verrà bloccata solo la release di quell'app finché non riuscirai a risolvere il problema.

La release dell'app mobile verrà pubblicata come previsto.

Come ho accennato in precedenza, esistono molti approcci alla modularizzazione.

Ecco un esempio di approccio per la modularizzazione di un'app di audiolibri che offre un'esperienza mobile e un'esperienza Android Automotive OS.

In alto, in verde, abbiamo un modulo dell'app per ogni fattore di forma, che aiuta a separare le dipendenze specifiche della piattaforma.

In giallo, abbiamo i moduli delle funzionalità, che corrispondono a parti isolate della funzionalità dell'app.

I moduli di dati sono in blu, mentre in basso abbiamo i moduli principali o comuni, che di solito vengono utilizzati per contenere il codice che altri moduli utilizzano di frequente.

Poi, nei file delle impostazioni di Gradle del progetto, puoi includere e configurare questa configurazione Gradle multimodulo per supportare questo tipo di modularizzazione.

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

Pertanto, continuerai a utilizzare lo stesso nome pacchetto o ID applicazione per ogni modulo e bundle dell'app.

Questo approccio modulare è direttamente collegato alla tua strategia per i canali in Play Console.

Quando pubblichi, hai a disposizione il canale mobile standard, ma offriamo anche canali dedicati ai fattori di forma.

Per Android TV, Android XR e Android Automotive OS, hai una scelta.

Puoi pubblicare insieme ai dispositivi mobili o utilizzare i canali dedicati per i fattori di forma.

Tuttavia, esistono due eccezioni.

Per Wear OS, devi utilizzare il canale Wear OS dedicato.

Per Android Auto, poiché si tratta fondamentalmente di un'estensione della tua app mobile proiettata sullo schermo dell'auto, l'unica scelta è il canale mobile standard.

Se gestisci più canali, il controllo delle versioni è fondamentale.

Un approccio consiste nell'assegnare le prime due cifre del codice di versione al fattore di forma.

Ad esempio, 01 per dispositivi mobili, 02 per Wear OS, 03 per Android Automotive OS e così via.

In genere, consigliamo di utilizzare codici di versione di almeno sette cifre, in modo che le cifre rimanenti possano essere utilizzate per la versione dell'app.

In questo modo si evitano conflitti di codici di versione in Play Console.

Una volta pacchettizzata l'app, è il momento di testarla.

Lo sviluppo di fattori di forma richiede test approfonditi e Google Play ti offre tre canali distinti per farlo prima del rilascio in produzione: test interni, test chiusi e test aperti.

Se utilizzi canali dedicati per i fattori di forma, puoi anche combinare questi canali di test con i fattori di forma, ottenendo un controllo ancora più granulare sul processo.

Ad esempio, potresti avere una release di test chiuso per la tua app mobile sul canale standard e una release di test chiuso separata per la tua app per Android TV sul canale dedicato al fattore di forma Android TV con gruppi di tester diversi, se vuoi configurarla in questo modo.

I test interni sono un ottimo punto di partenza.

Ti consente di distribuire rapidamente la tua app a un massimo di 100 tester e, soprattutto, non attiva una revisione di Google Play.

Ciò significa che tu e i tuoi tester potete installare rapidamente l'app sui dispositivi e convalidare l'esperienza su emulatori o su una TV, uno smartwatch o un altro dispositivo reale.

Con i test interni, riceverai un URL univoco che potrai condividere con i tester.

Quando i risultati dei test interni sono soddisfacenti, puoi passare ai test chiusi e aperti.

Puoi andare oltre i test interni con una release di test chiuso, che ti consente di testare le versioni di pre-release della tua app con un gruppo più ampio di tester per ricevere feedback mirati.

Puoi gestire i gruppi di test chiusi come elenchi di indirizzi email o tramite Google Gruppi.

Il test aperto, invece, ti aiuta a eseguire un test con un gruppo più numeroso su Google Play.

Sarai visibile su Google Play e chiunque potrà partecipare al programma di test aperto.

Non è necessario alcun invito e potranno condividere con te feedback privati sull'app.

Questi canali di test aperti e chiusi attivano le revisioni.

In realtà, questo è un enorme vantaggio.

Ti consente di testare la procedura di revisione stessa e di superare eventuali ostacoli molto prima del giorno del lancio tanto atteso.

A proposito del processo di revisione, parliamo un po' di cosa comporta e perché è importante.

In sostanza, queste norme e linee guida riguardano la qualità delle app.

Le app e i giochi di alta qualità offrono valore aggiunto agli utenti, sono piacevoli da usare, sfruttano al meglio i dispositivi premium e sono progettati per la sicurezza.

Vediamo quindi come puoi preparare la tua app per superare le revisioni nel modo più semplice possibile.

Penso che il punto di partenza migliore sia esaminare le norme sulla qualità delle app, che si concentrano su come deve essere un'esperienza utente ottimale.

Pubblichiamo le norme sulla qualità delle app di base che si applicano a tutte le app e definiscono la qualità minima che tutte le app devono soddisfare, nonché le linee guida per la qualità delle app adattive, che ti aiuteranno a garantire che la tua app offra un'esperienza ottimale indipendentemente dal fattore di forma del dispositivo, dalle dimensioni dello schermo o dalla modalità di visualizzazione.

Questi due insiemi di linee guida sono un ottimo punto di partenza.

Tuttavia, abbiamo anche norme sulla qualità delle app specifiche per ogni fattore di forma.

I nostri revisori testeranno le tue app su dispositivi reali ed emulatori in base a queste linee guida.

Pertanto, è molto importante assicurarsi che la tua app li rispetti.

Ecco una rapida panoramica dei motivi più comuni per cui le app vengono rifiutate per ogni fattore di forma.

Tieni presente, però, che non si tratta di un elenco esaustivo di tutte le norme sulla qualità delle app.

Quindi, assicurati di consultare le norme sulla qualità per ogni fattore di forma con cui lavori in dettaglio per l'insieme di criteri più solido.

Iniziamo con Android TV.

Quindi, nella parte inferiore di queste slide della sezione, vedrai un link breve che ti reindirizzerà all'elenco completo delle norme sulla qualità delle app per quel fattore di forma.

Un motivo comune per cui le app per Android TV vengono rifiutate è la mancanza di un'immagine del banner della schermata Home per ogni lingua supportata dall'app.

Pertanto, devi fornire un'immagine di 320 x 180 pixel che includa testo localizzato che identifichi la tua app.

L'immagine in questa slide mostra un esempio di banner della schermata Home che rispetta questi criteri.

In secondo luogo, sulla maggior parte delle TV, gli utenti interagiranno con il dispositivo utilizzando un telecomando con D-pad.

Pertanto, è fondamentale supportare correttamente la navigazione e lo stato attivo del D-pad.

Assicurati di supportare almeno i controlli D-pad minimi per evitare eventuali rifiuti basati su questi criteri.

Il terzo motivo comune per cui le app per Android TV vengono rifiutate è la mancanza del filtro per intent CATEGORY_LEANBACK_LAUNCHER nel file manifest Android.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

Questo filtro identificherà la tua app come abilitata per la TV e consentirà a Google Play di identificarla anche come app TV per gli utenti.

Quando un utente seleziona la tua app nella schermata Home della TV, questo intent identifica l'attività da avviare.

Assicurati di averlo incluso nel manifest.

Android XR è il prossimo passo.

Quando sviluppi per visori XR o occhiali XR con Android XR, presta particolare attenzione alle prestazioni, al rendering e alla stabilità delle tue app.

Puoi utilizzare Perfetto per profilare le prestazioni delle app create con l'SDK Jetpack XR per assicurarti di rispettare i requisiti minimi di frequenza fotogrammi.

Se stai creando un'app utilizzando un motore in tempo reale come Unity, puoi utilizzare gli strumenti di profilazione integrati nel motore per assicurarti di rispettare i requisiti di rendering.

Poi abbiamo le auto, che includono sia Android Auto sia Android Automotive OS.

Per Android Auto e Android Automotive OS, esiste il concetto di categorie, che sono un po' uniche per questo particolare fattore di forma.

Inoltre, solo alcune categorie di app possono essere pubblicate per le auto.

Quindi, se invii un'app per una categoria che non corrisponde a una di quelle supportate o se invii un'app per i test aperti o la produzione per una categoria che è solo in versione beta, l'app verrà rifiutata.

Ti mostro cosa intendo più nel dettaglio.

Qui puoi vedere una panoramica delle categorie di app supportate sulle auto per ogni piattaforma, insieme alla loro disponibilità.

Quindi, se è in versione beta, aperta, ovvero in disponibilità generale, o non ancora supportata, come indicato qui da "Disponibile a breve".

Alcune categorie, come le app di navigazione o di punti d'interesse, sono generalmente disponibili, il che significa che chiunque può pubblicare un'app in una di queste categorie in produzione per le auto.

Tuttavia, altre categorie, come le app di comunicazione e di chiamate per Android Auto, sono in versione beta.

Per queste categorie, puoi pubblicare l'app in un canale di test interno o chiuso, ma non in produzione, a meno che tu non abbia ricevuto l'accettazione in uno dei nostri programmi di accesso in anteprima per la categoria in questione.

Puoi trovare maggiori dettagli su questo e altro nelle nostre guide per gli sviluppatori di Android for Cars.

Qui puoi trovare i link per candidarti a questi programmi di accesso in anteprima.

Un altro motivo comune per cui le app vengono rifiutate è la mancanza o l'erroneità delle specifiche per gli screenshot di Android Automotive OS.

Pertanto, quando fornisci screenshot di Android Automotive OS, devi assicurarti di includere almeno due screenshot con orientamento verticale e almeno due screenshot con orientamento orizzontale con le dimensioni elencate qui.

Puoi utilizzare l'emulatore di Android Automotive OS per acquisirli.

È configurato in modo da acquisire screenshot delle dimensioni esatte di cui hai bisogno.

Infine, la sicurezza è fondamentale per le app per auto.

Pertanto, se la tua app non rispetta le nostre linee guida sulla distrazione del conducente, verrà rifiutata.

Un'app video, ad esempio, deve mettere in pausa la riproduzione e non può essere visibile mentre il veicolo è in movimento.

Infine, ma non meno importante, abbiamo Wear OS.

Pertanto, le app per Wear OS possono essere rifiutate se non sono ottimizzate e formattate per display piccoli e rotondi.

Per questo motivo, ti consigliamo di utilizzare l'ultima versione stabile di Compose per Wear OS per assicurarti che i contenuti non vengano tagliati ai bordi su dispositivi di dimensioni diverse o, ad esempio, per assicurarti che la barra di scorrimento venga visualizzata quando sono presenti contenuti scorrevoli.

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

Come per Android Automotive OS, le app per Wear OS possono essere rifiutate se gli screenshot di Wear OS sono mancanti o imprecisi.

Ecco un esempio, un buon esempio di screenshot della scheda del Google Play Store per l'app di esempio Androidify, che soddisfa i requisiti.

Assicurati quindi di inviare almeno uno screenshot che mostri la tua app in esecuzione su un dispositivo Wear OS.

Le nostre conclusioni?

Leggi le norme sulla qualità delle app per il tuo fattore di forma specifico ed esegui i test prima di inviare l'app.

Inoltre, ecco alcuni suggerimenti fondamentali.

Se la tua app richiede l'accesso, devi fornire un account demo attivo e credenziali valide nella sezione Accesso alle app di Play Console.

Se i nostri revisori non riescono ad accedere, non possiamo testare la tua app e questa verrà rifiutata automaticamente.

Inoltre, assicurati di mantenere le promesse.

Non utilizzare solo screenshot di dispositivi mobili.

Se la tua app è disponibile per Wear OS e Android TV, assicurati di caricare screenshot di alta qualità per questi fattori di forma specifici in Play Console.

Infine, sii descrittivo.

Spiega agli utenti esattamente cosa fa l'app, perché è utile e cosa possono aspettarsi quando la installano su ogni tipo di dispositivo.

In conclusione, raggiungere gli utenti quasi ovunque è un'opportunità incredibile. Progettando in modo modulare, sfruttando i test interni per un'iterazione rapida, progettando in base alle norme sulla qualità dei fattori di forma e ottimizzando le schede dello Store, potrai preparare la tua app per un processo di lancio e revisione più fluido.

Grazie mille per il tempo che ci avete dedicato oggi.

Non vediamo l'ora di scoprire le straordinarie esperienze multi-dispositivo che porterai su Google Play.