Se pubblichi la tua app su Google Play, devi creare e caricare un Android App Bundle. In questo caso, 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 l'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 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. Avrai anche gli strumenti necessari per rendere il più semplice possibile il mantenimento di un codebase 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 può sembrare che il supporto di più APK sia la soluzione migliore, ma spesso non è così. La sezione Utilizzare un singolo APK invece 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 imparare a scrivere codice che viene eseguito solo a determinati livelli API in un singolo APK, senza ricorrere a tecniche costose dal punto di vista del calcolo come la riflessione in questo articolo.
Se puoi gestirlo, limitare l'applicazione a un singolo APK presenta diversi vantaggi, tra cui:
- Pubblicazione e test più semplici
- C'è un solo codebase da mantenere
- La tua 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 della lezione presuppone che tu abbia esaminato l'argomento, assorbito con attenzione il materiale nelle risorse collegate e stabilito che più APK sono la strada giusta per la tua applicazione.
Crea un grafico dei requisiti
Inizia creando un semplice grafico per determinare rapidamente quanti APK ti servono e a quale intervallo di API viene coperto ogni 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 inizialmente può sembrare facile, tenere traccia dei set di livelli API scelti come target da ogni APK diventa piuttosto difficile piuttosto rapidamente, soprattutto se si verificano sovrapposizioni (spesso). Per fortuna, è facile definire i requisiti in modo rapido e semplice, nonché avere un riferimento facile per il futuro.
Per creare il grafico con più APK, inizia con una riga di celle che rappresentano i vari livelli API della piattaforma Android. Inserisci 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 | + |
Dopo aver creato il grafico, distribuiscilo al tuo team. La comunicazione del team sul progetto è diventata immediatamente più semplice perché invece di chiedere "Come va l'APK per i livelli API da 3 a 6, qui per Android 1.x. Come va?" Puoi semplicemente dire "Come sta arrivando l'APK blu?"
Inserisci tutto il codice e le risorse comuni in un progetto libreria
Che si tratti di modificare un'applicazione Android esistente o di iniziarne una da zero, questa è la prima cosa da fare sul codebase e di gran lunga la più importante. Tutto ciò che riguarda il progetto della libreria deve essere aggiornato una sola volta (pensa alle stringhe localizzate nella lingua, ai temi di colore, ai bug corretti nel codice condiviso), il che migliora i tempi di sviluppo e riduce la probabilità di errori che avrebbero potuto essere facilmente evitati.
Nota: anche se i dettagli di implementazione su come creare e includere progetti di libreria non rientrano nell'ambito di questa lezione, puoi imparare rapidamente a leggere Creare una raccolta Android.
Se stai convertendo un'applicazione esistente per utilizzare il supporto di più APK, esamina la base di codice per trovare tutti i file di stringhe localizzate, gli elenchi di valori, i colori del tema, le icone del menu e il layout che non cambieranno negli APK e inseriscili tutti nel progetto della libreria. Il codice che non cambierà molto andrà anche nel progetto Biblioteche. Probabilmente dovrai estendere queste classi per aggiungere uno o due metodi da un APK all'altro.
Se, d'altra parte, crei l'applicazione da zero, prova il più possibile a scrivere codice nel progetto della libreria prima, quindi spostalo verso il basso in un singolo APK solo se necessario. È molto più facile da gestire nel lungo periodo rispetto all'aggiungerlo a una, poi a un'altra, poi a un'altra e poi, 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 da 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 hai 3 APK seguendo 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-red
Una volta creati i progetti, aggiungi il progetto libreria come riferimento a ogni progetto APK. Se possibile, definisci l'attività iniziale nel progetto libreria ed estendi tale attività 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 mostrare che un determinato APK è idoneo.
- Tra gli APK idonei, vince il numero di versione più alto
Ad esempio, prendiamo l'insieme di diversi APK descritti in precedenza e 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 un valore minSdkVersion più alto abbia anche un codice di versione più elevato, sappiamo che, in termini di valori versionCode, rosso ≥ verde ≥ blu. Di conseguenza, possiamo comprimere il grafico in modo che abbia questo aspetto:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Supponiamo inoltre che l'APK rosso abbia alcuni requisiti che non sono presenti negli altri due. La pagina Filtri su Google Play della guida per gli sviluppatori Android presenta un intero elenco di possibili colpe. Ad esempio, supponiamo che il 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, a quanto pare, non tutti i dispositivi che supportano l'API 11 HANNO nemmeno una fotocamera anteriore! Che horror!
Fortunatamente, se un utente naviga su Google Play da un dispositivo di questo tipo, Google Play osserva il manifest, vede che Red indica la fotocamera anteriore come requisito e la ignora in silenzio, avendo determinato che Red e quel dispositivo non sono una combinazione creata nel paradiso digitale. Quindi vedrà che Green non solo è compatibile con i dispositivi con API 11 (dato che non è stato definito maxSdkVersion), ma non gli importa se ci sia o meno una fotocamera anteriore. L'utente può comunque scaricare l'app da Google Play perché, nonostante l'intero contrattempo con la fotocamera anteriore, esisteva ancora un APK che supportava quel particolare 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 di 1000, impostare le prime due cifre su minSdkVersion per l'APK specifico e incrementare da lì. Potrebbe avere il seguente aspetto:
Blu: 03001, 03002, 03003, 03004...
Verde: 07001, 07002, 07003, 07004…
Rosso: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 caricare l'app su Google Play, controlla i seguenti elementi. Ricorda che sono specifiche per più APK e non rappresentano in alcun modo un elenco di controllo completo per tutte le applicazioni che vengono 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 minSdkVersion più elevata deve avere un codice di versione superiore
- Verifica che nei filtri manifest siano presenti informazioni in conflitto (un APK che supporta soltanto cupcake sugli schermi XLARGE non verrà visto da nessuno).
- Il file manifest di ogni APK deve essere univoco in almeno uno schermo, una texture OpenGL o una versione della piattaforma supportati
- Prova a testare ogni APK su almeno un dispositivo. A parte questo, sulla tua macchina di sviluppo puoi disporre di uno degli emulatori di dispositivi più personalizzabili del settore. Scatenati!
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 creare e pacchettizzare le tue app Android ed è anche 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: 'small' 'normal' 'large' 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Quando esamini l'output aapt, accertati di non avere valori in conflitto per supports-cookies e compatibili-schermi e di non avere valori "uses-feature" indesiderati che non siano stati aggiunti a seguito delle autorizzazioni impostate nel 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 contiene hardware per la telefonia, Google Play filtrerà l'APK in tutti i casi, fino a quando non saranno disponibili dispositivi futuri che abbiano livelli API superiori E che dispongano di hardware per la telefonia.
Fortunatamente, questo problema si può risolvere facilmente aggiungendo al file manifest quanto segue:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
Viene aggiunto anche il requisito android.hardware.touchscreen in modo implicito. Se vuoi che l'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" />
Una volta 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 tutti i tuoi dispositivi di test per assicurarti che gli APK abbiano come target i dispositivi previsti. Congratulazioni, hai terminato.