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.
Quando sviluppi un'applicazione Android per sfruttare diversi APK su Google Play, è importante adottare alcune best practice fin dall'inizio ed evitare inutili grattacapi nel processo di sviluppo. Questa lezione mostra come creare più APK della tua app, supportando un sottoinsieme diverso di formati di texture OpenGL. Avrai anche alcuni strumenti necessari per rendere il più semplice possibile gestire un codebase più APK.
Conferma di aver bisogno di più APK
Durante il tentativo di creare un'applicazione che funzioni su tutte le piattaforme Android disponibili dispositivi, ovviamente desideri che la tua applicazione venga visualizzata al meglio su ogni singolo dispositivo, a prescindere non supportano tutte lo stesso set di texture GL. All'inizio può sembrare che il supporto di più APK è 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 come rilevare la texture supportata formati in fase di runtime. In base alla tua situazione, potrebbe essere più semplice raggruppare tutti i formati con l'applicazione e scegli semplicemente quale utilizzare per il runtime.
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
La Guida per gli sviluppatori Android fornisce un riferimento pratico di alcune delle texture più comuni supportate sui supports-gl-texture . Questa pagina contiene anche alcuni suggerimenti sui telefoni (o sulle famiglie di telefoni) supportati. formati di texture specifici. Tieni presente che in genere è consigliabile che uno degli APK supporti ETC1, poiché il formato della texture è supportato da tutti i dispositivi Android che supportano OpenGL ES. 2.0.
Poiché la maggior parte dei dispositivi Android supporta più di un formato di texture, è necessario definire un in ordine di preferenza. Crea un grafico che includa tutti i formati previsti per la tua applicazione assistenza in tempo reale. La cella più a sinistra sarà la priorità più bassa (probabilmente sarà ETC1, una un solido valore predefinito in termini di prestazioni e compatibilità). Quindi, colora il grafico in modo che ogni cella rappresenta un APK.
| ETC1 | ATI | PowerVR |
La colorazione nel grafico non si limita a rendere questa guida meno monocromatica: offre anche un modo le comunicazioni tra i team sono più semplici. Ora puoi semplicemente fare riferimento a ciascun APK come "blu", "verde" "rosso", invece di "quello che supporta i formati di texture ETC1" e così via.
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 usare viene scelto tramite alcune semplici regole:
- Il file manifest deve indicare che un determinato APK è idoneo.
- Tra gli APK idonei, vince il numero di versione più alto
- Se uno dei formati di texture elencati nell'APK è supportato dal dispositivo sul mercato, il dispositivo è considerato idoneo
Per quanto riguarda le texture GL, quest'ultima regola è importante. Significa che, ad esempio, Ad esempio, presta molta attenzione all'utilizzo di formati GL diversi nella stessa applicazione. Se usare PowerVR il 99% delle volte, ma usare ETC1 per, diciamo, per la schermata iniziale... Quindi, il file manifest indica necessariamente il supporto per entrambi i formati. Un dispositivo che supportava solo ETC1 potrebbe essere considerata compatibile, la tua app verrebbe scaricata e l'utente vedrà un arresto anomalo messaggi. Il caso comune è che se utilizzi più APK specificatamente per scegliere come target dispositivi diversi in base al supporto delle texture GL, sarà un formato di texture per APK.
In questo modo il supporto delle texture in realtà è un po' diverso rispetto agli altri due APK multipli dimensioni, livello API e dimensioni dello schermo. Ogni dispositivo ha un solo livello API e una schermata e spetta all'APK supportarne una serie. Con le texture, in genere l'APK supporteranno una texture, mentre il dispositivo ne supporterà molte. Spesso si sovrappongono in termini di dispositivo che supporta molti APK, ma la soluzione è la stessa: i codici di versione.
Ad esempio, prendi alcuni dispositivi e scopri quanti APK definiti in precedenza si adattano a ciascuno dispositivo.
| Telefono | Nexus S | Evo |
| ETC1 | ETC1 | ETC1 |
| PowerVR | TC di ATI |
Supponendo che i formati PowerVR e ATI siano entrambi preferiti rispetto a ETC1 quando disponibili, in base al "numero di versione più alto vince" se impostiamo l'attributo versionCode in ogni APK in modo tale che il rosso ≥ verde ≥ blu, il rosso e il verde siano sempre scelti rispetto al blu sui dispositivi che li supportano e, qualora dovesse presentarsi un dispositivo che supporta sia il rosso che il verde, viene scelto il rosso.
Per mantenere tutti i tuoi APK in "canali" separati, è importante avere un codice di versione valido . Quello consigliato è disponibile nell'area Codici di versione della nostra guida per gli sviluppatori. Dal giorno l'insieme di APK di esempio riguarda solo una delle tre possibili dimensioni, sarebbe sufficiente separa ogni APK per 1000 e da lì in più. Potrebbe avere il seguente aspetto:
Blu: 1001, 1002, 1003, 1004...
Verde: 2001, 2002, 2003, 2004...
Rosso:3001, 3002, 3003, 3004...
Riassumendo, i manifest Android avranno probabilmente un aspetto simile al seguenti:
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" /> ...
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
- 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 versione della piattaforma
- 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.