Creare più APK per diversi livelli API

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 delle quali copre una gamma leggermente diversa di livelli API. Troverai anche alcuni strumenti necessario per rendere il più semplice possibile il mantenimento di un codebase più APK.

Conferma di aver bisogno di più APK

Quando tenti di creare un'applicazione che funzioni su più generazioni di Android è naturale che la tua applicazione sfrutti le nuove funzioni sui nuovi dispositivi, senza sacrificare la compatibilità con le versioni precedenti. All'inizio può sembrare che più APK di assistenza è la soluzione migliore, ma spesso non è così. L'APK Utilizzo singolo La sezione della guida per gli sviluppatori relativa a più APK include alcune informazioni utili su come può farlo con un singolo APK, incluso l'uso della nostra libreria di supporto. Inoltre, puoi scoprire come scrivere codice che venga eseguito solo a determinati livelli API in un singolo APK, senza ricorrere a tecniche costose dal punto di vista computazionale come la riflessione da questo articolo.

Se sei in grado di gestirla, limitare l'applicazione a un singolo APK comporta diversi e 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 API coperto da ogni APK. Come riferimento pratico, consulta la pagina Versioni piattaforma della Il sito web per sviluppatori Android fornisce dati sul numero relativo di dispositivi attivi su cui è in esecuzione un determinato della piattaforma Android. Inoltre, anche se inizialmente sembra facile, tenere traccia di quale insieme di livelli API scelti come target da ogni APK diventa difficile piuttosto rapidamente, soprattutto alcune sovrapposizioni (e spesso si verificano). Per fortuna, è facile delineare rapidamente i tuoi requisiti e potrai usarli come riferimento futuro.

Per creare un grafico con più APK, inizia con una riga di celle che rappresenta il diversi livelli API della piattaforma Android. Getta una cella in più alla fine per rappresentare il futuro tutte le versioni di Android.

Ora solo i colori nel grafico fanno in modo che ogni colore rappresenti un APK. Ecco un esempio di come potresti applicare ogni APK a un determinato intervallo di livelli API.

Dopo aver creato il grafico, distribuiscilo al tuo team. Comunicazione del team sul progetto è diventato immediatamente più semplice perché invece di chiedere "Come funziona l'APK per i livelli API da 3 a 6, Android 1.x. Come procede?" Puoi dire semplicemente: "Come sta arrivando l'APK blu" ?"

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-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 in considerazione l'insieme di diversi APK descritti in precedenza e supponiamo di non aver Impostare un livello API massimo per gli APK. Considerati singolarmente, l'intervallo possibile di ogni APK ha questo aspetto:

Perché è necessario che un APK con un valore minSdkVersion più elevato abbia anche un di versione più elevata, sappiamo che, in termini di valori versionCode, red ≥ verde ≥ blu. Di conseguenza, possiamo comprimere il grafico in modo che abbia questo aspetto:

Supponiamo inoltre che l'APK rosso abbia dei requisiti che gli altri due no. Pagina Filtri su Google Play di la guida per gli sviluppatori Android ha un intero elenco di possibili colpe. Per Per esempio, supponiamo che il rosso richieda una fotocamera anteriore. Infatti, l'intero punto l'APK rosso combina la fotocamera anteriore con la nuova e dolce funzionalità aggiunta nell'API 11. Tuttavia, a quanto pare, non tutti i dispositivi che supportano l'API 11 HANNO nemmeno una fotocamera anteriore. La orrore!

Fortunatamente, se un utente naviga su Google Play da un dispositivo di questo tipo, Google Play esaminerà il puoi vedere che Red indica come requisito la fotocamera anteriore e ignorarla tranquillamente, ha stabilito che Red e questo dispositivo non sono un abbinamento perfetto. Noterà che Il verde non è solo compatibile con il forwarding con i dispositivi con API 11 (poiché non è stato definito maxSdkVersion), ma non importa se c'è o meno una fotocamera anteriore. L'app può essere ancora scaricata da Google Play dall'utente perché, nonostante l'intero contrattempo con la fotocamera anteriore, c'era ancora APK che supportava quel determinato 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. Poiché l'insieme di APK di esempio riguarda solo uno dei tre possibili sarebbe sufficiente separare ciascun APK per 1000, impostare le prime due cifre minSdkVersion per quell'APK specifico e poi incrementarla. Potrebbe avere il seguente aspetto:

Blu: 03001, 03002, 03003, 03004...
Verde: 07001, 07002, 07003, 07004...
Rosso:11001, 11002, 11003, 11004...

Complessivamente, i manifest Android avranno probabilmente 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" />
    ...

Esaminare l'elenco di controllo pre-lancio

Prima di caricare contenuti su Google Play, controlla attentamente 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 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 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!

È 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: '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 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 saranno visibili a molti dispositivi.

Perché? Aggiungendo l'autorizzazione SEND_SMS richiesta, è stato aggiunto implicitamente il requisito delle funzionalità di 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" />

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 tuoi dispositivi di test, per assicurarti che gli APK abbiano come target i dispositivi previsti. Congratulazioni, hai terminato.