Technical Report Accelerating Android Build on NetApp · Android application is generated in a...

Technical Report

Accelerating Android Build on NetApp NetApp March 2015 | TR-4394

Abstract

This technical report describes the characteristics and the I/O pattern of the Android build. It

contains information regarding the different challenges faced by the organizations using

Android for development and how NetApp® technologies can be used to accelerate Android

build time to achieve faster time to market as well as protect their investments and reduce

risks.

2 Accelerate Android Build on NAS © 2015 NetApp, Inc. All rights reserved.

TABLE OF CONTENTS

1 Introduction ........................................................................................................................................... 4

1.1 Scope ..............................................................................................................................................................4

2 Intended Audience................................................................................................................................ 4

3 Software Build Process ....................................................................................................................... 4

3.1 Android Build Overview ...................................................................................................................................5

3.2 Android Build I/O Pattern ................................................................................................................................5

4 Challenges in Android Build Environment ........................................................................................ 7

5 Approaches to Accelerate Builds ....................................................................................................... 8

5.1 Faster Developer Workspace ..........................................................................................................................8

5.2 Continuous Build Integration ...........................................................................................................................8

6 Approaches to Accelerate Android Build .......................................................................................... 9

6.1 Application Build Optimization .........................................................................................................................9

6.2 NFS Optimization .......................................................................................................................................... 11

6.3 Storage Optimization .................................................................................................................................... 12

7 Value of NetApp Storage in Android Build Environment ............................................................... 13

8 Conclusion .......................................................................................................................................... 14

Appendix .................................................................................................................................................... 16

Test Environment .................................................................................................................................................. 16

8.1 Android System Hardware Configuration ...................................................................................................... 16

8.2 NetApp Hardware Configuration ................................................................................................................... 17

References ................................................................................................................................................. 18

Version History ......................................................................................................................................... 18


LIST OF TABLES

Table 1) Distribution of the files before build ..................................................................................................................5

Table 2) Distribution of the files in the ‘out’ directory after build .....................................................................................6

Table 3) Android system hardware configuration. ........................................................................................................ 16

Table 4) NetApp hardware configuration. ..................................................................................................................... 17

LIST OF FIGURES

Figure 1 )Distribution of the files before build .................................................................................................................6

Figure 2) Distribution of the files in the ‘out’ directory after build. ...................................................................................7

Figure 3) Impact of increasing the thread parallelization. ............................................................................................. 10

Figure 4) Increasing the CCache. ................................................................................................................................. 11

Figure 5) Android build NFS optimization. .................................................................................................................... 12

Figure 6) Android build storage optimization. ............................................................................................................... 13

Figure 7) Test environment setup. ................................................................................................................................ 16


1 Introduction

Android is the market leader in the mobile operating system. It is widely used among mobile devices such

as smartphones and tablet computers and specialized user interface for televisions, cars, and wrist

watches. Android has over a billion active users, with more than a million new Android devices being

activated every day. Android is being extensively used by the semiconductor companies that make

systems on chips (SoC) and device drivers for the devices running Android OS.

With the increase in the number of Android devices being used every day, there is also an increase in the

number of developers working on the Android device drivers’ development. However, the organizations

building the device drivers for Android have to face many development and IT challenges, which affects

the time to market of the products.

This paper describes how NetApp technologies can be used to address the challenges of the Android

build environment to accelerate the build process, which results in the increase of the developer’s

productivity and lower time to market.

1.1 Scope

This technical report provides the reader with information that can assist in the faster build of Android on

NetApp storage. It contains information relating to performance of Android build across different storage

deployment options and other NetApp storage efficiencies that are beneficial in Android development

environments.

2 Intended Audience

This document is intended for use by individuals who are responsible for designing, architecting,

managing, and supporting Android development on NetApp storage. It assumes that readers are

knowledgeable about NetApp cluster storage solutions.

3 Software Build Process

Software build is the process of converting the source code into standalone artifacts that can run on a computer. The major component of software builds is code compilation, which involves converting source files into direct executable and intermediate object files in preparation for testing and then release. To understand the process and the I/O pattern of a software build, it is very important to understand how source code becomes an executable file.

There are three stages of software builds before which the source code is converted into an executable program:

