Android 11 AMA: nessuno screenshot a scorrimento, avvio delle app più veloce e altro ancora

click fraud protection

Il team di ingegneri Android di Google ha ospitato un AMA su Reddit per rispondere a domande su Android 11. Ecco cosa abbiamo appreso sulla prossima versione del sistema operativo Android.

Ieri, Google ha rilasciato Android11Beta2, introducendo SDK, NDK, superfici rivolte alle app, comportamenti della piattaforma e restrizioni sulle interfacce non SDK finalizzate per gli sviluppatori. Oggi Google risponde alle domande relative ad Android 11 sulla community /r/AndroidDev di Reddit dopo aver risposto alle domande la settimana scorsa. Ecco un riepilogo di tutto ciò che abbiamo imparato dall'AMA (Ask Me Anything) di Google.

Una delle funzionalità più attese di Android 11 non sarà disponibile quando il sistema operativo esce dalla beta l'8 settembre: Schermate a scorrimento. Inizialmente previsto per il lancio in Android 11, Google ha ora confermato che la funzione "non è stata tagliata per R." Anteprima per sviluppatori Android 11 1 e tutte le versioni successive DP e Beta hanno un pulsante segnaposto per acquisire uno screenshot a scorrimento che può essere

emerso manualmente con un comando nascosto dello sviluppatore, ma toccando il pulsante viene semplicemente visualizzato un messaggio di avviso che indica che la funzione "non è implementata".

Pulsante screenshot a scorrimento non implementato di Android 11.

Speravamo che la funzionalità arrivasse alla versione beta o anche solo alla versione stabile, ma sembra che ciò non accadrà.

Commento dalla discussione. Facciamo parte del team tecnico di Android. Chiedici qualsiasi cosa sugli aggiornamenti di Android 11 sulla piattaforma Android! (inizia il 9 luglio).

Questa notizia sarà comprensibilmente sconvolgente per alcuni utenti. Dopotutto, molti OEM hanno questa funzionalità nel proprio software da anni, quindi perché Google impiega così tanto tempo ad aggiungerla ai telefoni Pixel? Come spiegato da Dan Sandler del team System UI di Google, il problema è che Google vuole farlo nel modo giusto. Alcune implementazioni di screenshot a scorrimento disponibili semplicemente emulano uno scorrimento e quindi uniscono più screenshot mentre lo schermo si muove. Se hai mai avuto a che fare con l'automazione dell'interfaccia utente su Android, saprai che non sempre funziona poiché, come menziona Sandler, le app può utilizzare "un RecyclerView standard o aver implementato il proprio motore di scorrimento accelerato OpenGL". Poiché Google prevede di farlo implementare questa funzionalità non solo per gli smartphone Pixel ma per l'intero ecosistema Android come parte di AOSP, devono assicurarsi funzionerà Tutto app e non solo "una o due app selezionate con cura su un particolare dispositivo".

Perché il team ha dovuto "concentrare le [proprie] risorse limitate", soprattutto a causa delle sfide poste a causa del COVID-19, il team ha deciso di mettere in secondo piano gli screenshot a scorrimento per una futura versione di Android.

Nuovo requisito CDD per informare gli utenti delle restrizioni di background

Non è un segreto che molti OEM Android, soprattutto quelli cinesi, abbiano restrizioni aggressive sulle app in esecuzione in background. Alcuni sviluppatori erano così frustrati dal fatto che le loro app venivano uccise in background che si unirono per creare un sito web chiamato "Non uccidere la mia app" per classificare gli OEM in base alla scarsa capacità con cui gestiscono i processi delle app in background. Quegli stessi sviluppatori anche recentemente ha fatto un punto di riferimento in modo che gli utenti possano testare con quanta aggressività il loro dispositivo uccide le app in background. Il motivo per cui molti OEM amano interrompere i processi delle app in background è complicato, ma penso che sia meglio spiegato in questo commento di Redditor /u/forse discutibile. Il commento delinea lo stato complicato dello sviluppo di app Android in Cina, come lo sono le aziende tecnologiche cinesi sono coinvolti in ulteriori complicazioni e come la mancanza di servizi Google contribuisca a ciò disordine.

Indipendentemente da ciò, molti sviluppatori di app sono comprensibilmente frustrati da queste modifiche al comportamento della piattaforma Android, che hanno portato gli sviluppatori a inviare un commento chiedendo a Google cosa stanno facendo al riguardo in cima all'AMA di Reddit. Ecco la risposta di Google:

Commento dalla discussione. Facciamo parte del team tecnico di Android. Chiedici qualsiasi cosa sugli aggiornamenti di Android 11 sulla piattaforma Android! (inizia il 9 luglio).

Ci sono alcune cose da imparare da questa risposta. Innanzitutto, Google vuole che gli OEM siano più trasparenti con gli utenti riguardo alle restrizioni delle app in background che stanno applicando. Ho controllato il documento (CDD) di definizione della compatibilità di Android 11 (inedito) e ho trovato la seguente aggiunta proposta alla Sezione 3.5 - Compatibilità comportamentale dell'API:

Se le implementazioni del dispositivo implementano un meccanismo proprietario per limitare le app e tale meccanismo è più restrittivo del bucket di standby "Rare" su AOSP,:

[C-1-5] DEVE informare gli utenti se le restrizioni dell'app vengono applicate automaticamente a un'app. (NUOVO) Tali informazioni NON DEVONO essere fornite prima che siano trascorse 24 ore dall'applicazione di tali restrizioni.

(Nota) L'arresto forzato è considerato più restrittivo di "Raro" e DEVE soddisfare tutti i requisiti di cui al punto 3.5.1, incluso il nuovo 3.5.1/C-1-5

Fondamentalmente, Google non è in grado di impedire agli OEM di implementare le proprie funzionalità restrittive di uccisione delle app. Richiedono solo agli OEM di informare gli utenti se le restrizioni delle loro app vengono applicate automaticamente. Un OEM potrebbe mostrare una finestra di dialogo che impedirà l'esecuzione delle app in background che consumano batteria nel file background e l'utente potrebbe acconsentire senza rendersi conto che lo sono anche le app che desidera realmente eseguire in background ricercato! Google sta affidando agli sviluppatori l'onere di gestire i casi in cui la loro app viene interrotta inaspettatamente in background. Infatti, il commento di Reddit prosegue evidenziando la novità"motivi di uscita del processo dell'app" API che può indicare agli sviluppatori se la loro app è stata terminata dall'utente, dal sistema operativo o se si è semplicemente bloccata.

D'altra parte, Google sta finalmente affrontando la pratica sleale degli OEM che consentono ad alcune applicazioni privilegiate di aggirare le restrizioni delle app in background. Questo post medio dello sviluppatore Timothy Asiimwe entra nei dettagli su app come WhatsApp, Facebook e altre app che sono automaticamente esentate dalle dure restrizioni di background di alcuni software OEM. Google afferma che "richiedono che i produttori di dispositivi non creino elenchi di autorizzazione per le app principali". Non sappiamo come verrà applicato, ma è bello sapere che gli OEM saranno finalmente costretti a trattare gli sviluppatori di terze parti su un piano di parità, non importa quanto grandi o piccole siano le loro app Sono.

Infine, Google menziona anche come Android 11 abbia "aggiunto misure aggiuntive per prevenire comportamenti abusivi da parte di app che si comportano in modo anomalo", rendendo meno allettante per gli OEM l'eliminazione aggressiva dei processi in background. La società, tuttavia, non ha spiegato cosa comportano queste “misure aggiuntive”.

Backup da dispositivo a dispositivo migliorati

Il mese scorso abbiamo notato una modifica alla documentazione di Android 11 che accennato al supporto per migliori backup dei dati locali. In Android 11, il sistema ignorerà l'attributoallowBackup Manifest per qualsiasi app destinata al livello API 30 quando l'utente avvia una migrazione "da dispositivo a dispositivo" dei file dell'app. Il googler Eliot Stock afferma che questa funzionalità ha lo scopo di rendere "molto più semplice per i produttori di telefoni la creazione di strumenti di migrazione da dispositivo a dispositivo" come "l'eccellente prodotto Smart Switch di Samsung" per aiutare a "garantire che le app vengano trasferite in modo più affidabile tra i dispositivi dal punto di vista dell'utente". Purtroppo, questo non si applica ai backup basati su cloud, poiché Google vuole "dare agli sviluppatori di software il controllo su cosa". avviene con i dati delle loro app." Pertanto, Android 11 rispetterà comunque l'attributoallowBackup per qualsiasi backup e ripristino basato su cloud, ad esempio tramite Google Drive integrato di Google Play Service backup. Infine, Google riconosce che il limite massimo di backup di 25 MB per app potrebbe non essere sufficiente per alcuni sviluppatori, quindi stanno cercando modi per risolverlo. Tuttavia, i backup locali su un PC non sono presi in considerazione e Google ribadisce il proprio piano in tal senso eliminare gradualmente il backup adb in una futura versione di Android.

Commento dalla discussione. Facciamo parte del team tecnico di Android. Chiedici qualsiasi cosa sugli aggiornamenti di Android 11 sulla piattaforma Android! (inizia il 9 luglio).

Gli sviluppatori sono incoraggiati a implementare metodi di migrazione dei dati semplici. IL nuova libreria Block Store, che fa parte della libreria dei servizi di identità di Google, è progettato per semplificare l'accesso alle app ripristinate dal cloud sui nuovi dispositivi, ma spetta agli sviluppatori scegliere se vogliono implementarlo o meno biblioteca.

Velocità di avvio delle app più elevate con il processo I/O Read Ahead (IORap)

Google sperimenta continuamente modi per migliorare le prestazioni in Android. Una delle funzionalità poco conosciute aggiunte in Android 10 si chiama USAP (Unspecialized App Process Pool). Questa funzionalità elimina il fork di Zygote durante il processo di avvio dell'app, risparmiando circa ~ 5 ms nella velocità media di avvio dell'app su un dispositivo Pixel 2. La funzione è attualmente disabilitato per impostazione predefinita in AOSPe Google spiega che l'utilizzo della memoria aggiuntiva deve ancora essere testato. La cosa più interessante, però, è una nuova funzionalità in arrivo su Android 11 chiamata I/O Read Ahead Process (IORap). Secondo Google, questa funzionalità porterà a "avviamenti a freddo più del 5% più veloci con casi eroici che raggiungeranno il 20% più velocemente". Questa caratteristica "prelegherà gli artefatti delle applicazioni (come codice e risorse) durante il processo di avvio" per potenziare il lancio dell'app velocità.

