Android 11 AMA: nav ritināmu ekrānuzņēmumu, ātrāka lietotņu palaišana un daudz kas cits

Vakar Google izlaida Android 11 Beta 2, nodrošinot izstrādātājiem pabeigto SDK, NDK, lietotnēm vērstās virsmas, platformas darbības un ierobežojumus saskarnēm, kas nav SDK. Šodien Google atbild uz jautājumiem, kas saistīti ar operētājsistēmu Android 11, Reddit /r/AndroidDev kopienā pēc jautājumu uzdošanas pagājušajā nedēļā. Šeit ir kopsavilkums par visu, ko mēs uzzinājām no Google AMA (Ask Me Anything).

Viena no operētājsistēmas Android 11 gaidītākajām funkcijām nebūs pieejama operētājsistēmā 8. septembrī tiks izbeigta beta versija: ekrānuzņēmumu ritināšana. Sākotnēji plānots palaist operētājsistēmā Android 11, Google tagad ir apstiprinājusi, ka šī funkcija "nemazināja R." Android 11 izstrādātāja priekšskatījums 1 un visos turpmākajos DP un Beta laidienos ir viettura poga ritināma ekrānuzņēmuma uzņemšanai manuāli parādīts ar slēptu izstrādātāja komandu

, bet, pieskaroties pogai, vienkārši tiek parādīts grauzdiņš, kurā teikts, ka funkcija "nav ieviesta".

Mēs cerējām, ka šī funkcija nonāks beta versijā vai pat tikai stabilā versijā, taču izskatās, ka tas vienkārši nenotiks.

Šīs ziņas, protams, satrauc dažus lietotājus. Galu galā daudziem oriģinālo iekārtu ražotājiem šī funkcija ir bijusi savā programmatūrā jau gadiem ilgi, tāpēc, kāpēc Google prasa tik ilgu laiku, lai to pievienotu Pixel tālruņiem? Kā paskaidroja Dens Sandlers no Google sistēmas lietotāja interfeisa komandas, problēma ir tā, ka Google vēlas to darīt pareizi. Dažas ritināšanas ekrānuzņēmumu ieviešanas iespējas vienkārši atdarina ritināšanu un pēc tam savieno vairākus ekrānuzņēmumus, kad ekrāns pārvietojas. Ja kādreiz esat nodarbojies ar UI automatizāciju operētājsistēmā Android, jūs zināt, ka tas ne vienmēr darbojas, jo, kā min Sandler kungs, lietotnes var izmantot "purva standarta RecyclerView" vai ir ieviesuši savu OpenGL paātrināto ritināšanas programmu. Tā kā Google plāno ieviešot šo funkciju ne tikai Pixel viedtālruņos, bet visā Android ekosistēmā kā daļu no AOSP, viņiem ir jāpārliecinās tas darbosies visi lietotnes, nevis tikai "viena vai divas ar rokām izvēlētas lietotnes noteiktā ierīcē".

Tā kā komandai bija "jākoncentrē [savi] ierobežotie resursi", jo īpaši radušos izaicinājumu dēļ Covid-19 komanda nolēma ievietot ritināmos ekrānuzņēmumus aizmugures ierakstā nākamajam Android laidienam.

Jauna CDD prasība informēt lietotājus par fona ierobežojumiem

Nav noslēpums, ka daudziem Android oriģinālo iekārtu ražotājiem, īpaši ķīniešu, ir agresīvi ierobežojumi lietotnēm, kas darbojas fonā. Daži izstrādātāji bija tik neapmierināti, ka viņu lietotnes tika iznīcinātas fonā, ka viņi apvienojās, lai izveidotu vietni ar nosaukumu "Nenogalini manu lietotni", lai klasificētu oriģinālo iekārtu ražotājus, pamatojoties uz to, cik slikti tie apstrādā fona lietotņu procesus. Tie paši izstrādātāji pat nesen veica etalonu lai lietotāji varētu pārbaudīt, cik agresīvi viņu ierīce nogalina lietotnes fonā. Iemesls, kāpēc daudziem oriģinālo iekārtu ražotājiem patīk nogalināt fona lietotņu procesus, ir sarežģīts, taču es domāju, ka to vislabāk var izskaidrot šajā Redditor komentārā /u/iespējams, apšaubāms. Komentārā ir izklāstīts Android lietotņu izstrādes sarežģītais stāvoklis Ķīnā, kā Ķīnas tehnoloģiju uzņēmumi ir iesaistīti lietas vēl vairāk sarežģīšanā un kā Google pakalpojumu trūkums veicina notiekošo juceklis.

