Android 11 AMA: Inga rullande skärmdumpar, snabbare appstarter, mer

I går släppte Google Android 11 Beta 2, vilket ger den färdiga SDK, NDK, app-vända ytor, plattformsbeteenden och begränsningar för icke-SDK-gränssnitt för utvecklare. Idag svarar Google på frågor relaterade till Android 11 över på Reddits /r/AndroidDev-community efter att ha ställt frågor förra veckan. Här är en sammanfattning av allt vi lärde oss från Googles AMA (Ask Me Anything).

En av Android 11:s mest efterlängtade funktioner kommer inte att vara tillgänglig när operativsystemet avslutar betaversionen den 8 september: Rulla skärmdumpar. Initialt planerad att lanseras i Android 11, Google har nu bekräftat att funktionen "inte gjorde snittet för R." Android 11 Developer Preview 1 och alla efterföljande DP- och betaversioner har en platshållarknapp för att ta en rullande skärmdump som kan vara dök upp manuellt med ett dolt utvecklarkommando

, men att trycka på knappen visar helt enkelt ett toastmeddelande som säger att funktionen "inte är implementerad."

Vi hoppades att funktionen skulle ta sig in i en betaversion eller till och med bara den stabila utgåvan, men det ser ut som att det bara inte kommer att hända.

Denna nyhet kommer förståeligt nog att vara upprörande för vissa användare. Trots allt har många OEM-tillverkare haft den här funktionen i sin egen programvara i flera år, så vad tar Google så lång tid att lägga till den i Pixel-telefoner? Som förklarat av Dan Sandler från Googles System UI-team är problemet att Google vill göra det rätt. Vissa implementeringar av rullande skärmdumpar där ute emulerar helt enkelt en rullning och syr sedan ihop flera skärmdumpar när skärmen rör sig. Om du någonsin har sysslat med UI-automatisering på Android, vet du att detta inte alltid fungerar eftersom, som Mr. Sandler nämner, appar kan använda "en myrstandard RecyclerView eller ha implementerat sin egen OpenGL-accelererade rullningsmotor." Eftersom Google planerar att implementera den här funktionen för inte bara Pixel-smarttelefoner utan för hela Android-ekosystemet som en del av AOSP, de måste se till det kommer att fungera Allt appar och inte bara "en eller två handplockade appar på en viss enhet."

Eftersom teamet var tvungen att "fokusera [sina] begränsade resurser", särskilt på grund av de utmaningar som medförts av COVID-19 beslutade teamet att lägga rullande skärmdumpar på bakbrännaren för en framtida Android-version.

Nytt CDD-krav för att informera användare om bakgrundsbegränsningar

Det är ingen hemlighet att många Android OEM, särskilt kinesiska, har aggressiva begränsningar för appar som körs i bakgrunden. Vissa utvecklare var så frustrerade över att deras appar dödades i bakgrunden att de gick samman för att skapa en webbplats som heter "Döda inte min app" att rangordna OEMs baserat på hur dåligt de hanterar bakgrundsappprocesser. Samma utvecklare gjorde till och med nyligen ett riktmärke så att användare kan testa hur aggressivt deras enhet dödar appar i bakgrunden. Anledningen till att många OEM-tillverkare älskar att döda bakgrundsappprocesser är komplicerad, men jag tror att det bäst förklaras i den här kommentaren av Redditor /u/möjligen tveksamt. Kommentaren beskriver den komplicerade statusen för Android-apputveckling i Kina, hur kinesiska teknikföretag är involverade i att ytterligare komplicera saker och ting, och hur brist på Google-tjänster bidrar till det pågående röra.

Oavsett så är många apputvecklare förståeligt nog frustrerade över dessa justeringar av Android-plattformens beteende, vilket har resulterat i att utvecklare trycker på en kommentar frågar Google vad de gör åt det till toppen av Reddit AMA. Här är Googles svar:

Det finns några saker att ta bort från detta svar. För det första vill Google att OEM-tillverkare ska vara mer transparenta med användarna om apprestriktioner i bakgrunden de tillämpar. Jag kollade (ej släppt) Android 11 Compatibility Definition Document (CDD) och hittade följande föreslagna tillägg till avsnitt 3.5 - API Behavioral Compatibility:

Om enhetsimplementeringar implementerar proprietära mekanismer för att begränsa appar och den mekanismen är mer restriktiv än "Rare" standby-bucket på AOSP, gör de:

[C-1-5] MÅSTE informera användarna om apprestriktioner tillämpas på en app automatiskt. (NYTT) Sådan information FÅR inte tillhandahållas tidigare än 24 timmar innan sådana begränsningar tillämpas.

