Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
 |
By Lauren Darcey and Shane Conder
App developers have enough challenges designing and publishing apps for the many mobile platforms and devices available on the market today. As platforms become more sophisticated, and applications push hardware and software boundaries, effective application development tools become increasingly important. With their short development timelines, application developers do not have the luxury of time to wrestle with development tools. These days, the tools available with the Android SDK provide a wide range of features for app developers, but the Android team has always encouraged the wider Android community to take matters into their own hands and develop specialty tools to help developers make the best apps possible.
As a founding member of Android’s Open Handset Alliance, Intel has always been invested in the Android platform, so it should come as no surprise that this performance-oriented powerhouse would develop tools to help developers. Intel’s new tool suite takes a two-pronged approach: make developers’ machines perform better when using tools like the Android Emulator, and make Android apps running on Intel-based Android devices perform better.
What Tools Are Available in the Intel Android Tool Suite?
Intel has bundled its Android development tools into a single downloadable package code-named ‘Beacon Mountain’. The beta version of the tool suite is available for both Windows (7 and up, 64-bit) and Mac OS (10.8.3 and up) and currently includes four main tools and libraries:
- Intel Hardware Accelerated Execution Manager (Intel® HAXM), which can speed up your emulators if you use an Intel-processor-based development environment.
- Intel Graphics Performance Analyzers (Intel® GPA) can help you optimize your OpenGL ES code.
- Intel Integrated Performance Primitives Preview (Intel® IPP Preview)
- Intel Threading Building Blocks (Intel® TBB)
For convenience, Android development tools are also installed as part of the suite.
- Android Development Tools (ADT Bundle)
- Android NDK
- Apache Ant
This suite of tools and libraries is available as free downloads directly from Intel at http://software.intel.com/en-us/vcsource/tools/beaconmountain. The tools can also be downloaded individually. This article will focus on the first two tools, those with the widest application: HAXM and GPA.
Are the Intel Android Tools Right for You?
Intel’s suite of Android Tools is geared toward the Android developer writing OpenGL code using the Android NDK and targeting, at least in part, Android devices with Intel processors. That said any Android developer running their development environment on an Intel-based machine can greatly improve the Android emulator experience using Intel’s HAXM tool.
How to Install the Intel Android Tool Suite
For those who want to get started quickly and easily, the Beacon Mountain installer will install the Android Development Tools (ADT) bundle, the Android NDK, the Android Design tools, Apache Ant (optional), as well as the Intel’s four tools and some samples. While the installer includes all of the Android and Intel tools, it does not include a Java installer. You’ll still need to download and install the Java JDK before you start. It’s available at http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html.
The Beacon Mountain installation process is relatively straightforward. You can download the installer from http://software.intel.com/en-us/vcsource/tools/beaconmountain. Once you launch the installer, follow the wizard and complete the installation. The installation requires just over 5GB of space. Installation may take a while and will depend on the speed of your Internet connection.
Installing the Beacon Mountain Tool Suite
Now that you’ve installed the Beacon Mountain tools, let’s look at each of them in a bit more detail.
The Hardware Accelerated Execution Manager (HAXM)
We will start with the Hardware Accelerated Execution Manager (HAXM) since it has the potential to benefit the largest number of Android developers. Any Android developer running an Intel-processor-based development machine can benefit from HAXM.
Many Android developers use the Android emulator on a daily basis. With the variety of devices available on the market today and the cost of hardware, it’s simply unrealistic not to rely on the emulator for frequent development testing on configurations the developer doesn’t have hardware for. While the Android emulator has a great feature-set as emulators go, it has had a long history of performance problems. Put another way: a few years back, a developer might say “I’m not slacking off. My code is compiling.” Android developers are much more likely to say “I’m not slacking off. I’m waiting for the $%&% emulator to launch.” This gets so bad, many developers are forced to turn to devices, sometimes their personal hardware.
For the past few years, Android developers have been pushing for improvements to Android emulator performance and finally about a year or so ago, Intel came up with its solution: HAXM. Now on its third revision, the Intel® HAXM driver improves Android emulator performance dramatically and has helped developers reclaim thousands of lost work hours of waiting on the tools. In many cases, leveraging HAXM can make a laptop that previously was unworkable as a development machine suddenly a valid development environment.
If HAXM was not installed as part of the Beacon Mountain suite, installing the HAXM Driver is a straightforward process. The installer can be downloaded directly through the Android SDK Manager, in the extras section. Find the IntelHaxm.exe file within the /extras/intel folder of your Android SDK installation. Launch the executable to start the installation process. The installer will check your platform configuration for compatibility and then either install the driver or display a failure message if your computer is not compatible with the driver.
The HAXM Setup Wizard
Next, you will need to create a new AVD using the Android Virtual Device Manager. Most of the AVD settings will remain the same. Set the AVD Target property to an API level that you have downloaded an x86 system image for (all recent API levels have x86 system images available for download through the Android SDK Manager). Then, under the Hardware property settings, add a new value. Click New, select the GPU emulation option, and turn it on with a value of yes. When done, click Create AVD to actually save this AVD profile for use with the emulator.
Creating a HAXM-Compliant AVD
Now your development environment is ready to rumble with HAXM-powered emulation. Launch the emulator using your new AVD — you’re good to go. If you have any trouble, consult the “Configuring Virtual Machine Acceleration” section of the official Android emulator documentation for instructions on setting up HAXM. When you launch a properly configured AVD, you’ll see a brief status screen while it is starting up. If HAXM is properly configured, you’ll see a message, such as “HAX is working and emulator runs in fast virt mode.” This means HAXM is running properly.
Starting Android Emulator
You should notice the performance improvements immediately. Your emulator instances should boot up fast (once initialized on the first boot) and once running, you should experience a buttery-smooth simulation of a real device. In fact, we found that the performance improvements to developer environments were so good that they easily outperform many Android devices on the market, making performance testing on real in-the-field hardware an even more essential part of the application development process.
For a more in-depth look at HAXM and our first impressions when it came out last year, see our previous article, Supercharge Your Slow Android Emulator.
Intel’s Graphics Performance Analyzers (GPA)
Intel’s Graphics Performance Analyzers (GPAs) are a set of graphics analysis tools designed to help Android developers optimize their application graphics performance primarily for Intel-based devices. The GPA tools can help gather metrics for applications using both OpenGL ES 1.0 and 2.0, and is supported for Intel-based devices running Android 4.0 and higher.
There are a number of tools provided in the GPA, but only one of them is applicable to Android developers: the Intel GPA System Analyzer. The other tools, such as the Frame Analyzer, Platform Analyzer, and System Analyzer HUD, are not compatible with Android devices nor can you create frame capture or trace capture files with them. As such, we focus on how to leverage the Intel GPA System Analyzer in this article.
The Intel GPA System Analyzer is very helpful for tuning applications that rely upon OpenGL ES within the limitations described earlier. There are two major areas of functionality for the System Analyzer. First, you’ll find system metrics on everything from CPU usage to battery discharge clearly displayed for you. Second, and most interesting to us, are a set of graphics state overrides that can be performed. These overrides allow you to selectively disable — or factor out from the performance equation — a variety of major OpenGL ES features that frequently are the root cause of performance issues. For example, if you disable alpha blending and see a substantial performance increase, you’ll have a much better idea of whether or not alpha blending is a culprit for your performance bottlenecks.
Using the GPA System Analyzer
The System Analyzer can only provide metrics on Android devices running on Intel hardware. It also requires that the target application use OpenGL ES 1.0 or 2.0. With OpenGL ES 3.0 support in Android 4.3+, we hope it’s only a matter of time before this version will be supported by the System Analyzer. If your application and test devices meet these requirements, you are ready to get started using Intel GPA. Keep in mind that any optimizations you make based on this data can still be beneficial to applications even when they are not running Intel-based Android hardware.
First, you’ll need to have your target Intel-based Android device configured for debugging. The metrics gathering occurs while connected via ADB. Next, you’ll need to make sure that the application you want to analyze has the internet permission and debuggable configuration options set to true in the Android Manifest file (e.g., <uses-permission android_name=”android.permission.INTERNET”> and <application android_debuggable=”true”>, which is implicit when debugging on Eclipse). (Note: You can skip this step if your device is rooted, and analyze any application.)
Once you’ve made these changes, you can launch the System Analyzer and select your test device as an analysis target. If the Android SDK is not found automatically, press Ctrl-F1 to set it.
Connecting to the GPA System Analyzer
Once you connect your test device to the System Analyzer, it installs the Intel GPA package on the target device. The package installation automatically completes. Next, you will see a list of applications available to analyze. All running applications are listed. If yours is not in this list, build and deploy it again with the proper settings in the Android Manifest file and it should show up in the list.
List of Applications for System Analyzer Analysis
Once you select your application to analyze, its metrics screen will be displayed. There’s a ton of data here. Some is not specific to graphics performance but still of interest nonetheless. CPU, network, disk, memory, and power usage are all available, in addition to GPU and OpenGL-specific performance metrics.
System Analyzer Metrics Screen
Android devices often behave quite differently when charging as compared to relying solely on battery power. You can use the System Analyzer with Android devices that are not tethered via USB by testing over a network. To do this, use Android’s adb tool in TCP/IP mode to connect to the device. You’ll be able to take much more accurate measurements on some metrics, such as battery discharge rate, that are completely inaccurate while connected with USB and charging. However, other measurements may be altered due to extra network overhead.
The Black Art of Performance Tuning
Now is a good time to talk a little about performance tuning and how it works. Unfortunately, performance tuning tools don’t know what your application is trying to do, so it can only measure what it is doing at a given time. It’s up to you to interpret the results.
Interpreting performance data is something of a black art. You’re not going to get a lot of obvious, black-and-white answers. Performance information usually provides answers in “relatives.” Here are three “relative” statements that performance monitoring software can tell you about your applications:
Relative Statement No. 1: This area of the application takes 90 percent of the time or resources, while this other area is wicked fast or lean. This sort of relative information can help you identify areas of your application to review and improve with the best bang for the buck and which ones should be lower priorities.
Relative Statement No. 2: This application function was this fast before a code change and this fast after a code change. This sort of relative information can help you identify if your code or algorithm optimizations are helping or hurting your application performance. It’s a good idea to take a baseline before you make any changes to your application.
Relative Statement No. 3: Enabling these four overrides increases performance individually by 20 percent. However, this other override increases performance by 50 percent. Just given these numbers, we don’t know what each is doing and how important each is. If they should all be similar, you’ll know which to work on. You’ll also know which has the most room for improvement relative to the others. Even a small change in the 50 percent one could have a bigger impact than a large change in any of the others.
Sometimes performance tuning uncovers real bugs, whereas other times it simply helps you, the developer, identify the areas of your applications where you’ll want to spend the most time trying to improve performance by using any number of code or algorithm optimization tricks. When it comes to the System Analyzer, one of the challenges is determining which metrics to focus on. So let’s talk about some What-if scenarios you might find interesting.
System analyzer metrics graphics
Some Useful OpenGL What-If Scenarios
Collecting general application metrics is nice and all but where the System Analyzer really starts winning developers over is with its state override features. Overrides allow the developer to perform quick changes to the OpenGL ES application components and render states without recompiling. These overrides are invaluable for quickly narrowing down problem areas in the graphics pipeline. With two exceptions, all overrides are available for both OpenGL 1.0 and 2.0. Now let’s look at some of the most useful overrides and what they do.
For comparison, here is a rendered scene from a sample Android application:
Fully-rendered scene before overrides used
1×1 Scissor Rect: This override disables pixel processing. No pixels will be drawn on the OpenGL surface. If disabling this setting creates a huge performance jump compared to other overrides, then vertex shading or complex geometry could be creating performance issues. The resulting surface will be black.
Disable Alpha Blending: This override disables the alpha channel. Objects and textures will no longer be translucent. If turning off alpha blending improves performance compared to other overrides, then your scene may contain too many objects with transparency or translucency. The resulting surface is shown in the figure below; note the lack of transparency in the leaves.
Scene rendered with no alpha blending
Disable Alpha Test: This override disables per-pixel testing to determine if a pixel needs alpha blending. Performance may improve or degrade, depending upon the scene and how much alpha blending occurs before and after. This override is only available for applications using OpenGL ES 1.0.
Disable Z-Test: This override effectively disables depth testing, which helps optimize rendering to just objects, or pieces of objects, that will be visible to the user. Disabling depth testing will draw objects in the order they are presented to the renderer. This could reveal objects that could be removed in other ways, in particular if the performance improvements by disabling depth checking are more than expected.
Here, you don’t see the castle or tent, but you do see a number of tiny objects normally hidden. Perhaps they aren’t necessary?
Disable Draw Calls: This override disables all drawing calls to the video driver and GPU, allowing the developer to factor out device-specific drawing performance issues. For example, if you have two devices, one with acceptable performance and another with unacceptable performance, you can enable this override and see if turning off drawing calls makes a difference. If the performance on both devices equalizes, then the performance bottleneck could be a driver or GPU issue.
Show Wireframe: Unlike the performance-based overrides, this graphics mode is most useful to a scene designer or optimizer to view all the graphics components being drawn without textures or fill getting in the way.
A scene designer might spot some issues in Show Wireframe mode.
Texture 2×2: This graphics mode replaces all textures with four easy-to-differentiate colors. This mode helps factor out texture-based performance issues. If using this mode speeds up scene rendering more than expected, it could mean the textures are too numerous, too large, or too complex. For example, sometimes texture filtering settings are impractical for the hardware (such as anisotropic filtering) or shaders fetch from textures too frequently.
A scene designer would expect simple textures to draw quickly, but not too quickly.
Simple Fragment Shader: This graphics mode replaces all fragment shaders with a fixed color value. If enabling this mode results in a performance bump greater than expected, shader computation might be too much for the hardware. Another possibility is that texture performance is poor. Scene output in this mode will be a single color. This override is only available for applications using OpenGL ES 2.0.
As you can see, there are a number of very handy overrides and graphics modes that can help you, the developer, determine which areas of your application’s graphics pipeline should be priority targets for optimization.
Creating Custom Metrics
To make matters even more interesting, if the metrics provided aren’t enough for you, System Analyzer allows you to define custom metrics. This is done through OpenGL extensions. In short, you make EGL calls to get function pointers to the Intel-specific functions for creating, updating, and removing metrics. When run without Intel GPA, these methods will simply return null and the metrics won’t be collected. When running under Intel GPA monitoring, you’ll get the address to the function and can call it directly.
Custom metrics show up right alongside system metrics
Exporting System Analyzer Data
The information that the Intel System Analyzer collects can be displayed and interpreted in the application. If you wish to perform further analysis, or keep baselines and benchmark data for further review and analysis by other tools, you can also export the data provided in CSV format.
Exporting System Analyzer Data in the CSV Format
Conclusion
Intel continues to work with Android developers to help them design and publish faster, more efficient apps. The Intel Android tool suite offers Android developers several opportunities that they should not pass up. The HAXM driver enables developers to write and test applications in a more timely fashion on Intel-based development environments by significantly improving Android emulator performance. The Intel System Analyzer tool, which is part of the GPA package, provides many useful tools for tracking down OpenGL ES graphics performance issues. The other tools offered in the tool suite help developers tune their Android apps for Intel-processor-based devices for the best app experience possible.
To learn more about Intel tools for the Android developer, visit Intel® Developer Zone for Android.
Lauren Darcey and Shane Conder have coauthored several books on Android development: an in-depth programming book entitled Android Wireless Application Development Volume I: Android Essentials (3rd Edition) (ISBN-13: 978-0-321-81383-1), Android Wireless Application Development Volume II: Advanced Topics (3rd Edition) (ISBN-13: 978-0-321-81384-8) and Sams Teach Yourself Android Application Development in 24 Hours, Third Edition (ISBN-13: 978-0-672-33444-3). When not writing, they spend their time developing mobile software at their company and providing consulting services. They can be reached at androidwirelessdev+dc@gmail.com and via their blog at http://androidbook.blogspot.com. Follow them on twitter, @androidwireless.
