Android Q AMA Sammanfattning: Vad Google sa om Android 10 på Reddit

Googles ingenjörer gjorde en AMA på Reddit häromdagen. AMA handlade om Android Q beta. Här är en sammanfattning av vad vi lärde oss av deras svar.

Förra året var Googles Android-team värd för en Ask Me Anything (AMA) på Reddits /r/AndroidDev subreddit för att ställa frågor om Android P Developer Preview. I år svarade ingenjörsteamet som arbetar med Android Q beta på frågor på Reddit. AMA startade den 1 augusti klockan 12:00 PST och slutade ungefär en och en halv timme senare. 33 Google-ingenjörer var involverade i AMA och svarade på massor av frågor under den korta tid som AMA varade. Här är vår sammanfattning av all ny information som vi lärt oss.

Android Q AMA: Allt vi lärde oss från Google

Deltagare från Android Q betateam

  • Adam Cohen: TLM på Android Launcher / System UI
  • Adam Powell: TLM på UI-verktygssats/ramverk; vyer, livscykel, fragment, supportlibs
  • Alan Viverette: TLM, Jetpack / AndroidX
  • Allen Huang: PM för UI, startprogram, meddelanden, sökintegrationer och mer!
  • Andrew Sappirstein: TLM på Android-inställningar
  • Brahim Elbouchikhi: PM Director för Android Machine Learning and Camera (NN API, ML Kit, CameraX, Camera Platform)
  • Chad Brubaker: Programvaruingenjör, Android Platform Security
  • Charmaine D'Silva: PM för integritet
  • Chet Haase: Android chefsadvokat, utvecklarrelationer
  • Diana Wong: PM, appkompatibilitet, icke-SDK API-användning, ART, NDK
  • Dianne Hackborn: Chef för Android-ramteamet (Resurser, Fönsterhanterare, Aktivitetshanterare, Fleranvändare, Utskrift, Tillgänglighet, etc.)
  • E.K. Chung: Direktör för UX
  • Ian Lake: Mjukvaruingenjör, Jetpack (fragment, navigering, arkitekturkomponenter)
  • Iliyan Malchev: Huvudansvarig mjukvaruingenjör, Project Mainline
  • Jacob Lehrbaum: Director of Developer Relations för Android
  • Jake Wharton: Programvaruingenjör, Jetpack
  • Jamal Eason: PM, Android Studio
  • Jeff Bailey: TLM, Android Open Source Project (AOSP)
  • Jeff Sharkey: Programvaruingenjör, Android Framework
  • Jeffrey van Gogh: Android Studio, kompilatorer
  • Jen Chai: PM, Plats och sammanhang, Auth, Autofyll, icke-SDK API-användning, ART
  • Karen Ng: Grupp PM för Android Developer Tools, Android Studio, Android Tookit och Jetpack
  • Paul Bankhead: Direktör för produkthantering, Google Play
  • Rohan Shah: Produktchef, Android System UI
  • Romain Guy: Chef för Android Toolkit/Jetpack-teamet
  • Sagar Kamdar: Director of Product Management, Android
  • lör K: Director of Engineering, Android Connectivity
  • Selim Cinek: Programvaruingenjör, Android System UI
  • Stephanie Saad Cuthbertson: Senior Director of Product Management, Android
  • Sumir Kataria: Mjukvaruingenjör, Jetpack (WorkManager)
  • Travis McCoy: PM, Android-plattform
  • Trystan Upstill: Framstående ingenjör, ledare för Android System UI & Intelligence
  • Vinit Modi: PM, Android-kamera

Läs mer

OEM-tillverkare kan inte längre döda appar när användaren sveper bort dem i de senaste

Om du någonsin har använt en smartphone från ett kinesiskt märke, så har du förmodligen hanterat irriterande "batterioptimerings"-funktioner som döda alla dina favoritappar i bakgrunden. Detta beteende är inte bara irriterande för användare som förväntar sig att vissa appar ska fortsätta köras i bakgrunden oavsett anledning, men det är också irriterande för utvecklare som måste få dåliga recensioner från användare som inte förstår att det inte är appens fel. Medan Google är det fortfarande inte helt och hållet ta itu med denna fråga (de viftade bort problemet för hand genom att säga att detta beteende är det troligen redan bryter mot kraven på Android-kompatibilitetsdefinitionsdokumentet), företaget är vidta åtgärder mot en "batterisparande" beteendeförändring som används av vissa OEM-tillverkare.