Parser. The first step is to parse the source code using the parser. The parser converts the source code into a parse tree, which is a data structure representing the language constructs: variable declarations, type declarations, loops, expressions, and so on. After the parsing is done, all the header files and the macros that are included in the code are expanded. During this process a lot of read operations take place to locate the header files that need to be included in the program.

Compiler. When a source code is compiled, the compiler produces an intermediate compiled output. This intermediate output is in the form of object code that is actually executed by the computer.

Interpreter. Some programming languages use an interpreter, which converts the source code into intermediate form, which is executed by the interpreter instead of turning source code into machine code like the compiler does.

During the compiler/interpreter phase, large numbers of small files are generated, resulting in high metadata write operations.


Linker. After the object code is created by the compiler, it passes through the linker. The linker is a program that combines various modules and object code files into an executable program. After the data passes through the linker, an executable program comes into existence.

This phase is very read-write intensive because a lot of small number of intermediate object files are read and combined to produce an executable program.

The source code can be compiled and built using the makefile, which is the text files written in a certain

prescribed syntax. With the use of the make utility and the makefile, it helps to build the source files. It

also organizes the code and its compilation and linking. Makefiles can be run using following three

commands:

make. The make command only picks up what has changed from the last build and then builds only the changes without cleaning them.

make clean. The make clean command deletes all the object files created and builds the source files from scratch.

make clobber. The make clobber command also deletes all the object files, but it also deletes all the intermediate dependency files. It also builds the source files from scratch.

3.1 Android Build Overview Android, which is open source software, uses some predefined variables and series of makefiles in order to build Android and prepare it for deployment to a platform. Android make files end in the extension ".mk". Android has just one makefile to build the whole repository. The build output is put under the directories called "out/host" and "/out/target". Files under "out/host" are compiled for the host platform, whereas the build files under "out/target" eventually make their way to a target device, which is also known as the emulator.

3.2 Android Build I/O Pattern

The Android code base, which includes the source files, tools, and libraries, is approximately 17GB and

will generate an output of approximately 12GB when built. As mentioned before, the build output of the

Android application is generated in a directory called "out". Android version 4.01 has a large code base

with over 330,000 files before build, and it generates over 120,000 files after build. Most of the files are

less than 4k in size, which is laid out in a deep-dive directory, making the Android build workload very

metadata intensive. The distribution of the files before the Android source is built is shown in Table 1.

Table 1) Distribution of files before build

Size Number of Files

<4k 252383

4k – 8k 29641

8k – 16k 2217

16k – 32k 11952

32k – 64k 7757

64k – 128k 4187

>128k 6538


Figure 1) Distribution of files before build

As already mentioned, the output of the Android build is generated in a ‘out’ directory. The distribution of

the files, in the ‘out’ directory, after the Android source build is shown in table 2.

Table 2) Distribution of files in ‘out’ directory after build

Size Number of files

<4k 84402

4k – 8k 11958

8k – 16k 8199

16k – 32k 6998

32k – 64k 5321

64k – 128k 3867

>128k 7166

80%

10%

1%

4%

2% 1% 2%

File Distribution Before Build

< 4k

4k - 8k

8k - 16k

16k - 32k

32k - 64k

64k - 128k

> 28k


Figure 2) Distribution of the files in ‘out’ directory after build

4 Challenges in Android Build Environment

With the increase in the activations of Android OS, the number of developers working on the Android

build has also increased linearly. Many of the Android developers use local desktops for writing and

building the code. However, working on the local desktop creates many challenges that are being faced

by the engineering and IT departments. Some of these challenges are:

Longer time to create developer workspace. Organizations with a large number of developers use a software configuration management (SCM) tool to manage and keep track of the Android device drivers being developed. However, a large number of developers checking out the code in parallel creates a bottleneck in the network, storage, and the SCM server, which results in a longer time to create the developer workspace.

Increased build times. As mentioned earlier, on an average, some large device makers run over 50,000 builds per week. These builds consist of both the incremental and the complete builds. Complete builds are run during the integration phase, where the builds require more resources to build the Android device drivers. Hence, integration phase affects the build time of the incremental builds as well, making the build time inconsistent.

Inadequate data protection. Data protection and backup of the data are critical so that the hours and days of development are not lost. In many organizations, Android developers continue to use local desktops for creating user workspaces. This results in making the developer responsible for backup and data protection. Manual backup and data protection add overhead, which affects the productivity of the developer and risk of data loss.

