Android Build Times: The New Bottleneck

xkcd-code-is-compiling

© xkcd.com

As Android is becoming the platform of choice for everything from cell phones to home appliances to in-car management systems, the need to build and deploy faster has grown significantly.  Android device makers are under tremendous pressure to incorporate Google’s latest Android version – along with their own value add – in order to be competitive. One of the big challenges to improving the velocity of adopting new Android releases is the lengthening time required to build the Android operating system, which includes the Linux kernel.

As this table shows, the Android Open Source Project (AOSP) code size is increasing in both KLOC and the time it takes to build with gmake.

Android Release Initial Release Date Build Version Lines of Code Build Duration 1
Jelly Bean July 2012 4.3.1 29,725,532 35m35s
KitKat October 2013 4.4.4 46,328,885 61m58s
Lollipop November 2014 5.1.1 58,937,746 90m51s
Marshmallow October 2015 6.0.0 45,532,137 62m49s
Nougat August 2016 7.0.0 58,743,987 85m00s

1 Builds performed with gmake –j 8 on 32-core hyper-threaded PC with 256GB RAM and a striped RAID0 disk array

The problem is getting progressively worse with each feature-enhanced release, making Android builds the new bottleneck.  Dependencies in an Android build are very well maintained, so it is already possible to run the build with very high levels of parallelism – on the local machine.  However, 85 minutes is just too long for any developer to wait even if they are lucky enough to have a 32-core computer for the build.  Multiply that hour and a half by the size of the development team and a year’s worth of development time quickly gets sacrificed to the ping pong table.

So much for “market responsiveness.”

Google has done a tremendous job with maintaining the dependencies but not everybody has ready access to a 32- or 64-core machine on which to fully exploit that effort.  That much hardware is still a $25,000 or greater investment.  That’s not a viable alternative for most organizations.

So, if the goal is get that build time down to less than ten minutes, saving thousands of man-hours a year, then we need to look beyond simple dependency management and local parallelism to find more speed.

Where is the extra speed?

If parallelism is built in and buying more and more hardware is not a viable way to improve build times, where can time be squeezed out of the process?  Despite the impression that Google has already done everything that can be done, there are multiple ways Android builds can be accelerated.  The following table explains further:

What It Does Speeds Build Times…
Distributed Builds Exploits the parallelism native to AOSP by distributing the build process across all available resources – even to the cloud … due to more cores available than on the local machine
Resource and Schedule Optimization Ensures the best possible use of the CPU resources available in order to complete the build as quickly as possible … because it uses resources in the most efficient manner possible
Dependency Optimization Intelligently ignores overspecified dependencies and therefore run more things in parallel than might otherwise be possible. … because unneeded dependencies are ignored

 

(see sidebar)

Intelligent Cache/reuse Caching facilities that enable the reuse of work from other builds in the current build, rather than redoing that work from scratch … because it avoids doing work that does not have to be done
Build Analytics and Visualization Sophisticated visualization of build parallelization and dependencies …because it enables focusing effort on actual bottlenecks rather than guessing where they are

None of these capabilities are native to Android, which means going outside to find a solution.

So what’s the big deal about dependencies?  Plenty.

The data clouds below represent the specified vs the actual dependencies in the Android Jellybean release.  If you dump all the makefile rules you will get about 100,000 files and targets and nearly 2,000,000 dependencies.  It turns out you can ignore more than 80% of the specified dependencies during a build.

You can’t manually eliminate all those superfluous dependencies but you could write a script in gmake to do that and hope it works.  ElectricAccelerator does it automatically and guarantees build accuracy.

specified-dependencies actual-dependencies
Specified
1,990,628 dependencies
Actual
288,804 dependencies

Buy or Build?

The below flow chart illustrates the decision tree for solving your acceleration issues with Android.  You can develop your own internal solution, you can turn to open source or you can look to commercially available solutions.  Each has its benefits and drawbacks.

build-vs-buy-ci-build-acceleration-android

Custom

While developing your own customized solution in-house from scratch may be an interesting and satisfying technical challenge the reality is this option doesn’t make much sense for most organizations.  The time, support burden, and costs of internal development typically mean this isn’t a viable option, especially for a non-core, non-revenue tool.

Open Source

