Android Q AMA Sammendrag: Hva Google sa om Android 10 på Reddit

I fjor var Googles Android-team vertskap for en Ask Me Anything (AMA) på Reddits /r/AndroidDev-subreddit for å stille spørsmål om Android P-utviklerforhåndsvisning. I år svarte ingeniørteamet som jobber med Android Q beta på spørsmål på Reddit. AMA startet 1. august kl. 12:00 PST og ble avsluttet omtrent halvannen time senere. 33 Google-ingeniører var involvert i AMA, og svarte på massevis av spørsmål på den korte tiden AMA varte. Her er oppsummeringen av all den nye informasjonen vi har lært.

Android Q AMA: Alt vi lærte av Google

Deltakere fra Android Q beta-teamet

• Adam Cohen: TLM på Android Launcher / System UI
• Adam Powell: TLM på UI-verktøysett/rammeverk; visninger, livssyklus, fragmenter, støttelibs
• Alan Viverette: TLM, Jetpack / AndroidX
• Allen Huang: PM for UI, launcher, varsler, søkeintegrasjoner og mer!
• Andrew Sappirstein: TLM på Android-innstillinger
• Brahim Elbouchikhi: PM Director for Android Machine Learning and Camera (NN API, ML Kit, CameraX, Camera Platform)
• Chad Brubaker: Programvareingeniør, Android Platform Security
• Charmaine D’Silva: PM for personvern
• Chet Haase: Android Chief Advocate, Developer Relations
• Diana Wong: PM, appkompatibilitet, ikke-SDK API-bruk, ART, NDK
• Dianne Hackborn: Leder for Android-rammeteamet (Ressurser, Window Manager, Activity Manager, Multi-user, Printing, Accessibility, etc.)
• E.K. Chung: Direktør for UX
• Ian Lake: Programvareingeniør, Jetpack (fragmenter, navigasjon, arkitekturkomponenter)
• Iliyan Malchev: Hovedprogramvareingeniør, Project Mainline
• Jacob Lehrbaum: Direktør for utviklerrelasjoner for Android
• Jake Wharton: Programvareingeniør, Jetpack
• Jamal Eason: PM, Android Studio
• Jeff Bailey: TLM, Android Open Source Project (AOSP)
• Jeff Sharkey: Programvareingeniør, Android Framework
• Jeffrey van Gogh: Android Studio, kompilatorer
• Jen Chai: PM, Plassering og kontekst, Auth, Autofyll, ikke-SDK API-bruk, ART
• Karen Ng: Gruppe-PM for Android-utviklerverktøy, Android Studio, Android Tookit og Jetpack
• Paul Bankhead: Direktør for produktadministrasjon, Google Play
• Rohan Shah: Produktsjef, Android System UI
• Romain Guy: Leder for Android Toolkit/Jetpack-teamet
• Sagar Kamdar: Direktør for produktledelse, Android
• Lør K: Director of Engineering, Android Connectivity
• Selim Cinek: Programvareingeniør, Android System UI
• Stephanie Saad Cuthbertson: Seniordirektør for produktledelse, Android
• Sumir Kataria: Programvareingeniør, Jetpack (WorkManager)
• Travis McCoy: PM, Android-plattform
• Trystan Upstill: Utmerket ingeniør, ledende for Android System UI & Intelligence
• Vinit Modi: PM, Android-kamera

Les mer

OEM-er kan ikke lenger drepe apper når brukeren sveiper dem bort i de siste

Hvis du noen gang har brukt en smarttelefon fra et kinesisk merke, så har du sannsynligvis jobbet med irriterende "batterioptimalisering"-funksjoner som drep alle favorittappene dine i bakgrunnen. Ikke bare er denne oppførselen irriterende for brukere som forventer at enkelte apper fortsetter å kjøre i bakgrunnen uansett årsak, men det er også irriterende for utviklere som må lide dårlige anmeldelser fra brukere som ikke forstår at det ikke er appens feil. Mens Google er det fortsatt ikke fullstendig adressert denne saken (de håndviftet problemet bort ved å si at denne oppførselen er det sannsynligvis allerede i strid med kravene til Android Compatibility Definition Document), selskapet er handle mot en "batterisparende" atferdsendring brukt av noen OEM-er.

"For å hjelpe med situasjonen har vi lagt til en CTS-test i Android Q for å sikre at en app ikke blir drept når den blir sveipet fra Recents."

