Android 11 AMA: Brez drsenja posnetkov zaslona, ​​hitrejši zagoni aplikacij, več

Včeraj je Google izdal Android 11 beta 2, ki prinaša dokončane SDK, NDK, površine, usmerjene v aplikacije, vedenje platforme in omejitve za vmesnike, ki niso SDK, za razvijalce. Danes Google odgovarja na vprašanja v zvezi z Androidom 11 v Redditovi skupnosti /r/AndroidDev po vprašanjih prejšnji teden. Tukaj je povzetek vsega, kar smo izvedeli od Googlovega AMA (Vprašaj me kar koli).

Ena najbolj pričakovanih funkcij Androida 11 ne bo na voljo, ko OS zapusti beta 8. septembra: pomikanje po posnetkih zaslona. Sprva načrtovan za predstavitev v sistemu Android 11, je Google zdaj potrdil, da funkcija "ni uspela za R." Android 11 Developer Preview 1 in vse naslednje izdaje DP in Beta imajo gumb za označbo mesta za snemanje drsnega posnetka zaslona, ​​ki je lahko ročno prikazan s skritim ukazom razvijalca, vendar se z dotikom gumba preprosto prikaže sporočilo, ki navaja, da funkcija "ni implementirana".

Upali smo, da se bo funkcija prebila v različico beta ali celo v stabilno izdajo, a zdi se, da se to preprosto ne bo zgodilo.

Ta novica bo nekatere uporabnike razumljivo razburila. Navsezadnje imajo številni proizvajalci originalne opreme to funkcijo že leta v svoji lastni programski opremi, zakaj torej Google potrebuje toliko časa, da jo doda v telefone Pixel? Kot je pojasnil Dan Sandler iz Googlove ekipe za sistemski uporabniški vmesnik, je težava v tem, da želi Google to narediti pravilno. Nekatere implementacije drsnih posnetkov zaslona preprosto posnemajo drsenje in nato med premikanjem zaslona združijo več posnetkov zaslona. Če ste se kdaj ukvarjali z avtomatizacijo uporabniškega vmesnika v sistemu Android, boste vedeli, da to ne deluje vedno, saj, kot omenja gospod Sandler, aplikacije lahko uporabljajo "močvirski standardni RecyclerView ali implementirajo lasten pogon za drsenje, pospešen z OpenGL." Ker namerava Google izvajajo to funkcijo ne le za pametne telefone Pixel, temveč za celoten ekosistem Android kot del AOSP, morajo zagotoviti bo delovalo naprej vse aplikacije in ne samo "ena ali dve ročno izbrani aplikaciji na določeni napravi."

Ker je morala ekipa "osredotočiti [svoje] omejene vire," zlasti zaradi izzivov, ki so bili prineseni do COVID-19 se je ekipa odločila, da drseče posnetke zaslona pusti v ozadju za prihodnjo izdajo Androida.

Nova zahteva CDD za obveščanje uporabnikov o omejitvah v ozadju

Ni skrivnost, da imajo številni proizvajalci originalne opreme za Android, zlasti kitajski, agresivne omejitve za aplikacije, ki se izvajajo v ozadju. Nekateri razvijalci so bili tako razočarani nad tem, da so njihove aplikacije uničene v ozadju, da so se združili in ustvarili spletno mesto z imenom "Ne uniči moje aplikacije" za razvrščanje proizvajalcev originalne opreme glede na to, kako slabo upravljajo s procesi aplikacij v ozadju. Ti isti razvijalci celo pred kratkim izdelal merilo uspešnosti tako da lahko uporabniki preizkusijo, kako agresivno njihova naprava ubija aplikacije v ozadju. Razlog, zakaj mnogi proizvajalci originalne opreme radi uničujejo procese aplikacij v ozadju, je zapleten, vendar mislim, da je najbolje razložen v tem komentarju Redditorja /u/mogoče vprašljivo. Komentar opisuje zapleteno stanje razvoja aplikacij za Android na Kitajskem, kako kitajska tehnološka podjetja sodelujejo pri nadaljnjem zapletanju stvari in kako pomanjkanje Googlovih storitev prispeva k temu, kar se dogaja nered.

