Se pubblichi la tua app su Google Play, devi creare e caricare un Android App Bundle. Quando lo fai, Google Play automaticamente genera e pubblica APK ottimizzati per la configurazione del dispositivo di ciascun utente, in modo che vengano scaricati solo il codice e le risorse di cui hanno bisogno per eseguire l'app. La pubblicazione di più APK è utile se Non pubblichi su Google Play, ma devi creare, firmare e gestire ogni APK autonomamente.
Durante lo sviluppo di un'applicazione Android per sfruttare diversi APK su Google Play, è importante adottare alcune best practice fin dall'inizio ed evitare inutili mal di testa nel corso del processo di sviluppo. Questa lezione mostra come creare più APK del tuo ciascuna app, ognuno con una classe diversa di dimensioni dello schermo. Avrai anche alcuni strumenti necessari per rendere il più semplice possibile gestire un codebase più APK.
Conferma di aver bisogno di più APK
Quando provi a creare un'applicazione che funzioni su una vasta gamma di dispositivi Android ovviamente vuoi che la tua applicazione venga visualizzata al meglio su ogni singolo dispositivo. Vuoi sfruttare lo spazio degli schermi grandi ma lavorare su quelli piccoli per utilizzare la nuova API Android le funzionalità o le texture visive disponibili su dispositivi all'avanguardia, ma non tralasciare quelli meno recenti. Potrebbe sembra all'inizio come se il supporto di più APK sia la soluzione migliore, ma spesso non è la per verificare se è così. L'utilizzo La sezione relativa all'APK singolo della guida relativa agli APK include alcune informazioni utili su come: realizzare tutto questo con un unico APK, incluso l'uso della nostra libreria di supporto, e link alle risorse presenti nella guida per gli sviluppatori Android.
Se sei in grado di gestirlo, limitare l'applicazione a un singolo APK offre 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 correttamente
- Non devi preoccuparti delle preferenze di mercato, del comportamento degli "upgrade" da un APK successivo o quale APK si abbina alla classe di dispositivi
Per il resto della lezione si presuppone che tu abbia esaminato l'argomento e assorbito con attenzione i materiale nelle risorse collegate e stabilito che più APK rappresentano la soluzione adatta un'applicazione.
Crea un grafico dei requisiti
Inizia creando un semplice grafico per determinare rapidamente quanti APK ti servono e quale schermata dimensioni coperte da ciascun APK. Fortunatamente, è facile delineare rapidamente e facilmente i tuoi requisiti un facile riferimento per un secondo momento. Supponiamo che tu voglia suddividere gli APK in due dimensioni: API e dimensioni dello schermo. Creare una tabella con una riga e una colonna per ogni possibile coppia di valori e un colore. in alcuni "blob", dove ogni colore rappresenta un APK.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| piccole | |||||||||||
| normale | |||||||||||
| grande | |||||||||||
| xlarge |
Sopra è riportato un esempio con quattro APK. Il blu indica tutti i dispositivi con schermo piccolo/normale, mentre il verde indica le grandi con schermo di grandi dimensioni, mentre Red è quella con schermi più grandi, tutti con un intervallo API compreso tra 3 e 10. Il viola è un in un caso speciale, dato che è valido per schermi di tutte le dimensioni, ma solo per l'API 11 e versioni successive. Ma soprattutto, dando un'occhiata a questo grafico, puoi capire immediatamente quale APK copre una determinata combinazione di API/dimensioni dello schermo. A avvio, hai anche nomi in codice eleganti per ciascuno, dato che "Abbiamo testato il rosso sul ?" è molto più facile chiedere al tuo cubie di "Abbiamo testato l'APK xlarge da 3 a 10 rispetto a Xoom?" Stampa per creare un grafico e distribuirlo a ogni persona che lavora sul tuo codebase. La vita è diventata molto più facile.
Inserisci tutto il codice e le risorse comuni in un progetto libreria
Se stai modificando un'applicazione Android esistente o creandone una da zero, la prima cosa da fare al codebase e, di gran lunga, la più importante. Tutto che entra nel progetto della biblioteca deve essere aggiornato una sola volta (pensa alle stringhe localizzate in varie lingue, temi a colori, bug corretti nel codice condiviso), che migliora i tempi di sviluppo e riduce probabilità di errori che avrebbero potuto essere facilmente evitati.
Nota:sebbene i dettagli di implementazione relativi a come creare progetti libreria non rientrano nell'ambito di questa lezione, puoi approfondire consulta l'articolo Creare una Raccolta Android.
Se vuoi convertire un'applicazione esistente al supporto di più APK, esaminare il codebase alla ricerca di ogni file stringa localizzato, elenco di valori, i colori, le icone dei menu e il layout che non cambieranno da un APK all'altro, nel progetto biblioteca. Il codice che non cambierà molto dovrebbe nel progetto Biblioteche. Probabilmente ti capiterà di estendere questi per aggiungere uno o due metodi dall'APK all'APK.
Se, d'altra parte, crei l'applicazione da zero, prova come scrivere il codice prima nel progetto libreria, quindi spostarlo solo verso il basso un singolo APK, se necessario. È molto più facile da gestire nel lungo periodo rispetto ad una semplice aggiunta un'altra ancora, un'altra e poi mesi dopo, cercando di capire se questo blob può essere spostato più in alto alla sezione della biblioteca senza rovinare nulla.
Creare nuovi progetti APK
Deve essere presente un progetto Android separato per ogni APK da rilasciare. Per semplificare dell'organizzazione, inserisci il progetto 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 devono condividere il nome del pacchetto con la libreria. Se hai tre 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 libreria come riferimento a ogni progetto APK. Se possibile, definisci l'attività iniziale nel progetto della libreria ed estendi quell'attività nell'APK progetto. Avere un'attività iniziale definita nel progetto della biblioteca ti dà la possibilità di mettere tutti l'inizializzazione dell'applicazione in un unico posto, in modo che ogni singolo APK non debba reimplementare il valore "universale" come l'inizializzazione di Analytics, l'esecuzione dei controlli delle licenze e qualsiasi altra procedure di inizializzazione che non cambiano molto da APK ad APK.
Modificare i manifest
Quando un utente scarica un'applicazione che utilizza più APK tramite Google Play, l'applicazione corretta L'APK da utilizzare viene scelto tramite due semplici regole:
- Il file manifest deve indicare 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 che ogni L'APK è stato impostato per supportare schermi di tutte le dimensioni maggiori di quelle "target" dimensioni dello schermo. Diamo un'occhiata il grafico di esempio di prima:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| piccole | |||||||||||
| normale | |||||||||||
| grande | |||||||||||
| xlarge |
Dato che va bene che la copertura si sovrapponga, possiamo descrivere l'area coperta da ogni APK, ad esempio quindi:
- Il blu copre tutti gli schermi, minSDK 3.
- Il verde copre schermi grandi e superiori, minSDK 3.
- Il rosso copre schermi molto grandi (generalmente tablet), minSDK di 9.
- Il colore viola copre tutti gli schermi, minSDK di 11.
Tieni presente che queste regole presentano molte sovrapposizioni. Ad esempio, un È possibile che un dispositivo molto grande con API 11 esegua uno qualsiasi dei quattro APK specificati. Se però usi il "numero di versione più alto vince", regola, possiamo impostare un ordine la preferenza come segue:
Viola ≥ Rosso ≥ Verde ≥ Blu
Perché consentire tutte le sovrapposizioni? Supponiamo che l'APK viola abbia dei requisiti che mentre gli altri due no. Pagina Filtri su Google Play della guida per gli sviluppatori Android ha un intero elenco di possibili colpevoli. A titolo di esempio, supponiamo che Purple richieda una fotocamera anteriore. Infatti, lo scopo di Purple è usa la fotocamera anteriore per le attività di intrattenimento. Tuttavia, è emerso che non tutti i dispositivi con API 11 e versioni successive anche DI avere fotocamere anteriori. Che orrore!
Fortunatamente, se un utente naviga su Google Play da un dispositivo di questo tipo, Google Play esaminerà il puoi vedere che Purple indica come requisito la fotocamera anteriore e ignorala. ha stabilito che Purple e quel dispositivo non sono una combinazione perfetta nel paradiso digitale. Quindi Red non è solo compatibile con i dispositivi x large, ma non è importante anche se c'è una fotocamera anteriore. L'utente può comunque scaricare l'app da Google Play, perché nonostante l'intero contrattempo con la fotocamera anteriore, c'era ancora un APK che supportava quel particolare livello API.
Per mantenere tutti gli APK in "canali di controllo" separati, è importante avere un codice di versione valido . Quello consigliato è disponibile nell'area Codici di versione di la nostra guida per gli sviluppatori. Vale la pena leggere l'intera sezione, ma la sostanza di base è che questo insieme APK, dovremmo utilizzare due cifre per rappresentare il minSDK, due per rappresentare le dimensioni minime/massime dello schermo e 3 per rappresentare 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), gli eventuali APK che sono ora idonei e preferiti rispetto a quello attualmente installato potrebbe essere visto dal dispositivo come un "upgrade". Lo schema del numero di versione, quando applicato all'esempio insieme di APK, potrebbe avere il seguente aspetto:
Blu: 0304001, 0304002, 0304003...
Verde: 0334001, 0334002, 0334003
Rosso: 0344001, 0344002, 0344003...
Viola: 1104001, 1104002, 1104003...
Riassumendo, i manifest Android avranno probabilmente un aspetto simile al seguenti:
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 delle schermate supportate o tag compatibile con schermi compatibili. In genere si preferisce utilizzare gli schermi di supporto, che in genere è un pessimo l'idea di utilizzare entrambi. Rende le cose inutilmente complicate e aumenta la possibilità di errori. Inoltre, tieni presente che, invece di sfruttare i valori predefiniti (small e normal sono sempre veri) per impostazione predefinita), nei manifest impostano esplicitamente il valore di ogni dimensione dello schermo. In questo modo puoi risparmiare grattacapi in basso: ad esempio, un manifest con un SDK target pari a < 9 avranno una dimensione impostata automaticamente su false, poiché la dimensione non esisteva ancora. Quindi sii esplicito.
Esaminare l'elenco di controllo pre-lancio
Prima di caricare contenuti su Google Play, controlla attentamente i seguenti elementi. Ricorda che si tratta pertinenti per più APK e non rappresentano in alcun modo un elenco di controllo completo per tutti 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 minSdkVersion più elevata deve avere un valore una versione più recente.
- Imposta il valore true nel file manifest di tutte le dimensioni dello schermo supportate dall'APK. Ogni dimensione dello schermo vuoi evitare, impostalo su false.
- Verifica che nei filtri manifest siano presenti informazioni in conflitto (un APK che supporta solo il 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 completamente gestita.
- Prova a testare ogni APK su almeno un dispositivo. A parte questo, disporrai di uno dei emulatori di dispositivi personalizzabili in esecuzione sul tuo computer di sviluppo. Scatenati!
È opportuno controllare anche l'APK compilato prima di metterlo sul mercato, per assicurarti che non ci siano eventuali sorprese che potrebbero nascondere la tua applicazione su Google Play. È un processo molto semplice, utilizzando "aapt" lo strumento a riga di comando gcloud. Aapt (Android Asset Packaging Tool) fa parte del processo di creazione per creare e pacchettizzare le applicazioni 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: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Quando esamini l'output aapt, accertati di non avere valori in conflitto per supporti schermi e schermi compatibili e che non disponi di "uses-feature" involontario valori aggiunte in seguito alle autorizzazioni che hai impostato nel manifest. Nell'esempio precedente, l'APK non sarà visibile alla maggior parte dei dispositivi, se non a tutti.
Perché? Aggiungendo l'autorizzazione SEND_SMS richiesta, è stato aggiunto implicitamente il requisito delle funzionalità di android.hardware.telephony. Poiché la maggior parte dei dispositivi di grandi dimensioni (se non tutti) sono tablet senza hardware per la telefonia, in questi casi Google Play filtrerà questo APK, finché non saranno disponibili dispositivi futuri che siano entrambi abbastanza grandi da essere indicati come schermi di dimensioni molto grandi e dotati 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" />
Anche il requisito android.hardware.touchscreen viene aggiunto implicitamente. 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. La visualizzazione dell'applicazione durante la navigazione su Google Play potrebbe richiedere un po' di tempo, ma quando l'app viene visualizzata, esegui un ultimo controllo. Scarica l'applicazione su tutti i dispositivi di test di cui potresti avere bisogno per assicurarti che gli APK abbiano come target i dispositivi previsti. Congratulazioni, hai terminato.