Tekniska bloggspel, Android-app-apk, tips och tricks

Vad Google säger om Android 10 på Reddit

Android Q AMA: allt vi lär oss av Google

Deltagare i Android Q beta-teamet

  • Adam Cohen: TLM på Android Launcher / System UI
  • Adam Powell: TLM i UI-verktygssatsen / ramverket; display, livscykel, utdrag, lib-support
  • Alan Viverette: TLM, Jetpack / AndroidX
  • Allen Huang: PM för UI, lanseringar, aviseringar, sökintegration och mer!
  • Andrew Sappirstein: TLM i 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-plattformsäkerhet
  • Charmaine D’Silva: PM för integritet
  • Chet Haase: Chef för Android Defense, Developer Relations
  • Diana Wong: PM, applikationskompatibilitet, användning av andra API: er än SDK, ART, NDK
  • Dianne Hackborn: Android-ramhanterare (resurs, fönsterhanterare, aktivitetshanterare, flera användare, utskrift, tillgänglighet etc.)
  • EK. Chung UX-direktör
  • Lake Ian Programvaruingenjör, Jetpack (fragment, navigering, arkitektoniska komponenter)
  • Iliyan Malchev: Main Software Engineer, Main Project
  • Jacob Lehrbaum: Direktör för utvecklarrelationer för Android
  • Jake Wharton: Software Engineer, Jetpack
  • Jamal Eason: PM, Android Studio
  • Jeff Bailey: TLM, Android Open Source Project (AOSP)
  • Jeff Sharkey: Software Engineer, Android Framework
  • Jeffrey van Gogh: Android Studio, kompilator
  • Jen Chai: PM, plats och kontext, autentisering, autofullständig, användning av API: er utan SDK, ART
  • Karen Ng: PM Group för utvecklingsverktyg för Android, Android Studio, Android Tookit och Jetpack
  • Paul Bankhead: Director of Product Management, Google Play
  • Rohan Shah: Produktchef, Android-systemgränssnitt
  • Romain Guy: Android Team Manager / Jetpack Toolkit
  • Sagar Kamdar: Director of Product Management, Android
  • Lördag K: Teknisk chef, Android Connectivity
  • Selim Cinek: Software Engineer, Android System User Interface
  • Stephanie Saad Cuthbertson: Senior Director of Product Management, Android
  • Sumari Kataria: Software Engineer, Jetpack (WorkManager)
  • Travis McCoy: PM, Android-plattform
  • Trystan Upstill: Kära ingenjörer, Android UI-ledare och intelligenssystem
  • Vinit Modi: PM, Android-kamera

OEM-tillverkare kan inte längre radera applikationer när användare sveper dem i en ny överföring

Om du någonsin har använt en kinesisk märkesmartphone, kanske du har att göra med en irriterande “batterioptimering” -funktion som tar bort alla dina favoritapplikationer från bakgrunden. Detta beteende är inte bara irriterande för användare som förväntar sig att vissa applikationer fortsätter att köra i bakgrunden av någon anledning, utan också irriterande för utvecklare som måste drabbas av dålig kritik från användare som inte förstår att det inte är ett applikationsfel. Medan Google fortfarande hanterade inte detta problem helt (de tog omedelbart upp problemet genom att hävda att detta beteende kunde bryta mot kraven i Android Compatibility Definition Document), företaget vidtog åtgärder för att ändra “batterisparande” beteende av olika tillverkare av originalutrustning.

“För att hjälpa till med denna situation har vi lagt till ett CTS-test på Android Q för att säkerställa att applikationen inte togs bort när den försvann nyligen.”

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

Google planerar att lägga till skärmdumpar på Android R, men samtidigt tar Android-teamet “uppmärksamhet på hur (de) kan förbättra upplevelsen på full skärm (X) för R.” Därför kan vi se en annan förbättring av skärmdumpningsbeteende (OCH screencast) i nästa stora version av Android.

Förklar det nya skrivbordsläget för Android Q

Den första offentliga betaversionen av Android Q presenterar ett doldt gränssnitt för skrivbordsläge för AOSP och Pixel Launcher. Även om Google kort berörde funktionen under Googles I / O-session har vi aldrig hört direkt från Google om hur denna nya funktion passar in i Android-ekosystemet. Google klargör nu:

“I Q-läge AOSP skrivbordsläge” är ett utvecklingsalternativ för applikationsutvecklare. Detta gör att de kan testa sin applikation i en miljö med flera fönster och skärmfria lägen. Tidigare fanns det inget enkelt sätt att testa applikationsbeteende på den sekundära skärmen och genom att ändra storleken på den fria Windows Stock Android. Denna funktion är inte egenproducerad och är inte avsedd för vanliga användare för tillfället. Detta är dock grunden för Android-plattformen för tillverkare av originalutrustning att förnya och göra fantastiska produkter. “