Ne glede na to je veliko razvijalcev aplikacij razumljivo razočaranih nad temi prilagoditvami vedenja platforme Android, zaradi česar so razvijalci komentirali vpraša Google, kaj počnejo glede tega na vrh Reddit AMA. Tukaj je Googlov odgovor:

Iz tega odgovora je treba nekaj stvari odvzeti. Prvič, Google želi, da so proizvajalci originalne opreme z uporabniki bolj pregledni glede omejitev aplikacij v ozadju, ki jih uporabljajo. Preveril sem (neobjavljeni) Android 11 Compatibility Definition Document (CDD) in našel naslednji predlagani dodatek k razdelku 3.5 – API Behavioral Compatibility:

Če implementacije naprav izvajajo lastniški mehanizem za omejevanje aplikacij in je ta mehanizem bolj restriktiven kot »Redko« vedro pripravljenosti na AOSP:

[C-1-5] MORA obvestiti uporabnike, če se omejitve aplikacije samodejno uporabijo za aplikacijo. (NOVO) Take informacije NE SMEJO biti posredovane prej kot 24 ur pred uporabo takih omejitev.

(Opomba) Prisilna zaustavitev se šteje za bolj restriktivno kot "Redko" in MORA izpolnjevati vse zahteve pod 3.5.1, vključno z novim 3.5.1/C-1-5

V bistvu Google ni veliko, da bi proizvajalcem originalne opreme preprečil uvedbo lastnih omejevalnih funkcij za ubijanje aplikacij. Zahtevajo samo, da proizvajalci originalne opreme obvestijo uporabnike, če se njihove omejitve aplikacij samodejno uporabljajo. Proizvajalec originalne opreme lahko prikaže pogovorno okno, da bo preprečil izvajanje aplikacij v ozadju, ki porabljajo baterijo ozadju, uporabnik pa bi lahko privolil, ne da bi se zavedal, katere aplikacije resnično želi izvajati v ozadju prizadeti! Google na razvijalce nalaga odgovornost za reševanje primerov, ko njihova aplikacija v ozadju nepričakovano preneha delovati. Dejansko komentar na Redditu poudarja novo "razlogi za izhod iz procesa aplikacije" API, ki lahko razvijalcem pove, ali je njihovo aplikacijo uničil uporabnik, operacijski sistem ali pa se je preprosto zrušila.

Po drugi strani pa Google končno obravnava nepošteno prakso proizvajalcev originalne opreme, ki nekaterim privilegiranim aplikacijam dovoljujejo, da obidejo svoje omejitve aplikacij v ozadju. Ta srednja objava razvijalca Timothy Asiimwe podrobno opisuje aplikacije, kot so WhatsApp, Facebook in druge aplikacije, ki so samodejno izvzete iz strogih omejitev ozadja nekatere programske opreme OEM. Google pravi, da "zahtevajo, da proizvajalci naprav ne ustvarjajo dovoljenih seznamov za najbolj priljubljene aplikacije." Ne vemo, kako bo to uveljavljeno, vendar dobro je vedeti, da bodo proizvajalci originalne opreme končno prisiljeni razvijalce tretjih oseb obravnavati enakovredno – ne glede na to, kako velike ali majhne so njihove aplikacije so.

Nazadnje Google omenja tudi, kako je Android 11 "dodal dodatne ukrepe za preprečevanje zlorabe s slabo delujočimi aplikacijami", zaradi česar je za proizvajalce originalne opreme manj privlačno agresivno ubijanje procesov v ozadju. V družbi pa niso pojasnili, kaj ti "dodatni ukrepi" vključujejo.

Izboljšano varnostno kopiranje med napravami