Lack of scalability. Developers using the local desktop for the Android development copy the source code files from the central repository to the local workspace. There are times when the developer is working on multiple instances of the Android build from the different code lines. However, as the size of the code and the build grows, a developer may be limited by the hard disk space of the local desktop.

66%

9%

6%

6%

4%

3% 6%

File Distribution After Build

< 4k

4k - 8k

8k - 16k

16k - 32k

32k - 64k

64k - 128k

> 28k


5 Approaches to Accelerate Builds

5.1 Faster Developer Workspace

It can be challenging to get a quick copy of the Android source and to build it. Build times can increase if

multiple builds are done in parallel. With NetApp FlexClone® technology, the workspaces can be created

in seconds instead of hours. For this study, we are using Perforce as an example for the SCM tool.

Traditionally, there are two methods for obtaining a Perforce workspace:

A developer can create a p4 client, populate this client workspace with source code (p4 sync), and build the binaries. This takes an inordinately long time: in one use case, around 45 minutes to download the source code and another 1–2 hours to build the initial workspace.

Alternatively, the developer can use a fully populated prebuilt workspace using hard links back to the existing prebuilt workspace. This approach avoids the build step because it provides prebuilt objects. However, it is slow and error prone because files are shared among developers (using hard links) as well as with the build daemon. Any user can trash a shared file, and all the other users (including the build daemon) suffer.

To create faster workspace, developers can use NetApp FlexClone technology to create instant and

space-efficient clones of the production Android codebase. FlexClone technology is based on NetApp

Snapshot™

technology, which creates a writable point-in-time copy of the volume. The cloned volume

consists of only the data that change between the source and the clone, thus minimizing the storage

requirements. A FlexClone volume can be created in a few seconds because the technology creates a

copy of the metadata that is very small as compared to the actual data. A FlexClone volume can be

separated from the parent volume such that both volumes can work independently. However, new disk

space is only allocated when there is an addition to the parent or the cloned volume, saving additional

storage. For details on the process of creating Perforce faster workspace, refer to Accelerate the

Software Development Lifecycle Using NetApp Storage.

5.2 Continuous Build Integration

One solution to improve Android build is to make all the builds incremental. To make all the builds

incremental, there are two key requirements. First, it is required that the "makefiles" are modified to build

only the objects in which the source has been modified. Second is that the developer workspace consists

of all the prebuilt object files such that only the changes made in the code need to be built. This can be

made possible using NetApp FlexClone technology.

Using FlexClone technology, all the Android builds can be made incremental by creating a daemon

process, per code line, that runs periodically to check whether any new code has been checked in. If it

has, it syncs the new code using Perforce “p4 sync” and runs a build. If a build fails, the daemon process

files a bug and notifies all the developers who checked in the code since the last successful build. If a

build succeeds, it updates all the object files and closes the bug if previously filed. The process of

creating a build daemon process (prebuilt object files) involves the following:

1. Create a volume on the NetApp storage system.

2. Make the volume accessible using export and mount on the host’s server.

3. Run Perforce “p4 sync” on the host to populate the template workspace.

4. Run the build process in the template workspace to generate build artifacts.

5. Run the build process periodically to sync the new changes.

With FlexClone technology, it only takes time for the first full build and for incremental builds. This time is

amortized over all the users, because it takes only minutes for each user workspace to be created from

this central Snapshot copy of the built-out workspace. This is possible because cloning using FlexClone

http://www.netapp.com/ca/system/pdf-reader.aspx?pdfuri=tcm:44-129491-16&m=tr-4340.pdf



technology is instantaneous and also has the added advantage that new clones do not take any

additional space until changes are made to the workspace.

6 Approaches to Accelerate Android Build

A typical Android instance takes about 30 to 35 minutes to build on a shared environment; a reduction of

5 to 10 minutes would add up to almost 1,000 hours per week. The 15% to 20% overall improvement

would improve the productivity of the Android development, which leads to more development time and

faster time to market.

This section will describe each of the components, that is, application, NFS, and storage, that affect the

build performance and how they can be optimized for the overall improvement of Android builds running

on network-attached storage. The different optimization approaches used demonstrate the consistent