Android R kan gi flere endringer i skjermbilder enn vi forventet

Google planlegger å legge til rullende skjermbilder i Android R, men samtidig Android-teamet er "tar en nærmere titt på hvordan [de] kan forbedre hele skjermen-[X]-opplevelsen for R." Dermed kan vi se andre forbedringer av oppførselen til skjermdumpen (OG screencast) i den neste store Android-versjonen.

Klargjøring av Android Qs nye skrivebordsmodus

De første offentlige betaversjon av Android Q brakte et skjult grensesnitt for skrivebordsmodus til AOSP og Pixel Launcher. Selv om Google berørte kort innslaget under en Google I/O-økt har vi aldri hørt direkte fra Google hvordan den nye funksjonen passer inn i Android-økosystemet. Google avklarer nå:

"I Q AOSP er 'skrivebordsmodus' et utvikleralternativ rettet mot applikasjonsutviklere. Det lar dem teste appene sine i flerskjerms- og friformsvindumodusmiljøer. Tidligere var det ingen praktisk måte å teste app-oppførsel på en sekundær skjerm og med vinduer som kan endres fritt på lager Android. Denne funksjonen produseres ikke alene og er ikke ment for vanlige brukere for øyeblikket. Ikke desto mindre er det grunnlinjen til Android-plattformen for OEM-er å innovere og lage flotte produkter."

Dermed kan vi forvente å se OEM-er bygge på Android Qs opprinnelige skrivebordsmodus. For eksempel OnePlus 7 Pro støtter skjerm ut over HDMI, så det er mulig det OxygenOS 10 basert på Android Q vil ha sitt eget grensesnitt for skrivebordsmodus i fremtiden. Vi håper også at Google bygger videre på funksjonen for den kommende tiden Pixel 4.

Tidsbasert mørk modus

Android Q kommer endelig med en mye etterspurt funksjon: mørk modus for hele systemet. For øyeblikket kan den mørke modusen enten aktiveres manuelt i Innstillinger eller via en Hurtiginnstillinger-brikke, eller den kan aktiveres automatisk når batterisparing er aktivert. Før Android Q var det et alternativ for å aktivere mørk modus basert på tidspunktet på dagen, men det alternativet ble avviklet. I følge Chris Banes:

"Det er noen få grunner til at dette er utdatert (ikke fjernet) i AppCompat v1.1.0: det krever at apper ber om plasseringstillatelser skal være nøyaktige, og selv med en gyldig plassering kan soloppgangs-/solnedgangstidsberegningene buggy."

På spørsmål om disse feilene uttaler Mr. Banes at "beregning av soloppgang/solnedganger er notorisk vanskelig, spesielt for steder i nærheten av nord-/sørpoler." En bruker tar opp at nattlys, tilgjengelig siden Android 7.1 Nougat, kan veksles automatisk basert på solnedgang/soloppgang tidsplaner. Mr. Banes uttaler da at siden Night Light bruker CalendarAstronomer fra ICU4J, bruker den en "stor kodebit som vi ikke vil at AppCompat skal være avhengig av." Det gjør imidlertid laget stat at denne funksjonen er "noe [de] vil se nærmere på."

Obligatorisk Camera2 API/Camera HAL3-støtte for Android Q-startenheter

Google introduserte Camera2 API for å bedre definere hvordan apper kan samhandle med de individuelle kameraene som er koblet til smarttelefonen din. Mens Google oppmuntrer smarttelefonleverandører for å "eksponere alle sine fysiske kameraer for utviklere," mange leverandører velger å ikke gjøre det selv om "API i seg selv ikke er forhindrer dem i dag." Dette betyr at mange tredjeparts kameraapper ikke kan bruke de sekundære eller tertiære kameramodulene på moderne smarttelefoner. Det gjøres imidlertid fremskritt ettersom Android Q har blitt bedre LOGICAL_MULTI_CAMERA, et API som gir utviklere bedre tilgang til alle kameraer på en enhet og som gir OEM-er kontroll over strømforbruk og administrasjon av flere kameratilstander.

Videre sier Google at de har lagt til krav for alle enheter som lanseres med Android Q for å naturlig støtte Camera2 API/Camera HAL3. Ifølge Vinit Modi:

