Android 11 AMA: Fără capturi de ecran de defilare, lansări mai rapide de aplicații și mai mult

Echipa Google de inginerie Android a găzduit un AMA pe Reddit pentru a răspunde la întrebări despre Android 11. Iată ce am aflat despre următoarea versiune a sistemului de operare Android.

Ieri, Google a lansat Android 11 Beta 2, aducând SDK-ul, NDK-ul finalizat, suprafețele orientate către aplicații, comportamentele platformei și restricțiile asupra interfețelor non-SDK pentru dezvoltatori. Astăzi, Google răspunde la întrebări legate de Android 11 din comunitatea Reddit /r/AndroidDev după ce am pus întrebări săptămâna trecută. Iată un rezumat a tot ceea ce am învățat din AMA (Ask Me Anything) de la Google.

Una dintre cele mai așteptate funcții ale Android 11 nu va fi disponibilă atunci când sistemul de operare iese din beta pe 8 septembrie: Defilare capturi de ecran. Inițial planificat pentru lansare în Android 11, Google a confirmat acum că funcția „nu a făcut demersul pentru R”. Previzualizarea dezvoltatorului Android 11 1 și toate versiunile ulterioare DP și Beta au un buton substituent pentru a face o captură de ecran de derulare care poate fi

a apărut manual cu o comandă de dezvoltator ascunsă, dar atingerea butonului afișează pur și simplu un mesaj toast care afirmă că funcția „nu este implementată”.

Butonul de captură de ecran de derulare neimplementat al Android 11.

Speram că funcția își va face loc într-o versiune beta sau chiar într-o lansare stabilă, dar se pare că acest lucru pur și simplu nu se va întâmpla.

cometariu din discutie. Facem parte din echipa de inginerie Android. Întrebați-ne Orice despre actualizările Android 11 pentru platforma Android! (începe din 9 iulie).

Această știre va fi de înțeles deranjantă pentru unii utilizatori. La urma urmei, mulți OEM au această caracteristică în propriul software de ani de zile, așa că ce durează Google atât de mult să o adauge la telefoanele Pixel? După cum a explicat Dan Sandler de la echipa Google System UI, problema este că Google dorește să o facă corect. Unele implementări de capturi de ecran cu defilare emulează pur și simplu un defilare și apoi unesc mai multe capturi de ecran pe măsură ce ecranul se mișcă. Dacă te-ai ocupat vreodată de automatizarea UI pe Android, vei ști că aceasta nu funcționează întotdeauna, deoarece, așa cum menționează domnul Sandler, aplicațiile pot folosi „un RecyclerView standard de mlaștină sau au implementat propriul motor de defilare accelerat cu OpenGL”. Din moment ce Google plănuiește să implementează această funcție nu doar pentru smartphone-urile Pixel, ci și pentru întregul ecosistem Android ca parte a AOSP, trebuie să se asigure că va funcționa toate aplicații și nu doar „una sau două aplicații alese manual pe un anumit dispozitiv”.

Pentru că echipa a trebuit să „își concentreze [lor] resursele limitate”, mai ales din cauza provocărilor aduse de COVID-19, echipa a decis să pună capturi de ecran de defilare pe backburner pentru o viitoare lansare Android.

Noua cerință CDD pentru a informa utilizatorii cu privire la restricțiile de fundal

Nu este un secret pentru nimeni că mulți OEM Android, în special cei chinezi, au restricții agresive asupra aplicațiilor care rulează în fundal. Unii dezvoltatori au fost atât de frustrați că aplicațiile lor au fost ucise în fundal încât s-au unit pentru a crea un site web numit „Nu-mi ucideți aplicația" pentru a clasa OEM-urile în funcție de cât de prost gestionează procesele aplicațiilor de fundal. Aceiași dezvoltatori chiar a făcut recent un etalon astfel încât utilizatorii să poată testa cât de agresiv dispozitivul lor distruge aplicațiile din fundal. Motivul pentru care mulți OEM iubesc să ucidă procesele aplicațiilor de fundal este complicat, dar cred că este cel mai bine explicat în acest comentariu de către Redditor /u/eventual discutabil. Comentariul subliniază starea complicată a dezvoltării aplicațiilor Android în China, cum companiile chineze de tehnologie sunt implicați în complicarea în continuare a lucrurilor și modul în care lipsa serviciilor Google contribuie la acest lucru mizerie.

