Riepilogo AMA Android Q: cosa ha detto Google su Android 10 su Reddit

L'anno scorso, il team Android di Google ha ospitato un Ask Me Anything (AMA) sul subreddit /r/AndroidDev di Reddit per rispondere a domande sull'argomento Anteprima per sviluppatori Android P. Quest'anno, il team di ingegneri che lavora sulla beta di Android Q ha risposto alle domande su Reddit. L'AMA è iniziato il 1° agosto alle 12:00 PST e si è concluso circa un'ora e mezza dopo. 33 ingegneri di Google sono stati coinvolti nell'AMA, rispondendo a tantissime domande nel breve periodo di durata dell'AMA. Ecco il riepilogo di tutte le nuove informazioni che abbiamo appreso.

Android Q AMA: tutto ciò che abbiamo imparato da Google

Partecipanti del team beta di Android Q

• Adam Cohen: TLM sull'utilità di avvio/interfaccia utente di sistema di Android
• Adam Powell: TLM su toolkit/framework dell'interfaccia utente; visualizzazioni, ciclo di vita, frammenti, librerie di supporto
• Alan Viverette: TLM, Jetpack/AndroidX
• Allen Huang: PM per interfaccia utente, launcher, notifiche, integrazioni di ricerca e altro ancora!
• Andrew Sappirstein: TLM su Impostazioni Android
• Brahim Elbouchikhi: Direttore PM per Android Machine Learning e fotocamera (API NN, kit ML, CameraX, piattaforma fotocamera)
• Chad Brubaker: Ingegnere software, Sicurezza della piattaforma Android
• Charmaine D'Silva: PM per la Privacy
• Chet Haase: Avvocato capo di Android, Relazioni con gli sviluppatori
• Diana Wong: PM, compatibilità app, utilizzo API non SDK, ART, NDK
• Dianne Hackborn: Responsabile del team del framework Android (Risorse, Window Manager, Activity Manager, Multiutente, Stampa, Accessibilità, ecc.)
• E.K. Chung: Direttore dell'UX
• Ian Lago: Ingegnere software, Jetpack (frammenti, navigazione, componenti di architettura)
• Iliyan Malchev: Principale ingegnere del software, Project Mainline
• Jacob Lehrbaum: Direttore delle relazioni con gli sviluppatori per Android
• Jake Wharton: Ingegnere informatico, Jetpack
• Jamal Eason: Primo Ministro, Android Studio
• Jeff Bailey: TLM, progetto Android Open Source (AOSP)
• Jeff Sharkey: Ingegnere software, Framework Android
• Jeffrey van Gogh: Android Studio, compilatori
• Jen Chai: PM, posizione e contesto, autenticazione, compilazione automatica, utilizzo API non SDK, ART
• Karen Ng: PM di gruppo per strumenti per sviluppatori Android, Android Studio, Android Tookit e Jetpack
• Paolo Bankhead: Direttore della gestione del prodotto, Google Play
• Rohan Shah: Responsabile prodotto, interfaccia utente del sistema Android
• Romain Guy: Responsabile del team Android Toolkit/Jetpack
• Sagar Kamdar: Direttore della gestione del prodotto, Android
• Sab K: Direttore dell'ingegneria, connettività Android
• Selim Cinek: Ingegnere software, interfaccia utente del sistema Android
• Stephanie Saad Cuthbertson: Direttore senior della gestione del prodotto, Android
• Sumir Kataria: Ingegnere informatico, Jetpack (WorkManager)
• Travis McCoy: PM, piattaforma Android
• Tristano fermo: Ingegnere eminente, responsabile dell'interfaccia utente e dell'intelligence del sistema Android
• Vin Modi: PM, fotocamera Android

Per saperne di più

Gli OEM non possono più eliminare le app quando l'utente le rimuove dai recenti

Se hai mai utilizzato uno smartphone di un marchio cinese, probabilmente hai avuto a che fare con fastidiose funzionalità di "ottimizzazione della batteria" che uccidi tutte le tue app preferite in background. Non solo questo comportamento è fastidioso per gli utenti che si aspettano che determinate app continuino a funzionare in background per qualsiasi motivo, ma è anche fastidioso per gli sviluppatori che devono subire recensioni negative da parte di utenti che non capiscono che non è l'app colpa. Mentre Google lo è Ancora non affrontando completamente la questione (hanno ignorato il problema affermando che questo comportamento è probabilmente già in violazione dei requisiti del documento di definizione della compatibilità Android), l'azienda È prendere l'iniziativa contro un cambiamento di comportamento di "risparmio batteria" adottato da alcuni OEM.