Neskatoties uz to, daudzi lietotņu izstrādātāji ir saprotami vīlušies par šiem Android platformas uzvedības uzlabojumiem, kuru rezultātā izstrādātāji ir izteikuši komentāru. jautājot Google, ko viņi ar to dara Reddit AMA augšpusē. Lūk, Google atbilde:

No šīs atbildes ir jāņem vērā dažas lietas. Pirmkārt, Google vēlas, lai oriģinālo iekārtu ražotāji lietotājiem būtu skaidrāki par fona lietotņu ierobežojumiem, ko tie piemēro. Es pārbaudīju (neizlaista) Android 11 saderības definīcijas dokumentu (CDD) un atradu šādu ierosināto papildinājumu 3.5. sadaļai — API uzvedības saderība:

Ja ierīču implementācijās tiek ieviests patentēts mehānisms, lai ierobežotu lietotnes un šis mehānisms ir ierobežojošāks nekā AOSP gaidstāves segments “Reti”, tie:

[C-1-5] OBLIGĀTI jāinformē lietotāji, ja lietotnei tiek automātiski piemēroti lietotņu ierobežojumi. (JAUNS) Šādu informāciju NEDRĪKST sniegt agrāk kā 24 stundas pirms šādu ierobežojumu piemērošanas.

(Piezīme) Tiek uzskatīts, ka piespiedu apturēšana ir ierobežojošāka nekā “Reti”, un OBLIGĀTI jāatbilst visām 3.5.1. punkta prasībām, tostarp jaunajām 3.5.1/C-1-5.

Būtībā Google neļauj oriģinālo iekārtu ražotājiem ieviest savas ierobežojošās lietotņu iznīcināšanas funkcijas. Tie tikai pieprasa, lai oriģinālā aprīkojuma ražotāji informētu lietotājus, ja viņu lietotņu ierobežojumi tiek automātiski piemēroti. OEM varētu parādīt dialoglodziņu, ka viņi pārtrauks akumulatoru sūcošo fona lietotņu darbību fonā, un lietotājs var piekrist, neapzinoties, kuras lietotnes viņi patiešām vēlas palaist fonā ietekmēts! Google uzliek izstrādātājiem pienākumu risināt gadījumus, kad viņu lietotne tiek negaidīti nogalināta fonā. Patiešām, Reddit komentārs turpina izcelt jauno "lietotnes procesa iziešanas iemesliAPI, kas var pateikt izstrādātājiem, vai viņu lietotni nogalināja lietotājs, OS vai tā vienkārši avarēja.

No otras puses, Google beidzot risina oriģinālo iekārtu ražotāju negodīgo praksi, ļaujot noteiktām priviliģētām lietojumprogrammām apiet fona lietotņu ierobežojumus. Šī izstrādātāja vidēja ziņa Timotejs Asiimve ir detalizēti aprakstītas tādas lietotnes kā WhatsApp, Facebook un citas lietotnes, kuras automātiski tiek atbrīvotas no dažu OEM programmatūras skarbajiem fona ierobežojumiem. Google saka, ka viņi "pieprasa, lai ierīču ražotāji neveido atļauju sarakstus populārākajām lietotnēm." Mēs nezinām, kā tas tiks īstenots, bet ir labi zināt, ka oriģinālo iekārtu ražotāji beidzot būs spiesti vienlīdzīgi izturēties pret trešo pušu izstrādātājiem — neatkarīgi no tā, cik lielas vai mazas ir viņu lietotnes ir.

Visbeidzot, Google arī piemin, kā Android 11 ir "pievienojis papildu pasākumus, lai novērstu ļaunprātīgu uzvedību ar nepareizu lietotņu darbību", padarot oriģinālo iekārtu ražotājiem mazāk vilinošu agresīvu fona procesu iznīcināšanu. Tomēr uzņēmums sīkāk nepaskaidroja, ko šie "papildu pasākumi" ietver.

Uzlabota dublēšana starp ierīcēm