improvement in the wall clock time of the Android build.

6.1 Application Build Optimization

Some of the optimizations of the Android build environment are dependent on the version of the Android.

The application specific optimizations described in these sections are applicable only to Android version

4.0.1 and later.

Build acceleration from the server perspective can fall under two broad categories:

Hardware improvements: Maximize hardware and compute resources

Software improvements: Compiler options.

Hardware Improvements

The Android OS is based on GNU make, which can handle parallel tasks. Each Android build can run in

parallel using the "-jN" argument, where N is the number of tasks running in parallel. The value of N is

between 1 and 2 times the number of CPU threads on the computer that are being used for the builds.

An overall improvement of over 79% was noticed when a single instance of Android OS was built in

parallel with 32 jobs in parallel (argument "j32") as compared to running the build with 4 jobs in parallel

(argument "j4"). All the other parameters remain the same. The Android OS was built on NetApp storage

over NFSv3.


Figure 3) Impact of increasing thread parallelization

Software Improvements

Android OS uses a GNU compiler, which can take advantage of the "ccache". The option "ccache"

caches the output of the C and C++ compiler, such that the same compilation can be avoided and the

results can be taken from the cache. Android recommends cache size of 50GB to 100GB.

For this test case, eight instances of Android OS were built in parallel using the command "make –j16".

Figure 4 shows an improvement of 33% when "ccache" was enabled for the Android OS build.

0

10

20

30

40

50

60

70

80

90

100

4 16 32

Tim

e (

in m

ins)

Number of Parallel Jobs

Impact of increasing the thread parallelization

Build Time (Single AndroidInstance)

79% Reduction in Build

‘j4’ vs ‘j16’, 75% improvement

‘j16’ vs ‘j32’, 18% improvement


Figure 4) Increasing CCache

6.2 NFS Optimization

Developers working in the shared infrastructure use NFSv3 protocol to edit and build the source files. The

communication between the NFSv3 client and the storage happens over remote procedure calls (RPCs).

Traditional NFS has write-through caching. When a file is closed, ALL modified blocks are sent to a

server. The close() function does not return until each byte in each block is safely stored. However, if two

clients on a network are writing to a cached copy of the same file and issue a close command in close

proximity, NFS can't guarantee whose modified data will make it to the master copy. To avoid this

scenario, close-to-open cache consistency prevents two or more clients from modifying a file

simultaneously. Every client must query a server before modifying it. This trades off scalability with

consistency.

By default, if no NFS option is specified, the client uses close-to-open coherency semantics. If the "nocto"

option is specified, the client uses a nonstandard heuristic to determine when files on the server have

changed. However, the nocto option should only be used if the clients are using the files exclusively or if

the data on the server is changed occasionally.

For the study, Ubuntu 14.04 was used, which is the supported OS for the Android build. During the

testing, the "nocto" mount option was tested, and an improvement of 17.5% was noticed, as shown in

Figure 5.

0

10

20

30

40

50

60

70

0 100

Tim

e (

in m

ins)

Size of ccache

Increasing the CCache

Build Time (8 Android Instances)



Figure 5) Android built NFS optimization

6.3 Storage Optimization

With the growing size and complexity of the Android OS, it is very important to make the right choice of

the storage platform that can handle the concurrent I/O requests from the compute farm.

It is recommended to spread the file system across multiple volumes. It will lead to better inode and

directory file utilization on each volume. Spreading the data across multiple volumes reduces the

overhead of walking down the tree for a file system across different volumes and also it provides more

parallelism compared to having everything on the single volume.

NetApp recommends having four or more volumes to lay out the data as further improvements, as

mentioned before, are provided over a single volume. During the testing, it was observed that an

improvement of 15%, as shown in Figure 6, was observed when the instances of Android are spread

across four volumes as compared to a single volume.

0

5

10

15

20

25

30

35

40

45

NFSv3 NFSv3 'nocto' enabled

Tim

e (

in m

ins)

NFSv3

NFS Optimization


17.5% Reduction in Build


Figure 6) Android build storage optimization

7 Value of NetApp Storage in Android Build Environment

NetApp also provides the following features that help to improve the Android development cycle:

Storage efficiency

High availability

Unified storage

Data protection

Storage Efficiency

