Android 11 AMA: Ei rullaavia kuvakaappauksia, nopeammat sovellusten käynnistykset ja paljon muuta

Eilen Google julkaisi Android 11 Beta 2, joka tuo viimeistellyt SDK: n, NDK: n, sovelluksiin päin olevat pinnat, alustan käyttäytymisen ja rajoituksia ei-SDK-rajapinnoille kehittäjille. Tänään Google vastaa Android 11:een liittyviin kysymyksiin Redditin /r/AndroidDev-yhteisössä viime viikolla esitettyjen kysymysten jälkeen. Tässä on yhteenveto kaikesta, mitä opimme Googlen AMA: sta (Ask Me Anything).

Yksi Android 11:n odotetuimmista ominaisuuksista ei ole käytettävissä, kun käyttöjärjestelmä poistuu betasta 8. syyskuuta: Rullaavat kuvakaappaukset. Aluksi suunniteltu julkaistavaksi Android 11:ssä, Google on nyt vahvistanut, että ominaisuus "ei tehnyt leikkausta R: lle." Android 11 Developer Preview 1 ja kaikissa myöhemmissä DP- ja Beta-julkaisuissa on paikkamerkkipainike vierivän kuvakaappauksen ottamista varten

käsin esiin piilotetulla kehittäjäkomennolla, mutta painikkeen napauttaminen näyttää yksinkertaisesti maljaviestin, jossa todetaan, että ominaisuutta ei ole otettu käyttöön.

Toivoimme, että ominaisuus pääsisi betaversioon tai jopa vain vakaaseen julkaisuun, mutta näyttää siltä, ​​että niin ei vain tapahdu.

Tämä uutinen on ymmärrettävästi järkyttävä joillekin käyttäjille. Loppujen lopuksi monilla OEM-valmistajilla on ollut tämä ominaisuus omassa ohjelmistossaan vuosia, joten miksi Googlelta kestää niin kauan lisätä se Pixel-puhelimiin? Kuten Dan Sandler Googlen System UI -tiimistä selittää, ongelma on, että Google haluaa tehdä sen oikein. Jotkut vierittävät kuvakaappaustoteutukset yksinkertaisesti jäljittelevät vieritystä ja yhdistävät sitten useita kuvakaappauksia näytön liikkuessa. Jos olet koskaan käsitellyt käyttöliittymän automatisointia Androidissa, tiedät, että tämä ei aina toimi, koska, kuten herra Sandler mainitsee, sovellukset voivat käyttää "suon standardia RecyclerView'ta tai ottaa käyttöön oman OpenGL-kiihdytetyn vieritysmoottorin". Koska Google suunnittelee ottaa tämä ominaisuus käyttöön Pixel-älypuhelimien lisäksi koko Android-ekosysteemissä osana AOSP: tä, heidän on varmistettava, että se toimii kaikki sovelluksia eikä vain "yhtä tai kahta käsin valittua sovellusta tietyllä laitteella".

Koska tiimin täytyi "keskittää [rajalliset] resurssinsa" erityisesti tuomien haasteiden vuoksi COVID-19:n vuoksi tiimi päätti laittaa vieriviä kuvakaappauksia backburneriin tulevaa Android-julkaisua varten.

Uusi CDD-vaatimus ilmoittaa käyttäjille taustarajoituksista

Ei ole mikään salaisuus, että monilla Android OEM-valmistajilla, erityisesti kiinalaisilla, on aggressiivisia rajoituksia taustalla toimiville sovelluksille. Jotkut kehittäjät olivat niin turhautuneita sovellusten taustalla tappamiseen, että he yhdistivät yhteen verkkosivuston nimeltä "Älä tapa sovellustani" määrittää OEM-valmistajat sen perusteella, kuinka huonosti ne käsittelevät taustasovellusprosesseja. Samat kehittäjät jopa äskettäin tehty vertailukohta jotta käyttäjät voivat testata, kuinka aggressiivisesti heidän laitteensa tappaa sovelluksia taustalla. Syy, miksi monet OEM-valmistajat rakastavat taustasovellusprosessien tappamista, on monimutkainen, mutta mielestäni se selittyy parhaiten tässä Redditorin kommentissa /u/mahdollisesti kyseenalaista. Kommentti hahmottelee Android-sovelluskehityksen monimutkaisen tilan Kiinassa, miten kiinalaiset teknologiayritykset ovat mukana mutkistamassa asioita entisestään ja miten Google-palvelujen puute vaikuttaa meneillään olevaan sotku.