"Fra og med Android P kreves det nye enheter som sendes med 1 GB eller mer RAM for å kunne bruke HALv3/camera2. Android Q og utover må alle nye enheter ha innebygd støtte for HALv3/camera2. Dessverre er oppgraderinger fra HALv1 til HALv3 ganske komplekse over luften og kan ha uventede konsekvenser, derfor måtte vi begrense omfanget til nye enheter."

Interessant nok, Modis uttalelse om vanlige RAM Android P lanseringsenheter Motsier hva vi ble fortalt tidligere av Google og hva som er publisert på Image Test Suite-siden online.

Dynamisk app-tema med Jetpack Compose

Sonys OMS-temarammeverk ble lagt til AOSP en del utgivelser tilbake, men det er bare beregnet for OEM-er å bygge på. Det vet vi allerede Google er imot bruken av kjøretidsressursoverlegg av brukere til temaapper, men for utviklere er selskapet det håper det er Jetpack Compose UI rammeverket vil bringe frem "interessante tilnærminger til dynamisk tematikk."

Vulkan-backend for Skia for å gjengi brukergrensesnittet

I fjor, vi oppdaget en diskusjon blant Google-ingeniører som snakker om planene deres for å la Android-rammeverket bruke Vulkan graphics API for UI-gjengivelse. Mens det nå er mulig å aktivere Vulkan maskinvareakselerert backend uten telefonen din krasjer, har vi ikke hørt noen konkrete planer fra Google om når de planlegger å rulle ut disse Endringer. Denne AMA svarer ikke på det spørsmålet, men vi har i det minste bekreftet at det fortsatt er i arbeid. Ifølge Romain Guy:

"Teamet har jobbet med en Vulkan-backend for Skia, 2D-gjengivelsen som brukes av Android, men den er ikke aktivert som standard for øyeblikket. Brukergrensesnittet og Canvas går fortsatt gjennom OpenGL ES."

Gjør bevegelseslinjen til Android Q mer dynamisk

Noen på XDA mener fortsatt det Androids nye bevegelser er et rot, men jeg personlig synes de er fine. Hvis du leker litt med de nye bevegelsene i Android Q, vil du imidlertid legge merke til at bevegelseslinjen ikke beveger seg med fingeren. Den fester seg også på skjermer der den ikke er nødvendig, som startskjermen eller oversikt over nylige apper. Allen Huang sier at de er «helt enig i at det er muligheter» for å gjøre «navigasjonslinjen mindre statisk». sier han videre at "dette er noe vi jobber med - men også balansere slik at det ikke er distraherende dukker opp/forsvinner."

Forbedringer av lagringstilgangsrammeverket

De mange endringene i Android Q har betydelig forbedret sikkerhet og personvern for plattformen. En slik endring, kalt «Scoped Storage», begrenser appers tilgang til filer på den eksterne lagringen på en måte som gir mening; musikkapper skal for eksempel ikke trenge å se galleriet ditt. Filbehandlingsapper som kjører i Android Q må bruke en API kalt Storage Access Framework for å fortsette å fungere som normalt, men noen utviklere ser på dette API-et som dårligere til det som tidligere var tilgjengelig. Jeff Sharkey fra Google sier teamet har behandlet noen av disse utviklernes klager:

"Vi har gjort noen SAF-ytelsesforbedringer i de siste Android Q Beta-utgivelsene; kan du sjekke referansene dine mot den siste betaversjonen? Sørg også for at du bruker en ContentProviderClient når du kjører masseoperasjoner."

Project Treble forbedret Android Pie-adopsjon kontra Android Oreo

Vi har allerede sett hvordan Project Treble, en stor lavnivå-rearkitektering av Android-rammeverket, har forbedret bruken av nyere Android OS-versjoner. Google krediterer Treble bak mengden av smarttelefonleverandører som slutter seg til Android P beta i fjor og Android Q beta i år. Iliyan Malchev, ledende Project Treble og Hovedlinje ingeniør, sier at Android Pie-adopsjonen var "3 ganger" den for Android Oreo på slutten av 2018.

I den samme kommentaren erter Dick Dougherty at flere nyttige beregninger er under arbeid for distribusjonskartet for Android-versjonen. Diagrammet var sist oppdatert i mai, men dataene er mer nyttige for journalister enn apputviklere.

Skjermopptak er fortsatt en WIP

