Se pubblichi la tua app su Google Play, devi creare e caricare un Android App Bundle. In questo modo, Google Play genera e pubblica automaticamente APK ottimizzati per la configurazione del dispositivo di ogni utente, in modo che scarichi solo il codice e le risorse di cui ha bisogno per eseguire la tua app. La pubblicazione di più APK è utile se non pubblichi su Google Play, ma devi creare, firmare e gestire ogni APK autonomamente.
Quando sviluppi la tua applicazione Android per sfruttare più APK su Google Play, è importante adottare alcune best practice fin dall'inizio ed evitare problemi indesiderati più avanti nel processo di sviluppo. Questa lezione mostra come creare più APK della tua app, ognuno dei quali copre una gamma leggermente diversa di livelli API. Inoltre, avrai a disposizione alcuni strumenti necessari per semplificare al massimo la gestione di un codice base di più APK.
Verifica di aver bisogno di più APK
Quando cerchi di creare un'applicazione che funzioni su più generazioni della piattaforma Android, è naturale che tu voglia che l'applicazione sfrutti le nuove funzionalità sui nuovi dispositivi, senza sacrificare la compatibilità con le versioni precedenti. All'inizio potrebbe sembrare che il supporto di più APK sia la soluzione migliore, ma spesso non è così. La sezione Utilizzare un singolo APK della guida per gli sviluppatori relativa ai più APK include alcune informazioni utili su come eseguire questa operazione con un singolo APK, incluso l'utilizzo della nostra libreria di supporto. Puoi anche scoprire come scrivere codice che viene eseguito solo a determinati livelli API in un singolo APK, senza ricorrere a tecniche computazionalmente complesse come la riflessione, consultando questo articolo.
Se puoi gestirlo, limitare l'applicazione a un singolo APK presenta diversi vantaggi, tra cui:
- La pubblicazione e i test sono più semplici
- Esiste un'unica base di codice da gestire
- L'applicazione può adattarsi alle modifiche alla configurazione del dispositivo
- Il ripristino delle app su più dispositivi funziona e basta
- Non devi preoccuparti delle preferenze di mercato, del comportamento degli "upgrade " da un APK all'altro o di quale APK sia associato a quale classe di dispositivi
Il resto di questa lezione presuppone che tu abbia studiato l'argomento, assorbito attentamente il materiale nelle risorse collegate e stabilito che più APK sono la strada giusta per la tua applicazione.
Elabora un grafico dei requisiti
Per iniziare, crea un grafico semplice per determinare rapidamente quanti APK ti servono e l'intervallo di API coperto da ciascun APK. Come riferimento pratico, la pagina Versioni della piattaforma del sito web Android for Developers fornisce dati sul numero relativo di dispositivi attivi che eseguono una determinata versione della piattaforma Android. Inoltre, anche se all'inizio sembra facile, tenere traccia dell'insieme di livelli API di destinazione di ogni APK diventa difficile piuttosto rapidamente, soprattutto se ci sarà una sovrapposizione (spesso è così). Fortunatamente, è facile definire i requisiti in modo rapido e semplice, nonché avere un riferimento facile da consultare in un secondo momento.
Per creare il grafico con più APK, inizia con una riga di celle che rappresentano i vari livelli API della piattaforma Android. Aggiungi una cella aggiuntiva alla fine per rappresentare le versioni future di Android.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Ora colora il grafico in modo che ogni colore rappresenti un APK. Ecco un esempio di come potresti applicare ogni APK a un determinato intervallo di livelli API.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Una volta creato il grafico, distribuiscilo al tuo team. La comunicazione di gruppo sul tuo progetto è diventata subito più semplice, poiché invece di chiedere "Come va l'APK per i livelli API da 3 a 6, eh, sì, quello per Android 1.x. Come va?" Puoi semplicemente dire "Come va con l'APK Blue?"
Inserire tutto il codice e le risorse comuni in un progetto di libreria
Che tu stia modificando un'applicazione Android esistente o ne stia iniziando una da zero, questa è la prima cosa che devi fare alla base di codice e di gran lunga la più importante. Tutto ciò che viene inserito nel progetto della libreria deve essere aggiornato una sola volta (ad esempio stringhe localizzate in base alla lingua, temi di colore, bug corretti nel codice condiviso), il che migliora i tempi di sviluppo e riduce la probabilità di errori che potrebbero essere stati facilmente evitati.
Nota: anche se i dettagli di implementazione su come creare e includere progetti di librerie non rientrano nell'ambito di questa lezione, puoi acquisire le nozioni di base leggendo l'articolo Creare una libreria Android.
Se stai convertendo un'applicazione esistente per utilizzare il supporto di più APK, esamina la base di codice per individuare ogni file di stringhe localizzate, elenco di valori, colori del tema, icone del menu e layout che non cambieranno tra gli APK e inseriscili tutti nel progetto della libreria. Anche il codice che non cambierà molto deve essere inserito nel progetto della libreria. Probabilmente dovrai estendere queste classi per aggiungere uno o due metodi da un APK all'altro.
Se invece stai creando l'applicazione da zero, prova il più possibile a scrivere il codice prima nel progetto della libreria, poi spostalo in un singolo APK solo se necessario. È molto più facile da gestire nel lungo periodo rispetto all'aggiungerlo a uno, poi a un altro, poi a un altro e, mesi dopo, cercare di capire se questo blob può essere spostato nella sezione della libreria senza rovinare nulla.
Creare nuovi progetti APK
Deve essere presente un progetto Android separato per ogni APK che vuoi rilasciare. Per una facile organizzazione, posiziona il progetto della libreria e tutti i progetti APK correlati nella stessa cartella principale. Inoltre, ricorda che ogni APK deve avere lo stesso nome del pacchetto, anche se non necessariamente deve condividerlo con la libreria. Se avessi 3 APK che seguono lo schema descritto in precedenza, la tua directory principale potrebbe avere il seguente aspetto:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib 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 estendila nel progetto APK. Avere un'attività iniziale definita nel progetto della libreria ti offre la possibilità di riunire 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 utilizzando due semplici regole:
- Il file manifest deve indicare che il determinato APK è idoneo
- Tra gli APK idonei, vince il numero di versione più alto
A titolo esemplificativo, prendiamo l'insieme di più APK descritto in precedenza e supponiamo di non aver impostato un livello API massimo per nessuno degli APK. Presi singolarmente, l'intervallo possibile di ogni APK sarebbe simile al seguente:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Poiché è necessario che un APK con una versione minSdkVersion superiore abbia anche un codice di versione superiore, sappiamo che in termini di valori di versionCode, il rosso è maggiore del verde, che è maggiore del blu. Pertanto, possiamo comprimere il grafico in modo che abbia il seguente aspetto:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Supponiamo inoltre che l'APK rosso abbia alcuni requisiti che gli altri due non hanno. Nella pagina Filtri su Google Play della Guida per gli sviluppatori Android è disponibile un elenco completo dei possibili responsabili. A titolo di esempio, supponiamo che il colore rosso richieda una fotocamera anteriore. In effetti, l'intero scopo dell'APK rosso è combinare la fotocamera anteriore con le nuove funzionalità aggiunte nell'API 11. Tuttavia, non tutti i dispositivi che supportano l'API 11 dispongono di fotocamere anteriori. Cheorrore!
Fortunatamente, se un utente sta navigando su Google Play da uno di questi dispositivi, Google Play esaminerà il manifest, vedrà che Red elenca la fotocamera anteriore come requisito e lo ignorerà silenziosamente, avendo stabilito che Red e il dispositivo non sono una coppia perfetta nel paradiso digitale. Vedrà quindi che Green non è solo compatibile con i dispositivi con API 11 (poiché non è stata definita alcuna versione maxSdk), ma non è importante se è presente o meno una fotocamera anteriore. L'app può comunque essere scaricata dall'utente da Google Play, perché, nonostante l'incidente con la fotocamera anteriore, esisteva ancora un APK che supportava quel determinato livello API.
Per mantenere tutti gli APK su "canali" separati, è importante avere un buon schema di codici di versione. Quello consigliato si trova nell'area Codici versione della nostra guida per gli sviluppatori. Poiché l'insieme di APK di esempio riguarda solo una delle tre possibili dimensioni, sarebbe sufficiente separare ogni APK per 1000, impostare le prime due cifre su minSdkVersion per quel determinato APK e incrementare da lì. Potrebbe avere il seguente aspetto:
Blu: 03001, 03002, 03003, 03004…
Verde: 07001, 07002, 07003, 07004…
Red:11001, 11002, 11003, 11004...
Mettendo tutto insieme, i manifest di Android dovrebbero avere il seguente aspetto:
Blu:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="03001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> ...
Verde:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="07001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="7" /> ...
Rosso:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="11001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="11" /> ...
Controlla l'elenco di controllo pre-lancio
Prima di eseguire il caricamento su Google Play, controlla i seguenti elementi. Tieni presente che questi problemi sono specifici 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 del pacchetto
- Tutti gli APK devono essere firmati con lo stesso certificato
- Se gli APK si sovrappongono nella versione della piattaforma, quello con la versione minSdkVersion più alta deve avere un codice versione più alto
- Controlla attentamente che i filtri manifest non contengano informazioni in conflitto (un APK che supporta solo Cupcake su schermi XLARGE non verrà visto da nessuno).
- Il file manifest di ogni APK deve essere univoco per almeno una delle versioni supportate di schermo, texture OpenGL o piattaforma
- Prova a testare ogni APK su almeno un dispositivo. In caso contrario, sulla tua macchina di sviluppo hai uno degli emulatori di dispositivi più personalizzabili in circolazione. Divertiti!
Vale anche la pena ispezionare l'APK compilato prima di lanciarlo sul mercato, per assicurarti che non ci siano sorprese che potrebbero nascondere la tua applicazione su Google Play. È abbastanza semplice utilizzando lo strumento "aapt". Aapt (Android Asset Packaging Tool) fa parte del processo di compilazione per la creazione e il packaging delle applicazioni Android ed è anche uno strumento molto utile per ispezzionarle.
>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: 'small' 'normal' 'large' 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Quando esamini l'output di aapt, assicurati di non avere valori in conflitto per support-screens e compatible-screens e di non avere valori "uses-feature" indesiderati aggiunti a seguito delle autorizzazioni impostate nel file manifest. Nell'esempio riportato sopra, l'APK non sarà visibile a molti dispositivi.
Perché? Aggiungendo l'autorizzazione richiesta SEND_SMS, è stato aggiunto implicitamente il requisito della funzionalità android.hardware.telephony. Poiché l'API 11 è Honeycomb (la versione di Android ottimizzata specificamente per i tablet) e nessun dispositivo Honeycomb ha hardware di telefonia, Google Play filtrerà questo APK in tutti i casi, fino a quando non verranno lanciati dispositivi futuri con un livello API superiore E che dispongono di hardware di telefonia.
Per fortuna, il problema si risolve facilmente aggiungendo quanto segue al file manifest:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
Viene aggiunto anche il requisito android.hardware.touchscreen in modo implicito. 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 ciò avviene, esegui un ultimo controllo. Scarica l'applicazione su eventuali dispositivi di test di cui disponi per assicurarti che gli APK abbiano come target i dispositivi previsti. Complimenti, hai finito.