Android 11 AMA: Ingen rullende skjermbilder, raskere appstarter, mer

I går slapp Google Android 11 Beta 2, som bringer den ferdige SDK, NDK, app-vendte overflater, plattformatferd og begrensninger på ikke-SDK-grensesnitt for utviklere. I dag svarer Google på spørsmål knyttet til Android 11 på Reddits /r/AndroidDev-fellesskap etter å ha stilt spørsmål forrige uke. Her er et sammendrag av alt vi lærte fra Googles AMA (Ask Me Anything).

En av Android 11s mest etterlengtede funksjoner vil ikke være tilgjengelig når operativsystemet avslutter betaversjonen 8. september: Rulle skjermbilder. I utgangspunktet planlagt lansering i Android 11, har Google nå bekreftet at funksjonen "ikke gjorde snittet for R." Android 11 Developer Preview 1 og alle påfølgende DP- og Beta-utgivelser har en plassholderknapp for å ta et rulleskjermbilde som kan være dukket opp manuelt med en skjult utviklerkommando, men å trykke på knappen viser ganske enkelt en skålmelding som sier at funksjonen "ikke er implementert."

Vi håpet at funksjonen ville komme inn i en beta eller til og med bare den stabile utgivelsen, men det ser ut til at det ikke vil skje.

Denne nyheten vil forståelig nok være opprørende for noen brukere. Tross alt har mange OEM-er hatt denne funksjonen i sin egen programvare i årevis, så hva tar Google så lang tid å legge den til Pixel-telefoner? Som forklart av Dan Sandler fra Googles System UI-team, er problemet at Google ønsker å gjøre det riktig. Noen rullende skjermdumpimplementeringer der ute emulerer ganske enkelt en rulling og syr deretter sammen flere skjermbilder mens skjermen beveger seg. Hvis du noen gang har jobbet med UI-automatisering på Android, vil du vite at dette ikke alltid fungerer siden, som Mr. Sandler nevner, apper kan bruke "en myrstandard RecyclerView eller ha implementert sin egen OpenGL-akselererte rullemotor." Siden Google planlegger å implementere denne funksjonen for ikke bare Pixel-smarttelefoner, men for hele Android-økosystemet som en del av AOSP, må de sørge for det vil fungere alle apper og ikke bare «en eller to håndplukkede apper på en bestemt enhet».

Fordi teamet måtte "fokusere [sine] begrensede ressurser", spesielt på grunn av utfordringene av COVID-19 bestemte teamet seg for å legge rullende skjermbilder på bakbrenneren for en fremtidig Android-utgivelse.

Nytt CDD-krav for å informere brukere om bakgrunnsbegrensninger

Det er ingen hemmelighet at mange Android OEM-er, spesielt kinesiske, har aggressive restriksjoner på apper som kjører i bakgrunnen. Noen utviklere var så frustrerte over at appene deres ble drept i bakgrunnen at de slo seg sammen for å lage et nettsted kalt "Ikke drep appen min" å rangere OEM-er basert på hvor dårlig de håndterer bakgrunnsappprosesser. De samme utviklerne selv nylig laget en benchmark slik at brukere kan teste hvor aggressivt enheten deres dreper apper i bakgrunnen. Grunnen til at mange OEM-er elsker å drepe bakgrunnsappprosesser er komplisert, men jeg tror det er best forklart i denne kommentaren av Redditor /u/muligens tvilsomt. Kommentaren skisserer den kompliserte statusen for Android-apputvikling i Kina, hvordan kinesiske teknologiselskaper er med på å komplisere ting ytterligere, og hvordan mangel på Google-tjenester bidrar til det pågående rot.

Uansett er mange apputviklere forståelig nok frustrerte over disse tilpasningene til Android-plattformadferden, noe som har resultert i at utviklere har presset en kommentar spør Google hva de gjør med det til toppen av Reddit AMA. Her er Googles svar:

Det er et par ting å ta med seg fra dette svaret. For det første vil Google at OEM-er skal være mer transparente med brukerne om bakgrunnsapprestriksjonene de bruker. Jeg sjekket (ikke-utgitt) Android 11 Compatibility Definition Document (CDD) og fant følgende foreslåtte tillegg til Seksjon 3.5 - API Behavioral Compatibility:

Hvis enhetsimplementeringer implementerer proprietær mekanisme for å begrense apper og den mekanismen er mer restriktiv enn "Sjelden" standby-bøtte på AOSP, gjør de:

[C-1-5] MÅ informere brukere om apprestriksjoner påføres en app automatisk. (NY) Slik informasjon MÅ ikke gis tidligere enn 24 timer før slike restriksjoner tas i bruk.