Pagājušajā mēnesī mēs pamanījām izmaiņas Android 11 dokumentācijā, kas norādīja uz atbalstu labākai vietējo datu dublēšanai. Operētājsistēmā Android 11 sistēma neņems vērā atribūtu allowBackup Manifest jebkurai lietotnei, kuras mērķauditorija ir API 30. līmenis, kad lietotājs sāk lietotņu failu migrāciju no ierīces uz ierīci. Google darbinieks Eliots Stoks saka, ka šī funkcija ir paredzēta, lai tālruņu ražotājiem būtu "daudz vienkāršāk izveidot migrācijas rīkus no ierīces uz ierīci", piemēram, "Samsung lielisko Smart Switch produktu". palīdziet "nodrošināt lietotņu uzticamāku pārsūtīšanu starp ierīcēm no lietotāja viedokļa". Diemžēl tas neattiecas uz mākoņdatošanas dublējumiem, jo ​​Google vēlas "dot programmatūras izstrādātājiem kontrolēt, ko Tas notiek ar viņu lietotņu datiem." Tādējādi operētājsistēmā Android 11 joprojām tiks ievērots atribūts allowBackup jebkurai mākoņa dublēšanai un atjaunošanai, piemēram, izmantojot Google Play pakalpojuma iebūvēto Google disku. dublējums. Visbeidzot, Google atzīst, ka dažiem izstrādātājiem var nepietikt ar 25 MB uz vienu lietotni rezerves griestiem, tāpēc viņi meklē veidus, kā to atrisināt. Tomēr vietējās dublējumkopijas datorā netiek izskatītas, un Google atkārto savu plānu pakāpeniski pārtrauciet adb dublēšanu nākamajā Android laidienā.

Izstrādātāji tiek mudināti ieviest nevainojamas datu migrācijas metodes. The jaunā Block Store bibliotēka, kas ir daļa no Google identitātes pakalpojumu bibliotēkas, ir izstrādāta, lai atvieglotu pierakstīšanos atjaunotajās lietotnēs. no mākoņa jaunajās ierīcēs, taču izstrādātāju ziņā ir izvēlēties, vai viņi vēlas to ieviest bibliotēka.

Ātrāks lietotņu palaišanas ātrums ar I/O priekšlasīšanas procesu (IORAp)

Google vienmēr eksperimentē ar veidiem, kā uzlabot Android veiktspēju. Viena no maz zināmajām funkcijām, ko viņi pievienoja operētājsistēmā Android 10, tiek saukta par nespecializēto lietotņu procesu kopu (USAP). Šī funkcija novērš Zygote atdalīšanu lietotnes palaišanas procesa laikā, ietaupot aptuveni 5 ms vidējo lietotņu palaišanas ātrumu Pixel 2 ierīcē. Funkcija pašlaik ir pēc noklusējuma atspējots AOSP, un Google paskaidro, ka tā pievienotās atmiņas lietojums joprojām ir jāpārbauda. Tomēr vēl interesantāk ir jauna funkcija, kas nāk operētājsistēmā Android 11, ko sauc par I/O Read Ahead Process (IORap). Saskaņā ar Google, šī funkcija nodrošinās "vairāk nekā 5% ātrāku aukstu palaišanu, un varoņu gadījumi sasniedz 20% ātrāk." Šī funkcija "startēšanas procesa laikā tiks ielādēti lietojumprogrammu artefakti (piemēram, kods un resursi), lai paātrinātu lietotņu palaišanu ātrumiem.

Google ir arī "veicis uzlabojumus profilos, ko izmanto, lai optimizētu sāknēšanas klases ceļu un sistēmas attēlu" kas uzlabos lietotņu veiktspēju un samazinās ar sistēmu saistītās atmiņas un krātuves izmaksas artefakti. Šīs izmaiņas galvenokārt dos labumu ierīcēm ar lielāku RAM apjomu, lai gan Google nav norādījis, kāds ir ierobežojums, kur mēs redzēsim visvairāk priekšrocību.

Izmaiņas operētājsistēmas Android 11 tvēruma krātuvē — kāpēc ir ierobežota piekļuve/lejupielādes?

