Rezumat Android Q AMA: Ce a spus Google despre Android 10 pe Reddit

Anul trecut, echipa Google Android a găzduit un Ask Me Anything (AMA) pe subreddit-ul Reddit /r/AndroidDev pentru a pune întrebări despre Previzualizare pentru dezvoltatori Android P. Anul acesta, echipa de ingineri care lucrează la Android Q beta a răspuns la întrebările de pe Reddit. AMA a început la 1 august la 12:00 PST și s-a încheiat aproximativ o oră și jumătate mai târziu. 33 de ingineri Google au fost implicați în AMA, răspunzând la o mulțime de întrebări în scurtul timp care a durat AMA. Iată rezumatul nostru al tuturor informațiilor noi pe care le-am învățat.

Android Q AMA: Tot ce am învățat de la Google

Participanți din echipa Android Q beta

• Adam Cohen: TLM pe Lansatorul Android / Interfața de utilizare a sistemului
• Adam Powell: TLM pe trusa/cadru de instrumente UI; vizualizări, ciclu de viață, fragmente, biblioteci de suport
• Alan Viverette: TLM, Jetpack / AndroidX
• Allen Huang: PM pentru UI, lansator, notificări, integrări de căutare și multe altele!
• Andrew Sappirstein: TLM pe Setări Android
• Brahim Elbouchikhi: PM Director pentru Android Machine Learning și Camera (NN API, ML Kit, CameraX, Camera Platform)
• Chad Brubaker: inginer software, securitate platformă Android
• Charmaine D’Silva: PM pentru confidențialitate
• Chet Haase: Avocat șef Android, Relații cu dezvoltatorii
• Diana Wong: PM, Compatibilitate aplicație, utilizare API non-SDK, ART, NDK
• Dianne Hackborn: Managerul echipei framework Android (Resurse, Manager de ferestre, Manager de activități, Multi-utilizator, Imprimare, Accesibilitate etc.)
• E.K. Chung: Director UX
• Ian Lake: Inginer software, Jetpack (fragmente, navigație, componente de arhitectură)
• Iliyan Malchev: Inginer software principal, linia principală de proiect
• Jacob Lehrbaum: Director de Relații cu Dezvoltatorii pentru Android
• Jake Wharton: Inginer software, Jetpack
• Jamal Eason: PM, Android Studio
• Jeff Bailey: TLM, Android Open Source Project (AOSP)
• Jeff Sharkey: Inginer software, Android Framework
• Jeffrey van Gogh: Android Studio, compilatoare
• Jen Chai: PM, Locație și context, Autentificare, Completare automată, utilizare API non-SDK, ART
• Karen Ng: Group PM pentru Android Developer Tools, Android Studio, Android Tookit și Jetpack
• Paul Bankhead: Director de management de produs, Google Play
• Rohan Shah: Manager de produs, interfața de utilizare a sistemului Android
• Romain Guy: Manager al echipei Android Toolkit/Jetpack
• Sagar Kamdar: Director de management de produs, Android
• Sat K: Director de Inginerie, Conectivitate Android
• Selim Cinek: inginer software, interfața de utilizare a sistemului Android
• Stephanie Saad Cuthbertson: Director senior de management al produselor, Android
• Sumir Kataria: Inginer software, Jetpack (WorkManager)
• Travis McCoy: PM, platformă Android
• Trystan Upstill: Inginer distins, lider pentru interfața de utilizare și inteligența sistemului Android
• Vinit Modi: PM, Cameră Android

citeşte mai mult

Producătorii OEM nu mai pot ucide aplicațiile când utilizatorul le elimină recent