Oricum, mulți dezvoltatori de aplicații sunt de înțeles frustrați de aceste modificări ale comportamentului platformei Android, ceea ce i-a determinat pe dezvoltatori să facă un comentariu. întrebând Google ce fac în privința asta în vârful AMA Reddit. Iată răspunsul Google:

cometariu din discutie. Facem parte din echipa de inginerie Android. Întrebați-ne Orice despre actualizările Android 11 pentru platforma Android! (începe din 9 iulie).

Există câteva lucruri de reținut din acest răspuns. În primul rând, Google dorește ca OEM-urile să fie mai transparenți cu utilizatorii cu privire la restricțiile aplicațiilor de fundal pe care le aplică. Am verificat (nelansat) Documentul de definire a compatibilității Android 11 (CDD) și am găsit următoarea propunere de completare la Secțiunea 3.5 - Compatibilitate comportamentală API:

Dacă implementările dispozitivelor implementează un mecanism proprietar pentru a restricționa aplicațiile și acel mecanism este mai restrictiv decât grupul de așteptare „Rare” pe AOSP, acestea:

[C-1-5] TREBUIE să informeze utilizatorii dacă restricțiile aplicației sunt aplicate automat unei aplicații. (NOU) Astfel de informații NU TREBUIE furnizate mai devreme de 24 de ore înainte de aplicarea acestor restricții.

(Notă) Oprirea forțată este considerată a fi mai restrictivă decât „Rar” și TREBUIE să respecte toate cerințele de la 3.5.1, inclusiv noul 3.5.1/C-1-5

Practic, Google nu are prea mult pentru a împiedica OEM-urile să-și implementeze propriile caracteristici restrictive de ucidere a aplicațiilor. Cere doar ca OEM-urile să informeze utilizatorii dacă restricțiile aplicațiilor lor sunt aplicate automat. Un OEM ar putea afișa o casetă de dialog în care va opri rularea aplicațiilor de fundal care consumă baterie în fundal, iar utilizatorul ar putea să-și dea acordul fără să-și dea seama că aplicațiile pe care doresc cu adevărat să le ruleze în fundal sunt și ele afectat! Google le atribuie dezvoltatorilor sarcina de a se ocupa de cazurile în care aplicația lor este oprită în mod neașteptat în fundal. Într-adevăr, comentariul Reddit continuă să evidențieze noul „motive de ieșire a procesului aplicației„ API care poate spune dezvoltatorilor dacă aplicația lor a fost ucisă de utilizator, sistemul de operare sau dacă pur și simplu s-a prăbușit.

Pe de altă parte, Google abordează în sfârșit practicile neloiale ale OEM-urilor care permit anumitor aplicații privilegiate să ocolească restricțiile aplicațiilor de fundal. Această postare medie de la dezvoltator Timothy Asiimwe intră în detalii despre aplicații precum WhatsApp, Facebook și alte aplicații sunt scutite automat de restricțiile dure de fundal ale unor software OEM. Google spune că „cere ca producătorii de dispozitive să nu creeze liste de permisiuni pentru cele mai bune aplicații”. Nu știm cum va fi aplicat acest lucru, dar este bine de știut că OEM-urile vor fi în sfârșit obligați să trateze dezvoltatorii terți pe picior de egalitate – indiferent cât de mari sau mici sunt aplicațiile lor sunt.

În cele din urmă, Google menționează și modul în care Android 11 a „adăugat măsuri suplimentare pentru a preveni comportamentul abuziv prin comportamentul greșit al aplicațiilor”, făcându-l mai puțin atrăgător pentru OEM să ucidă în mod agresiv procesele de fundal. Compania nu a detaliat însă ce presupun aceste „măsuri suplimentare”.

Backup-uri îmbunătățite de la dispozitiv la dispozitiv