"För att hjälpa till med situationen har vi lagt till ett CTS-test i Android Q för att säkerställa att en app inte dödas när den svepas från Senaste."

Android R kan medföra fler ändringar av skärmdumpar än vi förväntade oss

Google planerar att lägga till rullande skärmdumpar i Android R, men samtidigt Android-teamet är "ta en närmare titt på hur [de] kan förbättra hela skärmen-[X]-upplevelsen för R." Således kan vi se andra förbättringar av beteendet för skärmdumpen (OCH screencast) i nästa stora Android-version.

Förtydligar Android Q: s nya skrivbordsläge

De första offentliga betaversion av Android Q tog med ett dolt gränssnitt för skrivbordsläge till AOSP och Pixel Launcher. Även om Google berörde kort inslaget under en Google I/O-session har vi aldrig hört direkt från Google hur den nya funktionen passar in i Androids ekosystem. Google klargör nu:

"I Q AOSP är 'skrivbordsläge' ett utvecklaralternativ riktat till applikationsutvecklare. Det låter dem testa sina appar i miljöer med flera skärmar och friformsfönster. Tidigare fanns det inget bekvämt sätt att testa appbeteende på en sekundär skärm och med fritt storleksändringsbara fönster på lager Android. Denna funktion produceras inte på egen hand och är inte avsedd för vanliga användare för tillfället. Ändå är det baslinjen för Android-plattformen för OEM-tillverkare att förnya och göra fantastiska produkter."

Därför kan vi förvänta oss att se OEM-tillverkare bygga på Android Q: s inbyggda skrivbordsläge. Till exempel OnePlus 7 Pro har stöd för display ut över HDMI, så det är möjligt det OxygenOS 10 baserat på Android Q kommer att ha ett eget gränssnitt för skrivbordsläge i framtiden. Vi hoppas också att Google bygger vidare på funktionen för den kommande Pixel 4.

Tidsbaserat mörkt läge

Android Q kommer äntligen med en mycket efterfrågad funktion: mörkt läge för hela systemet. För närvarande kan det mörka läget antingen aktiveras manuellt i Inställningar eller via en ruta för snabbinställningar, eller så kan det aktiveras automatiskt när batterisparläget är aktiverat. Innan Android Q fanns det ett alternativ för att aktivera mörkt läge baserat på tiden på dygnet, men det alternativet fasades ut. Enligt Chris Banes:

"Det finns några anledningar till varför detta är utfasat (inte borttaget) i AppCompat v1.1.0: det kräver att appar begär platsbehörigheter för att vara korrekta, och även med en giltig plats kan beräkningar av soluppgång/solnedgångstid buggy."

På frågan om dessa buggar, säger Mr. Banes att "beräkna soluppgång/solnedgångar är notoriskt svårt, särskilt för platser nära till nord-/sydpoler." En användare tar upp att nattljus, tillgängligt sedan Android 7.1 Nougat, kan växlas automatiskt baserat på solnedgång/soluppgång scheman. Mr. Banes uppger sedan att eftersom Night Light använder CalendarAstronomer från ICU4J, använder den en "stor bit kod som vi inte vill att AppCompat ska vara beroende av." Det gör laget dock stat att den här funktionen är "något [de] kommer att titta på."

Obligatoriskt Camera2 API/Camera HAL3-stöd för Android Q-startenheter

Google introducerade Camera2 API för att bättre definiera hur appar kan interagera med de enskilda kamerorna som är anslutna till din smartphone. Medan Google uppmuntrar smartphone-leverantörer för att "exponera alla sina fysiska kameror för utvecklare", många leverantörer väljer att inte göra det även om "API: et i sig inte är förhindrar dem idag." Detta innebär att många kameraappar från tredje part inte kan använda de sekundära eller tertiära kameramodulerna på moderna smartphones. Framsteg görs dock i takt med att Android Q har förbättrats LOGICAL_MULTI_CAMERA, ett API som ger utvecklare bättre tillgång till alla kameror på en enhet och som ger OEM-tillverkare kontroll över strömförbrukning och hantering av flera kameratillstånd.