Dacă ați folosit vreodată un smartphone de la o marcă chinezească, atunci probabil că v-ați confruntat cu funcții enervante de „optimizare a bateriei” care ucide toate aplicațiile tale preferate în fundal. Nu numai că acest comportament este enervant pentru utilizatorii care se așteaptă ca anumite aplicații să continue să ruleze în fundal, indiferent de motiv, dar este și enervant pentru dezvoltatorii care trebuie să sufere recenzii slabe de la utilizatorii care nu înțeleg că nu este aplicația vina. În timp ce Google este încă nu abordează pe deplin această problemă (au înlăturat problema, declarând că acest comportament este probabil încălcând deja cerințele Documentului de definire a compatibilității Android), compania este luând măsuri față de o schimbare a comportamentului de „economisire a bateriei” folosită de unii OEM.

„Pentru a ajuta cu situația, am adăugat un test CTS în Android Q pentru a ne asigura că o aplicație nu este oprită la trecerea prin glisare din Recente”.

Android R poate aduce mai multe modificări la capturile de ecran decât ne așteptam

Google plănuiește să adauge derularea capturilor de ecran în Android R, dar în același timp, cel Echipa Android este „Aruncând o privire atentă la modul în care [ele] pot îmbunătăți întreaga experiență ecran-[X] pentru R.” Astfel, putem vedeți alte îmbunătățiri ale comportamentului capturii de ecran (ȘI screencast-ului) în următoarea versiune majoră de Android.

Clarificarea noului mod desktop al Android Q

The prima lansare publică beta Android Q a adus o interfață pentru modul desktop ascuns la AOSP și Pixel Launcher. Deși Google atins pe scurt caracteristica în timpul unei sesiuni Google I/O, nu am auzit niciodată direct de la Google cum se încadrează noua funcție în ecosistemul Android. Google acum clarifică:

„În Q AOSP, „modul desktop” este o opțiune de dezvoltator destinată dezvoltatorilor de aplicații. Le permite să-și testeze aplicațiile în medii cu ecrane multiple și cu ferestre libere. Anterior nu exista o modalitate convenabilă de a testa comportamentul aplicației pe un afișaj secundar și cu ferestre redimensionabile liber pe Android stoc. Această caracteristică nu este produsă singură și nu este destinată utilizatorilor obișnuiți în acest moment. Cu toate acestea, este baza platformei Android pentru ca OEM-urile să inoveze și să realizeze produse grozave.”

Astfel, ne putem aștepta să vedem OEM-uri construind pe modul desktop nativ al Android Q. De exemplu, cel OnePlus 7 Pro acceptă afișarea prin HDMI, deci este posibil ca OxygenOS 10 bazat pe Android Q va avea propria interfață în modul desktop în viitor. De asemenea, sperăm că Google se bazează pe funcția pentru viitorul Pixel 4.

Modul întunecat bazat pe timp

Android Q aduce în sfârșit o funcție solicitată pe scară largă: modul întunecat la nivelul întregului sistem. În prezent, modul întunecat poate fi activat manual în Setări sau printr-o țiglă Setări rapide, sau poate fi activat automat când Economisirea bateriei este activată. Înainte de Android Q, exista o opțiune pentru a activa modul întunecat pe baza orei zilei, dar acea opțiune a fost depreciată. Potrivit lui Chris Banes:

„Există câteva motive pentru care acest lucru este depreciat (nu eliminat) în AppCompat v1.1.0: necesită aplicații să solicite permisiunile de locație să fie precise și, chiar și cu o locație validă, calculele orelor de răsărit/apus pot fi buggy."

Întrebat despre aceste bug-uri, domnul Banes afirmă că „calcularea răsăritului/apusului este notoriu de dificilă, mai ales pentru locațiile apropiate de poli nord/sud.” Un utilizator afișează Night Light, disponibilă începând cu Android 7.1 Nougat, poate fi comutată automat în funcție de Sunset/Sunrise orare. Domnul Banes afirmă apoi că, deoarece Night Light folosește CalendarAstronomer de la ICU4J, folosește o „porțiune mare de cod de care nu am dori să depindă AppCompat”. Cu toate acestea, echipa o face stat că această caracteristică este „ceva pe care [ei] vor căuta”.