"Per risolvere la situazione, abbiamo aggiunto un test CTS in Android Q per garantire che un'app non venga interrotta dopo essere stata trascinata da Recenti."

Android R potrebbe apportare più modifiche agli screenshot di quanto ci aspettassimo

Google prevede di aggiungere schermate a scorrimento in Android R, ma allo stesso tempo, il La squadra Android è "guardando da vicino come [loro] possono migliorare l'intera esperienza sullo schermo-[X] per R." Quindi, possiamo vedi altri miglioramenti al comportamento degli screenshot (E screencast) nella prossima versione principale di Android.

Chiarimento sulla nuova modalità desktop di Android Q

IL prima versione beta pubblica di Android Q ha portato un'interfaccia in modalità desktop nascosta su AOSP e Pixel Launcher. Sebbene Google ha brevemente accennato alla funzionalità durante una sessione di Google I/O, non abbiamo mai sentito direttamente da Google come la nuova funzionalità si inserisce nell'ecosistema Android. Google ora chiarisce:

"In Q AOSP la 'modalità desktop' è un'opzione sviluppatore destinata agli sviluppatori di applicazioni. Consente loro di testare le proprie app in ambienti multi-display e in modalità finestra a forma libera. In precedenza non esisteva un modo conveniente per testare il comportamento delle app su un display secondario e con finestre ridimensionabili liberamente su Android di serie. Questa funzionalità non è disponibile da sola e al momento non è pensata per gli utenti regolari. Tuttavia, costituisce la base della piattaforma Android per consentire agli OEM di innovare e realizzare ottimi prodotti."

Pertanto, possiamo aspettarci di vedere gli OEM basarsi sulla modalità desktop nativa di Android Q. Ad esempio, il OnePlus 7 Pro supporta l'uscita display tramite HDMI, quindi è possibile OxygenOS 10 basato su Android Q avrà la propria interfaccia in modalità desktop in futuro. Speriamo anche che Google sviluppi la funzionalità per il prossimo aggiornamento Pixel 4.

Modalità oscura basata sul tempo

Android Q porta finalmente una funzionalità ampiamente richiesta: modalità oscura a livello di sistema. Attualmente, la modalità oscura può essere abilitata manualmente in Impostazioni o tramite un riquadro Impostazioni rapide oppure può essere attivata automaticamente quando è abilitato il risparmio energetico. Prima di Android Q, esisteva un'opzione per abilitare la modalità oscura in base all'ora del giorno, ma tale opzione è stata deprecata. Secondo Chris Banes:

"Ci sono alcuni motivi per cui questo è deprecato (non rimosso) in AppCompat v1.1.0: richiede che le app richiedano le autorizzazioni di posizione siano precise e anche con una posizione valida i calcoli dell'ora di alba/tramonto possono esserlo carrozza."

Interrogato su questi bug, Banes afferma che "il calcolo dell'alba e del tramonto è notoriamente difficile, soprattutto per le località vicine a poli nord/sud." Un utente visualizza che la luce notturna, disponibile a partire da Android 7.1 Nougat, può essere attivata automaticamente in base al tramonto/alba orari. Il signor Banes afferma poi che poiché Night Light utilizza CalendarAstronomer da ICU4J, utilizza "una grossa porzione di codice da cui non vorremmo che AppCompat dipendesse". Tuttavia, la squadra lo fa stato che questa caratteristica è "qualcosa che [loro] esamineranno".

Supporto API Camera2/Camera HAL3 obbligatorio per i dispositivi di lancio Android Q

Google ha introdotto le API Camera2 per definire meglio come le app possono interagire con le singole fotocamere collegate allo smartphone. Mentre Google incoraggia fornitori di smartphone di "esporre tutte le loro fotocamere fisiche agli sviluppatori", molti fornitori scelgono di non farlo anche se "l'API stessa non è prevenendoli oggi." Ciò significa che molte app per fotocamere di terze parti non possono utilizzare i moduli fotocamera secondari o terziari su Modern smartphone. Tuttavia, si stanno facendo progressi grazie al miglioramento di Android Q LOGICAL_MULTI_CAMERA, un'API che offre agli sviluppatori un migliore accesso a tutte le fotocamere di un dispositivo e che offre agli OEM il controllo sul consumo energetico e sulla gestione di più stati della fotocamera.

Inoltre, Google afferma di aver aggiunto i requisiti per tutti i dispositivi avviati con Android Q per supportare nativamente Camera2 API/Camera HAL3. Secondo Vinit Modi:

"A partire da Android P, i nuovi dispositivi forniti con 1 GB o più di RAM devono utilizzare nativamente HALv3/camera2. Da Android Q in poi, tutti i nuovi dispositivi devono supportare nativamente HALv3/camera2. Sfortunatamente gli aggiornamenti da HALv1 a HALv3 sono piuttosto complessi via etere e potrebbero avere conseguenze inaspettate, quindi abbiamo dovuto limitare l'ambito ai nuovi dispositivi."

È interessante notare che la dichiarazione di Modi sui normali dispositivi di lancio Android P con RAM contraddice quanto ci è stato detto in precedenza da Google e quanto pubblicato online sulla pagina Image Test Suite.

Temi dinamici per le app con Jetpack Compose

Il framework tematico OMS di Sony è stato aggiunto ad AOSP parecchie versioni fa, ma è solo destinato agli OEM su cui basarsi. Lo sappiamo già Google è contrario l'uso di sovrapposizioni di risorse runtime da parte degli utenti alle app a tema, ma per gli sviluppatori l'azienda lo è sperando quello è Jetpack Componi interfaccia utente quadro porterà avanti "approcci interessanti alla tematizzazione dinamica".

Backend Vulkan per Skia per eseguire il rendering dell'interfaccia utente

L'anno scorso, abbiamo notato una discussione tra gli ingegneri di Google che parlano dei loro piani per far sì che il framework Android utilizzi l'API grafica Vulkan per il rendering dell'interfaccia utente. Mentre ora è possibile abilitare il backend con accelerazione hardware Vulkan senza il telefono crashando, non abbiamo sentito alcun piano concreto da parte di Google su quando intendono implementarli i cambiamenti. Questo AMA non risponde a questa domanda, ma almeno abbiamo la conferma che è ancora in lavorazione. Secondo Romain Guy:

"Il team ha lavorato su un backend Vulkan per Skia, il renderer 2D utilizzato da Android, ma al momento non è abilitato per impostazione predefinita. L'interfaccia utente e Canvas utilizzano ancora OpenGL ES."

Rendere la barra dei gesti di Android Q più dinamica

Alcuni su XDA lo pensano ancora I nuovi gesti di Android sono un disastro, ma personalmente penso che vadano bene. Se giochi un po' con i nuovi gesti in Android Q, noterai che la barra dei gesti non si muove con il dito. Rimane anche sugli schermi in cui non è necessario, come la schermata iniziale o la panoramica delle app recenti. Allen Huang dice che sono "totalmente d'accordo che ci siano opportunità" per rendere la "linea di navigazione meno statica". Dice inoltre che "questo è qualcosa su cui stiamo lavorando, ma anche su un bilanciamento in modo che non distragga apparire/scomparire."

Miglioramenti al framework di accesso allo storage

I numerosi cambiamenti apportati ad Android Q hanno notevolmente migliorato la sicurezza e privacy della piattaforma. Uno di questi cambiamenti, chiamato "Scoped Storage", limita l'accesso delle app ai file sulla memoria esterna in un modo che abbia senso; ad esempio, le app musicali non dovrebbero aver bisogno di vedere la tua galleria. Le app di gestione file in esecuzione su Android Q devono utilizzare un'API chiamata Storage Access Framework per continuare a funzionare normalmente, ma alcuni sviluppatori considerano questa API inferiore a quanto precedentemente disponibile. Jeff Sharkey di Google dice il team ha affrontato alcuni dei reclami di questi sviluppatori:

"Abbiamo apportato alcuni miglioramenti alle prestazioni SAF nelle ultime versioni di Android Q Beta; potresti controllare i tuoi benchmark rispetto all'ultima Beta? Assicurati inoltre di utilizzare un ContentProviderClient quando esegui operazioni in blocco."

Project Treble ha migliorato l'adozione di Android Pie rispetto ad Android Oreo

Abbiamo già visto come Project Treble, un'importante riprogettazione di basso livello del framework Android, abbia migliorato l'adozione delle versioni più recenti del sistema operativo Android. Google attribuisce a Treble il merito della serie di fornitori di smartphone che si sono uniti al progetto Android P beta l'anno scorso e Android Q beta quest'anno. Iliyan Malchev, il capo Project Treble e Linea principale ingegnere, dice che l'adozione di Android Pie è stata "3 volte" quella di Android Oreo alla fine del 2018.

Nello stesso commento, Dick Dougherty anticipa che sono in lavorazione metriche più utili per il grafico di distribuzione della versione Android. Il grafico era ultimo aggiornamento a maggio, ma i suoi dati sono più utili ai giornalisti che agli sviluppatori di app.

La registrazione dello schermo è ancora un WIP

