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 supporta un sottoinsieme diverso di formati texture OpenGL. 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 si cerca di creare un'applicazione che funzioni su tutti i dispositivi Android disponibili, è naturale che l'applicazione abbia un aspetto ottimale su ciascun dispositivo, a prescindere dal fatto che non tutti supportino lo stesso set di texture GL. All'inizio può 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 per gli sviluppatori con più APK include alcune informazioni utili su come risolvere questo problema con un singolo APK, incluso come rilevare i formati di texture supportati in fase di esecuzione. A seconda della tua situazione, potrebbe essere più semplice raggruppare tutti i formati nella tua applicazione e semplicemente scegliere quale utilizzare per il runtime.
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
La Guida per gli sviluppatori Android fornisce un riferimento pratico di alcune delle texture supportate più comuni nella pagina supports-gl-texture. Questa pagina contiene anche alcuni suggerimenti su quali telefoni (o famiglie di telefoni) supportano particolari formati di texture. Tieni presente che in genere è consigliabile che uno dei tuoi APK supporti l'ETC1, dato che questo formato di texture è supportato da tutti i dispositivi con piattaforma Android che supportano la specifica OpenGL ES 2.0.
Poiché la maggior parte dei dispositivi Android supporta più formati di texture, devi stabilire un ordine di preferenza. Crea un grafico che includa tutti i formati che saranno supportati dalla tua applicazione. La cella più a sinistra sarà la priorità più bassa (probabilmente sarà ETC1, un solido valore predefinito in termini di prestazioni e compatibilità). Poi colora il grafico in modo che ogni cella rappresenti un APK.
| ETC1 | ATI | VR |
La colorazione del grafico non si limita a rendere questa guida meno monocromatica: ha anche un modo di semplificare la comunicazione tra team. Ora puoi semplicemente fare riferimento a ogni APK come "blu", "verde" o "rosso", anziché "quello che supporta i formati di texture ETC1" e così via.
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-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 alcune semplici regole:
- Il file manifest deve indicare che l'APK specifico è idoneo
- Tra gli APK idonei, prevale il numero di versione più alto
- Il dispositivo sul mercato viene considerato idoneo se supporta uno qualsiasi dei formati di texture elencati nel tuo APK.
Per quanto riguarda le texture GL, l'ultima regola è importante. Ciò significa che devi, ad esempio, prestare molto attenzione all'utilizzo di formati GL diversi nella stessa applicazione. Se hai usato PowerVR per il 99% delle volte, ma usi ETC1 per, ad esempio, la schermata iniziale... Il file manifest indica necessariamente il supporto di entrambi i formati. Se un dispositivo supportasse solo ETC1, la tua app verrebbe scaricata e l'utente visualizzerà alcuni messaggi di arresto anomalo. Il caso più comune è che, se utilizzi più APK per scegliere come target dispositivi diversi in base al supporto delle texture GL, sarà presente un solo formato di texture per APK.
Questo rende il supporto delle texture un po' diverso dalle altre due diverse dimensioni APK, livello API e dimensioni dello schermo. Ogni dispositivo ha un solo livello API e una sola dimensione dello schermo, che è compito dell'APK supportarne. Per quanto riguarda le texture, l'APK in genere supporta una sola texture, mentre il dispositivo ne supporta molte. Spesso si verifica una sovrapposizione in termini di dispositivo che supporta molti APK, ma la soluzione è la stessa: i codici di versione.
Ad esempio, prendiamo qualche dispositivo e vediamo quanti APK definiti in precedenza sono adatti a ogni dispositivo.
| Telefono | Nexus S | Evo |
| ETC1 | ETC1 | ETC1 |
| VR | TC ATI |
Supponendo che i formati PowerVR e ATI siano entrambi preferiti rispetto a ETC1 quando disponibili, rispetto alla regola "Il numero di versione più elevato vince", se impostiamo l'attributo versionCode in ogni APK in modo che rosso ≥ verde ≥ blu, sui dispositivi che li supportano sia il rosso che il verde saranno sempre scelti sul blu e, qualora un dispositivo che li supporti sia rosso e verde, verrà scelto.
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. Poiché l'insieme di APK di esempio riguarda solo una delle 3 dimensioni possibili, sarebbe sufficiente separare ogni APK per 1000 e incrementare di conseguenza. L'URL potrebbe avere il seguente aspetto:
Blu: 1001, 1002, 1003, 1004...
Verde: 2001, 2002, 2003, 2004...
Rosso:3001, 3002, 3003, 3004...
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="1001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
...
Verde:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="2001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" />
...
Rosso:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="3001" android:versionName="1.0" package="com.example.foo">
<supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />
...
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
- 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 su 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.