Google samarbetar med Qualcomm för att göra det enklare att leverera programuppdateringar, vilket möjliggör 4 versioner av Android OS och 4 år av säkerhetsuppdateringar.
För över 3 år sedan, Google tillkännagav Project Treble, en stor omarbetning av Android utformad för att påskynda programuppdateringar. Medan arkitekturen som introducerades av Project Treble har hjälpt OEM-tillverkare att påskynda leveransen av större Android OS-uppdateringar och månatliga säkerhetskorrigeringar, det har haft en negativ effekt på SoC-leverantörer som Qualcomm. Faktum är att Treble faktiskt har ökat komplexiteten, och därmed de tekniska kostnaderna, som är förknippade med att tillhandahålla Android OS-uppdateringsstöd för en given chipset. Det har begränsat längden på support som Qualcomm kan tillhandahålla för sina SoCs, men det kommer snart att ändras. Alla Snapdragon SoCs lanseras med Android 11 eller senare – startar med Snapdragon 888, Qualcomm kommer att stödja 3 versioner av Android OS (lanseringsrelease + 3 bokstäver uppgraderingar) samt 4 års säkerhetsuppdateringar. Det är ytterligare ett år än vad de tidigare gav för sina flaggskeppskretsuppsättningar i 800-serien.
Dagens tillkännagivande är betydelsefullt, men det kan inte förstås utan bakgrundskunskapen om vad Google försökte åstadkomma med Project Treble för 3 år sedan.
Diskant skapade en uppdelning mellan Android OS-ramverket (inklusive all UI-kod, API: er och systemprocesser som appar interagera med) och enhetsspecifik mjukvara på låg nivå (inklusive den underliggande Linux-kärnan och hårdvaruabstraktionsskikten, eller HAL). Den enhetsspecifika mjukvaran på låg nivå kommunicerar med Android OS-ramverket genom en väldefinierad, stabil leverantörens gränssnitt. Varje Android OS-version garanterar bakåtkompatibilitet med leverantörsimplementeringen, vilket Google säkerställer genom att använda leverantörstestsviten (VTS), en standardiserad efterlevnadstestsvit. Detta innebär att till exempel Android 11 OS-ramverket är bakåtkompatibelt med leverantörsimplementeringen designad för Android 10. Faktum är att för varje ny Android-version publicerar Google Generic System Images (GSI), källbyggda systembilder som är bakåtkompatibla med de senaste 3 versionerna av leverantörsimplementeringar. När en OEM bygger en ny Android-enhet är de fria att modifiera Android OS-ramverket för att introducera nya proprietära funktioner och API: er, men de måste säkerställa att enhetens leverantörsimplementering är kompatibel med GSI.
Det här är i första hand hur Treble minskar fragmentering och påskyndar leveransen av nya OS-uppdateringar - det är mycket mindre brott när du parar Android OS-ramverket (som är öppet källa och tillhandahålls av Google) och den enhetsspecifika mjukvaran på låg nivå (som ofta är sluten källkod och tillhandahålls enligt kontrakt med SoC-leverantörer) tack vare den stabila leverantören gränssnitt. Idealiskt innebär det att OEM-tillverkare kan lägga mindre tid på att fixa buggar med hårdvara och mer tid på att portera sina systemnivåändringar ovanpå den senaste versionen av Android OS. Faktum är att sedan Treble introducerades säger Google att OEM-tillverkare har antagit den senaste versionen av Android OS mycket snabbare än tidigare. "När Android 11 lanserades fanns det 667 miljoner aktiva användare på Android 10, av vilka 82% fick sin Android 10-version via en OTA-uppdatering", säger Google.
Eftersom varje ny Android-utgåva lägger till stöd för fler hårdvarufunktioner (operativsystemet måste stödja nya funktioner för att hålla jämna steg med de snabba framstegen inom mobilbranschen), måste Google uppdatera leverantörens gränssnitt för det släpp. Företaget definierar alltså nya HAL-krav och kräver nya Linux-kärnversioner, men de kräver bara enheter sjösättning med den nya versionen av Android OS för att faktiskt stödja dessa leverantörspåverkande förändringar. Till exempel, om Google modifierar Androids kamera HAL för att stödja flera sensorer för bakre kamera, måste bara nya enheter som lanseras med den nya Android-versionen stöder den uppdaterade HAL, medan äldre enheter som uppgraderar till den nya versionen kan återanvända sin äldre leverantörsimplementering utan denna nya kamera-HAL krav. Detta minskar kostnaden och komplexiteten – ur ett OEM-perspektiv – för att ta med en ny version av Android OS till en äldre enhet. Problemet är dock att detta tillvägagångssätt introducerar ytterligare komplexitet för SoC-leverantörer som Qualcomm, MediaTek och andra.
Som ett resultat av denna designprincip måste Qualcomm och andra SoC-leverantörer stödja flera kombinationer av Android OS-ramprogram och leverantörsimplementeringar. En SoC-leverantör som stöder 3 generationer av Android OS-versioner för en viss styrkrets måste stödja 6 kombinationer av OS-ramprogram och leverantörsimplementeringar. Det beror på att OEM-tillverkare kan komma undan med att återanvända en äldre leverantörsimplementering för att kringgå ny HAL- och Linux-kärna versionskrav måste SoC-leverantörer säkerställa att deras leverantörsimplementeringar stödjer både det gamla och det nya krav. De får inte välja och vraka. Multiplicera det med de dussintals chipset som en SoC-leverantör måste stödja och du kan se hur Treble faktiskt har ökat komplexiteten för dem.
Det är av denna anledning som Qualcomm och andra SoC-leverantörer i allmänhet bara tillhandahåller maximalt 2 OS-bokstavsuppgraderingar och 3 års säkerhetsuppdateringar för en viss chipset. Även om jag inte är insatt i de exakta kostnaderna, antar jag att det inte är ekonomiskt möjligt för SoC-leverantörer som Qualcomm att stödja chipset mycket längre än så. Vi har sett Qualcomm och andra SoC-leverantörer ibland ge support under längre tid, men det beror på efterfrågan från OEM-tillverkare för att göra det ekonomiskt. Om det inte finns någon sådan efterfrågan, faller det på OEM-tillverkare att bära bördan av utvecklingskostnaderna för att ta fram en ny Android-version – och det är ingen lätt bedrift. Men tack vare de kombinerade ansträngningarna från Google och Qualcomm kommer det senare nu att stödja 4 Android OS versioner och 4 år av säkerhetsuppdateringar för utvalda Snapdragon-kretsuppsättningar, från och med Qualcomm Snapdragon 888.
För att göra detta möjligt har Google utvidgat Project Trebles "no-retroactivity-princip" till SoCs förutom enheter. Detta innebär att nya krav på HAL- och Linux-kärnversioner inte kommer att vara retroaktiva för SoCs. Så till exempel en SoC som lanseras med Android 11 (som Snapdragon 888) kan återanvända samma leverantörsimplementering för att stödja Android 12 till och med Android 14. Således kan SoC-leverantörer utveckla ett enda Board Support Package (BSP) för en viss chipset att distribuera till OEM, snarare än att underhålla flera versioner av BSP: n som måste uppdateras med varje ny Android släpp. Detta minskar dramatiskt tekniska kostnader förknippade med att stödja Android på en viss styrkrets, vilket ger SoC-leverantörer som Qualcomm möjligheten att stödja sina styrkretsar längre.
Google samarbetar också med Qualcomm för att säkerställa att den senare återanvänder samma OS-ramprogram på flera Qualcomm styrkretsar, vilket ytterligare sänker antalet OS-ramverk och leverantörsimplementeringskombinationer som Qualcomm måste Stöd. SoC-leverantörer modifierar för närvarande AOSP-ramverkets kod och bygger sina egna versioner av generiska systembilder. Qualcomms, till exempel, kallas QSSI, medan MediaTeks kallas MSSI. Dessa SoC-specifika systembilder kommer nu garanterat att vara kompatibla med flera chipset såväl som med äldre mjukvara från leverantörer, ungefär som Googles AOSP GSI.
Enheter med Qualcomm Snapdragon 888 förväntas lanseras mycket snart, med början i Xiaomi Mi 11 och Samsung Galaxy S21-serien. Även om vi hoppas att Google och Qualcomms tillkännagivande innebär att alla Snapdragon 888-enheter kommer att få 3 års Android OS och säkerhetsuppdateringar, finns det ingen garanti för att så kommer att vara fallet. OEM-tillverkare behöver fortfarande investera betydande summor för att utveckla och distribuera nya OS-versioner - men det är mycket mer sannolikt att hända nu när Qualcomm själva kommer att stödja 4 Android OS-versioner. Här hoppas vi att en eller flera OEM-tillverkare drar fördel av dagens tillkännagivande för att tillkännage utökat mjukvarustöd för sina framtida flaggskeppstelefoner som drivs av Snapdragon 888. De flesta OEM-tillverkare erbjuder bara 2 års Android-uppdateringar för tillfället, medan både Samsung och Google lovar 3 år. Det är fortfarande alldeles för kort jämfört med Apple och har med rätta ropats ut många, många gånger och kommer att fortsätta att ropas ut tills gapet har kortats.
När det gäller de andra SoC-leverantörerna är Google i samtal med dem för att tillämpa denna nya princip utan retroaktivitet så att de också kan tillhandahålla utökat mjukvarustöd för sina chipset. Vi har ingen bekräftelse från MediaTek eller andra SoC-leverantörer, men vi ser ingen anledning till varför de inte skulle vara med på denna idé – åtminstone för nya chipset. Enligt Google räknar de med att det mestadels bara är nylanserade SoC: er som kommer att dra nytta av dessa förändringar, så förvänta dig inte att någon av dina nuvarande enheter får utökat programvarustöd på grund av dagens meddelande.
Den här artikeln uppdaterades klockan 13:50 ET den 16/12/2020 för att ändra "enheter" i rubriken till "chipset" för att bättre återspegla var ändringarna kommer att träda i kraft. Ytterligare information har lagts till i artikeln med tillstånd av Google.
Den här artikeln uppdaterades klockan 14:10 ET för att återspegla att Google och Qualcomm lovar stöd för 4 Android OS-versioner – vilket betyder lanseringsreleasen plus 3 års Android OS-uppdateringar – snarare än 4 år med OS uppdateringar. Qualcomm lovar dock att tillhandahålla 4 års säkerhetsuppdateringar.