Le prime versioni beta di Android Q aggiungevano un flag di funzionalità per un registratore dello schermo di base, ma la piattaforma stessa ha migliorato notevolmente l'utilità della registrazione dello schermo consentendo alle app di acquisire l'audio da altre app. Stephanie Saad Cuthbertson ha detto che il team stava valutando "come potremmo fare meglio per quanto riguarda le esigenze di registrazione dello schermo fino a ieri". Altri marchi di smartphone come OnePlus, ASUS, Huawei e Samsung dispongono di robusti registratori di schermo in grado di registrare l'audio interno, quindi Google cercherà di recuperare il ritardo qui.

Tema scuro Tutte le cose!

Nel caso te lo fossi perso, Google sta aggiungendo la modalità oscura alla maggior parte delle sue app. Stephanie Saad Cuthbertson dice aspettarsi che tutte le "principali app" supportino un tema scuro "entro la versione ufficiale [di Android Q]". Anche Google Chrome, che attualmente forza il ricaricamento della pagina quando è abilitato il tema scuro a livello di sistema, verrà aggiornato per non aggiornarsi più quando il tema lo è cambiato.

Sì, i launcher di terze parti funzioneranno con i gesti (eventualmente)

I gesti di Android sono una specie di rotto quando si utilizza un launcher di terze parti. Questo perché l'interfaccia utente delle app recenti è contenuta nell'app di avvio delle azioni e Google non l'ha ancora fatto ha trovato un modo per avere le stesse transizioni fluide che vediamo quando utilizziamo i gesti con il Pixel di serie Lanciatore. Adam Cohen afferma I piani di Google per affrontare questi problemi "il più rapidamente possibile dopo il rilascio". Lo dice inoltre l'incompatibilità "verrà risolta nell'aggiornamento post-Q e verrà eseguito il backport per il lancio di nuovi dispositivi con Q."

Le partizioni dinamiche/logiche non sono qui per uccidere le ROM personalizzate

Per sostenere Aggiornamenti dinamici del sistema in Android Q, alcuni dispositivi come Google Pixel 3 e Pixel 3 XL utilizzano partizioni logiche. Queste partizioni possono essere ridimensionate dinamicamente. Questo cambiamento ha si è rivelato difficile nel far funzionare l'accesso roote alcuni sviluppatori temono che le ROM personalizzate vengano prese di mira. Iliyan Malchev ci assicura che l'intenzione non è quella di vincolare le ROM personalizzate. COME lui spiega:

"Le partizioni dinamiche non hanno lo scopo di limitare ciò che puoi fare con le ROM personalizzate. Sono semplicemente un soluzione al problema delle dimensioni fisse delle partizioni e alla mancanza di un modo sicuro per ripartizionare i dispositivi OTA. Prima delle partizioni dinamiche, se un OEM commetteva un errore nel dimensionamento, ad es. la partizione di sistema, quindi loro sarebbe vincolato da tale scelta, rendendo praticamente impossibile aggiornare un dispositivo dopo un certo periodo punto. Alcuni OEM ripartizionano i propri dispositivi su OTA come pratica, ma questo a) non è ufficialmente supportato in Android e b) la modifica della tabella delle partizioni è considerata piuttosto rischiosa. Le partizioni dinamiche mirano ad alleviare il problema introducendo un livello di indiretto tra la tabella delle partizioni fisiche e il sistema operativo. Questo a sua volta ci consente di regolare in modo sicuro le dimensioni delle partizioni su OTA. Per quanto riguarda le ROM personalizzate, non dovresti essere affatto vincolato più di quanto lo sei oggi con ciò che puoi fare. Il supporto delle ROM personalizzate è e continua ad essere qualcosa che ogni singolo OEM decide di abilitare."

Progetto Mainline - Modulo ART e durata del supporto

Mainline è una nuova iniziativa di Google che mira a standardizzare alcune librerie e pacchetti in modo che possano essere aggiornati indipendentemente dagli aggiornamenti della piattaforma. Alcuni si sono chiesti perché Android Runtime (ART) non è ancora un modulo Mainline, ma al Google I/O mi è stato detto che la complessità coinvolta nella modularizzazione di ART ha impedito loro di includerlo come uno dei pacchetti APEX iniziali. COME spiegato sia di Iliyan Malchev che di Diana Wong:

"Apportare aggiornamenti al Runtime (in particolare correzioni di prestazioni e GC e librerie principali) è sicuramente qualcosa che stiamo esplorando nel contesto della linea principale. Possiamo vedere molti vantaggi nel poter rendere questi aggiornamenti coerenti su tutti i dispositivi e su più versioni con la linea principale. È anche un’enorme sfida tecnica mentre pensiamo a come farlo al meglio per gli sviluppatori, e probabilmente uno sforzo pluriennale. Non è qualcosa che Mainline può fare attualmente, ma sicuramente è qualcosa a cui stiamo pensando."