Siitä huolimatta monet sovelluskehittäjät ovat ymmärrettävästi turhautuneita näistä Android-alustan käyttäytymiseen tehtävistä parannuksista, jotka ovat johtaneet siihen, että kehittäjät ovat kommentoineet kysyä Googlelta, mitä he tekevät asialle Reddit AMA: n alkuun. Tässä Googlen vastaus:

Tästä vastauksesta on otettava pois muutama seikka. Ensinnäkin Google haluaa OEM-valmistajien kertovan käyttäjille avoimemmin soveltamistaan ​​taustasovellusrajoituksista. Tarkistin (julkaisemattoman) Android 11 Compatibility Definition Documentin (CDD) ja löysin seuraavan ehdotetun lisäyksen kohtaan 3.5 - API Behavioral Compatibility:

Jos laitetoteutukset käyttävät patentoitua mekanismia sovellusten rajoittamiseksi ja tämä mekanismi on rajoittavampi kuin AOSP: n "harvinainen" valmiustilaryhmä, ne:

[C-1-5] TÄYTYY ilmoittaa käyttäjille, jos sovelluksen rajoituksia sovelletaan automaattisesti. (UUSI) Tällaisia ​​tietoja PITÄÄ toimittaa aikaisintaan 24 tuntia ennen rajoitusten soveltamista.

(Huomautus) Force Stop katsotaan rajoittavammaksi kuin "harvinainen" ja TÄYTYY täyttää kaikki kohdan 3.5.1 vaatimukset, mukaan lukien uusi 3.5.1/C-1-5

Pohjimmiltaan Google ei estä OEM-valmistajia ottamasta käyttöön omia rajoittavia sovellusten tappamisominaisuuksia. Ne edellyttävät vain, että OEM-valmistajat ilmoittavat käyttäjille, jos heidän sovellusrajoituksiaan sovelletaan automaattisesti. OEM voi näyttää valintaikkunan, jossa he aikovat lopettaa akkua imevien taustasovellusten toiminnan taustalla, ja käyttäjä voi antaa suostumuksensa ymmärtämättä, mitä sovelluksia hän todella haluaa käyttää taustalla vaikuttaa! Google asettaa kehittäjien vastuulle tapaukset, joissa heidän sovelluksensa tapetaan odottamatta taustalla. Todellakin, Reddit-kommentti korostaa uutta "sovellusprosessin poistumissyistä" API, joka voi kertoa kehittäjille, tappoiko käyttäjä, käyttöjärjestelmä heidän sovelluksensa vai kaattiko se vain.

Toisaalta Google on vihdoin puuttumassa OEM-valmistajien epäreiluun käytäntöön, jonka mukaan tietyt etuoikeutetut sovellukset voivat ohittaa taustasovellusrajoituksensa. Tämä Medium-postaus kehittäjältä Timothy Asiimwe käsittelee yksityiskohtaisesti sovelluksia, kuten WhatsApp, Facebook ja muut sovellukset, jotka vapautetaan automaattisesti joidenkin OEM-ohjelmistojen ankarista taustarajoituksista. Google sanoo, että ne "vaativat, että laitevalmistajat eivät luo sallittuja luetteloita suosituimmille sovelluksille". Emme tiedä kuinka tämä pannaan täytäntöön, mutta on hyvä tietää, että OEM-valmistajat joutuvat vihdoinkin kohtelemaan kolmannen osapuolen kehittäjiä tasavertaisesti – olivatpa heidän sovelluksensa kuinka suuria tai pieniä ovat.

Lopuksi Google mainitsee myös, kuinka Android 11 on "lisänyt ylimääräisiä toimenpiteitä väärinkäyttävien sovellusten väärinkäytön estämiseksi", mikä tekee OEM-valmistajista vähemmän houkuttelevaa tappaa taustaprosesseja aggressiivisesti. Yhtiö ei kuitenkaan tarkentanut, mitä nämä "lisätoimenpiteet" sisältävät.

Parannetut laitteiden väliset varmuuskopiot