Som sådan kan vi förvänta oss att se OEM-apparater integrerade i det ursprungliga skrivbordsläget för Android Q. Till exempel stöder OnePlus 7 Pro utgående display via HDMI, så kanske OxygenOS 10 baserat på Android Q kommer att ha sitt eget skrivbordslägegränssnitt i framtiden. Vi hoppas också att Google gör pixelfunktioner. 4 framtid

Mörkt läge baserat på tid

Android Q ger slutligen en mycket efterfrågad funktion: systembrett mörkerläge. För närvarande kan mörkt läge aktiveras manuellt i inställningar eller via snabbinställningsbrickan, eller det kan aktiveras automatiskt när batterispararen är aktiverad. Före Android Q fanns det ett alternativ att aktivera mörkt läge baserat på tid på dagen, men det alternativet är föråldrat. Enligt Chris Banes:

“Det finns ett antal skäl till att detta inte längre används (inte raderas) i AppCompat v1.1.0: det kräver att applikationen begär tillåtelse för dess exakta plats, och även med en giltig plats kan det beräkna avgångstider och solnedgångar vara fel.”

På frågan om detta fel, Mr. Banes uppgav att “beräkningen av soluppgång / solnedgång är mycket populär, särskilt för platser nära nord- / sydpolen.” Användaren visar Night Light, som är tillgängligt från Android 7.1 Nougat, det kan aktiveras automatiskt beroende på Sunset / Sunrise schema. Banes uppgav senare att eftersom Night Light använder CalendarAstronomer ICU4J, använder den “det mesta av koden som AppCompat inte vill lita på.” Teamet förklarade dock inte denna funktion som “något de kommer att undersöka.”

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

Google introducerade API för Camera2 för att bättre bestämma hur applikationer kan interagera med varje kamera ansluten till din smartphone. Medan Google uppmuntrar smartphoneleverantörer att “exponera alla sina fysiska kameror för utvecklare” väljer många leverantörer att inte göra det, även om “själva API: n inte hindrar dem idag.” Detta innebär att många tredjepartskameraprogram inte kan använda moderna tertiära kameramoduler eller sekundära smartphones. Framsteg görs dock, eftersom Android Q har förbättrat LOGICAL_MULTI_CAMERA, ett API som ger utvecklare bättre tillgång till alla kameror på enheten och ger OEM-kontroll över strömförbrukning och hantering av olika kameraförhållanden.

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

“Från och med Android P krävs en ny enhet med 1 GB eller mer RAM för att kunna använda den ursprungliga HALv3 / camera2. Android Q, etc., Alla nya enheter behövs för att stödja den ursprungliga HALv3 / camera2. Tyvärr är det ganska komplicerat att uppdatera från HALv1 till HALv3 luft och kan ha oväntade konsekvenser, så vi måste begränsa omfattningen av nya enheter. “

Intressant nog står Modis uttalande om det normala RAM-kortet för Android P-lanseringsenheten i motsats till vad vi sa tidigare av Google och vad som publicerades på webbsidan Image Test Suite.

Din dynamiska applikation med Jetpack Compose

Sony CSO-temaramen har lagts till i AOSP i flera återlanseringar, men är endast avsedd att skapa OEM-tillverkare. Vi vet redan att Google motsätter sig användningen av användarresursbeläggningar under körning för temapplikationer, men för utvecklare förväntar sig företaget att Jetpack Compose UI-ramverk ska främja en “intressant strategi för dynamiska teman.”

Vulkan-backend för Skia för att göra användargränssnittet

Förra året såg vi en diskussion bland Google-ingenjörer som talade om sina planer på att skapa ett Android-ramverk med Vulkan grafiska API för att göra användargränssnittet. Även om det nu är möjligt att aktivera en backend som påskyndar Vulkan-hårdvara utan att din mobiltelefon går sönder, har vi aldrig hört talas om en specifik plan från Google när de planerar att starta denna förändring. Denna AMA svarar inte på den frågan, men vi har åtminstone bekräftat att den fortfarande fungerar. Enligt Romain Guy:

“Teamet har arbetat med Vulkan backend för Skia, 2D-renderaren som används av Android, men är för närvarande inte aktiverat som standard. UI och Canvas går fortfarande via OpenGL ES.”

Gör Android Q-gestfältet mer dynamiskt

Vissa på XDA tycker fortfarande att det nya Android-steget är en röra, men personligen tycker jag att det är bra. Om du spelar med nya drag på Android Q ett tag kommer du att se att rörelsefältet inte rör sig med fingret. Den håller sig också fast vid skärmar där det inte behövs, som hemskärmen eller den senaste appöversikten. Allen Huang sa att “de var helt överens om att det fanns en möjlighet” att göra “navigationslinjer mindre statiska.” Han sa också att “detta är något vi arbetar med, men det är också balanserat så att det inte stör / försvinner.”

