https://github.com/android-ndk/ndk/issues/26
Licensing actually did not play a significant part in the decision. The other reasons that @DoDoENT mentioned are correct though (yes, GCC 5.x supports C++14, but new features definitely do happen more quickly in clang). The biggest reasons for why we made this decision actually haven't been mentioned though:
So, GCC was good to build Android for 10 years and now, suddenly is not, and google must ditch it.
Things change. GCC isn't good for Android any more because GCC doesn't provide the same security features that Clang does (and when it does, it provides them much later).
An incomplete list of why the platform switched to clang:
- We make extensive use of integer overflow sanitizers in shipping code to prevent issues like stagefright from recurring
- Address sanitizer and libfuzzer are used widely in testing
- Clang's better diagnostics catch a ton of bugs that GCC does not
- Control flow integrity and safe stacks are being deployed (are deployed?) for even more exploit mitigation.
The fact is that we have significant reason to invest in clang, and splitting effort across maintaining two compilers makes both of them worse.
As it stands now, both compilers are fairly comparable in terms of performance and code size. #21 points at code size increases for armeabi-v7a. That is not always the case, and for every other architecture we actually see smaller code. From some analysis I did when we made this decision for the platform:
It seems our 32-bit ARM devices are typically 1MB larger (out of 600MB-900MB total), whereas volantis is slightly smaller, and fugu is 15MB smaller. Strangely, sprout_b is also slightly smaller.
I think the ARM32 numbers are small enough to not bother anyone, especially given that it looks like it will be a win for the new devices since they're aarch64.
All the comparisons we did showed that Clang and GCC were pretty much equivalent quality when it came to the code they produced. Yes, sometimes we find cases where GCC is faster, but we also find cases where Clang is faster. As an example, we saw a 20% performance improvement in the ART interpreter when we switched to clang.