I can give you my opinions: Clang is faster while compiling source code; has better support for c++14/c++17 and since it is designed primarily as library, it can be used from IDEs like Android Studio to perform static code analysis, refactoring and code completion.

Besides that, Clang is under more permissive open source licence, unlike GCC, which is under GPL. Thus, it is easier to make commercial clang clones which give better support for certain CPU architectures. Also, clang works better with libc++ than GCC, and many native code developers tend to use libc++ because, when compared to GNU stdc++, it has better support for c++14/c++17 STL features and is under permissive BSD-like licence - this makes it possible to use c++14/c++17 features in commercial android apps, like games. GNU stdc++ is under LGPLv3, which makes it impossible to use in commercial apps (yes, stdc++ has special exception for LGPL which allows usage in commercial apps, provided that you do not modify it - but this makes commercial app development very uncomfortable).

I believe that issues like #21 and #9 will be solved soon.

You mean that latest clang has better support than gcc 4.9, right? Because AFAIK gcc 5.x has full C++14 support.

Regarding the licenses IMHO you get it wrong. Personally I prefer GPL because it doesn't allow closed source clones, IMHO is fair to give something when you take so much.
GNU libstdc++ is GPL (NOT LGPL) but the special exception that you've mentioned allows everyone to freely use it and also to CHANGE IT as long as the changes made to libstdc++ are made public under GPL. IMHO it is quite stupid to keep these changes for yourself and not to upstream them, because you'll need to maintain them which is not for free.

Least but not last, let's not forget that Google switched to OpenJDK, which is GPL, therefore IMHO the licensing issue doesn't stand.

So, GCC was good to build Android for 10 years and now, suddenly is not, and google must ditch it.

I just gave my opinions - let the NDK guys give theirs. I think the tooling support in clang is probably the main reason for switching to it.

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.

@stephenhines might want to add more to this, but I think I covered most of the bases.

Regarding

new features definitely do happen more quickly in clang

As of today, that is not true : GCC has better C++17 compiler support than clang...

http://en.cppreference.com/w/cpp/compiler_support

Even more, GCC 6.2 has now faster compile times than clang, while still producing more optimised binary. Here are benchmarks from Phoronix (see page 3).

Thanks for the updates on GCC. We still have no plans to continue maintaining it, but I am glad that others in the community are still working on it.

As of today, that is not true : GCC has better C++17 compiler support than clang...

http://en.cppreference.com/w/cpp/compiler_support

The majority of those features are not in any released version of GCC. Clang hasn't finished it's release cycle either. You have more C++17 with our current Clang than you would with a current GCC, and odds are Clang will close the current gap before 4.0 is done.

Keep in mind my comment above. We have many other reasons to choose Clang, and do not have the resources to pursue both.

@DanAlbert @stephenhines : I understand that you don't have resources to maintain it (which sounds like a joke to me ... who could imagine that google can't afford to pay a gcc hacker to maintain it), but why don't you accept community contributions?

@jcelerier @DoDoENT My feeling is that the whole story is not about which compiler is better for google customers, instead is about control and what is better for Google. Google is one of the most GPL haters out there (or at least this is how it looks like), and an BDS like license is more "suitable" for them... Why? Well because the BSD licence allows the Google to choose what (or if) they share back with the community. Again, this is my personal feeling...