Få förbättrad åtkomstram

De många förändringarna i Android Q har förbättrat plattformens säkerhet och integritet kraftigt. En av dessa förändringar, kallad “Scoped Storage”, begränsar applikationens åtkomst till filer till extern lagring på ett sätt som är vettigt; Musikapplikationer behöver till exempel inte se ditt galleri. Filhanteringsapplikationen som körs på Android Q måste använda ett API som heter Storage Access Framework för att fortsätta fungera normalt, men vissa utvecklare anser att detta API är lägre än vad som tidigare var tillgängligt. Jeff Sharkey från Google sa att teamet hade löst några av dessa klagomål för utvecklare:

“Vi har gjort några förbättringar av SAF-prestanda i den senaste versionen av Android Q Beta; kan du jämföra dina riktmärken med den senaste betaen? Se också till att använda ContentProviderClient när du utför massoperationer.”

Project Treble ökar antagandet av Android Pie kontra Android Oreo

Vi har sett hur Project Treble, den huvudsakliga omorganiseringen av Android-ramverket, har ökat antagandet av nya versioner av Android-operativsystemet. Google berömde Treble bakom många leverantörer av smarta telefoner som anslöt sig till Android P beta förra året och Android Q beta i år. Iliyan Malchev, projektchef och Treble engineer på Mainline, sa att antagandet av Android Pie var “3x” från Android Oreo i slutet av 2018.

I samma kommentar hävdade Dick Dougherty att det finns mer användbara statistik för Android-versionen av distributionskortet. Detta diagram uppdaterades senast i maj, men uppgifterna är mer användbara för journalister än applikationsutvecklare.

Skärminspelning är fortfarande WIP

Betaversionen av Android Q lägger omedelbart till en flaggfunktion till den grundläggande skärminspelaren, men själva plattformen har förbättrat skärminspelningsverktyget kraftigt genom att applikationer kan fånga ljud från andra applikationer. Stephanie Saad Cuthbertson sa att teamet överväger “hur vi kan öka behovet av skärminspelning från och med igår.” Andra smarttelefonmärken som OnePlus, ASUS, Huawei och Samsung har kraftfulla skärminspelare som kan spela in internt ljud, så Google kommer att komma hit.

Mörkt tema alla!

Om du saknar det lägger Google till mörkt läge i de flesta av sina applikationer. Stephanie Saad Cuthbertson sa att han hoppades att alla “kärnapplikationer” skulle stödja mörka teman “för officiell release (Android Q).” Till och med Google Chrome, som för närvarande tvingar laddning av sidor när mörka teman aktiveras i hela systemet, kommer att uppdateras så att de inte längre uppdateras när temat ändras.

Ja, tredjepartsstartare kommer att arbeta med gester (äntligen)

Android-rörelsen bryts lite när du använder en tredjepartsstarter. Detta beror på att applikationens senaste användargränssnitt finns i applikationen för åtgärdsstartare och Google har inte hittat ett sätt att ha samma smidiga övergång som vi ser när vi använder gester med action-pixel-startaren. Adam Cohen upprepade Googles plan att ta itu med denna fråga “så snart som möjligt efter lanseringen.” Han sade vidare att missanpassningen “kommer att tas upp i uppdateringen efter Q och vara kompatibel med nya enheter som släppts med Q.”

Dynamiska / logiska partitioner är inte här för att ta bort anpassade ROM-skivor

För att stödja dynamiska systemuppdateringar på Android Q använder vissa enheter som Google Pixel 3 och Pixel 3 XL logiska partitioner. Denna partition kan ändras storlek dynamiskt. Denna förändring är utmanande att få root-åtkomst att fungera, och vissa utvecklare är oroliga för att hitta en speciell ROM. Iliyan Malchev försäkrade oss om att hans syfte inte var att begränsa special ROM. När han förklarar:

“Dynamiska partitioner är inte avsedda att begränsa vad du kan göra med speciella ROM-skivor. Det är bara en lösning på problemet med fasta partitionsstorlekar och bristen på ett säkert sätt att partitionera enheter i OTA. Innan dynamiska partitioner, om OEM: er begick fel i att mäta till exempel systempartitioner, skulle de begränsat av det valet som gör det nästan omöjligt att lägga till enheter efter en viss punkt. Några OEM-indelare partitionerar sin enhet i OTA som en praxis men detta a) stöds inte officiellt med Android, och b) att ändra partitionstabellen anses vara ganska bullrig. problemet med att införa en nivå av bedrägeri mellan den fysiska partitionstabellen och operativsystemet. Detta i sin tur tillåter oss att ändra partitionsstorleken på ett säkert sätt till OTA. När det gäller anpassade ROM: er bör du inte vara begränsad eftersom du idag har vad Custom ROM-support kan göra är och är fortfarande ett val varje OEM som ska aktiveras. “