“Let’s go with open source.  It’s free,” is a common thought.  Tools like ccache and distcc that help with caching and distributed builds are well-known, and are extensible – to a point.  Unfortunately, like most open-source projects, these solutions have only small, part-time development staffs to support you in case things go badly.  And they don’t offer anything in the way of adaptive schedule optimization, guaranteed build dependency accuracy, fault tolerance or support for JACK.  Developers are on their own to figure out how best to use them, where to get help, troubleshooting, etc.  That’s another way of saying free isn’t really free.

Commercial Products

In the commercial build acceleration world there are only two options of note: IncrediBuild XGE and ElectricAccelerator.  When it comes to Android, however, as of this writing, IncrediBuild is a non-starter because it only supports Windows development platforms.
That leaves ElectricAccelerator.  Let’s compare it to open source solutions ccache and distcc:

ElectricAccelerator Open Source

Distributed Builds

Sharing across multiple servers

 
Sharing to cloud

Not dynamically
Fault Tolerance

 

Resource and Schedule Optimization

Adaptive schedule optimization

 

Cluster Sharing

 
Centralized Management

 

Grid Integration

 
Policy-driven resource allocation

 

Dependency Optimization

In-flight dependency correction

 
Removing unneeded dependencies

 ✘
Detecting missing dependencies

 

Intelligent Cache/Reuse

GCC

Yes, with ccache
JACK

 
Javac

 ✘

Build Analytics

Visualize parallel builds

 
Graphically Identify bottlenecks

 ✘
Troubleshooting builds

 ✘

While open source solutions are popular and well-known, they come up short in reducing the time and accuracy of Android builds.  In addition to speed, there’s enterprise reliability, scalability and the efficiencies of component reuse that are also important aspects of speeding time to market.  That’s all built in to ElectricAccelerator.

The Results

As with any comparison, the proof is in the pudding.  We ran tests with two prominent cell phone manufacturers’ Android code with stunning results: ElectricAccelerator was three times faster running on 1/3 of the cores.  Builds that were taking ¾ of an hour on 64 cores with gmake were taking 15 minutes or less on only 24 cores.

acceleration-results

Benchmarks created using Android M, gmake using 64 cores and ccache, ElectricAccelerator using 24 cores

That’s over 300% faster with fewer than half the resources!

Open Source Isn’t Always the Best Solution

While open source is initially an attractive option for solving many technical issues, when it comes to accelerating Android builds, it just doesn’t compare to the benefits of ElectricAccelerator.

  • Safely parallelize and distribute tasks
  • Leverage peer-to-peer multi-core desktops or scalable cloud infrastructure
  • Schedule optimization, ensures the best possible use of the CPU resources
  • Dependency optimization, intelligently ignores overspecified dependencies
  • Intelligent caching reuses work from other builds
  • Faster builds with fewer resources

Yes, we’re blowing our own horn here but if you need to get more Android releases out daily or weekly, ElectricAccelerator should be in your tool kit.  It’s not just us.  Here’s what one of our larger customers had to say:

huaweiReducing build times was a key focus to enable faster time-to-market with new Android releases.  With the unique technology in ElectricAccelerator 9.0, we were able to dramatically improve Android build times: release builds now complete in one-third the time, and incremental builds finish in under one minute instead of over six minutes.

James Lin ,   Sr. Manager, Development Tools, Huawei Technologies

 

In future blogs, we will talk further about additional ways to shorten Android build times through Build Analytics and Visualization, and Jobcache.


banner_huddle_free-build-accelerationAccelerate your Android Builds for free

Learn More about ElectricAccelerator and Download ElectricAccelerator Huddle Now!

Mohan Dattatreya

Mohan Dattatreya

General Manager, Acceleration Solutions at Electric Cloud
Mohan is responsible for product management, product delivery & strategy for Acceleration solutions at ElectricCloud. Mohan brings over 20 years of leadership experience in delivering innovative products at startups as well as at large companies. Prior to joining Electric Cloud, Mohan held leadership roles at Nortel Networks, Tasman Networks, SeriousEnergy and Cisco Systems.

Mohan holds a M.S in Computer Science from Stanford University and an MBA from Santa Clara University.
Mohan Dattatreya

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe

Subscribe via RSS
Click here to subscribe to the Electric Cloud Blog via RSS

Subscribe to Blog via Email
Enter your email address to subscribe to this blog and receive notifications of new posts by email.