Android 11 verrà fornito con una nuova impostazione "Compatibilità app" nell'Opzione sviluppatore, rendendo più semplice per gli sviluppatori di app testare le modifiche al comportamento della piattaforma.
Ogni anno al Google I/O, Google mette in evidenza alcuni dei cambiamenti più interessanti in arrivo nella prossima versione di Android. Sebbene la maggior parte degli utenti giudichi le versioni Android in base ai cambiamenti visivi che influenzano la loro esperienza, ogni aggiornamento Android include anche moltissimi aggiornamenti modifiche alle API E comportamento della piattaforma. È importante che gli sviluppatori di app prendano nota di questi cambiamenti e li preparino, poiché possono alterare radicalmente il modo in cui le loro app possono essere utilizzate dagli utenti finali. Con la prossima versione di Android, Android 11, Google renderà più semplice per gli sviluppatori testare e preparare le proprie app per le modifiche imminenti con una nuova impostazione "Compatibilità app" nelle Opzioni sviluppatore.
Ogni volta che Google rilascia una nuova versione di Android, gli sviluppatori di app interessati a mantenerla attivamente le loro applicazioni devono documentarsi sulle nuove modifiche e sulla documentazione fornita per queste i cambiamenti. Possono quindi decidere di aggiornare la propria app per aggiungere queste nuove funzionalità API, se lo desiderano, o di migrare l'utilizzo delle API esistenti verso API più recenti, un percorso che può essere facoltativo o meno. Gli sviluppatori di app non devono aggiornare immediatamente l'API di destinazione delle loro app, ma devono farlo alla fine per soddisfare i requisiti spostamento dei requisiti API target del Google Play Store. Successivamente, gli sviluppatori devono anche testare effettivamente la propria app sulla nuova versione di Android e ciò può essere fatto su un dispositivo emulato, un dispositivo ospitato nel cloud o un dispositivo locale. Il test fa parte della routine di sviluppo, ma diventa ancora più importante quando sono coinvolti cambiamenti importanti.
Inoltre, quando Google vuole introdurre importanti modifiche al comportamento della piattaforma, non implementa immediatamente la modifica nella nuova versione di Android. Questo serve a proteggere gli utenti dall'interruzione e dalla perdita di funzionalità di molte delle loro app e offre inoltre agli sviluppatori più tempo per aggiornare le proprie app. Ad esempio, con Android 7 Nougat, Google ha deciso di farlo limitare alcune trasmissioni implicite per risparmiare la durata della batteria. Con Android 8 Oreo, Google app completamente limitate dalla registrazione di ricevitori di trasmissione impliciti. Ma prima del rilascio di Android 8 Oreo, Google voleva che gli sviluppatori si preparassero per uno scenario in cui le loro app non sarebbero più state in grado di registrare ricevitori di trasmissione impliciti. E per questo, gli sviluppatori potrebbero utilizzare un comando ADB in Android 7 Nougat per simulare una condizione in cui le trasmissioni implicite non sono disponibili:
adb shell cmd appops set RUN_IN_BACKGROUND ignoreI comandi ADB come quello sopra sono un esempio di come Google consente agli sviluppatori di app di testare il comportamento delle loro app in caso di modifiche al comportamento della piattaforma Android.
Un altro esempio recente è come in Android Q Beta 2, Google ha chiesto agli sviluppatori di testare Scoped Storage sulle loro app eseguendo questo comando ADB:
adb shell cmd appops set your-package-name android: legacy_storage default && \Come sviluppatore di app, si può presumere che tu abbia dimestichezza con i comandi ADB e che non sia particolarmente contrario a usarli per testare queste modifiche alla piattaforma. Ma c'è sempre spazio per miglioramenti e Google sta semplificando questo processo di test introducendo una semplice interfaccia utente per controllare queste modifiche.
Con il nuovo Progetto PlatformCompat, gli sviluppatori non dovranno più eseguire comandi ADB per ogni nuova modifica del comportamento della piattaforma. Con Android 11, Android avrà un nuovo sottomenu all'interno delle Opzioni sviluppatore per attivare rapidamente le nuove modifiche al comportamento della piattaforma in base all'app, senza la necessità di inviare alcun comando shell ADB. Ci saranno sezioni diverse per ciascun livello API di destinazione, ad esempio il livello API > 29 avrà il proprio insieme di modifiche al comportamento che possono essere attivate/disattivate, mentre il livello API > 30 avrà il proprio insieme di i cambiamenti.
Nello screenshot qui sopra che mostra la sezione Compatibilità app (da un AOSP creato dal codice sorgente in esecuzione su un emulatore), il "Default La sezione Modifiche abilitate" include le modifiche API di Android 11 che verranno abilitate per impostazione predefinita su tutte le app indipendentemente dalla destinazione SDK. La sezione "abilitata per targetSDKversion > 29" contiene modifiche all'API Android 11 abilitate solo per le app destinate ad Android 11/livello API 30.
Anche se questo particolare cambiamento non entusiasmerà direttamente gli utenti finali, renderà più semplice il lavoro degli sviluppatori di app, e questa è sempre una buona cosa.
Grazie allo sviluppatore riconosciuto XDA luca020400 per il suggerimento e per aver fornito lo screenshot allegato.
Ulteriore copertura su Android 11:
- Android 11 potrebbe finalmente rimuovere il limite di dimensione dei file di 4 GB di Android per le registrazioni video
- La pianificazione della modalità oscura potrebbe arrivare in Android 11
- La modalità aereo potrebbe finalmente interrompere la disattivazione dell'audio Bluetooth, a partire da Android 11 R
- Google sta deprecando l'API AsyncTask di Android in Android 11
- Google farà sì che gli sviluppatori di file manager inviino un modulo per ottenere un ampio accesso all'archiviazione di file in Android 11
- Android 11 potrebbe finalmente portare un'implementazione ADB wireless nativa corretta