(Merk) Force Stop anses å være mer restriktiv enn "Sjelden" og MÅ overholde alle krav under 3.5.1, inkludert ny 3.5.1/C-1-5

I utgangspunktet er ikke Google mye for å stoppe OEM-er fra å implementere sine egne restriktive app-drepende funksjoner. De krever bare at OEM-er informerer brukerne om apprestriksjonene deres blir brukt automatisk. En OEM kan vise en dialogboks at de kommer til å stoppe batterisugende bakgrunnsapper fra å kjøre i bakgrunn, og brukeren kan samtykke uten å innse hvilke apper de virkelig ønsker å kjøre i bakgrunnen også er berørt! Google legger ansvaret på utviklere for å håndtere tilfeller der appen deres uventet blir drept i bakgrunnen. Faktisk fortsetter Reddit-kommentaren for å fremheve den nye "årsaker til avslutning av appprosessen" API som kan fortelle utviklere om appen deres ble drept av brukeren, operativsystemet, eller om den rett og slett krasjet.

På den annen side tar Google endelig opp den urettferdige praksisen til OEM-er som lar visse privilegerte applikasjoner omgå begrensningene deres for bakgrunnsapper. Dette Medium-innlegget av utvikler Timothy Asiimwe går i detalj om apper som WhatsApp, Facebook og andre apper er automatisk unntatt fra de harde bakgrunnsbegrensningene til noen OEM-programvare. Google sier at de "krever at enhetsprodusenter ikke oppretter tillatelseslister for de beste appene." Vi vet ikke hvordan dette vil bli håndhevet, men det er godt å vite at OEM-er endelig vil bli tvunget til å behandle tredjepartsutviklere på lik linje – uansett hvor store eller små appene deres er. er.

Til slutt nevner Google også hvordan Android 11 har "lagt til ekstra tiltak for å forhindre misbruk av apper", noe som gjør det mindre fristende for OEM-er å aggressivt drepe bakgrunnsprosesser. Selskapet har imidlertid ikke utdypet hva disse «ekstratiltakene» innebærer.

Forbedrede enhet-til-enhet-sikkerhetskopier

Forrige måned så vi en endring i Android 11s dokumentasjon som antydet støtte for bedre lokal sikkerhetskopiering av data. I Android 11 vil systemet se bort fra allowBackup Manifest-attributtet for enhver app som er målrettet mot API-nivå 30 når brukeren starter en "enhet-til-enhet"-migrering av appfiler. Googler Eliot Stock sier at denne funksjonen er ment å gjøre det "mye enklere for telefonprodusenter å bygge enhet til enhet migreringsverktøy" som "Samsungs utmerkede Smart Switch-produkt" til bidra til å "sikre apper mer pålitelig overføring mellom enheter fra et brukerperspektiv." Dessverre gjelder dette ikke skybaserte sikkerhetskopier, da Google ønsker å "gi programvareutviklere kontroll over hva skjer med appdataene deres." Som sådan vil Android 11 fortsatt respektere allowBackup-attributtet for all skybasert sikkerhetskopiering og gjenoppretting, for eksempel gjennom Google Play-tjenestens innebygde Google Disk backup. Til slutt erkjenner Google at sikkerhetskopieringstaket på 25 MB per app kanskje ikke er nok for enkelte utviklere, så de ser etter måter å løse det på. Lokale sikkerhetskopier til en PC vurderes imidlertid ikke, og Google gjentar planen deres fase ut adb backup i en fremtidig Android-utgivelse.

Utviklere oppfordres til å implementere friksjonsfrie datamigreringsmetoder. De nytt Block Store-bibliotek, som er en del av Google Identity Services Library, er designet for å gjøre det enklere å logge på apper som er gjenopprettet fra skyen på nye enheter, men det er opp til utviklere å velge om de vil implementere dette eller ikke bibliotek.

Raskere appoppstartshastigheter med I/O Read Ahead Process (IORap)

Google eksperimenterer alltid med måter å forbedre ytelsen i Android. En av de lite kjente funksjonene de la til i Android 10 kalles Unspecialized App Process Pool (USAP). Denne funksjonen eliminerer forking av Zygote under appoppstartsprosessen, og sparer omtrent 5 ms i gjennomsnittlig appoppstartshastighet på en Pixel 2-enhet. Funksjonen er for øyeblikket deaktivert som standard i AOSP, og Google forklarer at den ekstra minnebruken fortsatt må testes. Det som imidlertid er mer interessant, er en ny funksjon som kommer til Android 11 kalt I/O Read Ahead Process (IORap). Ifølge Google, vil denne funksjonen føre til "mer enn 5 % raskere kald oppstart med heltesaker som når 20 % raskere." Denne funksjonen "vil forhåndshente appartefakter (som kode og ressurser) under oppstartsprosessen" for å øke appstarten hastigheter.

