Hur Android Go kan hjälpa äldre Android-telefoner att köra Android 8.1 Oreo

Android Go är Googles avskalade version av Android Oreo 8.1 för nya enheter med låg RAM-minne. Som det visar sig kan det hjälpa anpassa ROM-utveckling på äldre enheter också.

Android Go är Googles avskalade version av Android baserad på Android 8.1 Oreo, och den syftar till att vara en optimerad version av Android för low-end-enheter med 1 GB RAM eller lägre. Det tillkännagavs i maj förra året på Google I/O Developer-konferensen, och så småningom avslöjades fler detaljer i december senare samma år. Den sägs vara gjord för nästa generations nybörjarenheter, för att säkerställa att de i utvecklingsländer kan fortfarande använda fungerande smartphones för att få tillgång till internet och använda appar.

Go har ett brett utbud av prestandaoptimeringar och förbättringar, inklusive att ta upp 50 procent mindre lagringsutrymme än en genomsnittlig Android Oreo-installation. Tack vare Android Runtime (ART) och kärnoptimeringar också, kommer en enhet som kör Android Go i genomsnitt att köras 15 procent snabbare än på en vanlig Android Oreo-installation på samma enhet. Dessa optimeringar görs genom ett antal specialiserade byggkonfigurationer gjorda av Google, som vi kommer att förklara senare.

Android Go drar också nytta av speciella "Go"-applikationer, som t.ex Files Go, YouTube Go och Google Maps Go. Det här är lätta versioner av applikationer från Google, som har minskade krav på att köras mer effektivt. Detta innebär att de med Android Go-enheter kan njuta av de flesta av samma fördelar som vanliga Android Oreo-användare också kan, vilket gör använda Googles programsvit utan att behöva spendera mycket pengar på ett flaggskepp eller till och med något dyrare budget enhet.

Allt handlar om att Google utökar sin marknad. Ändå väcker det frågan att om Android Go mestadels består av en byggkonfiguration och en svit med optimerade Google-appar, kan utvecklare göra sina egna versioner av Android Go? Kortfattat, Ja det kan vi.

Ett fåtal LineageOS-utvecklare bygger redan Android Go-optimerade anpassade ROM

Vi ser redan något av en uppgång i Android Go från vissa anpassade ROM-utvecklare, till exempel av XDA Recognized Developer AdrianDC, med sitt arbete på LineageOS 15.1 med Android Go-byggkonfigurationer för flera gamla Sony-telefoner. Enheterna i fråga är Sony Xperia SP, Sony Xperia T, Sony Xperia V och Sony Xperia TX. Dessa enheter går alla tillbaka till åren 2012 och 2013, men de kommer ändå att få LineageOS 15.1 baserat på Android 8.1 Oreo med en Android Go build-konfiguration, som kan göra det möjligt för enheterna att köra Google 'Go'-appar smidigt, om en Android Go-uppsättning Gapps så småningom skulle bli släppte.

Varje enskild LOS-underhållare bör kunna introducera en Android Go-konfigurerad build, med det som en uppsättning byggkonfigurationer och andra optimeringar. Vad detta betyder är att de som kan ha köpt Sony Xperia T till exempel, en enhet som kör Android 4.0.4 Ice Cream Sandwich vid lanseringen, kommer att kunna använda en bättre optimerad version av Android 8.1 Oreo på enheten, med användning av applikationer som YouTube Go och Google Maps Go. Det kommer inte att köras på flaggskeppsnivåer av prestanda, men det borde det vara användbar– speciellt för en enhet som går tillbaka till 2012.


Hur Android Go kan hjälpa äldre Android-telefoner att köra Android Oreo

Byggkonfigurationer på Android är en uppsättning parametrar som hänför sig till olika aspekter av Android-systemet som tillämpas när systembilden kompileras för att blinka på en enhet. Vanligtvis ändrar dessa hur systemet beter sig, och Android Gos huvudsakliga optimeringar kommer från dessa byggkonfigurationer.

Byggkonfigurationerna som används för att kompilera Android Go.

Jag pratade med XDA Recognized Developer joshuous, som hjälpte mig mycket att förstå förändringarna som ägde rum – vad som verkligen får Android Go att fungera. Vissa av dessa byggkonfigurationer kan inte ändras utan omkompilering och är en del av ritningen av själva ROM-minnet. Dessa är flaggorna med fullt versaler.

Alla dessa flaggor hänför sig dock till många olika aspekter av Android relaterade till lagring och minnesanvändning. Dessa inkluderar automatisk lagringshantering, Androids lågminnesdödare, dex (dalvik executable files) optimizer och RAM-gränser för att köra appar. APK-filer består av dessa DEX-filer, så på ett sätt är det möjligt att tänka på en APK-fil som helt enkelt en ZIP-fil som innehåller massor av .dex-filer, vilket faktiskt är vad Android kör när den kör en Ansökan. Automatisk lagringshantering kommer istället att styras av applikationen Files Go, inte Android-systemet.

Android Go Utilities Androids låga RAM-läge

