Se pubblichi la tua app su Google Play, devi creare e caricare un Android App Bundle. Se lo fai, Google Play genera e pubblica automaticamente APK ottimizzati per la configurazione del dispositivo di ogni utente, in modo che gli utenti scarichino solo il codice e le risorse necessarie per eseguire la tua app. La pubblicazione di più APK è utile se non pubblichi su Google Play, ma devi creare, firmare e gestire personalmente ogni APK.
Quando sviluppi la tua applicazione Android in modo da sfruttare più APK su Google Play, è importante adottare alcune best practice fin dall'inizio ed evitare inutili grattacapi durante il processo di sviluppo. Questa lezione spiega come creare più APK della tua app, ciascuno relativo a una classe diversa di dimensioni dello schermo. Avrai anche gli strumenti necessari per mantenere il più indolore possibile la gestione di più codebase APK.
Conferma di aver bisogno di più APK
Quando provi a creare un'applicazione che funzioni sulla vasta gamma di dispositivi Android disponibili, vuoi che l'applicazione abbia un aspetto ottimale su ogni singolo dispositivo. Vuoi sfruttare lo spazio disponibile sugli schermi di grandi dimensioni, continuando però a lavorare su quelli piccoli, per usare le nuove funzionalità dell'API Android o le texture visive disponibili su dispositivi all'avanguardia, senza però abbandonare quelli meno recenti. All'inizio potrebbe sembrare che il supporto di più APK sia la soluzione migliore, ma spesso non è così. La sezione relativa all'utilizzo di un singolo APK della guida con più APK include alcune informazioni utili su come risolvere questo problema con un unico APK, incluso l'utilizzo della nostra libreria di supporto, e i link alle risorse contenute nella Guida per gli sviluppatori Android.
Se sei in grado di gestirla, limitare la tua applicazione a un singolo APK presenta diversi vantaggi, tra cui:
- Pubblicazione e test più semplici
- C'è un solo codebase da mantenere
- L'applicazione può adattarsi alle modifiche alla configurazione del dispositivo
- Il ripristino delle app su tutti i dispositivi funziona sempre
- Non devi preoccuparti delle preferenze del mercato, del comportamento degli "upgrade" da un APK al successivo o dell'APK abbinato alla classe di dispositivi.
Nella parte restante di questa lezione si presuppone che tu abbia effettuato ricerche sull'argomento, analizzato attentamente il materiale presente nelle risorse collegate e stabilito che più APK siano la strada giusta per la tua applicazione.
Crea un grafico dei tuoi requisiti
Inizia creando un semplice grafico per determinare rapidamente il numero di APK di cui hai bisogno e le dimensioni dello schermo coperte da ogni APK. Fortunatamente, è facile tracciare le tue esigenze in modo facile e veloce e avere a disposizione un riferimento pratico per un secondo momento. Supponiamo che tu voglia suddividere gli APK in due dimensioni: API e dimensioni dello schermo. Crea una tabella con una riga e una colonna per ogni possibile coppia di valori e colora alcuni "blob", ognuno dei quali rappresenta un APK.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| Piccolo | |||||||||||
| normale | |||||||||||
| Grande | |||||||||||
| xlarge |
Sopra è riportato un esempio con quattro APK. Il blu è indicato per tutti i dispositivi con schermo normale o di piccole dimensioni, il verde è indicato per i dispositivi con schermi grandi e il rosso è per quelli con schermo grande, tutti con un intervallo API di 3-10. Il viola è un caso speciale, in quanto è valido per schermi di qualsiasi dimensione, ma solo per l'API 11 e versioni successive. Ancora più importante, semplicemente guardando questo grafico, puoi sapere immediatamente quale APK copre ogni combinazione di API/dimensioni dello schermo. Per l'avvio, hai anche nomi in codice originali per ciascuno, dato che "Abbiamo testato il rosso sul ?" è molto più facile da chiedere al tuo cubie rispetto a "Abbiamo testato l'APK xlarge da 3 a 10 con lo Xoom?" Stampa questo grafico e consegnalo a tutte le persone che lavorano sul tuo codebase. La vita è diventata molto più facile.
Inserisci tutto il codice e le risorse comuni in un progetto libreria
Che si tratti di modificare un'applicazione Android esistente o di avviarne una da zero, questa è la prima cosa da fare al codebase, e soprattutto la più importante. Tutto ciò che rientra nel progetto della libreria deve essere aggiornato una sola volta (pensa a stringhe localizzate nel linguaggio, temi a colori, bug corretti nel codice condiviso), il che riduce i tempi di sviluppo e la probabilità di errori che si sarebbero facilmente evitati.
Nota: i dettagli dell'implementazione di come creare e includere progetti di libreria esulano dall'ambito di questa lezione, ma puoi comunque mantenerti al passo leggendo l'articolo Creare una libreria Android.
Se stai convertendo un'applicazione esistente per utilizzare il supporto di più APK, cerca nel codebase ogni file di stringa localizzato, l'elenco di valori, i colori dei temi, le icone di menu e il layout che non cambierà da un APK a un altro, quindi inserisci tutto nel progetto libreria. Anche il codice che non cambierà molto dovrebbe essere inserito nel progetto della biblioteca. Probabilmente ti ritroverai a estendere queste classi per aggiungere uno o due metodi da APK ad APK.
Se, invece, stai creando l'applicazione da zero, prova prima il più possibile a scrivere codice nel progetto della libreria, quindi spostalo verso il basso su un singolo APK, se necessario. È molto più facile da gestire a lungo termine piuttosto che aggiungerlo a uno, quindi a un altro, poi a un altro e infine, mesi dopo, cercando di capire se il blob può essere spostato nella sezione della raccolta senza rovinare nulla.
Crea nuovi progetti APK
Dovrebbe esserci un progetto Android separato per ogni APK che intendi rilasciare. Per semplificare l'organizzazione, posiziona il progetto della libreria e tutti i progetti APK correlati nella stessa cartella principale. Ricorda inoltre che ogni APK deve avere lo stesso nome di pacchetto, anche se non è necessariamente necessario condividere il nome del pacchetto con la libreria. Se avessi 3 APK che seguono lo schema descritto in precedenza, la directory root potrebbe avere il seguente aspetto:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-purple foo-red
Una volta creati i progetti, aggiungi il progetto della libreria come riferimento a ogni progetto APK. Se possibile, definisci l'attività iniziale nel progetto della libreria ed estendi tale attività nel progetto APK. Avere un'attività iniziale definita nel progetto libreria ti offre la possibilità di mettere tutta l'inizializzazione dell'applicazione in un unico posto, in modo che ogni singolo APK non debba implementare nuovamente attività "universali", come l'inizializzazione di Analytics, l'esecuzione di controlli delle licenze e qualsiasi altra procedura di inizializzazione che non cambia molto da un APK all'altro.
Modificare i manifest
Quando un utente scarica un'applicazione che utilizza più APK tramite Google Play, l'APK corretto da utilizzare viene scelto seguendo due semplici regole:
- Il file manifest deve indicare che l'APK specifico è idoneo
- Tra gli APK idonei, prevale il numero di versione più alto.
A titolo di esempio, prendiamo il set di più APK descritto in precedenza e supponiamo che ogni APK sia impostato per supportare tutte le dimensioni dello schermo superiori alla sua dimensione "target". Diamo un'occhiata al grafico di esempio precedente:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| Piccolo | |||||||||||
| normale | |||||||||||
| Grande | |||||||||||
| xlarge |
Poiché va bene che la copertura si sovrapponga, possiamo descrivere l'area coperta da ogni APK in questo modo:
- Il blu copre tutte le schermate, minimo SDK 3.
- Il colore verde copre gli schermi di grandi dimensioni e quelli successivi, minSDK 3.
- Il colore rosso copre gli schermi di dimensioni molto grandi (in genere i tablet), l'SDK minimo pari a 9.
- Il colore viola copre tutti gli schermi, SDK minimo pari a 11.
Tieni presente che queste regole presentano molte sovrapposizioni. Ad esempio, un dispositivo di grandi dimensioni con l'API 11 può eseguire in teoria uno qualsiasi dei quattro APK specificati. Tuttavia, utilizzando la regola "Il numero di versione più elevato vince", possiamo impostare un ordine di preferenza nel seguente modo:
Viola ≥ Rosso ≥ Verde ≥ Blu
Perché consentire tutta la sovrapposizione? Supponiamo che l'APK viola abbia dei requisiti che gli altri due non hanno. La pagina Filtri su Google Play della guida per gli sviluppatori Android contiene un elenco completo dei possibili colpevoli. Ad esempio, supponiamo che Viola richieda una fotocamera anteriore. Infatti, lo scopo principale di Purple è usare oggetti per l'intrattenimento con la fotocamera anteriore. Abbiamo scoperto che non tutti i dispositivi con API 11 o versioni successive Hanno la fotocamera anteriore. Orrore!
Fortunatamente, se un utente naviga su Google Play da un dispositivo di questo tipo, Google Play esamina il file manifest, vede che Purple elenca la fotocamera anteriore come requisito e la ignora, dopo aver stabilito che Purple e quel dispositivo non sono una corrispondenza trovata nel paradiso digitale. Quindi, vedrà che Red non è compatibile solo con i dispositivi xlarge, ma non importa anche se c'è o meno una fotocamera anteriore. L'utente può comunque scaricare l'app da Google Play perché, nonostante l'intero incidente con la fotocamera anteriore, esisteva ancora un APK che supportava quel particolare livello API.
Per mantenere tutti gli APK in "canali separati", è importante avere uno schema di codice di versione efficace. Quello consigliato è disponibile nell'area Codici di versione della nostra guida per gli sviluppatori. Vale la pena leggere l'intera sezione, ma il concetto di base riguarda questo insieme di APK, useremmo due cifre per rappresentare il minSDK, due per rappresentare le dimensioni minime e massime dello schermo e 3 per il numero di build. In questo modo, quando il dispositivo esegue l'upgrade a una nuova versione di Android (ad esempio da 10 a 11), tutti gli APK idonei e preferiti rispetto a quella attualmente installata verrebbero considerati dal dispositivo come "upgrade". Lo schema del numero di versione, quando applicato al set di esempio di APK, potrebbe essere:
Blu: 0304001, 0304002, 0304003...
Verde: 0334001, 0334002, 0334003
Rosso: 0344001, 0344002, 0344003...
Viola: 1104001, 1104002, 1104003...
Per riassumere, i tuoi file manifest Android probabilmente avrebbero il seguente aspetto:
Blu:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Verde:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Rosso:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Viola:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Tieni presente che, tecnicamente, più APK funzionano con il tag supporta-screen o tag compatibili con gli schermi. In genere è preferibile usare gli schermi di supporto, ma entrambi sono un'ottima idea di pessima idea. Questo rende le cose inutilmente complicate e aumenta la possibilità che si verifichino errori. Tieni inoltre presente che, anziché utilizzare i valori predefiniti (piccolo e normale, sono sempre veri per impostazione predefinita), i manifest impostano esplicitamente il valore per ogni dimensione dello schermo. In questo modo puoi evitare mal di testa. Ad esempio, un manifest con un SDK target < 9 verrà impostato automaticamente su xlarge su false, in quanto quella dimensione non esisteva ancora. Quindi sii esplicito!
Esamina l'elenco di controllo pre-lancio
Prima di eseguire il caricamento su Google Play, ricontrolla quanto segue. Ricorda che queste informazioni sono specifiche per più APK e non rappresentano in alcun modo un elenco di controllo completo per tutte le applicazioni caricate su Google Play.
- Tutti gli APK devono avere lo stesso nome di pacchetto.
- Tutti gli APK devono essere firmati con lo stesso certificato.
- Se gli APK si sovrappongono nella versione della piattaforma, quello con il valore minSdkVersion più alto deve avere un codice di versione più alto.
- Ogni dimensione dello schermo che vuoi che sia supportata dall'APK, nel file manifest deve essere impostata su true. Imposta il valore false per tutte le dimensioni dello schermo che non vuoi che vengano evitate.
- Controlla se nei filtri del file manifest sono presenti informazioni contrastanti (un APK che supporta solo Cupcake sugli schermi XLARGE non verrà visualizzato da nessuno)
- Il file manifest di ogni APK deve essere univoco in almeno uno schermo supportato, una texture OpenGL o una versione della piattaforma.
- Prova a testare ogni APK su almeno un dispositivo. Salvo ciò, hai uno degli emulatori di dispositivi più personalizzabili nell'azienda sulla tua macchina di sviluppo. Pazzesco!
Vale anche la pena esaminare l'APK compilato prima di metterlo sul mercato, per assicurarti che non ci siano sorprese che potrebbero nascondere la tua applicazione su Google Play. Per farlo, basta usare lo strumento "aapt". Aapt (Android Asset Packaging Tool) fa parte del processo di creazione e pacchettizzazione delle applicazioni Android, oltre a essere uno strumento molto utile per ispezionarle.
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Quando esamini l'output aapt, assicurati di non avere valori in conflitto per supports-screen e compatible-SCREEN e di non avere valori "uses-feature" non intenzionali aggiunti a seguito delle autorizzazioni impostate nel file manifest. Nell'esempio precedente, l'APK sarà invisibile alla maggior parte dei dispositivi, se non a tutti.
Perché? Aggiungendo l'autorizzazione richiesta SEND_SMS, il requisito per le funzionalità di android.hardware.telephony è stato aggiunto implicitamente. Poiché la maggior parte dei dispositivi xlarge (se non tutti) sono tablet senza hardware per la telefonia, in questi casi Google Play filtrerà questo APK, finché non verranno forniti i dispositivi futuri che sono entrambi abbastanza grandi da poter segnalare le dimensioni dello schermo xlarge e possiedono hardware per la telefonia.
Fortunatamente, questo problema può essere facilmente risolto aggiungendo quanto segue al file manifest:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
Anche il requisito android.hardware.touchscreen viene aggiunto implicitamente. Se vuoi che il tuo APK sia visibile sulle TV che non sono dispositivi touchscreen, devi aggiungere quanto segue al file manifest:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Dopo aver completato l'elenco di controllo pre-lancio, carica gli APK su Google Play. Potrebbe essere necessario un po' di tempo prima che l'applicazione venga visualizzata durante la navigazione su Google Play, ma quando viene visualizzata devi eseguire un ultimo controllo. Scarica l'applicazione su tutti i dispositivi di test necessari per assicurarti che gli APK abbiano come target i dispositivi previsti. Congratulazioni, hai completato la procedura.