Android 11 AMA: pole keritavaid ekraanipilte, rakenduste kiiremad käivitamised ja palju muud

Eile avaldas Google Android 11 Beta 2, tuues arendajate jaoks valmis SDK, NDK, rakendusega seotud pinnad, platvormi käitumise ja piirangud mitte-SDK liidestele. Täna vastab Google Redditi kogukonnas /r/AndroidDev Android 11 versiooniga seotud küsimustele pärast eelmisel nädalal küsimuste esitamist. Siin on kokkuvõte kõigest, mida õppisime Google'i AMA-st (Ask Me Anything).

Üks Android 11 oodatumaid funktsioone ei ole OS-i ajal saadaval väljub beetaversioonist 8. septembril: ekraanipiltide kerimine. Esialgu plaanitakse käivitada Android 11-s, on Google nüüd kinnitanud, et see funktsioon "ei teinud R-i jaoks kärpimist." Android 11 arendaja eelvaade 1 ja kõigil järgnevatel DP- ja beetaversioonidel on kohahoidja nupp keritava ekraanipildi tegemiseks käsitsi peidetud arendajakäsuga, kuid nupule koputades kuvatakse lihtsalt röstsanade teade, et funktsioon pole rakendatud.

Lootsime, et see funktsioon jõuab beetaversiooni või isegi stabiilsesse versiooni, kuid tundub, et seda lihtsalt ei juhtu.

See uudis on mõne kasutaja jaoks arusaadavalt häiriv. Lõppude lõpuks on paljudel originaalseadmete tootjatel see funktsioon oma tarkvaras juba aastaid olnud, nii et mis võtab Google'il selle Pixeli telefonidele lisamiseks nii kaua aega? Nagu selgitas Dan Sandler Google'i süsteemi kasutajaliidese meeskonnast, on probleem selles, et Google tahab seda õigesti teha. Mõned keritavad ekraanipiltide rakendused lihtsalt jäljendavad kerimist ja ühendavad seejärel mitu ekraanipilti, kui ekraan liigub. Kui olete kunagi Androidis kasutajaliidese automatiseerimisega tegelenud, siis teate, et see ei tööta alati, sest nagu hr Sandler mainib, on rakendused saab kasutada "rabastandardit RecyclerView" või on rakendanud oma OpenGL-i kiirendatud kerimismootori. Kuna Google plaanib rakendama seda funktsiooni mitte ainult Pixeli nutitelefonides, vaid kogu Androidi ökosüsteemis AOSP osana, peavad nad tagama see töötab edasi kõik rakendusi, mitte ainult "üks või kaks käsitsi valitud rakendust konkreetses seadmes".

Kuna meeskond pidi "keskendama [oma] piiratud ressursse", eriti esile kerkinud väljakutsete tõttu COVID-19 tõttu otsustas meeskond tulevase Androidi väljaande jaoks lisada keritavad ekraanipildid tagapõletisse.

Uus CDD nõue teavitada kasutajaid taustapiirangutest

Pole saladus, et paljudel Androidi originaalseadmete tootjatel, eriti Hiina omadel, on taustal töötavatele rakendustele agressiivsed piirangud. Mõned arendajad olid nii pettunud, et nende rakendused taustal tapeti, et nad lõid kokku veebisaidi nimega "Ära tapa minu rakendust", et järjestada originaalseadmete tootjaid selle põhjal, kui halvasti nad taustarakenduste protsesse käsitlevad. Need samad arendajad isegi hiljuti tehtud etalon nii saavad kasutajad testida, kui agressiivselt nende seade taustal rakendusi tapab. Põhjus, miks paljud originaalseadmete tootjad armastavad taustarakenduste protsesse tappa, on keeruline, kuid ma arvan, et seda saab kõige paremini selgitada selles Redditori kommentaaris /u/võimalik, et küsitav. Kommentaaris kirjeldatakse Androidi rakenduste arendamise keerulist seisu Hiinas, kuidas Hiina tehnoloogiaettevõtted on seotud asjade edasise keerulisemaks muutmisega ja kuidas Google'i teenuste puudumine käimasolevale kaasa aitab segadus.