Prejšnji mesec smo opazili spremembo dokumentacije za Android 11, ki namignil podporo za boljše lokalne varnostne kopije podatkov. V Androidu 11 sistem ne bo upošteval atributa manifesta allowBackup za katero koli aplikacijo, ki cilja na raven API-ja 30, ko uporabnik sproži selitev datotek aplikacije »od naprave do naprave«. Uslužbenec Googla Eliot Stock pravi, da je ta funkcija namenjena temu, da bi proizvajalcem telefonov "veliko olajšala izdelavo orodij za selitev med napravami", kot je "Samsungov odličen izdelek Smart Switch" na pomagajo "zagotoviti, da se aplikacije bolj zanesljivo prenašajo med napravami z uporabniškega vidika." Na žalost to ne velja za varnostno kopiranje v oblaku, saj želi Google "razvijalcem programske opreme dati nadzor nad tem, kaj se zgodi z njihovimi podatki aplikacije." Kot tak bo Android 11 še vedno upošteval atribut allowBackup za vsako varnostno kopiranje in obnovitev v oblaku, na primer prek vgrajenega Google Drive storitve Google Play rezerva. Nazadnje Google priznava, da zgornja meja 25 MB za varnostno kopiranje na aplikacijo morda ne bo dovolj za nekatere razvijalce, zato iščejo načine za rešitev tega problema. Lokalne varnostne kopije v osebnem računalniku pa niso v obravnavi in ​​Google ponavlja svoj načrt postopoma opusti varnostno kopiranje adb v prihodnji izdaji za Android.

Razvijalce spodbujamo, da izvajajo metode selitve podatkov brez trenja. The nova knjižnica Block Store, ki je del knjižnice storitev Google Identity Services, je zasnovan tako, da olajša prijavo v obnovljene aplikacije iz oblaka na novih napravah, vendar se razvijalci sami odločijo, ali želijo to implementirati ali ne knjižnica.

Hitrejše zagone aplikacij s postopkom vnaprejšnjega branja I/O (IORap)

Google ves čas eksperimentira z načini za izboljšanje delovanja v sistemu Android. Ena od malo znanih funkcij, ki so jo dodali v Android 10, se imenuje Unspecialized App Process Pool (USAP). Ta funkcija odpravi razcepitev Zygote med postopkom zagona aplikacije in prihrani približno ~5 ms pri povprečni hitrosti zagona aplikacije v napravi Pixel 2. Funkcija je trenutno privzeto onemogočeno v AOSP, Google pa pojasnjuje, da je njegovo uporabo dodatnega pomnilnika treba še preizkusiti. Še bolj zanimiva pa je nova funkcija, ki prihaja v Android 11, imenovana I/O Read Ahead Process (IORap). Glede na Google, bo ta funkcija vodila do "več kot 5 % hitrejših hladnih zagonov s primeri junakov, ki bodo dosegli 20 % hitreje." Ta funkcija »med postopkom zagona bo vnaprej pridobil artefakte aplikacij (kot so koda in viri)« za pospešitev zagona aplikacije hitrosti.

Google je tudi "izboljšal profile, ki se uporabljajo za optimizacijo poti zagonskega razreda in slike sistema" kar bo izboljšalo delovanje aplikacije in zmanjšalo stroške pomnilnika in shranjevanja, povezane s sistemom artefakti. Te spremembe bodo večinoma koristile napravam z večjo količino RAM-a, čeprav Google ni povedal, kakšna je meja, kjer bomo videli največ koristi.

Spremembe obsega shranjevanja v sistemu Android 11 – zakaj je dostop do /Prenosov omejen?