NetApp has many storage features that improve storage efficiency. These features help to provide high

data consistency and better data management and minimize the time to recover the data without affecting

the performance:

Deduplication. NetApp data deduplication and data compression help to boost storage efficiency. NetApp deduplication is a single-instance data storage technique that eliminates the duplicate copies of the redundant data. NetApp deduplication is very useful in Android development environments because it eliminates the redundant copies of the Android instances on which the developers are working.

25

26

27

28

29

30

31

32

33

34

1 4

Tim

e (

in m

ins)

Number of Volumes

Storage Optimization



http://www.netapp.com/us/products/platform-os/dedupe.aspx


Thin provisioning. Developers working in the shared environment tend to create bigger volumes, but most of them use little or none of that storage. However, NetApp has a feature called thin provisioning, which is designed to allow more logical space to the developer than it actually has in the pool of physical storage. Instead of providing the physical space upfront, storage space is dynamically allocated to the developer as the data is written.

High Availability

NetApp controllers have a good high-availability solution that improves reliability with low cost and

complexity:

HA cluster pair. HA cluster provides seamless failover to its partner in case of any hardware failure, without disrupting the Android build getting disrupted.

RAID DP. NetApp RAID DP® is a double parity RAID 6 implementation that prevents data loss when two discs fail.

Unified Storage

NetApp supports multiple storage protocols; for example, NFS, CIFS, FCP, and iSCSI can coexist on the

same storage. Ubuntu Linux® is the OS of choice for most of the Android developers; however, many

organizations rely on Windows® for the Android development. A file stored on NetApp storage can be

accessed by a Linux user using NFS as well as by a Windows user using CIFS.

Data Protection and Disaster Recovery

NetApp provides enterprise-class features for data protection that are embedded in the clustered Data

ONTAP storage that provides consistent backups and disaster recovery:

SnapMirror. NetApp SnapMirror® provides fast, efficient data replication and disaster recovery for your critical data. NetApp SnapMirror technology is based on Snapshot technology, which replicates only the changes that are being made to the data, making the data replication technique very efficient.

SnapRestore. NetApp SnapRestore® software is used to restore the Snapshot copies to recover entire file systems or data volumes in seconds.

Snapshot. The traditional approach for backup used by the developers, which includes making copies of the ongoing source files or using tape-based backups, results in additional overhead. Such disruptions can significantly affect the product development process. NetApp relies on its enterprise-class feature Snapshot technology, which creates Snapshot copies in less than a second, regardless of the volume size, eliminating long backup windows. Snapshot technology creates a dedicated volume that keeps track of all the backups that can be used to recover any previous version of the ongoing project. For further details on backup and recovery using Snapshot, refer to the Snapshot documentation.

8 Conclusion

There are numerous challenges faced by the large organizations that develop device drivers for the

Android operating system. With the increase in the number of developers running Android build in

parallel, the challenges for the organizations to support Android build are immense. However,

organizations can rely on NetApp storage to address the challenges in the development of Android device

drivers. This paper highlights the techniques to optimize the application, network, and storage to

accelerate the Android build time running in the shared environment.

NetApp has solutions with clustered Data ONTAP and its enterprise-class features to support

development of Android device drivers:

https://library.netapp.com/ecmdocs/ECMP1196981/html/GUID-B7CB9621-4E27-4D46-BB73-0E2B2C56C498.html

https://library.netapp.com/ecmdocs/ECMP1196981/html/GUID-B7CB9621-4E27-4D46-BB73-0E2B2C56C498.html

http://www.netapp.com/us/products/platform-os/raid-dp.aspx

http://www.netapp.com/us/products/protection-software/snapmirror.aspx

http://www.netapp.com/us/products/protection-software/snaprestore.aspx

http://www.netapp.com/us/products/platform-os/snapshot.aspx


One of the biggest challenges is to create faster developer workspaces. Using NetApp FlexClone technology, the developer workspace can be created in minutes rather than hours.

Many organizations face the issue of long Android build times. However, with the process described in this paper, which is based on NetApp FlexClone technology, the Android build time can be optimized by making the builds incremental.

For data protection, Android developers can use NetApp Snapshot technology, which creates Snapshot copies of their work in less than a minute, eliminating long backup windows.

