Google-ingeniører lavede en AMA på Reddit forleden. AMA handlede om Android Q beta. Her er en oversigt over, hvad vi lærte af deres svar.
Sidste år var Googles Android-team vært for en Ask Me Anything (AMA) på Reddits /r/AndroidDev subreddit for at stille spørgsmål om Forhåndsvisning af Android P-udvikler. I år har ingeniørteamet, der arbejder på Android Q beta, besvaret spørgsmål på Reddit. AMA startede den 1. august kl. 12:00 PST og sluttede cirka halvanden time senere. 33 Google-ingeniører var involveret i AMA og besvarede et væld af spørgsmål i den korte tid, AMA varede. Her er vores sammenfatning af alle de nye oplysninger, vi har lært.
Android Q AMA: Alt, hvad vi har lært af Google
Deltagere fra Android Q beta-teamet
- Adam Cohen: TLM på Android Launcher / System UI
- Adam Powell: TLM på UI toolkit/framework; synspunkter, livscyklus, fragmenter, støttelibs
- Alan Viverette: TLM, Jetpack / AndroidX
- Allen Huang: PM for UI, launcher, notifikationer, søgeintegrationer og mere!
- Andrew Sappirstein: TLM på Android-indstillinger
- Brahim Elbouchikhi: PM Director for Android Machine Learning and Camera (NN API, ML Kit, CameraX, Camera Platform)
- Chad Brubaker: Softwareingeniør, Android Platform Security
- Charmaine D'Silva: PM for privatliv
- Chet Haase: Android Chief Advocate, Developer Relations
- Diana Wong: PM, App-kompatibilitet, ikke-SDK API-brug, ART, NDK
- Dianne Hackborn: Leder af Android framework-teamet (Ressourcer, Window Manager, Activity Manager, Multi-user, Printing, Accessibility osv.)
- E.K. Chung: Direktør for UX
- Ian Lake: Softwareingeniør, Jetpack (fragmenter, navigation, arkitekturkomponenter)
- Iliyan Malchev: Hovedsoftwareingeniør, Project Mainline
- Jacob Lehrbaum: Direktør for Developer Relations til Android
- Jake Wharton: Softwareingeniør, Jetpack
- Jamal Eason: PM, Android Studio
- Jeff Bailey: TLM, Android Open Source Project (AOSP)
- Jeff Sharkey: Softwareingeniør, Android Framework
- Jeffrey van Gogh: Android Studio, kompilatorer
- Jen Chai: PM, placering og kontekst, godkendelse, autofyld, ikke-SDK API-brug, ART
- Karen Ng: Gruppe PM til Android Developer Tools, Android Studio, Android Tookit og Jetpack
- Paul Bankhead: Direktør for Product Management, Google Play
- Rohan Shah: Produktchef, Android System UI
- Romain Guy: Leder af Android Toolkit/Jetpack-teamet
- Sagar Kamdar: Direktør for produktledelse, Android
- Lør K: Director of Engineering, Android Connectivity
- Selim Cinek: Softwareingeniør, Android System UI
- Stephanie Saad Cuthbertson: Seniordirektør for Product Management, Android
- Sumir Kataria: Softwareingeniør, Jetpack (WorkManager)
- Travis McCoy: PM, Android-platform
- Trystan Upstill: Distinguished Engineer, Lead for Android System UI & Intelligence
- Vinit Modi: PM, Android-kamera
Læs mere
OEM'er kan ikke længere dræbe apps, når brugeren stryger dem væk i de seneste
Hvis du nogensinde har brugt en smartphone fra et kinesisk mærke, så har du sandsynligvis beskæftiget dig med irriterende "batterioptimerings"-funktioner, der dræbe alle dine yndlingsapps i baggrunden. Ikke kun er denne adfærd irriterende for brugere, der forventer, at visse apps fortsætter med at køre i baggrunden uanset årsagen, men det er også irriterende for udviklere, der skal lide under dårlige anmeldelser fra brugere, der ikke forstår, at det ikke er appens fejl. Mens Google er stadig ikke fuldt ud adresserede denne sag (de håndviftede problemet væk ved at sige, at denne adfærd er sandsynligvis allerede i strid med kravene til Android Compatibility Definition Document), virksomheden er tage affære mod en "batteribesparende" adfærdsændring anvendt af nogle OEM'er.
"For at hjælpe med situationen har vi tilføjet en CTS-test i Android Q for at sikre, at en app ikke dræbes, når den bliver swipet fra Seneste."
Android R kan bringe flere ændringer til skærmbilleder, end vi havde forventet
Google planlægger at tilføje rullende skærmbilleder i Android R, men på samme tid Android-teamet er "at se nærmere på, hvordan [de] kan forbedre hele skærmen-[X]-oplevelsen for R." Således kan vi evt se andre forbedringer af skærmbilledet (OG screencast) adfærd i den næste store Android-version.
Præcisering af Android Qs nye skrivebordstilstand
Det første offentlige betaudgivelse af Android Q bragte en skjult desktop mode interface til AOSP og Pixel Launcher. Selvom Google berørte kort indslaget under en Google I/O-session har vi aldrig hørt direkte fra Google, hvordan den nye funktion passer ind i Android-økosystemet. Google nu afklarer:
"I Q AOSP er 'desktop mode' en udviklermulighed målrettet applikationsudviklere. Det giver dem mulighed for at teste deres apps i multi-display og freeform windowing mode-miljøer. Tidligere var der ingen praktisk måde at teste app-adfærd på en sekundær skærm og med vinduer, der frit kunne ændre størrelse på standard Android. Denne funktion produceres ikke alene og er ikke beregnet til almindelige brugere i øjeblikket. Ikke desto mindre er det basislinjen for Android-platformen for OEM'er at innovere og lave fantastiske produkter."
Således kan vi forvente at se OEM'er bygge videre på Android Q's oprindelige desktop-tilstand. For eksempel OnePlus 7 Pro understøtter display ud over HDMI, så det er muligt OxygenOS 10 baseret på Android Q vil have sin egen desktop mode interface i fremtiden. Vi håber også, at Google bygger videre på funktionen til den kommende tid Pixel 4.
Tidsbaseret mørk tilstand
Android Q bringer endelig en meget efterspurgt funktion: mørk tilstand for hele systemet. I øjeblikket kan den mørke tilstand enten aktiveres manuelt i Indstillinger eller via en flise med hurtige indstillinger, eller den kan aktiveres automatisk, når batterisparer er aktiveret. Før Android Q var der en mulighed for at aktivere mørk tilstand baseret på tidspunktet på dagen, men den mulighed blev forældet. Ifølge Chris Banes:
"Der er et par grunde til, at dette er forældet (ikke fjernet) i AppCompat v1.1.0: det kræver, at apps anmoder om placeringstilladelser for at være nøjagtige, og selv med en gyldig placering kan solopgangs-/solnedgangstidsberegninger buggy."
Da han bliver spurgt om disse fejl, udtaler hr. Banes, at "beregning af solopgang/solnedgange er notorisk vanskeligt, især for steder tæt på nord-/sydpoler." En bruger fremhæver, at natlys, tilgængeligt siden Android 7.1 Nougat, kan skiftes automatisk baseret på solnedgang/solopgang tidsplaner. Mr. Banes udtaler derefter, at siden Night Light bruger CalendarAstronomer fra ICU4J, bruger den en "stor bidder kode, som vi ikke ønsker, at AppCompat skal være afhængig af." Det gør holdet dog stat at denne funktion er "noget [de] vil se nærmere på."
Obligatorisk Camera2 API/Camera HAL3-understøttelse til Android Q-startenheder
Google introducerede Camera2 API for bedre at definere, hvordan apps kan interagere med de individuelle kameraer, der er tilsluttet din smartphone. Mens Google opmuntrer smartphone-leverandører for at "udsætte alle deres fysiske kameraer for udviklere," mange leverandører vælger ikke at gøre det, selvom "API'en i sig selv ikke er forhindrer dem i dag." Dette betyder, at mange tredjeparts kameraapps ikke kan bruge de sekundære eller tertiære kameramoduler på moderne smartphones. Der gøres fremskridt, efterhånden som Android Q er blevet forbedret LOGICAL_MULTI_CAMERA, et API, som giver udviklere bedre adgang til alle kameraer på en enhed, og som giver OEM'er kontrol over strømforbrug og styring af flere kameratilstande.
Desuden siger Google, at de har tilføjet krav til alle enheder, der lanceres med Android Q, til at understøtte Camera2 API/Camera HAL3. Ifølge Vinit Modi:
"Fra og med Android P kræves der nye enheder, der sendes med 1 GB eller mere RAM for at kunne bruge HALv3/camera2. Android Q og fremefter kræves alle nye enheder for at understøtte HALv3/camera2. Desværre er opgraderinger fra HALv1 til HALv3 temmelig komplekse over luften og kan have uventede konsekvenser, hvorfor vi var nødt til at begrænse omfanget til nye enheder."
Interessant nok, Modis udtalelse om normale RAM Android P-lanceringsenheder modsiger hvad vi tidligere fik at vide af Google, og hvad der er offentliggjort på siden Image Test Suite online.
Dynamisk app-tema med Jetpack Compose
Sonys OMS temaramme blev tilføjet til AOSP en del udgivelser tilbage, men det er kun beregnet til OEM'er at bygge videre på. Det ved vi allerede Google er imod brugen af runtime-ressourceoverlejringer af brugere til temaapps, men for udviklere er virksomheden håber at dens Jetpack Compose UI rammen vil bringe "interessante tilgange til dynamisk tematik."
Vulkan-backend til Skia til at gengive brugergrænsefladen
Sidste år, vi fik øje på en diskussion blandt Google-ingeniører, der taler om deres planer om at lade Android-rammerne bruge Vulkan-grafik-API'en til UI-gengivelse. Selvom det nu er muligt at aktivere Vulkan hardwareaccelererede backend uden din telefon går ned, har vi ikke hørt nogen konkrete planer fra Google om, hvornår de planlægger at udrulle disse ændringer. Denne AMA besvarer ikke det spørgsmål, men vi har i det mindste bekræftet, at det stadig er under arbejde. Ifølge Romain Guy:
"Teamet har arbejdet på en Vulkan-backend til Skia, 2D-rendereren, der bruges af Android, men den er ikke aktiveret som standard i øjeblikket. Brugergrænsefladen og lærredet går stadig gennem OpenGL ES."
Gør Android Q's gestusbar mere dynamisk
Nogle på XDA mener det stadig Androids nye bevægelser er et rod, men jeg synes personligt de er fine. Hvis du leger lidt med de nye bevægelser i Android Q, vil du dog bemærke, at bevægelsesbjælken ikke bevæger sig med din finger. Det hænger også fast på skærme, hvor det ikke er nødvendigt, f.eks. startskærmen eller oversigt over seneste apps. Allen Huang siger at de er "helt enige om, at der er muligheder" for at gøre "navigationslinjen mindre statisk." Han siger videre at "det er noget, vi arbejder på - men også balancerer, så det ikke er distraherende dukker op/forsvinder."
Forbedringer til Storage Access Framework
De mange ændringer i Android Q har væsentligt forbedret platformens sikkerhed og privatliv. En sådan ændring, kaldet "Scoped Storage", begrænser apps' adgang til filer på det eksterne lager på en måde, der giver mening; musikapps skulle for eksempel ikke have behov for at se dit galleri. Filhåndteringsapps, der kører i Android Q, skal bruge en API kaldet Storage Access Framework for at fortsætte med at fungere som normalt, men nogle udviklere ser denne API som ringere til det, der tidligere var tilgængeligt. Jeff Sharkey fra Google siger holdet har behandlet nogle af disse udviklers klager:
"Vi lavede nogle SAF-ydeevneforbedringer i de seneste Android Q Beta-udgivelser; kunne du tjekke dine benchmarks i forhold til den seneste beta? Sørg også for, at du bruger en ContentProviderClient, når du kører nogen masseoperationer."
Project Treble forbedrede Android Pie-adoption i forhold til Android Oreo
Vi har allerede set, hvordan Project Treble, en større lavniveau-rearkitektering af Android-rammeværket, har forbedret adoptionen af nyere Android OS-versioner. Google krediterer Treble bag de mange smartphone-leverandører, der slutter sig til Android P beta sidste år og Android Q beta dette år. Iliyan Malchev, den ledende Project Treble og Hovedlinje ingeniør, siger at Android Pie-adoptionen var "3 gange" den for Android Oreo i slutningen af 2018.
I samme kommentar driller Dick Dougherty, at der er mere brugbare målinger på vej til distributionsdiagrammet for Android-versionen. Diagrammet var sidst opdateret i maj, men dens data er mere nyttige for journalister end app-udviklere.
Skærmoptagelse er stadig en WIP
Tidlige Android Q-betaer tilføjede et funktionsflag til en grundlæggende skærmoptager, men selve platformen har forbedret anvendeligheden af skærmoptagelse væsentligt ved at giver apps mulighed for at optage lyden fra andre apps. Stephanie Saad Cuthbertson sagde, at holdet overvejede "hvordan vi kunne gøre det bedre på skærmens optagelsesbehov så sent som i går." Andre smartphone mærker som OnePlus, ASUS, Huawei og Samsung har robuste skærmoptagere, der kan optage den interne lyd, så Google vil spille indhentning her.
Mørkt tema alle ting!
Hvis du gik glip af det, tilføjer Google mørk tilstand til de fleste af deres apps. Stephanie Saad Cuthbertson siger at forvente, at alle "store apps" understøtter et mørkt tema "ved officiel [Android Q]-udgivelse." Selv Google Chrome, som pt tvinger en sidegenindlæsning, når det mørke tema for hele systemet er aktiveret, vil blive opdateret til ikke længere at opdatere, når temaet er ændret.
Ja, tredjepartsstartere vil arbejde med bevægelser (til sidst)
Androids bevægelser er en slags ødelagt, når du bruger en tredjeparts launcher. Det er fordi den seneste apps brugergrænseflade er indeholdt i aktiestarter-appen, og Google har endnu ikke udarbejdet en måde at få de samme sømløse overgange, som vi ser, når du bruger bevægelser med den almindelige Pixel Launcher. Adam Cohen bekræfter Googles planer om at løse disse problemer "så hurtigt som muligt efter udgivelsen." Det siger han videre inkompatibiliteten "vil blive behandlet i post-Q-opdateringen og backporteret for nye enheder, der lanceres med Q."
Dynamiske/logiske partitioner er ikke her for at dræbe brugerdefinerede ROM'er
For at støtte Dynamiske systemopdateringer i Android Q gør visse enheder som Google Pixel 3 og Pixel 3 XL brug af logiske partitioner. Disse partitioner kan ændres dynamisk. Denne ændring har bevist udfordrende med at få root-adgang til at fungere, og nogle udviklere er bekymrede over, at brugerdefinerede ROM'er bliver målrettet. Iliyan Malchev forsikrer os om, at hensigten ikke er at begrænse brugerdefinerede ROM'er. Som forklarer han:
"Dynamiske partitioner er ikke beregnet til at begrænse, hvad du kan gøre med brugerdefinerede ROM'er. De er simpelthen en løsning på problemet med faste partitionsstørrelser og mangel på en sikker måde at ompartitionere enheder på OTA. Før dynamiske skillevægge, hvis en OEM lavede en fejl ved dimensionering af f.eks. systempartitionen, så de ville være begrænset af det valg, hvilket gør det praktisk talt umuligt at opgradere en enhed efter en vis punkt. Nogle OEM'er ompartitionerer deres enheder på OTA som et spørgsmål om praksis, men dette er a) ikke officielt understøttet i Android, og b) at ændre partitionstabellen anses for at være ret risikabelt. Dynamiske partitioner har til formål at afhjælpe problemet ved at indføre et niveau af indirekte mellem den fysiske partitionstabel og OS ser. Dette giver os igen mulighed for sikkert at justere partitionsstørrelser på OTA. Hvad angår brugerdefinerede ROM'er, bør du slet ikke være begrænset mere, end du er i dag, med hvad du kan gøre. At understøtte brugerdefinerede ROM'er er og bliver ved med at være noget, hver enkelt OEM beslutter at aktivere."
Projekt Mainline - ART-modul og støttelængde
Mainline er et nyt initiativ fra Google, der har til formål at standardisere visse biblioteker og pakker, så de kan opdateres uafhængigt af platformopdateringer. Nogle har undret sig over, hvorfor Android Runtime (ART) endnu ikke er et Mainline-modul, men jeg fik at vide på Google I/O, at kompleksiteten involveret i modularisering af ART forhindrede dem i at inkludere det som en af de indledende APEX-pakker. Som forklaret af både Iliyan Malchev og Diana Wong:
"At lave opdateringer til Runtime (især ydeevne & GC-rettelser og kernebiblioteker) er bestemt noget, vi udforsker i forbindelse med mainline. Vi kan se en masse fordele ved at være i stand til at gøre disse opdateringer konsistente på tværs af alle enheder og på tværs af flere udgivelser med mainline. Det er også en stor teknisk udfordring, da vi tænker på, hvordan vi gør dette bedst for udviklere, og sandsynligvis en flerårig indsats. Det er ikke noget, Mainline kan gøre i øjeblikket, men bestemt noget, vi tænker på."
Hvis du følger AOSP Gerrit, vil du se, at Google ikke desto mindre har været det hårdt på arbejde lave en Runtime APEX. I øjeblikket ser de ud til at være det opdeling af Bionic og ART/libcore i separate APEX-moduler.
Med hensyn til fordelene ved Project Mainline spurgte en bruger om længden af Mainline-opdateringer. Som svar, Iliyan Malchev siger at "dette er et politisk spørgsmål, som vi stadig evaluerer, men vi ønsker at opdatere Mainline-moduler på en enhed så længe som muligt." XDA anerkendt udvikler luca020400 spurgte om forudbyggede Mainline-moduler vil blive leveret, så brugerdefinerede ROM-udviklere kan flette opdateringer, og som svar svarede Jeff Bailey gentager at "modulerne, der opdeles fra AOSP, vil have kildeudgivelser, der matcher hver moduludgivelse." Vi kan allerede se udviklingen af nye APEX-moduler i AOSP, såsom et til Neurale netværk API.
CameraX møder ML Kit
Ved I/O i år introducerede Google CameraX Jetpack bibliotek. Dette bibliotek er designet til at gøre det nemmere for udviklere at understøtte Androids Camera2 API og samtidig bevare kompatibiliteten helt tilbage til Android Lollipop. Vinit Modi driller som virksomheden arbejder på at integrere CameraX med ML sæt, Googles Firebase SDK for maskinlæring, så udviklere kan føre billedrammer ind i ML Kit til analyse.
CameraX-leverandørudvidelser og udgivelsesdato
Udvikleren af en kamera-app beklager det faktum, at avancerede kamerafunktioner som Google Pixels Night Sight ikke er tilgængelige for tredjeparts kamera-apps. Dette formodes at kunne løses med CameraX-leverandørudvidelser, som Jeff Sharkey fra Google til siger at "alle Pixel-enheder er optimeret til CameraX Core." Han driller, at "udvidelsesaspektet vil blive understøttet på nye og kommende enheder." Desuden er Google "at arbejde med flere producenter for at kunne bringe deres enhedsfunktioner til både udviklere og brugere." Selvom det ikke er direkte bekræftet, er det muligt, at vi kan se funktioner synes godt om Nattesyn på den Google Pixel 4 bliver tilgængelige for tredjeparts kameraapps, der bruger CameraX-biblioteket.
Mr. Sharkey udtaler, at Google sigter mod en beta-udgivelse i slutningen af dette år.
Hukommelsesstyringsforbedringer i Android Q
Pixel 3 blev lammet for at have adskillige problemer efter lanceringen, men Google har gjort meget for at løse disse problemer via adskillige opdateringer efter lanceringen. Hukommelsesstyring har været et af Pixel 3s svageste aspekter, men tingene burde være en smule bedre i Android Q-udgivelsen. Ifølge Selim Cinek:
"I SystemUI for eksempel, havde vi forskellige store refaktoreringsbestræbelser i Q for at reducere RAM-forbruget af notifikationer og andre overflader."
Får vi endelig trådløs ADB?
Hvis du trådløst vil debugge din telefon, skal du roote din enhed. Jamal Eason fra Android Studio-teamet siger at de i øjeblikket behandler gennemførligheden af denne funktion.
Tester Google stadig på tablets?
XDA anerkendt udvikler Luk1337 spurgt, om Google stadig tester AOSP UX på tablets. Det er et rimeligt spørgsmål i betragtning af mangel på gode Android-tablets og fejl til stede i aktuelle udgivelser. Allen Huang siger at Google stadig "tester og laver rettelser hvert år", og at virksomheden arbejder tæt sammen med partnere "for at sikre en god Android-tabletoplevelse."
Der er mange flere indlæg i hele tråden på Reddit. Det, jeg har dækket her, opsummerer alle de nye oplysninger, vi har lært, men flere Googlere (især Dianne Hackborn) gå ind i deres begrundelse bag at skære X-funktionen eller ikke implementere Y tilladelse. Jeg anbefaler, at du læser hele AMA, hvis du vil forstå Android-teamets beslutningstagning lidt bedre.
Læs hele AMA på /r/AndroidDev