Sure, this is why it's adopting a structure similar to Blaze, Buck and others with smaller modules, not to mention sharded compilation with Instant Run. The whole reason for Blaze, Buck, etc. existence is that common build systems fail at huge applications used at Google / FB / Microsoft scale. And yet that doesn't seem to stop adoption of build systems like Maven, SBT, Gradle and all others which are used by vast majority of developers not working at GooAmaBookSoft scale.
> Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet.
Tools team is certanly aware of it.
> The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction.
Not sure how second follows from the first. React Native is gaining traction because it lets developers quickly develop for two platforms at once (just like Xamarin, Cordova, Ionic gained a lot of traction in enterprise before). Instant redeploy is very nice but hardly a huge deciding factor.
> Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time.
Huh, lack of proper build system is a huge headache when doing iOS CI builds. The compiler is also comparably slow for Swift/ObjC (especially if you add just a bit of C++ code) so I don't know how can you just dismiss it. It has very similar issues and the adoption didn't suffer.
> Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.
Not sure what you worked on (I'm guessing Gradle itself?) but it doesn't seem like you know all that much about building Android apps with Gradle in most companies out there.