All these features can save organizations hundreds of hours, thus accelerating the time to market of their

products.


Appendix

Test Environment This study was conducted at a NetApp lab using Android version 4.0.1. For this study, 8 instances of Android application were built in parallel on the NetApp storage using 2 servers, each 24 cores each running Ubuntu 14.04.1 LTS. All the tests were performed on a 10GbE network. Figure 7 shows the test configuration connectivity.

Figure 7) Test environment setup

8.1 Android System Hardware Configuration Table 3 shows the configuration of the servers used for the testing. All the servers used were dedicated for the testing.

Table 3) Android system hardware configuration

Hardware/Software Configuration Details

Model IBM 3650

Operating system Ubuntu 14.04.1 LTS

Processor Intel® Xeon® CPU X5650 @ 2.67GHz, 24 cores

Memory 32GB

Network 10GbE connections


8.2 NetApp Hardware Configuration The NetApp storage used was dedicated for the testing. All the tests are performed on NFSv3 with different mount options. All the volumes created for the testing resides on the single controller head. Table x shows the configuration of the NetApp storage used for the testing.

Table 4) NetApp hardware configuration

Hardware/Software Configuration Details

Storage nodes Pair of FAS3270

Operating system Clustered Data ONTAP 8.2.2

RAID size 16

Number of disks in aggregate 6

Disks type SAS 15K RPM, 600GB

Network 10GbE connections

Switch Cisco Nexus® 5010


References

Android: http://source.android.com/

Accelerate Software Development Lifecycle Using NetApp Storage: http://www.netapp.com/ca/system/pdf-reader.aspx?pdfuri=tcm:44-129491-16&m=tr-4340.pdf

Version History

Version Date Document Version History

Version 1.0 March 2015 Vibhor Gupta; NetApp

http://source.android.com/



Copyright © 1994–2015 NetApp, Inc. All rights reserved. Printed in the U.S. No part of this document covered by copyright may be reproduced in any form or by any means—graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an electronic retrieval system—without prior written permission of the copyright owner.

Software derived from copyrighted NetApp material is subject to the following license and disclaimer:

THIS SOFTWARE IS PROVIDED BY NETAPP "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL NETAPP BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

NetApp reserves the right to change any products described herein at any time, and without notice. NetApp assumes no responsibility or liability arising from the use of products described herein, except as expressly agreed to in writing by NetApp. The use or purchase of this product does not convey a license under any patent rights, trademark rights, or any other intellectual property rights of NetApp.

The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications.

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7103 (October 1988) and FAR 52-227-19 (June 1987).

NetApp, the NetApp logo, ASUP, AutoSupport, Campaign Express, Cloud ONTAP, Customer Fitness, Data ONTAP, DataMotion, Fitness, Flash Accel, Flash Cache, Flash Pool, FlashRay, FlexArray, FlexCache, FlexClone, FlexPod, FlexScale, FlexShare, FlexVol, FPolicy, GetSuccessful, LockVault, Manage ONTAP, Mars, MetroCluster, MultiStore, NetApp Insight, OnCommand, ONTAP, ONTAPI, RAID DP, SANtricity, SecureShare, Simplicity, Simulate ONTAP, Snap Creator, SnapCopy, SnapDrive, SnapIntegrator, SnapLock, SnapManager, SnapMirror, SnapMover, SnapProtect, SnapRestore, Snapshot, SnapValidator, SnapVault, StorageGRID, Tech OnTap, Unbound Cloud, and WAFL are trademarks or registered trademarks of NetApp, Inc., in the United States and/or other countries. A current list of NetApp trademarks is available on the Web at http://www.netapp.com/us/legal/netapptmlist.aspx.

Cisco and the Cisco logo are trademarks of Cisco in the U.S. and other countries. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such. TR-4394-0415

Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact product and feature versions described in this document are supported for your specific environment. The NetApp IMT defines the product components and versions that can be used to construct configurations that are supported by NetApp. Specific results depend on each customer's installation in accordance with published specifications.

http://www.netapp.com/us/legal/netapptmlist.aspx

http://support.netapp.com/matrix/mtx/login.do

Technical Report Accelerating Android Build on NetApp · Android application is generated in a...

Documents

Transcript of Technical Report Accelerating Android Build on NetApp · Android application is generated in a...