Aplikacije, ki ciljajo na Android 11 in uporabljajo namen ACTION_OPEN_DOCUMENT_TREE za zahtevanje dostopa do določenih imenikov na zunanji shranjevanje ne bo več moglo zahtevati od uporabnikov dostopa do korenskega imenika zunanjega pomnilnika (/data/media/{user}), prenos imenik (/data/media{user}/Download) ali kateri koli podatkovni imenik za aplikacijo v zunanjem pomnilniku (/Android/data ali /Android/obb). Zakaj je dostop do imenika za prenose omejen? Po Googlu Roxanna Aliabadi, to je zato, ker je mapa za prenos "najbolj ogrožena zaradi zasebnih podatkov." Kot primer uporabniki, ki prenesejo svoj davek vračil ali bančnih izpiskov ne bi smelo skrbeti, da bi aplikacije zlorabile njihov stalen dostop za branje do imenik. Google pravi, da bo imel izbirnik dokumentov "posodobljeno besedilo... ki označuje, da je Android omejil določene mape da bodo izbrani." Upamo, da bo to zmanjšalo zmedo o tem, zakaj aplikacijam ne morejo odobriti dostopa do določenih imenikov več.

Za več informacij o prihajajočih spremembah pravilnika o omejenem shranjevanju in predvajanju glej ta članek.

Razne teme

• Googlovo stališče do rootanja/modinga
  • Jeff Bailey iz Googlove ekipe AOSP ponavlja stališče podjetja glede podpore izbiri. Google bo "še naprej zagotavljal, da je možno spreminjanje/ukoreninjenje linije naprav Pixel," vendar bo tudi "podpiral izbiro proizvajalcev originalne opreme, da svojim napravam ne dovolijo Poleg tega daje Google razvijalcem programske opreme možnost, da "ne dovolijo, da bi se njihova programska oprema izvajala na napravah z rootanimi pravicami," glede na nedavne spremembe v odkrivanje poseganja v programsko opremo API-ja za potrdila SafetyNet.
• Kaj se je zgodilo z "odpri in nastavi na privzeto"?
  • Android 10 narejen malce nadležno je nastaviti aplikacijo kot privzeti upravljavec za posebne povezave, za katere Google pravi, da so uporabnike zaščitili pred "izkoriščevalskimi aplikacijami". Google se je umaknil o tej spremembi po ponovnem premisleku in "številnih spremembah v zakulisju" za zaščito uporabnika.
• Uporabljate Vulkan Graphics API za upodabljanje uporabniškega vmesnika?
  • Google namerava sčasoma uporabiti Vulkan Graphics API za upodabljanje uporabniškega vmesnika, kar bo prineslo nekaj izboljšav zmogljivosti. To je še vedno ocenjujejo, vendar podjetje ni imelo povedati nobenih podrobnosti.
• V mnogih napravah manjka CallScreeningService
  • Aplikacije za Android lahko izvajajo CallScreeningService API za prestrezanje novih dohodnih in odhodnih klicev, kar jim omogoča, da identificirajo klicatelja in sprejmejo ali zavrnejo klic. Čeprav je to uradno dokumentiran API, je po mnenju razvijalca /u/ očitno veliko proizvajalcev originalne opreme, ki ga ne izvajajo pravilno._zeromod_. Google potrdi da je ta API potrjen s zbirko testov združljivosti (CTS), avtomatizirano zbirko testov, ki jo morajo opraviti vse naprave, da se štejejo za združljive z Androidom. Iz kakršnega koli razloga ta API vrne ničelno vrednost, ko ga kličejo naprave proizvajalcev originalne opreme, kot so Huawei, Vivo, Xiaomi ali Samsung, zato je verjetno, da imajo ti proizvajalci originalne opreme napako v svoji programski opremi.
• Ni načrtov za ogrodje zvočnih vtičnikov
  • Razvijalec je vprašal Google, ali nameravajo implementirati ogrodje zvočnih vtičnikov, kot so Applove avdio enote, vendar odgovor je, da se to verjetno ne bo zgodilo v bližnji prihodnosti.

Preberete lahko vse odgovore inženirske ekipe za Android tukaj Ekipa v nekaj komentarjih govori nekaj o Javi, Kotlinu, sistemu za gradnjo Android, API-ju CameraX in drugih temah. Obstaja tudi več komentarjev o Wear OS, Android TV in Android Auto, vendar Google večinoma ponavlja njihovo obstoječe delo na teh platformah in razvijalcem sporoča, naj spremljajo več informacij med "Android Beyond Phones" teden, ki se začne 10. avgusta.