Compatibilitate obligatorie Camera2 API/Camera HAL3 pentru dispozitivele de lansare Android Q

Google a introdus Camera2 API pentru a defini mai bine modul în care aplicațiile pot interacționa cu camerele individuale conectate la smartphone-ul tău. În timp ce Google încurajează furnizorii de smartphone-uri pentru a „expune toate camerele lor fizice pentru dezvoltatori”, mulți vânzători aleg să nu facă acest lucru, chiar dacă „API-ul în sine nu este împiedicându-le astăzi.” Aceasta înseamnă că multe aplicații de cameră terță parte nu pot folosi modulele secundare sau terțiare ale camerei pe camere moderne. smartphone-uri. Cu toate acestea, se fac progrese, deoarece Android Q s-a îmbunătățit LOGICAL_MULTI_CAMERA, un API care oferă dezvoltatorilor un acces mai bun la toate camerele de pe un dispozitiv și care oferă OEM-urilor control asupra consumului de energie și gestionarea mai multor stări ale camerei.

În plus, Google spune că a adăugat cerințe pentru toate dispozitivele care se lansează cu Android Q pentru a accepta în mod nativ Camera2 API/Camera HAL3. Potrivit lui Vinit Modi:

„Începând cu Android P, dispozitivele noi livrate cu 1 GB sau mai mult RAM sunt necesare pentru a utiliza în mod nativ HALv3/camera2. De la Android Q, toate dispozitivele noi sunt necesare pentru a suporta nativ HALv3/camera2. Din păcate, actualizările de la HALv1 la HALv3 sunt destul de complexe în aer și pot avea consecințe neașteptate, prin urmare a trebuit să limităm domeniul de aplicare la dispozitive noi.”

Interesant este declarația lui Modi despre dispozitivele normale de lansare RAM Android P contrazice ceea ce ni s-a spus mai devreme de către Google și ce este publicat pe pagina Image Test Suite online.

Tematică dinamică a aplicației cu Jetpack Compose

Cadrul de tematică OMS de la Sony a fost adăugat la AOSP cu câteva versiuni în urmă, dar este doar destinat OEM-urilor să construiască pe. Știm deja asta Google este împotrivă utilizarea suprapunerilor de resurse de rulare de către utilizatori la aplicațiile tematice, dar pentru dezvoltatori, compania este sperând că este Interfața de utilizare Jetpack Compose cadrul va prezenta „abordări interesante ale tematicii dinamice”.

Vulkan-backend pentru Skia pentru a reda interfața de utilizare

Anul trecut, am observat o discuție printre inginerii Google care vorbesc despre planurile lor de a face ca framework-ul Android să folosească API-ul grafic Vulkan pentru redarea UI. Deși acum este posibil să activați backend-ul accelerat de hardware Vulkan fără telefon prăbușind, nu am auzit niciun plan concret de la Google despre când intenționează să le lanseze schimbări. Acest AMA nu răspunde la această întrebare, dar cel puțin avem confirmarea că este încă în lucru. Potrivit lui Romain Guy:

„Echipa a lucrat la un backend Vulkan pentru Skia, redarea 2D folosită de Android, dar nu este activată implicit în prezent. Interfața de utilizare și Canvas încă trec prin OpenGL ES."

Faceți bara de gesturi a Android Q mai dinamică

Unii de pe XDA încă mai cred asta Noile gesturi ale Android sunt o mizerie, dar personal cred că sunt bine. Dacă te joci puțin cu noile gesturi din Android Q, totuși, vei observa că bara de gesturi nu se mișcă cu degetul. De asemenea, rămâne pe ecranele unde nu este necesar, cum ar fi ecranul de pornire sau prezentarea generală a aplicațiilor recente. Allen Huang spune că „sunt total de acord că există oportunități” de a face „linia de navigație mai puțin statică”. El mai spune că „acesta este ceva la care lucrăm – dar și echilibrăm, astfel încât să nu ne distragă atenția apariția/dispariția”.