Dessutom säger Google att de har lagt till krav för alla enheter som lanseras med Android Q för att inbyggt stödja Camera2 API/Camera HAL3. Enligt Vinit Modi:

"Från och med Android P krävs nya enheter som levereras med 1 GB eller mer RAM för att kunna använda HALv3/camera2. Android Q och framåt krävs att alla nya enheter har inbyggt stöd för HALv3/camera2. Tyvärr är uppgraderingar från HALv1 till HALv3 ganska komplexa direkt och kan få oväntade konsekvenser, därför var vi tvungna att begränsa omfattningen till nya enheter."

Intressant nog, Modis uttalande om normala RAM Android P lanseringsenheter motsäger vad vi fick höra tidigare av Google och vad som publicerats på sidan för Image Test Suite online.

Dynamisk apptema med Jetpack Compose

Sonys ramverk för OMS-teman lades till i AOSP ett antal släpp tillbaka, men det är bara avsedd för OEM att bygga på. Det vet vi redan Google är emot användningen av runtime-resursöverlagringar av användare till temaappar, men för utvecklare är företaget hoppas att dess Jetpack Compose UI ramverket kommer att presentera "intressanta tillvägagångssätt för dynamisk tematik."

Vulkan-backend för Skia att rendera UI

Förra året, vi såg en diskussion bland Googles ingenjörer som talar om sina planer på att låta Android-ramverket använda Vulkans grafik-API för UI-rendering. Medan det nu är möjligt att aktivera Vulkans hårdvaruaccelererade backend utan din telefon kraschar, vi har inte hört några konkreta planer från Google om när de planerar att rulla ut dessa ändringar. Denna AMA svarar inte på den frågan, men vi har åtminstone bekräftelse på att den fortfarande är under arbete. Enligt Romain Guy:

"Teamet har arbetat på en Vulkan-backend för Skia, 2D-renderaren som används av Android, men den är inte aktiverad som standard för närvarande. Användargränssnittet och Canvas går fortfarande igenom OpenGL ES."

Gör Android Q: s gestfält mer dynamisk

Vissa på XDA tycker fortfarande det Androids nya gester är en enda röra, men jag tycker personligen att de är bra. Om du leker med de nya gesterna i Android Q en stund, kommer du dock att märka att gestsfältet inte rör sig med fingret. Den sitter också kvar på skärmar där den inte behövs, som startskärmen eller översikt över senaste appar. Allen Huang säger att de är "helt överens om att det finns möjligheter" att göra "navigationslinjen mindre statisk". säger han vidare att "det här är något vi jobbar med - men också balanserar så det inte är distraherande dyker upp/försvinner."

Förbättringar av Storage Access Framework

De många förändringarna i Android Q har avsevärt förbättrat plattformens säkerhet och integritet. En sådan förändring, kallad "Scoped Storage", begränsar appars åtkomst till filer på den externa lagringen på ett sätt som är vettigt; musikappar ska till exempel inte behöva se ditt galleri. Filhanterarappar som körs i Android Q måste använda ett API som kallas Storage Access Framework för att fortsätta fungera som vanligt, men vissa utvecklare ser detta API som sämre till vad som tidigare fanns tillgängligt. Jeff Sharkey från Google säger teamet har åtgärdat några av dessa utvecklares klagomål:

"Vi gjorde några SAF-prestandaförbättringar i de senaste Android Q Beta-versionerna; kan du kontrollera dina riktmärken mot den senaste betan? Se också till att du använder en ContentProviderClient när du kör några massoperationer."

Project Treble förbättrade Android Pie-användningen jämfört med Android Oreo

Vi har redan sett hur Project Treble, en stor omarbetning av Android-ramverket på låg nivå, har förbättrat antagandet av nyare Android OS-versioner. Google krediterar Treble bakom mängden av smartphone-leverantörer som ansluter sig till Android P beta förra året och Android Q beta det här året. Iliyan Malchev, ledaren Project Treble och Mainline ingenjör, säger att Android Pie-antagandet var "3 gånger" så mycket som Android Oreo i slutet av 2018.

I samma kommentar retar Dick Dougherty att mer användbara mätvärden är på gång för distributionsdiagrammet för Android-versionen. Diagrammet var senast uppdaterad i maj, men dess data är mer användbar för journalister än apputvecklare.

