Ahogy egyre nyilvánvalóbb az Android létjogosultsága az ultramobil eszközök piacán, úgy feszül egymásnak az ARM és az Intel álláspontja is a processzor architektúrája szempontjából. Nyilvánvaló, hogy mindkét cég a saját nézetét ecseteli a piac számára, hiszen miért is mondanának olyat, ami veszélyeztetné az adott termék eladását, de annyira erős manapság már az ellentét, hogy érdemes a hivatalos álláspont mögé nézni. A vita alapját az Intel adja, hiszen a cég szerint az alapvetően ARM-hoz készült Android már működik x86 alatt is. Ezzel lényegében egyetért az ARM is, hiszen maguk a megjelent termékek bizonyítják az állítást. Emellé azonban azt is kijelenti az Intel, hogy a Google Play áruházba felkerülő alkalmazások több mint háromnegyede nem tartalmaz natív kódot, vagyis tökéletesen üzemképes az x86-os processzormagokon is, míg a natívan ARM-ra lefordított alkalmazások esetében a vállalat továbbra is bináris fordítást használ. Ezzel az Intel arra utal, hogy az elérhető applikációk 90-95%-a elindul az x86-os hardvereken is.

Az ARM szerint a fentiek nem teljesen fedik a valóságot, amit egy méréssel alá is támasztottak. A teszthez alapul vették az Egyesült Államok 100 legnépszerűbb alkalmazását. Ezt a megfelelő szelekció érdekében négy részre osztották, így a legjobb 25-25 darab ingyenes és fizetős alkalmazás, illetve játék került a tesztcsomagba. A januári felmérés során a 100 alkalmazás közül 3-ról nem volt információ, így ezek kiesnek a rostán, míg a maradék 97 applikáció közül 9 nem indult el x86-on, illetve 44-hez bináris fordítást kellett használni. 21 program nem használt natív kódot, míg 23 alkalmazásnak volt natív x86-os kódja. Ezzel szemben ARM-on 21 program szintén nem használt natív kódot, míg a maradék 76 applikáció szimplán futott natív módban.

Az adatokat összesítve 97 alkalmazásból az ARM-os rendszer 97-et képes úgy futtatni, ahogy azt a fejlesztő elképzelte, míg az x86-os rendszer esetében ez a szám 44. Előbbihez hozzájön még 44 extra alkalmazás bináris fordítással, de ennek a mérések szerint komoly ára van. Bár az Intel azt kommunikálja, hogy a megoldásuk nem jár lényeges hátrányokkal, ez a gyakorlatban láthatóan nem igaz. Egyrészt helyből erre vezethető vissza, hogy 9 alkalmazás el sem indult, másrészt a bináris fordítás lassabb és több energiát fogyaszt a natív programfuttatásnál. Erre jó példa az iGAO7 korábbi tesztje, mely az Atom Z2760-as rendszerchipen futtatott számos programot natív és bináris fordítást lehetővé tevő módban. Az eredményeket az alábbi táblázat részletezi:

Látható, hogy a bináris fordítás a szintetikus mérésekben jellemzően 60-80%-os tempóhátránnyal jár, miközben a fogyasztás is nő, hiszen a fordítással járó munka növeli a processzorhasználatot. Valós alkalmazást tekintve az Epic Citadel volt megjáratva, melyben 32%-kal esett a teljesítmény a natív módhoz képest, miközben 15%-kal nőtt a CPU-ra rótt terhelés, ami 15%-kal nagyobb fogyasztás eredményezett. Bár ezek az értékek szerencsére nem olyan kiugróak, mint a szintetikus méréseknél, ám így is olyan az eredmény, amit a felhasználó nem szeretne látni egy ultramobil eszköznél. Persze az Intel eleve csak a futtathatóságot emelte ki a bináris fordítás esetében, a felhasználói élményről már nincs hivatalos álláspont.

A nagy kérdés természetesen nem a bináris fordítás létjogosultsága. Nem is gondolja ezt igazán komolyan az Intel, csupán kényszerből alkották meg, hogy a natívan ARM-ra írt alkalmazások (amelyekből nagyon sok van) is fussanak x86-os processzoron, mivel a hosszabb távú tervben az szerepel, hogy az applikációkat ne csak ARM-ra, hanem x86-ra is lefordítsák a fejlesztők. Gondot jelent azonban, hogy a piac egy része az Intel bináris fordítójára úgy tekint, mint egy megoldásra, ami azért létezik, hogy az x86-os porttal ne kelljen törődni. Ez lehet, hogy a kevésbé tehetős programozók számára egyszerűbben járható ösvény, de ezzel a felfogással jelentősen rontják az Intel hardverein elérhető felhasználói élményt. Az ARM elemzése arra is rámutat, hogy az x86-ra natívan lefordított alkalmazások száma nehogy nőne, hanem egyenesen csökken, ami szintén kedvezőtlen.

A Google számára is kellemetlen a szituáció, hiszen beengedték az x86-ot az Android piacra, ami eleve küzd a fragmentációval. Mára minden szükséges eszközt megadnak a fejlesztőknek, hogy a natív ARM mellé natív x86-os programot fordítsanak, de ezt furcsamód nem teszik meg annyian, mint remélték. Itt lehet feltenni azt a kérdést, hogy miért nem? A Google mindenképp figyelhetne jobban az alkalmazások tesztelésére, így eleve nem kellene felkínálni letöltésre az elvileg kompatibilis, de a gyakorlatban már nem futó alkalmazásokat. Egy nem működő programot letölteni egyszerűen kiábrándító, függetlenül attól, hogy ki okozza a hibát. Természetesen lehetetlen tökéletes munkát végezni, de az elfogadhatatlan, hogy a legjobb 100 alkalmazás közel 10%-a nem indul el az adott eszközön, holott a Google Play felkínálta letöltésre.

Véleményünk szerint a probléma megoldása a fejlesztői támogatás lehetne. Az Intel abban látja a gondok gyökerét, hogy nincs elég Atom rendszerchipre épülő androidos eszköz a piacon, ami lehet egy ok, de nem az a megoldás rá, hogy majdnem ingyen kínálják a terméket a partnerek számára. Ettől a felhasználó még ugyanúgy belefut a fenti problémákba, ami sokat ronthat az Atom, illetve az Android megítélésén is. Célszerűbb lenne fejlesztői támogatásra fordítani azt a közel egymilliárd dollárt, amit az Intel negyedévente veszteségként elkönyvel az Atom terjedése érdekében. Ennyi pénzből már meg lehetne oldani rengeteg program natív x86-os portját, ami számottevően növelné a felhasználói élményt. Később persze be lehetne vezetni egy kedvezményes rendszert a gyártóknak, hogy az Atomot rakják bele a termékekbe, de előbb mindenképp az alapproblémát kellene megoldani, mert az agresszív terjesztés a fenti gondok mellett rendkívül kockázatos a márka megismertetése szempontjából.