Android O: s Autofill Framework kommer äntligen att lösa ett långvarigt fördröjningsproblem med lösenordshanterare

Det nya Autofill-ramverket i Android O kommer att lösa ett långvarigt eftersläpningsproblem i samband med lösenordshanterarens tillgänglighetstjänster.

Det har redan gått en månad sedan Google släppte första Android O Developer Preview (tiden går säkert fort!), och som med alla nya versioner av Android - det finns mycket att gräva i. Vi har publicerat massor av artiklar om Android O redan, men det finns en funktion som jag känner inte riktigt har fått den uppmärksamhet den förtjänar: Autofyll ramverk.

Autofyll i Android O

Lösenordshanterare är en krona ett dussin nuförtiden (även om vi är det delvis till KeePass med öppen källkod), men det är bara med Android O som Google verkligen officiellt stöder lösenordshanterare. Med Android O kan tredjepartsapplikationer fylla rollen av en autofylltjänst, som kommunicerar med appar genom det nya Autofill Framework. Appar som använder standard Se element kommer att fungera med Autofill Framework ur lådan, även om det finns ytterligare steg som utvecklare kan vidta för att 

optimera för autofyll för att säkerställa att alla appens anpassade vyer kan fyllas i automatiskt.

När en autofyllbar vy hamnar i fokus kommer Autofyll-ramverket att anropa en autofyll-begäran. Autofyll-tjänsten svarar genom att skicka tillbaka vissa Autofyll-dataset (som användarnamn, lösenord, adress, kreditkortsnummer etc.) som användaren sedan kan välja. Autofyll-tjänsten anges av användaren i Inställningar --> Appar och aviseringar --> Standardappar --> Autofyll-app.

Autofyll-app i Android O. Krediter: Lastpass.

Förklaringen av det nya Autofill Framework ovan är bara en kort sammanfattning av vad som händer i både den begärande appen och autofylltjänstens ände. Det som är viktigast för din förståelse här är inte de exakta detaljerna om hur autofyll fungerar i Android O, utan det faktum att lösenordshanterarens appar själva hanterar inte längre att upptäcka när en vy kan fyllas i automatiskt.


Rekommenderad läsning: AgileBits visar hur Android O: s Autofill Framework kommer att se ut


Autofyll före Android O

Jämför det med hur autofyll fungerade innan Android O. Innan lösenordshanterare hade någon form av officiell metod för att upptäcka när en vy kunde fyllas i automatiskt, var och en applikationen var tvungen att implementera en tillgänglighetstjänst för att skanna den aktuella vyn för att hitta autofyllbar fält.

Användningen av en tillgänglighetstjänst kan dock resultera i avsevärd eftersläpning under vissa förutsättningar. Fördröjningen förknippad med din typiska lösenordshanterarens tillgänglighetstjänst är dock så uppenbar att populära tjänster som LastPass till och med har supportsidor upp angående frågan. Dessa supportsidor berättar vanligtvis att din enda utväg för att hantera överdriven fördröjning orsakad av deras Tillgänglighetstjänst är att antingen inaktivera tillgänglighetstjänsten eller byta till att använda sin egen anpassade inmatning metod. Hur som helst, du förlorar all form av autofyllförmåga.

Men exakt varför verkar LastPass's tillgänglighetstjänst, eller någon annan lösenordshanterares tillgänglighetstjänst, orsaka så mycket eftersläpning? Anledningen är på grund av hur dessa lösenordshanterare måste använda tillgänglighetstjänster för att upptäcka inmatningsfält. En tillgänglighetstjänst attribut definieras i en XML-resursfil inom APK, så att vi kan se hur tjänsten fungerar genom att dekompilera APK-filen.

Nedan är resursfilen hämtad från dekompileringen av LastPass APK:


"@string/accessibility_service_description"
android: accessibilityEventTypes="typeViewFocused|typeWindowContentChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="200"
android: accessibilityFlags="flagReportViewIds"
android: canRetrieveWindowContent="true"
android: canRequestEnhancedWebAccessibility="true"
xmlns: andro />

Från detta kan vi hämta följande information: LastPass's tillgänglighetstjänst begär två händelsetyper att övervaka - TYPE_VIEW_FOCUSED och TYPE_WINDOW_CONTENT_CHANGED. Den gör detta eftersom den behöver veta när en app/webbsidas innehåll ändras eller hamnar i fokus, och sedan hämtar den det aktuella fönsterinnehållet för att leta efter eventuella lösenordsinmatningsfält. Men eftersom tjänsten ständigt gör detta på två extremt ofta skjutande tillgänglighetshändelser, resulterar det i eftersläpning. För en mer djupgående diskussion om hur tillgänglighetstjänster kan orsaka eftersläpning hänvisar jag till min tidigare artikel i frågan.


Rekommenderad läsning: "Arbeta som avsett" - En utforskning av Androids tillgänglighetsfördröjning


Android O dödar två fåglar med en sten

Före Android O fanns det inte så mycket som utvecklare av lösenordshanterare kunde göra för att mildra denna fördröjning. Det beror på att lösenordshanterare inte hade något sätt att veta när ett autofyllbart inmatningsfält fanns på skärmen utan att göra det möjligt för en tillgänglighetstjänst att ständigt övervaka dem. Men tack vare det nya Autofill Framework i Android O kan dessa lösenordshanterare nu dra tillbaka sina tillgänglighetstjänster. Istället kommer de appar som själva behöver inmata data att begära att Autofill Framework ringer autofylltjänsten som sedan skickar data. Tack vare detta nya ramverk kommer inte bara lösenordsinmatning att bli mycket lättare för användare eftersom de inte längre behöver förlita sig på en ytterligare inmatningsmetod, men fördröjningen förknippad med att aktivera lösenordshanterarens tillgänglighetstjänster kommer att vara en sak dåtid.

Jag vet att för vissa av er kanske detta faktum inte är banbrytande, men jag tänkte att eftersom diskussionen kring tillgänglighetstjänsten var så tyst så kunde det här ämnet ha varit värt att ta upp igen. Bara lite att tänka på i helgen!


Vad tycker du om Android O: s nya Autofill Framework? Låt oss veta i kommentarerna nedan!