Google ha inoltre "apportato miglioramenti ai profili utilizzati per ottimizzare il percorso della classe di avvio e l'immagine di sistema" che migliorerà le prestazioni dell'app e ridurrà i costi di memoria e archiviazione associati al sistema artefatti. Questi cambiamenti andranno a beneficio soprattutto dei dispositivi con quantità maggiori di RAM, anche se Google non ha detto quale sarà il limite per cui vedremo i maggiori vantaggi.

Modifiche all'ambito di archiviazione di Android 11: perché l'accesso a/Download è limitato?

App destinate ad Android 11 e che utilizzano l'intento ACTION_OPEN_DOCUMENT_TREE per richiedere l'accesso a directory specifiche sull'esterno storage non sarà più in grado di chiedere agli utenti l'accesso alla directory root dello storage esterno (/data/media/{user}), il Download directory (/data/media{user}/Download) o una qualsiasi delle directory di dati specifiche dell'app nella memoria esterna (/Android/data o /Android/obb). Perché l'accesso alla directory di download è limitato? Secondo Google Roxanna Aliabadi, è perché la cartella di download "è quella più a rischio di contenere informazioni private". Ad esempio, gli utenti che scaricano il file tax i resi o gli estratti conto bancari non dovrebbero preoccuparsi della possibilità che le app abusino del loro accesso in lettura continua al file directory. Google afferma che il selettore di documenti avrà "testo aggiornato... per indicare che Android ha limitato determinate cartelle da selezionare." Si spera che ciò riduca la confusione sul motivo per cui non possono concedere alle app l'accesso a determinate directory più.

Per ulteriori informazioni sulle imminenti modifiche alle policy di archiviazione e riproduzione con ambito, fare riferimento a questo articolo.

Argomenti vari

  • La posizione di Google sul rooting/modding
    • Jeff Bailey del team AOSP di Google ribadisce la posizione dell'azienda a sostegno della scelta. Google "continuerà a garantire che sia possibile il modding/rooting della linea di dispositivi Pixel", ma "sosterrà anche la scelta degli OEM di non consentire ai loro dispositivi essere rootato." Inoltre, Google offre agli sviluppatori di software la scelta di "non consentire l'esecuzione del loro software su dispositivi rooted", in riferimento ai recenti cambiamenti in rilevamento di manomissioni software dell'API di attestazione SafetyNet.
  • Cosa è successo a "apri e imposta su predefinito"?
    • Android 10 realizzato è un po' fastidioso impostare un'app come gestore predefinito per collegamenti specifici, che secondo Google è stato fatto per proteggere gli utenti da "app di sfruttamento". Google ha fatto marcia indietro su questo cambiamento dopo averlo ripensato, apportando una "serie di modifiche dietro le quinte" per tutelare l'utente.
  • Utilizzi l'API grafica Vulkan per eseguire il rendering dell'interfaccia utente?
    • Google eventualmente prevede di utilizzare l'API grafica Vulkan per eseguire il rendering dell'interfaccia utente, che produrrà alcuni miglioramenti delle prestazioni. Questo è ancora in fase di valutazione, ma la società non aveva dettagli da condividere.
  • CallScreeningService mancante su molti dispositivi
    • Le app Android possono implementare API CallScreeningService per intercettare nuove chiamate in entrata e in uscita, consentendo loro di identificare il chiamante e accettare o rifiutare la chiamata. Sebbene si tratti di un'API ufficialmente documentata, a quanto pare ci sono molti OEM che non la implementano correttamente, secondo lo sviluppatore /u/_zeromod_. Google conferma che questa API è convalidata dalla Compatibility Test Suite (CTS), una suite di test automatizzata che tutti i dispositivi devono superare per essere considerati compatibili con Android. Per qualche motivo, questa API restituisce null quando viene richiamata su dispositivi di OEM come Huawei, Vivo, Xiaomi o Samsung, quindi è probabile che questi OEM abbiano un bug nel loro software.
  • Nessun piano per un framework di plug-in audio
    • Uno sviluppatore ha chiesto a Google se intende implementare un framework di plug-in audio come Audio Units di Apple, ma la risposta è che è improbabile che accada nel prossimo futuro.

Puoi leggere tutte le risposte del team tecnico di Android Qui. Il team parla un po' di Java, Kotlin, del sistema di build Android, dell'API CameraX e di altri argomenti in alcuni commenti. Ci sono diversi commenti anche su Wear OS, Android TV e Android Auto, ma Google per lo più ribadisce il loro lavoro esistente su queste piattaforme e dice agli sviluppatori di rimanere sintonizzati per ulteriori informazioni durante il "Android oltre i telefoni" settimana a partire dal 10 agosto.