© 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. CloudBees Accelerator does it automatically and guarantees build accuracy.
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.
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 CloudBees Accelerator. When it comes to Android, however, as of this writing, IncrediBuild is a non-starter because it only supports Windows development platforms. That leaves CloudBees Accelerator. Let’s compare it to open source solutions ccache and distcc:
CloudBees Accelerator | 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 CloudBees Accelerator.
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: CloudBees Accelerator 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.
Benchmarks created using Android M, gmake using 64 cores and ccache, CloudBees Accelerator 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 CloudBees Accelerator.
- 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, CloudBees Accelerator should be in your tool kit. It’s not just us. Here’s what one of our larger customers had to say:
Reducing build times was a key focus to enable faster time-to-market with new Android releases. With the unique technology in CloudBees Accelerator 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.
Accelerate your Android Builds for free
Learn More about CloudBees Accelerator and Download CloudBees Accelerator Now!