(Obs) Force Stop anses vara mer restriktivt än "Sällsynt" och MÅSTE uppfylla alla krav under 3.5.1, inklusive nya 3.5.1/C-1-5

I grund och botten är Google inte mycket för att hindra OEM-tillverkare från att implementera sina egna restriktiva app-dödande funktioner. De kräver bara att OEM-tillverkare informerar användarna om deras appbegränsningar tillämpas automatiskt. En OEM kan visa en dialogruta att de kommer att stoppa batterisugande bakgrundsappar från att köras i bakgrund, och användaren kan samtycka utan att inse vilka appar de verkligen vill köra i bakgrunden också är påverkade! Google lägger ansvaret på utvecklarna att hantera fall där deras app oväntat dödas i bakgrunden. Faktum är att Reddit-kommentaren fortsätter att markera den nya "skäl för att avsluta appprocessen" API som kan berätta för utvecklare om deras app dödades av användaren, operativsystemet eller om den helt enkelt kraschade.

Å andra sidan tar Google äntligen upp den orättvisa praxisen hos OEM-tillverkare som tillåter vissa privilegierade applikationer att kringgå deras begränsningar för bakgrundsappar. Detta medelstora inlägg av utvecklare Timothy Asiimwe går in i detalj om appar som WhatsApp, Facebook och andra appar är automatiskt undantagna från de hårda bakgrundsbegränsningarna för vissa OEM-program. Google säger att de "kräver att enhetstillverkare inte skapar tillåtelselistor för toppappar." Vi vet inte hur detta kommer att genomföras, men det är bra att veta att OEM-tillverkare äntligen kommer att tvingas behandla tredjepartsutvecklare på lika villkor – oavsett hur stora eller små deras appar är är.

Slutligen nämner Google också hur Android 11 har "lagt till extra åtgärder för att förhindra kränkande beteende genom att missbruka appar", vilket gör det mindre lockande för OEM-tillverkare att aggressivt döda bakgrundsprocesser. Bolaget har dock inte utvecklat vad dessa "extra åtgärder" innebär.

Förbättrade Device-to-Device Backups

Förra månaden såg vi en förändring i Android 11:s dokumentation som antydde stöd för bättre lokala säkerhetskopieringar av data. I Android 11 kommer systemet att bortse från attributet allowBackup Manifest för alla appar som är inriktade på API-nivå 30 när användaren initierar en "enhet-till-enhet"-migrering av appfiler. Googler Eliot Stock säger att den här funktionen är avsedd att göra det "mycket enklare för telefontillverkare att bygga enhet till enhet migreringsverktyg" som "Samsungs utmärkta Smart Switch-produkt" till hjälpa till att "se till att appar överförs mer tillförlitligt mellan enheter ur ett användarperspektiv." Tyvärr gäller detta inte för molnbaserade säkerhetskopior, eftersom Google vill "ge mjukvaruutvecklare kontroll över vad händer med deras appdata." Som sådan kommer Android 11 fortfarande att respektera allowBackup-attributet för all molnbaserad säkerhetskopiering och återställning, till exempel via Google Play-tjänstens inbyggda Google Drive säkerhetskopiering. Slutligen erkänner Google att backuptaket på 25 MB per app kanske inte är tillräckligt för vissa utvecklare, så de undersöker sätt att lösa det. Lokala säkerhetskopior till en PC övervägs dock inte, och Google upprepar sin plan att göra det fasa ut adb backup i en framtida Android-version.

Utvecklare uppmuntras att implementera friktionsfria datamigreringsmetoder. De nya Block Store-biblioteket, som är en del av Google Identity Services Library, är utformad för att göra det enklare att logga in på återställda appar från molnet på nya enheter, men det är upp till utvecklarna att välja om de vill implementera detta eller inte bibliotek.

Snabbare appstartshastigheter med I/O Read Ahead Process (IORap)

Google experimenterar alltid med sätt att förbättra prestanda i Android. En av de föga kända funktionerna de lade till i Android 10 kallas Unspecialized App Process Pool (USAP). Den här funktionen eliminerar splittring av Zygote under appstartsprocessen, vilket sparar cirka 5 ms i genomsnittlig appstarthastighet på en Pixel 2-enhet. Funktionen är för närvarande inaktiverad som standard i AOSP, och Google förklarar att dess extra minnesanvändning fortfarande behöver testas. Vad som dock är mer intressant är en ny funktion som kommer till Android 11 som heter I/O Read Ahead Process (IORap). Enligt Google, kommer den här funktionen att leda till "mer än 5 % snabbare kallstarter med hjältefodral som når 20 % snabbare." Denna funktion "kommer att förhämta applikationsartefakter (som kod och resurser) under startprocessen" för att öka appstarten hastigheter.