Îmbunătățiri ale cadrului de acces la stocare

Multe modificări din Android Q au îmbunătățit semnificativ securitatea și confidențialitatea platformei. O astfel de modificare, numită „Scoped Storage”, limitează accesul aplicațiilor la fișierele de pe stocarea externă într-un mod care are sens; Aplicațiile muzicale nu ar trebui să vă vadă galeria, de exemplu. Aplicațiile de gestionare a fișierelor care rulează în Android Q trebuie să utilizeze un API numit Storage Access Framework pentru a continua să funcționeze ca de obicei, dar unii dezvoltatori văd acest API ca fiind inferior la ceea ce era disponibil anterior. Jeff Sharkey de la Google spune echipa a abordat unele dintre plângerile acestor dezvoltatori:

„Am adus câteva îmbunătățiri ale performanței SAF în cele mai recente versiuni Android Q Beta; ați putea să vă verificați benchmark-urile cu cea mai recentă versiune beta? De asemenea, asigurați-vă că utilizați un ContentProviderClient atunci când executați orice operațiuni în bloc."

Proiectul Treble a îmbunătățit adoptarea Android Pie față de Android Oreo

Am văzut deja cum Project Treble, o rearhitectură majoră la nivel scăzut a cadrului Android, a îmbunătățit adoptarea versiunilor mai noi ale sistemului de operare Android. Google creditează Treble în spatele mulțimii de furnizori de smartphone-uri care se alătură Android P beta anul trecut și Android Q beta anul acesta. Iliyan Malchev, liderul Proiectului Treble și Linia principală inginer, spune că adoptarea Android Pie a fost de „de trei ori” față de Android Oreo la sfârșitul anului 2018.

În același comentariu, Dick Dougherty tachinează că sunt în lucru mai multe valori utile pentru diagrama de distribuție a versiunii Android. Graficul a fost ultima actualizare în mai, dar datele sale sunt mai utile pentru jurnaliști decât pentru dezvoltatorii de aplicații.

Înregistrarea ecranului este încă un WIP

Primele versiuni beta Android Q au adăugat un semnalizator de caracteristică pentru un înregistrator de ecran de bază, dar platforma în sine a îmbunătățit semnificativ utilitatea înregistrării ecranului prin permițând aplicațiilor să capteze sunetul de la alte aplicații. Stephanie Saad Cuthbertson a spus că echipa se gândește „cum ne-am putea descurca mai bine în ceea ce privește nevoile de înregistrare pe ecran, chiar ieri”. Alte mărci de smartphone-uri precum OnePlus, ASUS, Huawei și Samsung au aparate de înregistrare a ecranului robuste care pot înregistra sunetul intern, așa că Google va juca aici.

Tema întunecată Toate lucrurile!

În cazul în care ați ratat-o, Google adaugă modul întunecat la majoritatea aplicațiilor lor. Stephanie Saad Cuthbertson spune să vă așteptați ca toate „aplicațiile majore” să accepte o temă întunecată „prin lansarea oficială [Android Q]”. Chiar și Google Chrome, care în prezent forțează o reîncărcare a paginii când este activată tema întunecată la nivel de sistem, va fi actualizată pentru a nu se mai reîmprospăta când tema este schimbat.

Da, Lansatoarele terțe vor funcționa cu Gesturi (Eventual)

Gesturile lui Android sunt oarecum rupt atunci când utilizați un lansator terță parte. Acest lucru se datorează faptului că interfața de utilizare a aplicațiilor recente este conținută în aplicația de lansare a stocurilor, iar Google încă nu am găsit o modalitate de a avea aceleași tranziții fără întreruperi pe care le vedem atunci când folosim gesturi cu Pixelul stoc Lansatorul. Adam Cohen afirmă Planurile Google de a aborda aceste probleme „cât mai repede posibil după lansare”. El mai spune că incompatibilitatea „va fi rezolvată în actualizarea post-Q și va fi backportată pentru dispozitivele noi care se lansează cu Q."