Tidlige Android Q-betaer la til et funksjonsflagg for en grunnleggende skjermopptaker, men selve plattformen har forbedret nytten av skjermopptak betydelig ved å slik at apper kan fange opp lyden fra andre apper. Stephanie Saad Cuthbertson sa at teamet vurderte "hvordan vi kunne gjøre det bedre på skjermens opptaksbehov så sent som i går." Andre smarttelefonmerker som OnePlus, ASUS, Huawei og Samsung har robuste skjermopptakere som kan ta opp den interne lyden, så Google vil spille catch up her.

Mørkt tema alle ting!

I tilfelle du gikk glipp av det, legger Google til mørk modus til de fleste appene deres. Stephanie Saad Cuthbertson sier å forvente at alle "store apper" støtter et mørkt tema "ved offisiell [Android Q]-utgivelse." Til og med Google Chrome, som for tiden tvinger en sideinnlasting på nytt når det mørke temaet for hele systemet er aktivert, vil bli oppdatert for ikke lenger å oppdatere når temaet er endret.

Ja, tredjepartsoppstartere vil fungere med bevegelser (til slutt)

Androids bevegelser er på en måte ødelagt når du bruker en tredjeparts launcher. Det er fordi brukergrensesnittet for de siste appene er inneholdt i aksjestartappen, og Google har ikke gjort det ennå utarbeidet en måte å ha de samme sømløse overgangene som vi ser når du bruker bevegelser med den vanlige Pixel Launcher. Adam Cohen bekrefter Googles planer om å løse disse problemene "så raskt som mulig etter utgivelsen." Det sier han videre inkompatibiliteten "vil bli adressert i post-Q-oppdatering, og tilbakeportert for nye enheter som lanseres med Q."

Dynamiske/logiske partisjoner er ikke her for å drepe tilpassede ROM-er

For å støtte Dynamiske systemoppdateringer i Android Q bruker visse enheter som Google Pixel 3 og Pixel 3 XL logiske partisjoner. Disse partisjonene kan endres dynamisk. Denne endringen har bevist utfordrende for å få root-tilgang til å fungere, og noen utviklere er bekymret for at tilpassede ROM-er blir målrettet. Iliyan Malchev forsikrer oss om at intensjonen ikke er å begrense tilpassede ROM-er. Som forklarer han:

"Dynamiske partisjoner er ikke ment å begrense hva du kan gjøre med tilpassede ROM-er. De er ganske enkelt en løsning på problemet med faste partisjonsstørrelser og mangel på en sikker måte å ompartisjonere enheter på OTA. Før dynamiske partisjoner, hvis en OEM gjorde en feil i dimensjonering av f.eks. systempartisjonen, så de ville være begrenset av det valget, noe som gjør det praktisk talt umulig å oppgradere en enhet etter en viss punkt. Noen OEM-er partisjonerer enhetene sine på OTA som et spørsmål om praksis, men dette er a) ikke offisielt støttet i Android, og b) å endre partisjonstabellen anses som ganske risikabelt. Dynamiske partisjoner tar sikte på å lindre problemet ved å introdusere et nivå av indirekte mellom den fysiske partisjonstabellen og OS ser. Dette lar oss igjen trygt justere partisjonsstørrelser på OTA. Når det gjelder tilpassede ROM-er, bør du ikke være mer begrenset enn du er i dag med hva du kan gjøre. Å støtte tilpassede ROM-er er og fortsetter å være noe hver enkelt OEM bestemmer seg for å aktivere."

Prosjekt hovedlinje - ART-modul og støttelengde

Mainline er et nytt initiativ fra Google som har som mål å standardisere visse biblioteker og pakker slik at de kan oppdateres uavhengig av plattformoppdateringer. Noen har lurt på hvorfor Android Runtime (ART) ennå ikke er en hovedlinjemodul, men jeg ble fortalt på Google I/O at kompleksiteten involvert i modularisering av ART forhindret dem fra å inkludere den som en av de første APEX-pakkene. Som forklart av både Iliyan Malchev og Diana Wong:

"Å gjøre oppdateringer til Runtime (spesielt ytelses- og GC-reparasjoner og kjernebiblioteker) er definitivt noe vi utforsker i sammenheng med mainline. Vi kan se mange fordeler ved å kunne gjøre disse oppdateringene konsistente på tvers av alle enheter og på tvers av flere utgivelser med mainline. Det er også en stor teknisk utfordring når vi tenker på hvordan vi kan gjøre dette best for utviklere, og sannsynligvis en flerårig innsats. Det er ikke noe Mainline kan gjøre for øyeblikket, men absolutt noe vi tenker på."