Viime kuussa havaitsimme muutoksen Android 11:n dokumentaatiossa vihjasi tuesta paremmille paikallisille tietojen varmuuskopioille. Android 11:ssä järjestelmä jättää huomioimatta allowBackup Manifest -attribuutin kaikissa sovelluksissa, jotka kohdistavat API-tasolle 30, kun käyttäjä aloittaa sovellustiedostojen siirron laitteelta laitteelle. Googlen työntekijä Eliot Stock sanoo, että tämän ominaisuuden tarkoituksena on tehdä "paljon helpommaksi puhelinvalmistajien rakentaa laitteiden välisiä siirtotyökaluja", kuten "Samsungin erinomainen Smart Switch -tuote". auttaa "varmistamaan, että sovellukset siirtyvät luotettavammin laitteiden välillä käyttäjän näkökulmasta". Valitettavasti tämä ei koske pilvipohjaisia ​​varmuuskopioita, koska Google haluaa "antaa ohjelmistokehittäjille hallinnan siitä, mitä tapahtuu heidän sovellustietojensa kanssa." Sellaisenaan Android 11 noudattaa edelleen allowBackup-attribuuttia kaikissa pilvipohjaisissa varmuuskopioissa ja palautuksissa, kuten Google Play -palvelun sisäänrakennetun Google Driven kautta. varmuuskopioida. Lopuksi Google myöntää, että 25 Mt: n sovelluskohtainen varmuuskopiointi ei ehkä riitä joillekin kehittäjille, joten he etsivät tapoja ratkaista ongelma. Paikallisia varmuuskopioita PC: lle ei kuitenkaan harkita, ja Google toistaa suunnitelmansa adb-varmuuskopiointi vaiheittain tulevassa Android-julkaisussa.

Kehittäjiä rohkaistaan ​​ottamaan käyttöön kitkattomia tiedonsiirtomenetelmiä. The uusi Block Store -kirjasto, joka on osa Google Identity Services -kirjastoa, on suunniteltu helpottamaan palautettuihin sovelluksiin kirjautumista pilvestä uusilla laitteilla, mutta kehittäjät voivat valita, haluavatko he toteuttaa tämän vai eivät kirjasto.

Nopeammat sovelluksen käynnistysnopeudet I/O-etulukuprosessilla (IORAp)

Google kokeilee jatkuvasti tapoja parantaa suorituskykyä Androidissa. Yksi vähän tunnetuista ominaisuuksista, jotka he lisäsivät Android 10:een, on nimeltään Unspecialized App Process Pool (USAP). Tämä ominaisuus eliminoi Zygoten haaroittamisen sovelluksen käynnistysprosessin aikana, mikä säästää noin ~5 ms sovelluksen keskimääräisissä käynnistysnopeuksissa Pixel 2 -laitteella. Ominaisuus on tällä hetkellä oletuksena poistettu käytöstä AOSP: ssä, ja Google selittää, että sen lisämuistin käyttöä on vielä testattava. Mielenkiintoisempaa on kuitenkin Android 11:een tulossa uusi ominaisuus nimeltä I/O Read Ahead Process (IORap). Googlen mukaan, tämä ominaisuus johtaa "yli 5 % nopeampiin kylmäkäynnistyksiin ja sankaritapaukset saavuttavat 20 % nopeamman". Tämä ominaisuus "hakee valmiiksi sovellusten artefakteja (kuten koodia ja resursseja) käynnistysprosessin aikana" tehostaakseen sovelluksen käynnistämistä nopeudet.

Google on myös "tehnyt parannuksia profiileihin, joita käytetään käynnistysluokan polun ja järjestelmäkuvan optimointiin" mikä parantaa sovelluksen suorituskykyä ja vähentää järjestelmään liittyviä muisti- ja tallennuskustannuksia esineitä. Nämä muutokset hyödyttävät enimmäkseen laitteita, joissa on enemmän RAM-muistia, vaikka Google ei ole kertonut, mikä on raja, jossa näemme eniten etuja.

Android 11:n laajennetun tallennustilan muutokset – Miksi pääsyä /Latauksiin on rajoitettu?

