Intervju med utviklere av SaberMod og Hyper Toolchains

For å kompilere ethvert Android-prosjekt som en kjerne eller ROM, må utviklere bruke en verktøykjede. Som per elinux.org er en verktøykjede et sett med forskjellige programvareutviklingsverktøy som er koblet (eller lenket) sammen etter bestemte trinn som GCC, binutils og glibc (en del av GNU Toolchain). Verktøykjeder kan inneholde en debugger eller en kompilator for et spesifikt programmeringsspråk som C ++ eller annet. Ganske ofte er verktøykjeden som brukes til innebygd utvikling, en kryssverktøykjede, eller mer kjent som en tverrkompilator. Alle programmene (som GCC) kjører på et vertssystem med en spesifikk arkitektur (for eksempel x86), men produserer binær kode (kjørbare filer) for å kjøre på en annen arkitektur (f.eks. ARM).

Den mest brukte verktøykjeden er GCC, som opprinnelig ble utgitt for snart 20 år siden. En lett modifisert GCC brukes av Google under AOSP-byggeprosessen. Mens Googles GCC anses å være den mest stabile verktøykjeden rundt, har den noen ganske anstendige konkurrenter som Linaro og SaberMod. Disse prosjektene er kjent for å øke den generelle systemytelsen betydelig på mange enheter. La oss ta en rask titt for å se bakgrunnen til disse prosjektene.

Linaro-organisasjonen ble grunnlagt i midten av 2010, og utviklerne begynte nesten øyeblikkelig å jobbe med mange prosjekter, inkludert GCC-baserte verktøykjeder for ARM. Android builds kompilert med Linaro begynte å dukke opp noen måneder senere. Helt siden Linaro-gruppen ble grunnlagt, priset brukerne den for anstendige ytelsesforbedringer og generell snapiness. Linaro bruker sine egne løsninger og blir kontinuerlig oppdatert. Du kan laste ned den nyeste versjonen av verktøykjeden direkte fra websiden.

Noen år senere, i 2013, opprettet en utvikler ved navn Paul Beeler SaberMod-prosjektet. Opprinnelig ble prosjektet brukt på SaberMod ROM for Nexus 7 WiFi-modellen (2013). Dette fortsatte inn på Nexus 4 og Nexus 5 ved hjelp av brukerdonasjoner. Verktøykjedene er basert på GNU GCC 4.8, 4.9 og 5.0 med AOSP-lapper fremover portert inn i GNU GCC. SaberMod gir også ekstra optimaliseringsfunksjoner i motsetning til Googles verktøykjede, som gir alternativer for noen få endringer i selve ROMen for å legge til flere ytelsesgevinster, for eksempel optimalisering av grafittløkketransformasjoner. SaberMod sporer andre verktøy fra GNU i kildekomponentene til verktøykjeden som generelt er mer oppdatert enn AOSP eller Linaro verktøykjeder, og sporer nesten alltid utviklingsgrenene til GNU GCC for de siste oppdateringene og feilrettelsene. Økosystemet til verktøykjeden i SaberMod er veldig forskjellig fra AOSP, og bruker komplekse skript for å gi raske, oppdaterte verktøykjeder. Andre kilder til verktøykjeder som AOSP-baserte arkivbyggelagre er blitt kraftig modifisert for å fungere til fordel for måten SaberMod-verktøykjeder blir produsert. Jeg har henvendt seg til noen verktøykjedeutviklere for å stille noen spørsmål.

Hvis du kan beskrive SaberMod i ett ord, hva ville det da være og hvorfor?

Joe (frap129) : Optimalisering. Jeg sier dette fordi det er vårt (SaberMod-lagets) hovedmål, ikke nødvendigvis hastighet. Selv om optimalisering kan gi mye ytelse og hastighetsøkning, kan den også gjøre ting som krympe kode eller legge til spesifikke justeringer som gir bedre bruk av maskinvaren til en enhet.

En verktøykjede er ikke spesielt lett å utvikle. Kan du fortelle meg hvilke språk og verktøy som kreves for å kompilere et prosjekt som SaberMod?

Joe : Det kreves mange programmer før man selv bygger en verktøykjede, akkurat som Android. Ting som bison, libpython-dev, programmene du bare ser i en guide for å sette opp en build-maskin for å kompilere en ROM og deretter glemme. I likhet med Android er det mange repos og prosjekter som trengs, den viktigste GCC-koden, BinUtils, GDB, MPFR og MPC er det minste minimum, men for ekstra funksjoner og ytelse legger vi til andre prosjekter og biblioteker som GMP, CLooG, ISL, OSL, og Python. Dette høres sannsynligvis ut som tull, men tenk på disse som den eksterne mappen i Android build source, tingene i bakgrunnen som får den til å fungere.

Adin (YoshiShaPow) : Når det gjelder språk, krever ikke utvikling fullstendig flyt av noe kodespråk (selv om det sikkert hjelper mye). Bare kunnskap om kodestruktur og grunnleggende syntaks kan hjelpe noen til å produsere bra arbeid!

