# ARMv7 vs FAT in Unity Android Build Settings (release multiple valid APKs)

If I select ARMv7 instead of FAT (ARMv7+x86) in the Android Build Settings of Unity5-Free, the APK binary drops to half size.

FAT => ~20MB
ARM => ~10MB


(Tested with an empty scene, no assets, nothing, just the core libraries).

I've seen the "official stats" of the CPU usage are here:

http://hwstats.unity3d.com/mobile/cpu.html

So not a lot of business to loose as for the date of publishing this question. But x86 seems to be an increasing trend.

Questions:

1. Is there any way to publish a binary to the ARM users and another version to the x86 users but with the same product-id so if they change the mobile phone, the software gets properly downloaded (but still each one gets a small footprint)?
2. Does this CPU correlate with WinPhone? Or is an othogonal measure? In other words: Are all Androids ARM? Or there are ARM and x86 Androids?

Thanks!

## 1 Answer

1. you can publish different versions of your APK targeting different CPU architectures, with the same package name:

Build an ARMv7 only package and an x86 only package with different version codes. The versionCode of the x86 package has to be higher than the one of the ARM package.

When publishing, send both of your APKs to the developer console. Note that you need to be in "advanced mode" to distribute multiple APKs.

2. There are ARM and x86 Androids, there is no x86 WinPhones yet.

• Perfect answer! Key in "advanced mode" which is the one that supports "multi-APK". If you only upload one, platform is not depicted, but if you upload multiple ones, a new field on the screen appears to distinguish plaftom-target. Thanks! Feb 3, 2016 at 15:19
• For the sake of clarity to other readers: I played around doing the x86 version code smaller and ARM greater just to check what happened. An explanation is given in real-time by the console in this sense: All ARM phones just get ARM APKs. Instead, some x86 phones may accept ARM APKs in addition to the x86, to execute via emulation. If you put the x86 with a smaller number, then those "dual-devices" are going to get the ARM version as it has a higher humber, forcing emulation. So ARM first, then x86 higher to force all x86 devices go native instead of emulating. Feb 3, 2016 at 15:20