Luna trecută, am observat o modificare a documentației Android 11 care a sugerat suportul pentru copii de rezervă ale datelor locale mai bune. În Android 11, sistemul va ignora atributul allowBackup Manifest pentru orice aplicație care vizează nivelul API 30 atunci când utilizatorul inițiază o migrare „de la dispozitiv la dispozitiv” a fișierelor aplicației. Googler Eliot Stock spune că această funcție are scopul de a face „mult mai ușor pentru producătorii de telefoane să construiască instrumente de migrare de la dispozitiv la dispozitiv”, cum ar fi „produsul Smart Switch excelent de la Samsung” la ajuta la „asigurarea unui transfer mai fiabil al aplicațiilor între dispozitive din perspectiva utilizatorului”. Din păcate, acest lucru nu se aplică backup-urilor bazate pe cloud, deoarece Google dorește „să acorde dezvoltatorilor de software controlul asupra a ceea ce se întâmplă cu datele aplicației lor.” Ca atare, Android 11 va respecta în continuare atributul allowBackup pentru orice copie de rezervă și restaurare bazată pe cloud, cum ar fi prin serviciul Google Play încorporat Google Drive backup. În cele din urmă, Google recunoaște că plafonul de rezervă de 25 MB per aplicație poate să nu fie suficient pentru unii dezvoltatori, așa că caută modalități de a rezolva asta. Totuși, backup-urile locale pe un computer nu sunt luate în considerare, iar Google își reiterează planul eliminarea treptată a backup-ului adb într-o viitoare versiune Android.

cometariu din discutie. Facem parte din echipa de inginerie Android. Întrebați-ne Orice despre actualizările Android 11 pentru platforma Android! (începe din 9 iulie).

Dezvoltatorii sunt încurajați să implementeze metode de migrare a datelor fără fricțiuni. The noua bibliotecă Block Store, care face parte din Biblioteca Google Identity Services, este concepută pentru a facilita conectarea la aplicațiile restaurate din cloud pe dispozitive noi, dar depinde de dezvoltatori să aleagă dacă doresc sau nu să implementeze acest lucru bibliotecă.

Viteze mai rapide de pornire a aplicației cu procesul de citire anticipată I/O (IORap)

Google experimentează mereu modalități de îmbunătățire a performanței în Android. Una dintre caracteristicile puțin cunoscute pe care le-au adăugat în Android 10 se numește Unspecialized App Process Pool (USAP). Această funcție elimină bifurcarea Zygote în timpul procesului de pornire a aplicației, economisind aproximativ ~5 ms la viteze medii de pornire a aplicației pe un dispozitiv Pixel 2. Caracteristica este în prezent dezactivat implicit în AOSP, iar Google explică că utilizarea suplimentară a memoriei necesită încă testare. Ceea ce este mai interesant, totuși, este o nouă funcție care vine pe Android 11 numită I/O Read Ahead Process (IORap). Potrivit Google, această caracteristică va duce la „porniri la rece cu mai mult de 5% mai rapide, cu cazuri de eroi ajungând cu 20% mai repede”. Această caracteristică „va preleva artefactele aplicațiilor (cum ar fi codul și resursele) în timpul procesului de pornire” pentru a stimula lansarea aplicației viteze.

De asemenea, Google a „a făcut îmbunătățiri profilurilor utilizate pentru a optimiza calea clasei de pornire și imaginea sistemului” ceea ce va îmbunătăți performanța aplicației și va reduce costurile de memorie și stocare asociate sistemului artefacte. Aceste modificări vor beneficia în mare parte dispozitivelor cu cantități mai mari de memorie RAM, deși Google nu a spus care este limita pentru care vom vedea cele mai multe beneficii.

Modificări ale spațiului de stocare Android 11 - De ce este restricționat accesul la /Descărcări?