Kan du fortelle oss hvorfor du valgte verktøykjeder? Og hva har vært den vanskeligste situasjonen du har opplevd så langt?

Paul : Til å begynne med var jeg interessert i Linaro verktøykjede, men fant ut at det var ganske mange feil som ikke var til stede i AOSPs verktøykjeder. Så beslutningen ble tatt om å lage en ny verktøykjede basert strengt på GNU GCC, og AOSP verktøykjettkilder, med Linaro ROM-patcher for optimalisering av jellybean. Dermed ble SaberMod født. Flere modifikasjoner i verktøykjeder og android systemkilde kom i årene etter. Det vanskeligste var å få verktøykjedene til å samle seg på samme måte som AOSP gjør, og finne ut hvilke versjoner av GNU-verktøy (binutils, gdb etc.) som var nødvendige for å få verktøykjedene til å samle riktig.

SaberMod er ikke det eneste prosjektet du jobber med. Kan du fortelle oss noe om Hyper Toolchains?

Joe : Hyper Toolchains var opprinnelig bare en side som jeg opprettet på GitHub for å hjelpe til med å organisere mine egne verktøykjeder, så de blir ikke bare rotete og kastet inn med resten av repoene mine, men etter at jeg begynte å rote med verktøykjeder mer og mer, jeg endte med å lage ting som var ganske annerledes enn standard SaberMod, Linaro eller AOSP GCC verktøykjeder. Blandende aspekter ved Linaro og SaberMod utvidet spekteret av ting utviklere kun kunne gjøre med verktøykjeder. Det var da jeg bestemte meg for å legge en tråd på, slik at devs kunne ha mer kontroll over hastigheten og glattheten i prosjektene deres, ikke bare ha hastigheten og responsen til SaberMod eller glattheten til Linaro.

SaberMod og Hyper Toolchains er utviklet av et team av utviklere. Kan dere alle fortelle oss litt om dere selv?

Paul : Min interesse for Android startet med G1 for snart 4 år siden. Jeg hadde ingen erfaring med koding. Jeg var interessert i åpen kildekode, men hadde ingen anelse om hvor jeg skulle begynne med å lage en ROM eller kjerne eller noe for den saks skyld. Jeg begynte med å eksperimentere med android bash scripting for native apps2sdext basert på et utviklerarbeid fra firerat. Dette tillot mer lagringsplass for apper som var veldig begrenset den gangen (500 MB for system og apper). Etterpå fortsatte jeg dette for Evo-skiftet 4g fram til Nexus 7 da mod ikke lenger var nødvendig fra lagringsbegrensninger. Jeg startet også en del kjerneutvikling med Evo Shift 4G ved å inkludere andre diskplanleggere som BFS som ingen andre hadde gjort for enheten den gangen. Jeg fortsatte kjerneutviklingen til Nexus 7. Men min kjerneutvikling anses fortsatt som lav annet enn å endre ting her og der for å få kjernene til å kompilere med SaberMod-verktøykjeder og optimaliseringer. Jeg eier for øyeblikket en Nexus 5.

Joe : Vel, jeg begynte å jobbe med utviklingsting for litt over 2 år siden med null erfaring innen koding, Linux eller Android. Som tenåring som nettopp hadde oppgradert fra en gammel jailbroken iPod til en fancy ny første generasjon Nexus 7, bestemte jeg meg for å rote med Android så mye jeg kunne, til slutt kompilere mine egne nattlige bygg med apper, skript og modi lagt til. Etter en stund sluttet jeg da Nexus 7 min tragisk knuste (RIP i stykker). Når jeg lagret nok til å få en brukt GS3, lastet jeg ned den nyeste kilden, begynte faktisk å jobbe med ROM-kilde, og begynte å bygge mye av programvaren på PC-en min også. Jeg har nylig fått en OnePlus One, som gjorde utviklingen mye enklere og ga meg mer motivasjon.

Adin : Det første androidprosjektet mitt ble opprettet i løpet av den tiden jeg hadde hjernerystelse og var utenfor skolen tilbake i april 2014. Da jeg endelig fikk OK til å være på elektronikk, bestemte jeg meg for å prøve ut et Android-prosjekt og endte opp med å lage en tilpasset kernel for Moto G. Jeg hadde heller ingen kunnskap om koding og Linux på den tiden. Noen mennesker sier at det er sprøtt for en 15 åring å kunne gjøre disse tingene, men jeg ser det som motivasjon for å strebe etter bedre. Med det har Joe og jeg laget en serie TGM-hybridkerner. Jeg kan også løse en 3 × 3 Rubik's Cube på 15 sekunder i gjennomsnitt. Min nåværende daglige driver er OnePlus One.

Takk for tiden og lykke til med prosjektene dine!

SaberMod og Hyper Toolchains finner du på og GitLab. Sørg for å ta en titt på dem hvis du planlegger å gi ut din egen tilpassede ROM. Hva er din favoritt verktøykjede og hvorfor? Del tankene dine i kommentarene nedenfor.