Skärminspelning är fortfarande en WIP

Tidiga betaversioner av Android Q lade till en funktionsflagga för en grundläggande skärminspelning, men själva plattformen har avsevärt förbättrat användbarheten av skärminspelning med tillåter appar att fånga ljudet från andra appar. Stephanie Saad Cuthbertson sa att teamet övervägde "hur vi skulle kunna göra bättre på skärmens inspelningsbehov så sent som igår." Andra smartphonemärken som OnePlus, ASUS, Huawei och Samsung har robusta skärminspelare som kan spela in det interna ljudet, så Google kommer att spela ikapp här.

Mörkt tema alla saker!

Om du missade det lägger Google till mörkt läge till de flesta av sina appar. Stephanie Saad Cuthbertson säger att förvänta sig att alla "stora appar" stöder ett mörkt tema "genom officiell [Android Q] release." Även Google Chrome, som för närvarande tvingar en sida att ladda om när det systemomfattande mörka temat är aktiverat, kommer att uppdateras så att det inte längre uppdateras när temat är ändrats.

Ja, tredjepartsstartare kommer att fungera med gester (så småningom)

Androids gester är typ trasig när du använder en startprogram från tredje part. Det beror på att de senaste apparnas gränssnitt finns i lagerstartappen, och Google har inte gjort det ännu utarbetade ett sätt att få samma sömlösa övergångar som vi ser när du använder gester med den vanliga Pixel Launcher. Adam Cohen bekräftar Googles planer på att ta itu med dessa problem "så snabbt som möjligt efter release." Det säger han vidare inkompatibiliteten "kommer att åtgärdas i post-Q-uppdateringen och backporteras för nya enheter som lanseras med Q."

Dynamiska/logiska partitioner är inte här för att döda anpassade ROM

För att stödja Dynamiska systemuppdateringar i Android Q använder vissa enheter som Google Pixel 3 och Pixel 3 XL logiska partitioner. Dessa partitioner kan ändras dynamiskt. Denna förändring har visat sig vara utmanande för att få root-åtkomst att fungera, och vissa utvecklare är oroliga över att anpassade ROM-skivor är inriktade på. Iliyan Malchev försäkrar oss att avsikten inte är att begränsa anpassade ROM. Som han förklarar:

"Dynamiska partitioner är inte avsedda att begränsa vad du kan göra med anpassade ROM. De är helt enkelt en lösning på problemet med fasta partitionsstorlekar och bristen på ett säkert sätt att partitionera om enheter på OTA. Före dynamiska partitioner, om en OEM gjorde ett misstag när han dimensionerade t.ex. systempartitionen, sedan de skulle begränsas av det valet, vilket gör det praktiskt taget omöjligt att uppgradera en enhet efter en viss punkt. Vissa OEM-tillverkare partitionerar om sina enheter på OTA som en praxis, men detta stöds a) inte officiellt i Android, och b) att ändra partitionstabellen anses vara ganska riskabelt. Dynamiska partitioner syftar till att lindra problemet genom att införa en nivå av indirektion mellan den fysiska partitionstabellen och OS ser. Detta i sin tur tillåter oss att säkert justera partitionsstorlekar på OTA. När det gäller anpassade ROM-skivor bör du inte alls vara begränsad mer än vad du är idag med vad du kan göra. Att stödja anpassade ROM är och fortsätter att vara något som varje enskild OEM bestämmer sig för att möjliggöra."

Projektets huvudlinje - ART-modul och stödlängd

Mainline är ett nytt initiativ från Google som syftar till att standardisera vissa bibliotek och paket så att de kan uppdateras oberoende av plattformsuppdateringar. Vissa har undrat varför Android Runtime (ART) ännu inte är en Mainline-modul, men jag fick höra på Google I/O att komplexiteten i att modularisera ART hindrade dem från att inkludera det som ett av de första APEX-paketen. Som förklarade av både Iliyan Malchev och Diana Wong:

"Att göra uppdateringar av Runtime (särskilt prestanda & GC-fixar och kärnbibliotek) är definitivt något vi utforskar i samband med mainline. Vi kan se många fördelar med att kunna göra dessa uppdateringar konsekventa på alla enheter och över flera utgåvor med mainline. Det är också en enorm teknisk utmaning när vi funderar på hur man gör detta bäst för utvecklare, och troligen en flerårig insats. Det är inget Mainline kan göra för närvarande, men definitivt något vi funderar på."