Sellest hoolimata on paljud rakenduste arendajad arusaadavalt pettunud nendest Androidi platvormi käitumise muudatustest, mille tulemusena on arendajad kommenteerinud. küsides Google'ilt, mida nad sellega teevad Reddit AMA tippu. Siin on Google'i vastus:

Sellest vastusest tuleb mõned asjad ära võtta. Esiteks soovib Google, et originaalseadmete tootjad oleksid kasutajate jaoks läbipaistvamad nende rakendatavate taustarakenduste piirangute osas. Kontrollisin (avaldamata) Android 11 ühilduvuse definitsiooni dokumenti (CDD) ja leidsin jaotisele 3.5 – API käitumise ühilduvus järgmise pakutud täienduse:

Kui seadmete juurutused rakendavad rakenduste piiramiseks patenteeritud mehhanismi ja see mehhanism on piiravam kui AOSP-i „haruldane” ooterežiimi salp, siis:

[C-1-5] PEAB kasutajaid teavitama, kui rakendusele rakenduvad automaatselt rakenduse piirangud. (UUS) Sellist teavet EI TOHI esitada varem kui 24 tundi enne selliste piirangute rakendamist.

(Märkus) Sundseiskamist peetakse piiravamaks kui "Rare" ja PEAB vastama kõigile punkti 3.5.1 nõuetele, sealhulgas uutele 3.5.1/C-1-5 nõuetele.

Põhimõtteliselt ei takista Google palju originaalseadmete tootjaid rakendamast oma piiravaid rakendusi hävitavaid funktsioone. Nad nõuavad ainult seda, et originaalseadmete tootjad teavitaksid kasutajaid, kui nende rakendusepiirangud rakenduvad automaatselt. OEM võib näidata dialoogi, et nad peatavad akut imevate taustarakenduste töötamise taustal ja kasutaja võib anda nõusoleku, ilma et oleks aru saanud, milliseid rakendusi ta tegelikult taustal käivitada soovib mõjutatud! Google paneb arendajatele kohustuse tegeleda juhtumitega, kui nende rakendus taustal ootamatult tapetakse. Tõepoolest, Redditi kommentaar toob esile uue "rakenduse protsessist väljumise põhjused" API, mis võib arendajatele öelda, kas nende rakenduse tappis kasutaja, OS või see lihtsalt jooksis kokku.

Teisest küljest on Google lõpuks tegelemas originaalseadmete tootjate ebaausa tavaga, mis lubab teatud privilegeeritud rakendustel taustarakenduste piirangutest mööda minna. See arendaja keskmine postitus Timothy Asiimwe kirjeldab üksikasjalikult rakendusi, nagu WhatsApp, Facebook ja muud rakendused, mis on automaatselt vabastatud mõne OEM-tarkvara karmidest taustapiirangutest. Google ütleb, et nad "nõuavad, et seadmete tootjad ei koostaks populaarseimate rakenduste jaoks lubade loendeid". Me ei tea, kuidas seda jõustatakse, kuid on hea teada, et originaalseadmete tootjad on lõpuks sunnitud kohtlema kolmandate osapoolte arendajaid võrdsetel alustel – olenemata sellest, kui suured või väikesed nende rakendused on on.

Lõpuks mainib Google ka seda, kuidas Android 11 on "lisanud lisameetmeid, et vältida valesti käituvate rakenduste kuritarvitamist", muutes originaalseadmete tootjate jaoks vähem ahvatlevaks taustaprotsesse agressiivselt tappa. Ettevõte ei täpsustanud, mida need "lisameetmed" aga endast kujutavad.

Täiustatud seadmetevahelised varukoopiad