Partițiile dinamice/logice nu sunt aici pentru a ucide ROM-urile personalizate

Pentru a sprijini Actualizări dinamice ale sistemului în Android Q, anumite dispozitive precum Google Pixel 3 și Pixel 3 XL folosesc partiții logice. Aceste partiții pot fi redimensionate dinamic. Această schimbare are s-a dovedit o provocare pentru a funcționa accesul la rădăcină, iar unii dezvoltatori sunt îngrijorați de faptul că ROM-urile personalizate sunt vizate. Iliyan Malchev ne asigură că intenția nu este de a constrânge ROM-urile personalizate. La fel de el explica:

„Partițiile dinamice nu sunt menite să limiteze ceea ce puteți face cu ROM-urile personalizate. Sunt pur și simplu un soluție la problema dimensiunilor partițiilor fixe și a lipsei unei modalități sigure de repartizare a dispozitivelor OTA. Înainte de partițiile dinamice, dacă un OEM a făcut o greșeală în dimensionare, de ex. partiția de sistem, apoi ei ar fi constrâns de această alegere, făcând practic imposibilă actualizarea unui dispozitiv după o anumită punct. Unii OEM repartiționează dispozitivele lor pe OTA ca o chestiune de practică, dar acest lucru a) nu este acceptat oficial în Android și b) schimbarea tabelului de partiții este considerată destul de riscantă. Partițiile dinamice urmăresc să atenueze problema prin introducerea unui nivel de indirectă între tabelul de partiții fizice și sistemul de operare. Acest lucru, la rândul său, ne permite să ajustăm în siguranță dimensiunile partițiilor pe OTA. În ceea ce privește ROM-urile personalizate, nu ar trebui să fii deloc constrâns mai mult decât ești astăzi cu ceea ce poți face. Sprijinirea ROM-urilor personalizate este și continuă să fie ceva ce fiecare OEM individual decide să îl activeze.”

Linia principală a proiectului - Modulul ART și lungimea suportului

Mainline este o nouă inițiativă a Google care își propune să standardizeze anumite biblioteci și pachete, astfel încât acestea să poată fi actualizate independent de actualizările platformei. Unii s-au întrebat de ce Android Runtime (ART) nu este încă un modul Mainline, dar mi s-a spus la Google I/O că complexitatea implicată în modularizarea ART i-a împiedicat să-l includă ca unul dintre pachetele inițiale APEX. La fel de explicat atât de Iliyan Malchev, cât și de Diana Wong:

„Efectuarea de actualizări la Runtime (în special performanță și corecții GC și biblioteci de bază) este cu siguranță ceva pe care îl explorăm în contextul liniei principale. Putem vedea o mulțime de beneficii pentru a putea face aceste actualizări coerente pe toate dispozitivele și pe mai multe versiuni cu linia principală. Este, de asemenea, o provocare tehnică uriașă, deoarece ne gândim cum să facem acest lucru cel mai bine pentru dezvoltatori și, probabil, un efort pe mai mulți ani. Nu este ceva ce Mainline poate face în prezent, dar cu siguranță ceva la care ne gândim.”

Dacă urmați AOSP Gerrit, veți vedea că Google a fost totuși greu la muncă realizarea unui Runtime APEX. În prezent, par să fie împărțirea Bionic și ART/libcore în module APEX separate.