I Android 4.4 KitKat introducerade Google en ny flagga som heter "låg-ram", som syftade till att stödja enheter med 512 MB RAM. Det gör ett antal optimeringar av systemet. Dessa förändringar är oerhört fördelaktiga för enheter med lägre RAM-minne.

Förbättrad minneshantering

  • Validerade minnesbesparande kärnkonfigurationer: Byt till ZRAM.
  • Döda cachade processer om de är på väg att vara uncachade och för stora.
  • Tillåt inte stora tjänster att sätta sig tillbaka i A Services (så att de inte kan orsaka att startprogrammet dödas).
  • Döda processer (även om de vanligtvis inte går att döda, t.ex. nuvarande IME) som blir för stora vid inaktivt underhåll.
  • Serialisera lanseringen av bakgrundstjänster.
  • Avstämt minnesanvändning av enheter med låg RAM: snävare justeringar för out-of-memory (OOM), mindre grafikcacher, etc.

Dessa ändringar ovan säkerställer i princip att systemet ser till att använda komprimerat RAM-minne där det är möjligt, genom att använda ZRAM. ZRAM är i grunden en RAMdisk (ett lagringsmedium som använder RAM, mycket snabbare än att använda vanlig lagring på enheten) som en swap-fil. En växlingsfil används när RAM-användningen är hög och applikationer fortfarande kräver minne. Detta är mycket, mycket långsammare än RAM och bör undvikas där det är möjligt. I huvudsak komprimerar det helt enkelt innehållet i minnet.

Minskat systemminne

  • Trimmade system_server och SystemUI processer (sparade flera MB).
  • Förladda dex-cacher i Dalvik (sparade flera MB).
  • Validerat JIT-off-alternativ (sparar upp till 1,5 MB per process).
  • Minskad typsnittscache per process.
  • Introducerade ArrayMap/ArraySet och används flitigt i ramverk som en ersättare med lättare fotavtryck för HashMap/HashSet.

Det som mestadels händer här är bara minskad minnesförbrukning från olika processer som körs på enheten, för att vara så konservativ som möjligt. Viktiga systemtjänster har tagits bort för att använda så lite minne som möjligt i bakgrunden, eftersom varje megabyte RAM är viktig.

Android Go använder en modifierad lågminnesdödare och dex-optimeringar

Med tanke på att Android Go främst är för enheter med 1 GB RAM eller mindre, kommer det att behövas mer aggressiv minneshantering. Android Go modifierar Low Memory Killer (LMK) på några olika sätt. Först, när en stor mängd av RAM-minnet är förbrukat, går den låga minnesmördaren till en "kritiskt tryck" stat. Detta beror på att när minnesanvändningen är hög kommer systemet att bli trögt på grund av att man ständigt försöker komma åt en växlingsfil på enhetens lagring. Att hålla RAM-minnet rent förhindrar att systemet behöver använda den här växlingsfilen och förhindrar minnesstörning. Minnestrashning inträffar när enhetens minne är fullt och ständigt måste söka efter växlingsfilen på enhetens lagring, vilket försämrar prestandan kraftigt.

Tjänster och WiFi-tjänster är inställda på "hastighetsprofil," vilket betyder att utvalda metoder i dessa tjänster kompileras i förväg (Ahead-of-Time). (En metod hänvisar till en uppsättning kod som kan anropas när som helst med namn.) Detta minskar RAM-användningen och lagring, eftersom Android-systemet inte behöver kontinuerligt kompilera om viktiga tjänster som körs på enhet. Under tiden är delade APK-filer inställda på "quicken", vilket är designat för att ge extra batteritid och extra CPU-cykler genom att optimera dex-instruktioner för att få bättre prestanda.

När det gäller dex-optimeringar gör Android Go ganska mycket. Till att börja med, efter 10 dagar kommer det att göra det nedgradera en applikation om den inte används för att spara utrymme. Nedgradering här syftar inte på att det faktiska versionsnumret för applikationen minskar, utan snarare innebär det att dalvik_cachen för appen kommer att raderas. Dalvik-cachen används så att enheten inte behöver kompilera om appar, istället kompilerar den bara de mest nödvändiga delarna av den och cachar det. Resten kompileras med hjälp av JIT-kompilatorn (Just in Time) när applikationen körs. Om applikationen dock inte används på 10 dagar, tas även de väsentliga delarna av applikationen som är förkompilerade bort. Detta görs för att frigöra så mycket utrymme som möjligt. En annan enkel ändring är att inte tillåta en apps RAM-användning att överstiga 256 MB så att en app inte kan använda allt RAM-minne på enheten.


Är Android Go framtiden för anpassad ROM-utveckling på low-end-enheter?

För närvarande vet vi inte svaret på detta, men framtiden ser ljus ut för anpassad ROM-utveckling på äldre enheter. Det kan finnas andra problem med att få en nyare version av Android att köras på en enhet, men i teorin, en uppgradering till en mer optimerad Android Go baserad på Android Oreo skall få en äldre, low-end enhet att fungera bättre.