Google har också "gjort förbättringar av profilerna som används för att optimera startklassens sökväg och systembild" vilket kommer att förbättra appens prestanda och minska minnes- och lagringskostnaderna förknippade med systemet artefakter. Dessa förändringar kommer främst att gynna enheter med högre mängd RAM, även om Google inte har sagt vad gränsen är för där vi kommer att se de största fördelarna.

Android 11:s scoped Storage-ändringar – Varför är åtkomsten till /nedladdningar begränsad?

Appar som är inriktade på Android 11 och använder ACTION_OPEN_DOCUMENT_TREE-avsikten för att begära åtkomst till specifika kataloger på den externa lagring kommer inte längre att kunna be användare om åtkomst till rotkatalogen för den externa lagringen (/data/media/{användare}), nedladdningen katalog (/data/media{user}/Download), eller någon av de appspecifika datakatalogerna på den externa lagringen (/Android/data eller /Android/obb). Varför är åtkomsten till nedladdningskatalogen begränsad? Enligt Google Roxanna Aliabadi, det beror på att nedladdningsmappen "har störst risk att ha privat information." Som ett exempel, användare som laddar ner sin skatt returer eller kontoutdrag ska inte behöva oroa sig för möjligheten att appar missbrukar sin kontinuerliga läsåtkomst till katalog. Google säger att dokumentväljaren kommer att ha "uppdaterad text... för att indikera att Android har begränsat vissa mappar att väljas." Detta kommer förhoppningsvis att minska förvirringen om varför de inte kan ge appar åtkomst till vissa kataloger längre.

För mer information om de kommande ändringarna av policyändringar för Scoped Storage and Play, hänvisa till den här artikeln.

Diverse ämnen

• Googles inställning till rooting/modding
  • Jeff Bailey från Googles AOSP-team upprepar företagets ståndpunkt om att stödja val. Google kommer att "fortsätta att se till att modding/rooting av Pixel-enheterna är möjliga", men kommer också att "stödja OEMs val att inte tillåta sina enheter att vara rotad." Dessutom ger Google mjukvaruutvecklare valet "att inte tillåta deras programvara att köras på rotade enheter", med hänvisning till de senaste ändringarna i mjukvarumanipuleringsdetektering av SafetyNet Attestation API.
• Vad hände med "öppna och inställd på standard"?
  • Android 10 tillverkad det är lite irriterande att ställa in en app som standardhanterare för specifika länkar, vilket Google säger gjordes för att skydda användare från "exploitativa appar". Google backade på denna förändring efter att ha omtänkt den, och gjort ett "antal ändringar bakom kulisserna" för att skydda användaren.
• Använder du Vulkan Graphics API för att rendera användargränssnittet?
  • Google planerar så småningom att använda Vulkan Graphics API för att återge användargränssnittet, vilket kommer att ge vissa prestandaförbättringar. Detta är utvärderas fortfarande, men företaget hade inga detaljer att dela med sig av.
• Saknar CallScreeningService på många enheter
  • Android-appar kan implementera CallScreeningService API för att avlyssna nya inkommande och utgående samtal, så att de kan identifiera den som ringer och antingen acceptera eller avvisa samtalet. Även om detta är ett officiellt dokumenterat API, finns det tydligen många OEM-tillverkare som inte implementerar det korrekt, enligt utvecklaren /u/_zeromod_. Google bekräftar att detta API är validerat av Compatibility Test Suite (CTS), en automatiserad testsvit som alla enheter måste klara för att anses vara Android-kompatibla. Av någon anledning returnerar detta API null när det anropas på enheter från OEM-tillverkare som Huawei, Vivo, Xiaomi eller Samsung, så det är troligt att dessa OEM-tillverkare har en bugg i sin programvara.
• Inga planer på ett ramverk för ljudplugin
  • En utvecklare frågade Google om de planerar att implementera ett ramverk för ljudplugin som Apples ljudenheter, men svaret är att det är osannolikt att det händer inom en snar framtid.

Du kan läsa alla svar från Android-ingenjörsteamet här. Teamet pratar lite om Java, Kotlin, Android-byggsystemet, CameraX API och andra ämnen i några kommentarer. Det finns också flera kommentarer om Wear OS, Android TV och Android Auto, men Google upprepar oftast deras befintliga arbete på dessa plattformar och uppmanar utvecklare att hålla sig uppdaterade för mer information under "Android Beyond Phones"vecka som börjar den 10 augusti.