Eelmisel kuul märkasime Android 11 dokumentatsioonis muudatust, mis vihjasid paremate kohalike andmete varukoopiate toetamisele. Operatsioonisüsteemis Android 11 eirab süsteem atribuuti allowBackup Manifest kõigi rakenduste puhul, mis sihivad API taset 30, kui kasutaja algatab rakenduse failide migratsiooni seadmest seadmesse. Google'i töötaja Eliot Stock ütleb, et see funktsioon on mõeldud selleks, et telefonitootjatel oleks "palju lihtsam luua seadmest seadmesse migratsioonitööriistu", nagu "Samsungi suurepärane Smart Switch toode". aidata "tagada rakenduste usaldusväärsem edastus seadmete vahel kasutaja vaatenurgast". Kahjuks ei kehti see pilvepõhiste varukoopiate kohta, kuna Google soovib anda tarkvaraarendajatele kontrolli selle üle, mida juhtub nende rakenduste andmetega." Seetõttu austab Android 11 endiselt atribuuti allowBackup mis tahes pilvepõhise varundamise ja taastamise puhul, näiteks Google Play teenuse sisseehitatud Google Drive'i kaudu. varukoopia. Lõpuks tunnistab Google, et mõnele arendajale ei pruugi 25 MB-i rakenduse kohta varundamise ülemmäär olla piisav, mistõttu nad otsivad võimalusi selle lahendamiseks. Kohalikke varukoopiaid arvutisse siiski ei kaaluta ja Google kordab oma plaani järk-järgult lõpetama adb-varundamine tulevases Androidi versioonis.

Arendajaid julgustatakse rakendama hõõrdumatuid andmete migratsiooni meetodeid. The uus Block Store'i raamatukogu, mis on osa Google'i identiteediteenuste raamatukogust, on loodud taastatud rakendustesse sisselogimise hõlbustamiseks. uutes seadmetes pilvest, kuid arendajad saavad valida, kas nad soovivad seda rakendada või mitte raamatukogu.

Rakenduse kiirem käivituskiirus koos I/O ettelugemisprotsessiga (IORAp)

Google katsetab alati võimalusi Androidi jõudluse parandamiseks. Üks vähetuntud funktsioone, mille nad Android 10-sse lisasid, nimetatakse Unspecialized App Process Pool (USAP). See funktsioon välistab rakenduse käivitamise ajal Zygote'i hargnemise, säästes Pixel 2 seadmes keskmiselt umbes 5 ms rakenduse käivituskiirust. Funktsioon on praegu AOSP-s vaikimisi keelatud, ja Google selgitab, et selle lisatud mälukasutus vajab veel testimist. Huvitavam on aga Android 11 uus funktsioon nimega I/O Read Ahead Process (IORap). Google’i järgi, toob see funktsioon kaasa "rohkem kui 5% kiiremad külmkäivitused, kusjuures kangelaste juhtumid jõuavad 20% kiiremini." See funktsioon "eellaadib rakenduste artefakte (nt koodi ja ressursid) käivitusprotsessi ajal", et kiirendada rakenduse käivitamist kiirused.

Google on ka "täiustanud profiile, mida kasutatakse alglaadimisklassi tee ja süsteemipildi optimeerimiseks" mis parandab rakenduse jõudlust ja vähendab süsteemiga seotud mälu- ja salvestuskulusid artefaktid. Need muudatused toovad enamasti kasu suurema RAM-i mahuga seadmetele, kuigi Google ei ole öelnud, milline on piirmäär, kus me näeme kõige rohkem eeliseid.

Android 11 ulatusega salvestusruumi muudatused – miks on juurdepääs /Allalaadimistele piiratud?

Rakendused, mis sihivad operatsioonisüsteemi Android 11 ja kasutavad kavatsust ACTION_OPEN_DOCUMENT_TREE, et taotleda juurdepääsu välise seadme konkreetsetele kataloogidele salvestusruum ei saa enam küsida kasutajatelt juurdepääsu välise salvestusruumi juurkataloogile (/data/media/{user}), kataloog (/data/media{user}/Download) või mis tahes rakendusespetsiifiline andmekataloog välismällu (/Android/data või /Android/obb). Miks on juurdepääs allalaadimiskataloogile piiratud? Google'i andmetel Roxanna Aliabadi, selle põhjuseks on asjaolu, et allalaadimiskaust "on privaatse teabe omamise oht kõige suurem." Näiteks kasutajad, kes oma maksu alla laadivad tagastused või pangaväljavõtted ei peaks muretsema võimaluse pärast, et rakendused kuritarvitavad oma pidevat lugemisõigust kataloog. Google ütleb, et dokumendivalijal on "värskendatud tekst, mis näitab, et Android on teatud kaustu piiranud olema valitud." Loodetavasti vähendab see segadust selle üle, miks nad ei saa anda rakendustele juurdepääsu teatud kataloogidele enam.