Lietotnes, kuru mērķauditorija ir operētājsistēma Android 11 un kuras izmanto nolūku ACTION_OPEN_DOCUMENT_TREE, lai pieprasītu piekļuvi noteiktiem direktorijiem ārējā ierīcē krātuve vairs nevarēs lūgt lietotājiem piekļuvi ārējās krātuves (/data/media/{user}) saknes direktorijam, direktoriju (/data/media{user}/Download) vai jebkuru no lietotnei specifiskiem datu direktorijiem ārējā atmiņā (/Android/data vai /Android/obb). Kāpēc ir ierobežota piekļuve lejupielādes direktorijam? Saskaņā ar Google Roxanna Aliabadi, tas ir tāpēc, ka lejupielādes mape "ir vislielākais risks, ka tajā būs privāta informācija." Piemēram, lietotāji, kuri lejupielādē nodokļus atgriešanai vai bankas izrakstiem nevajadzētu uztraukties par iespēju, ka lietotnes ļaunprātīgi izmantos nepārtraukto lasīšanas piekļuvi direktoriju. Google saka, ka dokumentu atlasītājam būs "atjaunināts teksts..., lai norādītu, ka Android ir ierobežojis noteiktas mapes Jāizvēlas." Cerams, ka tas mazinās neskaidrības par to, kāpēc viņi nevar piešķirt lietotnēm piekļuvi noteiktiem direktorijiem vairs.

Lai iegūtu plašāku informāciju par gaidāmajām Scopped Storage and Play politikas izmaiņām, skatiet šo rakstu.

Dažādas tēmas

• Google nostāja sakņu/modinga jautājumā
  • Džefs Beilijs no Google AOSP komandas atkārto uzņēmuma nostāju par izvēles atbalstīšanu. Google "turpinās nodrošināt, ka ir iespējama Pixel ierīču līnijas modifikācija/saknešana", bet arī "atbalstīs oriģinālo iekārtu ražotāju izvēli neatļaut savas ierīces Turklāt Google sniedz programmatūras izstrādātājiem izvēli "neļaut savai programmatūrai darboties ierīcēs ar saknēm", atsaucoties uz nesenajām izmaiņām SafeNet Attestation API programmatūras iejaukšanās noteikšana.
• Kas notika ar "atvērt un iestatīt uz noklusējuma"?
  • Izgatavots Android 10 ir nedaudz kaitinoši iestatīt lietotni kā noklusējuma apdarinātāju konkrētām saitēm, kas, pēc Google domām, tika darīts, lai aizsargātu lietotājus no "ekspluatējošām lietotnēm". Google atkāpās par šīm izmaiņām pēc to pārdomāšanas, veicot "vairākas izmaiņas aizkulisēs", lai aizsargātu lietotāju.
• Vai izmantojat Vulkan Graphics API, lai renderētu lietotāja interfeisu?
  • Google galu galā plāno izmantot Vulkan Graphics API, lai renderētu lietotāja interfeisu, kas nodrošinās dažus veiktspējas uzlabojumus. Tas ir vēl tiek vērtēts, taču uzņēmumam nebija nekādas specifikas, ar ko dalīties.
• Daudzās ierīcēs trūkst CallScreeningService
  • Android lietotnes var ieviest CallScreeningService API lai pārtvertu jaunus ienākošos un izejošos zvanus, ļaujot tiem identificēt zvanītāju un pieņemt vai noraidīt zvanu. Lai gan šī ir oficiāli dokumentēta API, šķiet, ka daudzi oriģinālā aprīkojuma ražotāji to pareizi neievieš, norāda izstrādātājs /u/_zeromod_. Google apstiprina ka šo API ir apstiprinājis Compatibility Test Suite (CTS) — automatizēta testa komplekts, kas ir jānokārto visām ierīcēm, lai tās uzskatītu par saderīgām ar Android. Jebkura iemesla dēļ šī API atgriež nulli, kad tā tiek izsaukta ierīcēs no oriģinālā aprīkojuma ražotājiem, piemēram, Huawei, Vivo, Xiaomi vai Samsung, tāpēc, visticamāk, šo OEM programmatūrā ir kļūda.
• Nav plānu audio spraudņa ietvaram
  • Izstrādātājs jautāja Google, vai viņi plāno ieviest audio spraudņu sistēmu, piemēram, Apple audio vienības, bet atbilde ir maz ticams, ka tas notiks tuvākajā nākotnē.

Varat izlasīt visas Android inženieru komandas atbildes šeit. Komanda dažos komentāros nedaudz runā par Java, Kotlin, Android veidošanas sistēmu, CameraX API un citām tēmām. Ir arī vairāki komentāri par Wear OS, Android TV un Android Auto, taču Google lielākoties atkārto savu pašreizējo darbu šajās platformās un liek izstrādātājiem sekot līdzi plašākai informācijai "Android ārpus tālruņiem" nedēļa, kas sākas 10. augustā.