Aplicații care vizează Android 11 și utilizează intenția ACTION_OPEN_DOCUMENT_TREE de a solicita acces la anumite directoare din partea externă stocarea nu va mai putea cere utilizatorilor acces la directorul rădăcină al stocării externe (/data/media/{user}), descărcarea directorul (/data/media{user}/Download) sau oricare dintre directoarele de date specifice aplicației din stocarea externă (/Android/data sau /Android/obb). De ce este restricționat accesul la directorul de descărcare? Potrivit Google Roxanna Aliabadi, deoarece folderul de descărcare „este cel mai expus riscului de a avea informații private”. De exemplu, utilizatorii care își descarcă impozitul retururile sau extrasele bancare nu ar trebui să-și facă griji cu privire la posibilitatea ca aplicațiile să abuzeze de accesul lor continuu de citire la director. Google spune că selectorul de documente va avea „text actualizat... pentru a indica faptul că Android a restricționat anumite foldere să fie selectate.” Acest lucru va reduce, sperăm, confuzia cu privire la motivul pentru care nu pot acorda aplicațiilor acces la anumite directoare mai mult.

Pentru mai multe informații despre viitoarele modificări ale politicii de stocare și redare în domeniu, consultați acest articol.

Subiecte diverse

  • Poziția Google cu privire la înrădăcinare/modificare
    • Jeff Bailey de la echipa Google AOSP reiterează poziția companiei cu privire la susținerea alegerii. Google va „continua să se asigure că este posibilă modificarea/rădăcinarea liniei de dispozitive Pixel”, dar, de asemenea, „sprijină alegerea OEM-urilor de a nu permite dispozitivele lor”. În plus, Google oferă dezvoltatorilor de software opțiunea „de a nu permite software-ului lor să ruleze pe dispozitive înrădăcinate”, cu referire la modificările recente în detectarea falsificării software a API-ului SafetyNet Attestation.
  • Ce s-a întâmplat cu „deschiderea și setarea implicită”?
    • Android 10 realizat este puțin enervant să setați o aplicație ca handler implicit pentru anumite link-uri, despre care Google spune că a fost făcut pentru a proteja utilizatorii de „aplicații de exploatare”. Google a dat înapoi asupra acestei schimbări după regândirea ei, făcând un „număr de modificări în culise” pentru a proteja utilizatorul.
  • Folosești API-ul Vulkan Graphics pentru a reda interfața de utilizare?
    • Google intenționează să folosească în cele din urmă API-ul Vulkan Graphics pentru a reda interfața de utilizare, ceea ce va aduce unele îmbunătățiri de performanță. Aceasta este încă în curs de evaluare, dar compania nu avea detalii de împărtășit.
  • Lipsește CallScreeningService pe multe dispozitive
    • Aplicațiile Android pot implementa API CallScreeningService pentru a intercepta noile apeluri primite și ieșite, permițându-le să identifice apelantul și să accepte sau să respingă apelul. Deși acesta este un API documentat oficial, se pare că există mulți OEM care nu îl implementează corect, conform dezvoltatorului /u/_zeromod_. Google confirmă că acest API este validat de Compatibility Test Suite (CTS), o suită de testare automată pe care trebuie să o treacă toate dispozitivele pentru a fi considerate compatibile cu Android. Indiferent de motiv, acest API returnează nul atunci când este apelat pe dispozitive de la OEM-uri precum Huawei, Vivo, Xiaomi sau Samsung, așa că este probabil că acești OEM au o eroare în software-ul lor.
  • Nu există planuri pentru un cadru de plugin audio
    • Un dezvoltator a întrebat Google dacă intenționează să implementeze un cadru de plugin audio precum Unitățile audio de la Apple, dar răspunsul este că este puțin probabil să se întâmple în viitorul apropiat.

Puteți citi toate răspunsurile de la echipa de ingineri Android Aici. Echipa vorbește puțin despre Java, Kotlin, sistemul de construcție Android, API-ul CameraX și alte subiecte în câteva comentarii. Există, de asemenea, câteva comentarii despre Wear OS, Android TV și Android Auto, dar Google reiterează în mare parte munca lor existentă pe aceste platforme și le spune dezvoltatorilor să rămână la curent pentru mai multe informații în timpul "Android dincolo de telefoane„săptămâna începând cu 10 august.