Om du följer AOSP Gerrit ser du att Google ändå har varit det hårt på jobbet gör en Runtime APEX. För närvarande verkar de vara det dela Bionic och ART/libcore i separata APEX-moduler.

När det gäller fördelarna med Project Mainline frågade en användare om längden på Mainline-uppdateringar. Som svar, Iliyan Malchev säger att "det här är en policyfråga som vi fortfarande utvärderar, men vi vill uppdatera Mainline-moduler på en enhet så länge som möjligt." XDA erkänd utvecklare luca020400 frågade om förbyggda Mainline-moduler kommer att tillhandahållas så att anpassade ROM-utvecklare kan slå samman uppdateringar, och som svar svarade Jeff Bailey upprepar att "modulerna som delar av AOSP kommer att ha källutgåvor som matchar varje modulutgåva." Vi kan redan se utvecklingen av nya APEX-moduler i AOSP, till exempel en för Neural Networks API.

CameraX möter ML Kit

På I/O i år introducerade Google CameraX Jetpack-bibliotek. Det här biblioteket är utformat för att göra det lättare för utvecklare att stödja Androids Camera2 API samtidigt som kompatibiliteten bibehålls hela vägen tillbaka till Android Lollipop. Vinit Modi retas som företaget arbetar med att integrera CameraX med ML Kit, Googles Firebase SDK för maskininlärning, så att utvecklare kan mata in bildramar i ML Kit för analys.

CameraX-leverantörstillägg och releasedatum

Utvecklaren av en kameraapp beklagar det faktum att avancerade kamerafunktioner som Google Pixels Night Sight inte är tillgängliga för kameraappar från tredje part. Detta är tänkt att kunna lösas med CameraX-leverantörstillägg, som Jeff Sharkey från Google till säger att "alla Pixel-enheter är optimerade för CameraX Core." Han retar att "Extensions-aspekten kommer att stödjas på nya och kommande enheter." Dessutom är Google "att samarbeta med flera tillverkare för att kunna erbjuda sina enhetsfunktioner till både utvecklare och användare." Även om det inte är direkt bekräftat, är det möjligt att vi kan se funktioner tycka om NattsynGoogle Pixel 4 bli tillgänglig för kameraappar från tredje part som använder CameraX-biblioteket.

Mr. Sharkey uppger att Google siktar på en betaversion i slutet av detta år.

Förbättringar av minneshantering i Android Q

Pixel 3 blev berömd för att ha många nummer efter lanseringen, men Google har gjort mycket för att ta itu med dessa problem via flera uppdateringar efter lanseringen. Minneshantering har varit en av Pixel 3:s svagaste aspekter, men saker och ting borde vara lite bättre i Android Q-utgåvan. Enligt Selim Cinek:

"I SystemUI till exempel, hade vi olika stora refaktoriseringsinsatser i Q för att minska RAM-användningen av meddelanden och andra ytor."

Kommer vi äntligen att få trådlös ADB?

Om du vill felsöka din telefon trådlöst måste du rota enheten. Jamal Eason från Android Studio-teamet säger att de för närvarande tar upp genomförbarheten av den här funktionen.

Testar Google fortfarande på surfplattor?

XDA erkänd utvecklare Luk1337 frågade om Google fortfarande testar AOSP UX på surfplattor. Det är en rättvis fråga med tanke på brist på bra Android-surfplattor och den buggar närvarande i aktuella utgåvor. Allen Huang säger att Google fortfarande "testar och fixar varje år" och att företaget arbetar nära med partners "för att säkerställa en bra Android-surfplatta-upplevelse."


Det finns många fler inlägg i hela tråden på Reddit. Det jag har tagit upp här sammanfattar all ny information vi lärt oss, men flera Googlers (särskilt Dianne Hackborn) gå in på deras resonemang bakom att skära av X-funktionen eller inte implementera Y lov. Jag rekommenderar att du läser hela AMA om du vill förstå Android-teamets beslutsfattande lite bättre.

Läs hela AMA på /r/AndroidDev