Google har også "gjort forbedringer av profilene som brukes for å optimalisere oppstartsklassens banen og systembildet" som vil forbedre appytelsen og redusere minne- og lagringskostnadene knyttet til systemet gjenstander. Disse endringene vil for det meste være til fordel for enheter med større mengder RAM, selv om Google ikke har sagt hva grensen er for hvor vi vil se de fleste fordelene.

Android 11s Scoped Storage-endringer – Hvorfor er tilgangen til /Nedlastinger begrenset?

Apper som er målrettet mot Android 11 og bruker ACTION_OPEN_DOCUMENT_TREE-hensikten for å be om tilgang til spesifikke kataloger på den eksterne lagring vil ikke lenger kunne be brukere om tilgang til rotkatalogen til den eksterne lagringen (/data/media/{bruker}), nedlastingen katalog (/data/media{user}/Download), eller noen av de appspesifikke datakatalogene på den eksterne lagringen (/Android/data eller /Android/obb). Hvorfor er tilgangen til nedlastingskatalogen begrenset? Ifølge Google Roxanna Aliabadi, er det fordi nedlastingsmappen "er størst risiko for å ha privat informasjon." Som et eksempel, brukere som laster ned skatten sin returer eller kontoutskrifter bør ikke bekymre deg for muligheten for at apper misbruker sin kontinuerlige lesetilgang til katalog. Google sier at dokumentvelgeren vil ha "oppdatert tekst... for å indikere at Android har begrenset visse mapper for å bli valgt." Dette vil forhåpentligvis redusere forvirringen om hvorfor de ikke kan gi apper tilgang til visse kataloger lenger.

For mer informasjon om de kommende endringene i retningslinjene for lagring og spill med omfang, referer til denne artikkelen.

Diverse emner

• Googles holdning til rooting/modding
  • Jeff Bailey fra Googles AOSP-team gjentar selskapets holdning til å støtte valg. Google vil «fortsette å sikre at modding/rooting av Pixel-enhetene er mulig», men vil også «støtte valget av OEM-er om å ikke tillate enhetene deres å være forankret." Videre gir Google programvareutviklere valget "å ikke la programvaren deres kjøre på rotfestede enheter," med henvisning til nylige endringer i deteksjon av programvaremanipulering av SafetyNet Attestation API.
• Hva skjedde med "åpne og satt til standard"?
  • Android 10 laget det er litt irriterende å sette en app som standardbehandler for spesifikke lenker, som Google sier ble gjort for å beskytte brukere mot «utnyttende apper». Google trakk seg tilbake på denne endringen etter å ha revurdert den, foreta en "antall endringer bak kulissene" for å beskytte brukeren.
• Bruker du Vulkan Graphics API for å gjengi brukergrensesnittet?
  • Google planlegger etter hvert å bruke Vulkan Graphics API for å gjengi brukergrensesnittet, som vil gi noen ytelsesforbedringer. Dette er blir fortsatt evaluert, men selskapet hadde ingen detaljer å dele.
• Mangler CallScreeningService på mange enheter
  • Android-apper kan implementere CallScreeningService API for å avlytte nye innkommende og utgående anrop, slik at de kan identifisere den som ringer og enten godta eller avvise anropet. Selv om dette er et offisielt dokumentert API, er det tilsynelatende mange OEM-er som ikke implementerer det ordentlig, ifølge utvikleren /u/_zeromod_. Google bekrefter at denne API-en er validert av Compatibility Test Suite (CTS), en automatisert testsuite som alle enheter må bestå for å anses som Android-kompatibel. Uansett grunn, returnerer denne API-en null når den kalles på enheter fra OEM-er som Huawei, Vivo, Xiaomi eller Samsung, så det er sannsynlig at disse OEM-ene har en feil i programvaren.
• Ingen planer for et lydplugin-rammeverk
  • En utvikler spurte Google om de planlegger å implementere et lydplugin-rammeverk som Apples lydenheter, men svaret er at det neppe vil skje i nær fremtid.

Du kan lese alle svarene fra Android-ingeniørteamet her. Teamet snakker litt om Java, Kotlin, Android-byggesystemet, CameraX API og andre emner i noen få kommentarer. Det er også flere kommentarer om Wear OS, Android TV og Android Auto, men Google gjentar stort sett deres eksisterende arbeid på disse plattformene og ber utviklere å følge med for mer informasjon i løpet av "Android Beyond Phones" uke som starter 10. august.