Se segui l'AOSP Gerrit, vedrai che Google è comunque stato Duro a lavoro creare un Runtime APEX. Attualmente sembra che lo siano dividendo Bionic e ART/libcore in moduli APEX separati.

Per quanto riguarda i vantaggi di Project Mainline, un utente ha chiesto informazioni sulla durata degli aggiornamenti di Mainline. In risposta, Iliyan Malchev dice che "questa è una questione politica che stiamo ancora valutando, ma vogliamo aggiornare i moduli Mainline su un dispositivo il più a lungo possibile". Sviluppatore riconosciuto XDA luca020400 ha chiesto se verranno forniti moduli Mainline predefiniti in modo che gli sviluppatori di ROM personalizzate possano unire gli aggiornamenti e, in risposta, Jeff Bailey ribadisce che "i moduli che si stanno separando da AOSP avranno versioni sorgente corrispondenti a ciascuna versione del modulo". Possiamo già vedere la progressione dei nuovi moduli APEX in AOSP come quello per API delle reti neurali.

CameraX incontra il kit ML

All'I/O di quest'anno, Google ha presentato il Libreria CameraX Jetpack. Questa libreria è progettata per consentire agli sviluppatori di supportare più facilmente l'API Camera2 di Android mantenendo la compatibilità fino ad Android Lollipop. Vinit Modi stuzzica con cui l'azienda sta lavorando all'integrazione di CameraX Kit ML, l'SDK Firebase di machine learning di Google, in modo che gli sviluppatori possano inserire frame di immagine in ML Kit per l'analisi.

Estensioni del fornitore CameraX e data di rilascio

Lo sviluppatore di un'app per fotocamera lamenta il fatto che le funzionalità avanzate della fotocamera come Night Sight di Google Pixel non siano accessibili alle app per fotocamera di terze parti. Questo dovrebbe essere risolvibile con le estensioni del fornitore CameraX, a cui Jeff Sharkey di Google dice che "tutti i dispositivi Pixel sono ottimizzati per CameraX Core". Egli anticipa che "l'aspetto delle estensioni sarà supportato sui dispositivi nuovi e futuri". Inoltre, Google lo è "collaborando con diversi produttori per poter offrire le funzionalità dei loro dispositivi sia agli sviluppatori che agli utenti." Anche se non confermato direttamente, è possibile che vengano visualizzate funzionalità Piace Vista notturna sul GooglePixel4 diventano disponibili per app per fotocamere di terze parti che utilizzano la libreria CameraX.

Il signor Sharkey afferma che Google punta a rilasciare una versione beta per la fine di quest'anno.

Miglioramenti alla gestione della memoria in Android Q

Il Pixel 3 è stato criticato per averlo numerosi problemi post-lancio, ma Google ha fatto molto per risolvere questi problemi tramite numerosi aggiornamenti post-lancio. La gestione della memoria è stata uno degli aspetti più deboli del Pixel 3, ma le cose dovrebbero andare un po' meglio nella versione Android Q. Secondo Selim Cinek:

"In SystemUI, ad esempio, abbiamo effettuato diversi grandi sforzi di refactoring in Q per ridurre l'utilizzo della RAM da parte delle notifiche e di altre superfici."

Avremo finalmente l'ADB wireless?

Se desideri eseguire il debug in modalità wireless del tuo telefono, dovrai eseguire il root del tuo dispositivo. Jamal Eason del team di Android Studio dice che stanno attualmente valutando la fattibilità di questa funzione.

Google esegue ancora test sui tablet?

Sviluppatore riconosciuto XDA Luk1337 ha chiesto se Google testa ancora AOSP UX sui tablet. È una domanda giusta considerando il carenza di buoni tablet Android e il bug presenti nelle versioni attuali. Allen Huang dice che Google continua a "testare e apportare correzioni ogni anno" e che la società sta lavorando a stretto contatto con i partner "per garantire una buona esperienza sui tablet Android".

---

Ci sono molti più post nel thread completo su Reddit. Ciò che ho trattato qui riassume tutte le nuove informazioni che abbiamo appreso, ma diversi Googler (in particolare Dianne Hackborn) approfondiscono il ragionamento dietro il taglio della funzionalità X o la mancata implementazione di Y autorizzazione. Ti consiglio di leggere l'AMA completo se vuoi comprendere un po' meglio il processo decisionale del team Android.

Leggi l'AMA completo su /r/AndroidDev