Come saprete certamente recentemente Google ha cambiato il formato con cui è possibile sottoporre le app al suo store: il vecchio formato apk va in pensione in favore del nuovo e scintillante aab.
I vantaggi di questo “pensionamento” sono molteplici, e qui non mi dilungherò: lascio in particolare in linkografia alcuni documenti che ho trovato utili per comprenderne qualcosa in più.
Comunque pur avendone letto negli scorsi mesi devo ammettere che ho continuato a pubblicare le nuove versioni delle app alle quali lavoro sempre in apk, ma solo per sciatteria, lasciandomi il battesimo con aab alla prima occasione utile.
Infatti da quello che ho potuto verificare sino alla data odierna aggiornamenti di app esistenti accettano ancora il vecchio e glorioso formato apk: nuove app devono giocoforza usare aab.
Qualche giorno l’occasione di usare questo nuovo formato è arrivata, e devo dire che arrivare in fondo, e riuscire a pubblicare la mia nuova app con il nuovo formato, non è stato affatto semplice o banale: anzi è stato un vero e proprio percorso a ostacoli.
Piccola/grande nota:so perfettamente che devops nonchè anche le buone norme di programmazione intimano che il deploy dovrebbe essere automatico e quindi che il processo di cui parlo in queste righe dovrebbe essere completamente automatico.
Però io ho inziato a programmare ai tempi ai tempi in cui se eri ricco avevi ben 64 KB di memoria, altrimenti se eri poveraccio (come il sottoscritto) dovevi accontentarti di 8 KB: per questo alcune operazioni preferisco farmele ancora a mano, “alla vecchia maniera”.
Proprio per questo ho deciso di scrivere questo post per aiutare i tapini come me in questo processo, non certo complicato, ma che nasconde alcune insidie: al termine di queste note potrete vantarVi anche Voi in giro di usare aab per le Vostre app.
La prima operazione da fare è convincere Visual Studio a produrre il file di setup di Android nel formato corretto.
Questo è il processo più semplice: basta mettere mano alle proprietà del progetto e in Android Options selezionare alla voce Android Package Format la voce bundle.
Fatto questo occorre anche verificare che l’opzione Android Package Signing non abbia alcuna firma impostata (dovrebbe essere il default per Release mode, ma un’occhio è meglio darlo).
Fermi lì: già che siete con le opzioni del progetto Xamarin Android aperto dovete anche portare il target del progetto almeno ad Android 11, altrimenti quando proverete a sottoporre il file nel play store otterrete il seguente errore.
Your app currently targets API level 29 and must target at least API level 30 to ensure it is built on the latest APIs optimized for security and performance. Change your app’s target API level to at least 30
Anche questa operazione è abbastanza semplice: basta andare in Application, e portare la voce Compile using Android version (Target Framework) almeno ad Android 11.0 (R).
Poi i sacri testi dicono che è meglio anche impostare alla stessa versione anche nell’opzione Target Android Version: per fare questo accedere all’opzione Android Manifest e impostare Taget Android Version almeno ad Android 11.0 (API Level 30 – R).
Oss.: Troverete in questo blog due articoli che parlano diffusamente di queste due opzioni, che Vi invito a leggere se siete interessati.
Ora se pensate di aver finito direi che Vi sbagliate: infatti se avete altre app pubblicate nello store dovete creare una nuova firma fiammante da usare per firmare il pacchetto aab, altrimenti quando tenterete di propinarlo al play store per la sua pubblicazione Vi beccherete un’altro maledetto messaggio di errore.
You uploaded an APK or Android App Bundle that is signed with a key that is also used to sign APKs that are delivered to users. Because you are enrolled in Play App Signing, you should sign your APK or Android App Bundle with a new key before you upload it.
Fare questa operazione è abbastanza semplice, e non Ve lo espongo nemmeno ma Vi lascio in linkografia le istruzioni ufficiali (Signing the Android Application Package).
Mi raccomando di salvare anche la firma così creata in luogo sicuro e lontano da rotture del Vs hard disk: trovate tutti i file in parola sotto C:\Users\<none utente>\AppData\Local\Xamarin\Mono for Android\Keystore\.
In questo modo se il Vs pc decide di lasciarVi Voi potrete continuare a usare la stessa firma per pubblicare le app.
Nota finale: se volete fare un rapido test al pacchetto creato su un dispositivo fisico prima di sottoporre il pacchetto di installazione al paly store, giusto per verificare che tutte le maschere si aprano e che l’AOT abbia funzionato a dovere, ecco la cosa non si può fare con questo formato !
Infatti i dispositivi Android usano sempre e solo il formato apk, e se gli date in pasto un file aab questi non sanno che farsene e Vi guardano straniti se provate a proporglielo (provate con il Vs tablet Andoird e vederete che faccia strana farà….).
Però esemplificando parecchio il file di installazione aab contiene al suo interno l’apk che è possibile estrarre in alcuni modi: io Vi riporto qui i due più facili, ma sono sicuro che Ve ne sono altri.
- Usare il progrrammillo bundletool che promette di prendersi un aab e di darVi in cambio il relativo apk
- Da dentro la pagina del play store esiste una voce App bundle explorer da dove è possibile scaricare l’agognato file in formato apk.
Linkografia
Blog Dan Siegel AndroidX, App Bundle and Profiled AOT for Xamarin Android
You Tube: Top 7 takeaways for Android App Bundles
Dev Blog Microsoft: Publish smaller apps with the Android App Bundle
M$ Docs: Signing the Android Application Package
Informatica Pressapochista: Xamarin Android: Il grande mistero degli Android API Level – Prima parte
Follow