Sovellukset, jotka on kohdistettu Android 11:een ja jotka käyttävät ACTION_OPEN_DOCUMENT_TREE-tarkoitusta pyytääkseen pääsyä tiettyihin ulkoisen laitteen hakemistoihin tallennustila ei voi enää pyytää käyttäjiltä pääsyä ulkoisen tallennustilan (/data/media/{user}) juurihakemistoon. hakemistoon (/data/media{user}/Download) tai mihin tahansa sovelluskohtaiseen tietohakemistoon ulkoisessa tallennustilassa (/Android/data tai /Android/obb). Miksi pääsyä lataushakemistoon on rajoitettu? Googlen mukaan Roxanna Aliabadi, se johtuu siitä, että latauskansio "on suurin riski saada yksityisiä tietoja." Esimerkkinä käyttäjät, jotka lataavat veronsa palautusten tai tiliotteiden ei pitäisi joutua huolehtimaan mahdollisuudesta, että sovellukset käyttävät väärin jatkuvaa lukuoikeuttaan hakemistosta. Google sanoo, että asiakirjavalitsimella on "päivitetty teksti..." osoittamaan, että Android on rajoittanut tiettyjä kansioita valitaan." Tämä toivottavasti vähentää hämmennystä siitä, miksi he eivät voi myöntää sovelluksille pääsyä tiettyihin hakemistoihin enää.

Saat lisätietoja tulevista Scoped Storage and Play -käytäntöjen muutoksista: katso tämä artikkeli.

Muut aiheet

• Googlen kanta juurtumiseen/muokkaamiseen
  • Jeff Bailey Googlen AOSP-tiimistä toistaa yrityksen kannan tukea valintaa. Google "varmistaa jatkossakin, että Pixel-laitteiden modifiointi/roottaminen on mahdollista", mutta tukee myös "OEM-valmistajien valintaa olla sallimatta laitteitaan Lisäksi Google antaa ohjelmistokehittäjille mahdollisuuden "eivät salli ohjelmistojensa toimia juurtuneilla laitteilla" viitaten viimeaikaisiin muutoksiin Ohjelmiston peukaloinnin havaitseminen SafetyNet Attestation API: ssa.
• Mitä tapahtui "avaa ja aseta oletukseksi" -toiminnolle?
  • Android 10 tehty on hieman ärsyttävää asettaa sovellus oletuskäsittelijäksi tietyille linkeille, mikä Googlen mukaan tehtiin käyttäjien suojelemiseksi "riistosilta sovelluksilta". Google perääntyi tätä muutosta harkittuaan sitä uudelleen ja tekemällä "muutoksia kulissien takana" käyttäjän suojelemiseksi.
• Käytätkö Vulkan Graphics -sovellusliittymää käyttöliittymän hahmontamiseen?
  • Google aikoo lopulta käyttää Vulkan Graphics API hahmontaa käyttöliittymän, mikä parantaa suorituskykyä. Tämä on vielä arvioitava, mutta yrityksellä ei ollut mitään yksityiskohtia kerrottavana.
• CallScreeningService puuttuu monista laitteista
  • Android-sovellukset voivat toteuttaa CallScreeningService API siepata uudet saapuvat ja lähtevät puhelut, jolloin he voivat tunnistaa soittajan ja joko hyväksyä tai hylätä puhelun. Vaikka tämä on virallisesti dokumentoitu API, ilmeisesti monet OEM-valmistajat eivät ota sitä käyttöön oikein, kehittäjän /u/ mukaan._zeromod_. Google vahvistaa että tämän sovellusliittymän on validoinut Compatibility Test Suite (CTS), automaattinen testipaketti, joka kaikkien laitteiden on läpäistävä, jotta niitä voidaan pitää Android-yhteensopivina. Jostain syystä tämä API palauttaa nollan, kun sitä kutsutaan Huawein, Vivon, Xiaomin tai Samsungin kaltaisten OEM-laitteiden laitteille, joten on todennäköistä, että näiden OEM-laitteiden ohjelmistoissa on virhe.
• Ei suunnitelmia äänilaajennuskehyksestä
  • Kehittäjä kysyi Googlelta, aikovatko he ottaa käyttöön äänilaajennuskehyksen, kuten Applen ääniyksiköt, mutta vastaus se on epätodennäköistä, että se tapahtuu lähitulevaisuudessa.

Voit lukea kaikki Androidin suunnittelutiimin vastaukset tässä. Tiimi puhuu hieman Javasta, Kotlinista, Android-rakennusjärjestelmästä, CameraX API: sta ja muista aiheista muutamassa kommentissa. Wear OS: stä, Android TV: stä ja Android Autosta on myös useita kommentteja, mutta Google enimmäkseen toistaa heidän nykyisen työnsä näillä alustoilla ja kehottaa kehittäjiä pysymään kuulolla saadaksesi lisätietoja "Android Beyond Phones"viikko alkaa 10. elokuuta.