În ceea ce privește beneficiile proiectului Mainline, un utilizator a întrebat despre durata actualizărilor Mainline. Ca răspuns, Iliyan Malchev spune că „aceasta este o întrebare de politică pe care încă o evaluăm, dar dorim să actualizăm modulele Mainline pe un dispozitiv cât mai mult timp posibil”. Dezvoltator recunoscut XDA luca020400 a întrebat dacă vor fi furnizate module Mainline preconstruite, astfel încât dezvoltatorii de ROM personalizate să poată îmbina actualizările și, ca răspuns, Jeff Bailey reiterează că „modulele care se despart de AOSP vor avea versiuni sursă care se potrivesc cu fiecare versiune de modul”. Putem vedea deja progresul noilor module APEX în AOSP, cum ar fi unul pentru API-ul rețelelor neuronale.

CameraX întâlnește Kitul ML

La I/O anul acesta, Google a introdus Biblioteca CameraX Jetpack. Această bibliotecă este concepută pentru a facilita dezvoltatorilor să accepte API-ul Camera2 pentru Android, menținând în același timp compatibilitatea până la Android Lollipop. Vinit Modi tachinează cu care compania lucrează la integrarea CameraX Kit ML, SDK-ul Firebase de învățare automată de la Google, astfel încât dezvoltatorii să poată introduce cadre de imagine în Kitul ML pentru analiză.

Extensiile furnizorului CameraX și data lansării

Dezvoltatorul unei aplicații pentru cameră deplânge faptul că funcțiile avansate ale camerei, cum ar fi Night Sight de la Google Pixel, nu sunt accesibile pentru aplicațiile de cameră terță parte. Acest lucru ar trebui să fie rezolvabil cu extensiile furnizorului CameraX, la care Jeff Sharkey de la Google spune că „toate dispozitivele Pixel sunt optimizate pentru CameraX Core”. El tachinează că „aspectul Extensii va fi acceptat pe dispozitivele noi și viitoare”. În plus, Google este „colaborează cu mai mulți producători pentru a putea aduce capabilitățile dispozitivului lor atât dezvoltatorilor, cât și utilizatorilor.” Deși nu este confirmat direct, este posibil să vedem funcții ca Vedere de noapte pe Google Pixel 4 devin disponibile pentru aplicațiile de cameră terță parte care folosesc biblioteca CameraX.

Domnul Sharkey afirmă că Google vizează o lansare beta pentru sfârșitul acestui an.

Îmbunătățiri de gestionare a memoriei în Android Q

Pixel 3 a fost criticat pentru că are numeroase probleme după lansare, dar Google a făcut multe pentru a rezolva aceste probleme prin numeroase actualizări după lansare. Gestionarea memoriei a fost unul dintre cele mai slabe aspecte ale Pixel 3, dar lucrurile ar trebui să fie puțin mai bune în versiunea Android Q. Potrivit lui Selim Cinek:

„În SystemUI, de exemplu, am avut diferite eforturi mari de refactorizare în Q pentru a reduce utilizarea RAM a notificărilor și a altor suprafețe.”

Vom primi în sfârșit ADB wireless?

Dacă doriți să depanați telefonul fără fir, va trebui să vă rootați dispozitivul. Jamal Eason de la echipa Android Studio spune că în prezent abordează fezabilitatea acestei funcții.

Google mai testează pe tablete?

Dezvoltator recunoscut XDA Luk1337 a întrebat dacă Google mai testează AOSP UX pe tablete. Este o întrebare corectă având în vedere lipsa de tablete Android bune si bug-uri prezente în versiunile curente. Allen Huang spune că Google încă „testează și face remedieri în fiecare an” și că compania lucrează îndeaproape cu partenerii „pentru a asigura o experiență bună pentru tableta Android”.

---

Există mult mai multe postări în firul complet de pe Reddit. Ceea ce am tratat aici rezumă toate informațiile noi pe care le-am aflat, dar mai mulți angajați Google (în special Dianne Hackborn) intră în raționamentul lor din spatele tăierii caracteristicii X sau neimplementarea lui Y permisiune. Vă recomand să citiți întregul AMA dacă doriți să înțelegeți puțin mai bine procesul decizional al echipei Android.

Citiți AMA complet pe /r/AndroidDev