Mainstream Project – ART-modul och supportens längd

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

“Att göra uppdateringar till Runtime (särskilt prestandaförbättringar och GC: er och kärnbibliotek) är definitivt något vi utforskar i samband med mainstream. Vi kan se många fördelar eftersom det kan göra denna uppdatering konsekvent på alla enheter och vissa stora versioner. Detta är också en teknisk utmaning. vilket är enormt eftersom vi tänker på sätt att göra det bästa för utvecklare och en eventuell flerårig ansträngning. Detta är inte något som Mainline kan göra just nu, men det är naturligtvis något vi tänker på. “

Om du följer AOSP Gerrit ser du att Google fortfarande arbetar hårt för att skapa en APEX Runtime. För närvarande verkar de dela upp Bionic och ART / libcore i separata APEX-moduler.

Beträffande fördelarna med Mainline-projektet frågar användare om varaktigheten av Mainline-uppdateringen. Som svar sa Iliyan Malchev: “Detta är en policyfråga som vi fortfarande utvärderar, men vi vill uppdatera Mainline-modulen så länge som möjligt.” Den välkända utvecklaren XDA luca020400 frågar om en förbyggd Mainline-modul kommer att tillhandahållas så att anpassade ROM-utvecklare kan inkludera uppdateringar, och som svar upprepar Jeff Bailey att “modulen som separerar AOSP kommer att ha en källversion som matchar varje modulversion”. Vi kan redan se utvecklingen av nya APEX-moduler i AOSP, t.ex. det konstgjorda neurala nätverks-API.

CameraX följer ML Kit

Vid årets I / O introducerade Google CameraX Jetpack-biblioteket. Detta bibliotek är utformat för att göra det enklare för utvecklare att stödja Android Camera2 API samtidigt som Android Lollipop-kompatibilitet bibehålls. Vinit Modi fördömer att företaget arbetar med att integrera CameraX med ML Kit, Googles motor som studerar Firebase SDK, så att utvecklare kan infoga fotoramar i ML Kit för analys.

CameraX Vendor släppförlängning och släppningsdatum

Utvecklare av kameraprogram beklagar det faktum att kameraprogram från tredje part inte kan komma åt avancerade kamerafunktioner som Google Pixels Night Sight. Detta måste tas upp med CameraX-förlängningsleverantören, säger av Jeff Sharkey från Google, “alla Pixel-enheter är optimerade för CameraX Core.” Han fördömde att “tilläggsaspekten kommer att vara kompatibel med nya och framtida enheter.” Google “samarbetar med olika tillverkare för att föra funktioner för sina enheter till utvecklare och användare.” Även om det inte direkt bekräftas, kan vi se funktioner som Night Sight på Google Pixels 4 tillgängliga för tredjeparts kameraprogram som använder CameraX-biblioteket.

Sharkey uppgav att Google riktar sig till betaversionen senare i år.

Förbättrad minnehantering på Android Q

Pixel 3 förolämpas för att ha många problem efter lansering, men Google har gjort många saker för att lösa problemet genom flera uppdateringar efter lansering. Minneshantering har blivit en av de svagaste aspekterna av Pixel. 3, men saker och ting blir lite bättre i lanseringen av Android Q. Enligt Selim Cinek:

“På SystemUI har vi till exempel olika huvudsakliga Q-refactoring-ansträngningar för att minska användningen av anmälnings-RAM och andra ytor.”

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

Om du vill felsöka din telefon trådlöst måste du rota din enhet. Jamal Eason från Android Studio-teamet sa att de för närvarande hanterar genomförbarheten för denna funktion.

Testar Google fortfarande på surfplattor?

Den berömda XDA-utvecklaren Luk1337 frågar om Google fortfarande testar AOSP UX på surfplattor. Detta är en rimlig fråga med tanke på bristen på goda Android-surfplattor och buggar som finns i den aktuella versionen. Allen Huang sa att Google fortfarande “testar och gör förbättringar varje år” och att företaget arbetar nära med partners “för att säkerställa en god Android-surfplattaupplevelse.”


Det finns fler inlägg i full tråd på Reddit. Det jag diskuterar här sammanfattar all den nya informationen vi har lärt oss, men vissa Googlers (särskilt Dianne Hackborn) förstår dina skäl för att skära funktion X eller inte be om tillstånd Y. Jag föreslår att du läser hela AMA om du vill förstå beslutsfattande. Android-teamet är lite bättre.

Läs hela AMA i / r / AndroidDev

Vill du få fler inlägg som detta i din inkorg? Ange din e-post för att prenumerera på vårt nyhetsbrev.

Table of Contents