Kui soovite lisateavet eelseisvate rakendusala salvestusruumi ja esitamise eeskirjade muudatuste kohta, vaadake seda artiklit.

Mitmesugused teemad

• Google'i seisukoht juurdumise/muutmise kohta
  • Jeff Bailey Google'i AOSP meeskonnast kordab ettevõtte seisukohta valiku toetamisel. Google "tagab jätkuvalt, et Pixeli seadmete seeria modifitseerimine/juurimine on võimalik", kuid toetab ka originaalseadmete tootjate valikut oma seadmeid mitte lubada. Lisaks annab Google tarkvaraarendajatele võimaluse mitte lubada oma tarkvaral juurtega seadmetes töötada, viidates hiljutistele muudatustele SafeNet Atestation API tarkvara rikkumiste tuvastamine.
• Mis juhtus funktsiooniga "avatud ja vaikimisi seadistatud"?
  • Android 10 tehtud on natuke tüütu määrata rakendus vaikekäsitlejaks konkreetsete linkide jaoks, mis Google'i sõnul tehti kasutajate kaitsmiseks "ekspluateerivate rakenduste eest". Google taganes selle muudatuse kohta pärast selle ümbermõtestamist, tehes kasutaja kaitsmiseks "kulisside taga mitmeid muudatusi".
• Kas kasutate kasutajaliidese renderdamiseks Vulkan Graphics API-t?
  • Google kavatseb lõpuks kasutada kasutajaliidese renderdamiseks Vulkan Graphics API, mis toob kaasa mõned jõudluse täiustused. See on veel hinnatakse, kuid ettevõttel polnud konkreetseid andmeid jagada.
• Paljudes seadmetes puudub CallScreeningService
  • Androidi rakendused saavad rakendada CallScreeningService API uute sissetulevate ja väljaminevate kõnede pealtkuulamiseks, võimaldades neil helistaja tuvastada ja kõne vastu võtta või tagasi lükata. Kuigi see on ametlikult dokumenteeritud API, on arendaja /u/ sõnul ilmselt palju originaalseadmete tootjaid, kes seda korralikult ei rakenda._zeromod_. Google kinnitab et seda API-t kinnitab ühilduvustesti komplekt (CTS), automaatne testkomplekt, mille peavad Androidiga ühilduvaks käsitlemiseks läbima kõik seadmed. Mingil põhjusel tagastab see API nulli, kui seda kutsutakse OEM-ide, nagu Huawei, Vivo, Xiaomi või Samsungi seadmetes, seega on tõenäoline, et nende originaalseadmete tootjate tarkvaras on viga.
• Heliplugina raamistikku pole plaanis
  • Arendaja küsis Google'ilt, kas nad kavatsevad rakendada helipistikprogrammi nagu Apple'i heliüksused, kuid vastus on see, et seda lähitulevikus tõenäoliselt ei juhtu.

Saate lugeda kõiki Androidi insenerimeeskonna vastuseid siin. Meeskond räägib mõnes kommentaaris natuke Javast, Kotlinist, Androidi ehitussüsteemist, CameraX API-st ja muudest teemadest. Wear OS-i, Android TV ja Android Auto kohta on ka mitmeid kommentaare, kuid Google kordab seda enamasti nende olemasolevat tööd nendel platvormidel ja käsib arendajatel olla kursis, et saada rohkem teavet "Android väljaspool telefone" nädal alates 10. augustist.