Hvis du følger AOSP Gerrit, vil du se at Google likevel har vært det hardt på jobb lage en Runtime APEX. Foreløpig ser de ut til å være det splitting Bionic og ART/libcore inn i separate APEX-moduler.

Når det gjelder fordelene med Project Mainline, spurte en bruker om lengden på Mainline-oppdateringer. Som svar, Iliyan Malchev sier at "dette er et policyspørsmål som vi fortsatt vurderer, men vi ønsker å oppdatere Mainline-moduler på en enhet så lenge som mulig." XDA anerkjent utvikler luca020400 spurte om forhåndsbygde Mainline-moduler vil bli levert slik at tilpassede ROM-utviklere kan slå sammen oppdateringer, og som svar svarte Jeff Bailey gjentar at "modulene som splittes av AOSP vil ha kildeutgivelser som matcher hver modulutgivelse." Vi kan allerede se utviklingen av nye APEX-moduler i AOSP, for eksempel en for Neural Networks API.

CameraX møter ML Kit

På I/O i år introduserte Google CameraX Jetpack-bibliotek. Dette biblioteket er designet for å gjøre det enklere for utviklere å støtte Androids Camera2 API samtidig som kompatibiliteten opprettholdes helt tilbake til Android Lollipop. Vinit Modi erter som selskapet jobber med å integrere CameraX med ML-sett, Googles Firebase SDK for maskinlæring, slik at utviklere kan mate bilderammer inn i ML Kit for analyse.

CameraX-leverandørutvidelser og utgivelsesdato

Utvikleren av en kameraapp beklager det faktum at avanserte kamerafunksjoner som Google Pixels Night Sight ikke er tilgjengelige for tredjeparts kameraapper. Dette er ment å kunne løses med CameraX-leverandørutvidelser, som Jeff Sharkey fra Google til sier at "alle Pixel-enheter er optimalisert for CameraX Core." Han erter at "Extensions-aspektet kommer til å bli støttet på nye og kommende enheter." Dessuten er Google "jobber med flere produsenter for å kunne bringe enhetens evner til både utviklere og brukere." Selv om det ikke er direkte bekreftet, er det mulig vi kan se funksjoner som Nattsyn på Google Pixel 4 bli tilgjengelig for tredjeparts kameraapper som bruker CameraX-biblioteket.

Mr. Sharkey uttaler at Google sikter mot en betaversjon mot slutten av dette året.

Minneadministrasjonsforbedringer i Android Q

Pixel 3 ble lammet for å ha en rekke utgaver etter lansering, men Google har gjort mye for å løse disse problemene via en rekke oppdateringer etter lansering. Minnehåndtering har vært en av Pixel 3s svakeste aspekter, men ting skal være litt bedre i Android Q-utgivelsen. I følge Selim Cinek:

"I SystemUI, for eksempel, hadde vi forskjellige store refaktoriseringsinnsatser i Q for å redusere RAM-bruken til varsler og andre overflater."

Vil vi endelig få trådløs ADB?

Hvis du vil feilsøke telefonen trådløst, må du rote enheten. Jamal Eason fra Android Studio-teamet sier at de for tiden tar for seg muligheten for denne funksjonen.

Tester Google fortsatt på nettbrett?

XDA anerkjent utvikler Luk1337 spurte om Google fortsatt tester AOSP UX på nettbrett. Det er et rettferdig spørsmål tatt i betraktning mangel på gode Android-nettbrett og feil tilstede i nåværende utgivelser. Allen Huang sier at Google fortsatt «tester og gjør rettelser hvert år» og at selskapet jobber tett med partnere «for å sikre en god Android-nettbrettopplevelse».

---

Det er mange flere innlegg i hele tråden over på Reddit. Det jeg har dekket her, oppsummerer all den nye informasjonen vi har lært, men flere Googlere (spesielt Dianne Hackborn) gå inn på deres resonnement bak å kutte X-funksjonen eller ikke implementere Y tillatelse. Jeg anbefaler deg å lese hele AMA hvis du vil forstå Android-teamets beslutningstaking litt bedre.

Les hele AMA på /r/AndroidDev