When developing an Android* application, you usually need to test, optimize, and debug on many different platforms. While basically every hardware and chip manufacturer provides a set of custom tools for this, developers can find it cumbersome to install and learn how to use all of them.

Since their latest releases (2014 R2 as of now), Intel® Graphics Performance Analyzers (Intel® GPA), Intel® Frame Debugger, and Intel® VTune™  Amplifier are able to support most mainstream Android 4.x devices, regardless of their architecture (ARM* or x86).

We have tested these Intel tools and successfully used them on the ARM Android devices listed here, but basically any Android 4.x device is probably compatible.

Summary:
Getting a high level view of how your app is performing, using GPA System Analyzer.
Debugging an OpenGL rendered view, using Intel® Frame Debugger.
Analyzing the performance of C/C++ code from Android applications, using Intel® VTune Amplifier.

Getting a high-level view of how your app is performing using Intel® GPA System Analyzer.

Intel GPA System Analyzer can run on: Windows* 7/8.x, Mac* OS X*, and Linux* and can be used to analyze apps running on almost any Android 4.x device connected over ADB.

It’s a free tool, part of the Intel GPA suite you can get from this dedicated page or INDE.

If your device is rooted, this tool can analyze any application installed on the device. Otherwise, it can only analyze apps with Internet permission and the debuggable flag set to true.

Setting the debuggable flag to true in the AndroidManifest is done automatically when you’re doing a debug build with gradle or ant / Android Studio or Eclipse*. But when it comes to analyzing the real performance of an application, you want to run a version that has been optimized for release!

You can manually set this flag to true in your manifest, but lint will complain about it and cause your build to abort. You can easily overcome that.

In Eclipse: disable “HardcodedDebugMode” in Lint Error checking inside Android Preferences. In Android Studio: set inside your build.gradle

android {
	lintOptions {
		disable 'HardcodedDebugMode'
}
}

Now, when running Intel GPA System Analyzer, you first get a list of applications running on the device you’ve chosen:

Selecting one will trigger its launch on the device, along with its real-time analysis:

From there, you can drag&drop any metric from the left side to see its value evolve in real time.

You may not get hardware-specific metrics on every device as their support varies, but you’ll have at least: Target App CPU Load, RAM usage, Device and Network IOs, OpenGL* metrics (draw calls, vertex count, frame time).

In addition to these real-time values, you have the ability to trigger “state overrides” from the bottom left of the window. This will help you determine the current bottleneck in your application:

You can also disable all the Draw calls. Then no graphics will be rendered, but if the FPS improves, the bottleneck isn’t on the OpenGL* side.

A more in-depth article on Intel GPA along with a sample code is available here: https://software.intel.com/en-us/android/articles/using-the-intel-gpa-system-analyzer-to-improve-android-apps

Debugging an OpenGL rendered view using Intel® Frame Debugger

Intel Frame Debugger is used to capture and fully debug OpenGL frames. It’s once again a free tool you can get from this dedicated page or INDE and fully works on most Android devices.

As of now, it can be run on Windows 7/8.x platforms only.

First add a frame from a device by clicking “Add”:

This will show you a list of applications that you may, or may not, have the right to analyze. Just like previously with Intel GPA System Analyzer, you may analyze any application on a rooted device. Otherwise, only the ones with Internet permission and the debuggable flags set to true:

Double-click to launch one and click on “capture” to get a frame. Once it’s done, go back to the previous view and select the captured frame:

You can see all the draw calls that have been made on the left side and the associated simulated OpenGL ES framebuffer on the right side.

A double click on one of these draw calls will allow you to inspect all steps of the OpenGL ES pipeline associated with the draw call, among these:

The primitives and the associated Vertex Buffer Objects

The vertex and fragment shaders

You can see and modify these shaders and even modify the values they’re receiving. This will modify the simulated frame as well as the rendered frame on your device if it’s still connected!

Analyzing the performance of C/C++ code from Android applications using Intel® VTune™ Amplifier

Intel VTune Amplifier is part of Intel® System Studio suite. Contrary to the previous tools, this suite isn’t free unless it’s for non-commercial software development. As of now, this tool can be run from Windows and Linux hosts.

To begin with VTune Amplifier, create a new project:

In its properties, choose your device and “Launch Android Package” as type, then you can enter your package name or click on “browse” to look for it:

Once this is done, you can launch a “basic hotspot” analysis. Starting the analysis will launch the app on your device:

Click on Stop to stop the collection (and automatically close the application).

The trace will be collected and displayed:

From there you can, for example, start looking at the results with the “Bottom-up” view and group data by Module / Function / Call Stack:

To associate full library symbols and sources to your results, you can add their paths to your project properties (usually ./obj/local/ABI/ for the non-stripped libs and ./jni for the sources).

More information on performance analysis using VTune can be found here: https://software.intel.com/en-us/node/471808

On supported x86 Android Devices (Intel® reference designs and Dell Venue* 8 with developer image), VTune Amplifier can be used to analyze Java* workloads, get CPU and GPU metrics, and do power analysis! You can find more details here:

• https://software.intel.com/en-us/android/articles/mobile-development-kit-for-android
• https://software.intel.com/en-us/articles/enabling-java-analysis-on-android-using-vtune-amplifier-2014-for-systems
• https://software.intel.com/en-us/articles/how-to-use-the-intel-energy-profiler-in-intel-system-studio-2014

Notices

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.

Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.htm

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark* and MobileMark*, are measured using specific computer systems, components, software, operations, and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products.

Any software source code reprinted in this document is furnished under a software license and may only be used or copied in accordance with the terms of that license.

Intel, the Intel logo, and VTune are trademarks of Intel Corporation in the U.S. and/or other countries.

Copyright © 2014 Intel Corporation. All rights reserved.

*Other names and brands may be claimed as the property of others.

Hey everyone ...!

i'm new in android development and i'm having a problem which i haven't found any solution for a month.

--i'm using "Delphi XE6" which includes the Dev tools for Android .

..I've created some apps and debugging them with the "ARM" and they worked just fine, i found out that the emulator is abnormally too slow 

so i downloaded the intel HAXM to give it some speed and it worked ,it became fast and smooth ...till now no problem.

****but when i tried to debug build my apps using the x86 emulator, the app starts up with a black screen 

     written in the center of it "Application does not support this device"!!!!!

  i dont know what's the problem !! and it took me a lot of time without finding any solution ....so please help me

Thanks in advance!

I am happy to announce that Meshcentral is going global with the web site launching in a total of 11 languages. It’s always been the goal of Meshcentral to be a universal cloud management web site that cuts across devices, operating systems, architectures and form factors, highlighting and utilizing Intel unique features when available. Now, we also cut across languages. Supported languages are: English, German, French, Italian, Japanese, Korean, Portuguese, Russian, Chinese (China), Chinese (Taiwan).

If your browser is set with your correct language preference, Meshcentral.com will automatically show up in the most preferred language that is supported. The translations have been done using a combination of machine and human translations systems. Since I personally only speak English and French, we are looking for feedback and corrections. This is just a start, we will continue to improve the quality of the internalization and localizations moving forward.

Meshcentral makes it easier than ever to make use of Intel technologies and Internalization of Meshcentral is an important step to bring Intel unique usages, technologies and value to a global audience. Early next week, all 11 languages will be pushed out to all other instances of Meshcentral (Amazon AWS and self-hosted servers).

Questions and feedback appreciated,
Ylian Saint-Hilaire
meshcentral.com/info

Meshcentral.com is going global with an impressive set of language support.

Introduction:    

Corona is a popular framework that can be used to rapidly develop cross platform mobile apps.  Apps are developed using the Corona SDK which is based on the Lua scripting language.  Corona has a vibrant community of developers creating apps which has led to many great tutorials about using Corona available already.  This blog takes a specific focus on Android gaming and shows how to get started developing some basic components for a game and deploying it onto an Intel® Android* x86 device.  In particular, displaying graphics, using the physics engine, detecting collisions, handling gestures, playing sounds, user interface widgets, saving & restoring state, and building & launching the Android APK will be discussed.

Development Environment:

The recommended development environment is using the Corona Editor.  This editor is a combination of using the Sublime Text 2 Editor with a Corona Plugin.  This plugin allows running, debugging, setting breakpoints, and single stepping through code.  This is a nice development environment for developing with the Corona Simulator.  

To learn more and get started with the Corona Editor, please see the link below.

http://coronalabs.com/products/editor/

Displaying Images:

Displaying an image in corona can be accomplished in 1 line of code.  The image file name and screen coordinates are passed to the function.

local myBall = display.newImage("myBall.png", display.contentCenterX, 20)

To learn more about the display API's, please see the link below.

http://docs.coronalabs.com/api/library/display/index.html

Using The Physics Engine:

Corona comes with a powerful physics engine that is easy to use.  In this example, a ball is put into motion that can bounce off each side of the screen.  

-- 1. Add required code for using the physics engine
local physics = require("physics")
physics.start()

-- 2. Add bumper images to each side of the screen
local topBumper = display.newImage("top.png", display.contentCenterX, 0)
local bottomBumper = display.newImage("bottom.png", display.contentCenterX, display.contentHeight)
local leftBumper = display.newImage("left.png", 20, display.contentCenterY)
local rightBumper = display.newImage("right.png", display.contentWidth-20, display.contentCenterY)

-- 3. Assign a body with density, friction, and bounce characteristics to each bumper image
physics.addBody( topBumper, "static", {density=3.0, friction=0.5, bounce=0.6} )
physics.addBody( bottomBumper, "static", {density=3.0, friction=0.5, bounce=0.6} )
physics.addBody( leftBumper, "static", {density=3.0, friction=0.5, bounce=0.6} )
physics.addBody( rightBumper, "static", {density=3.0, friction=0.5, bounce=0.6} )

-- 4. Add the ball image to the screen
local myBall = display.newImage("myBall.png", display.contentCenterX, 20)

-- 5.  Assign a body with density, friction, and bounce characteristics to the ball
physics.addBody( myBall, {density=3.0, friction=0.5, bounce=1.0} )

-- 6. Set the gravity initial value
local gravity=4
physics.setGravity(0, gravity)

To learn more about the physics API's, please see the link below:

http://docs.coronalabs.com/api/library/physics/index.html#physics.

Detecting Collisions:

Corona makes it easy to detect object collisions.  In this example, when the ball collides with one of the bumpers, it is detected and a sound is played.

--1.  Implement the onBallCollision listener and play a sound when the collision begins
local function onBallCollision ( event )
      if ( event.phase == "began" ) then
          media.playSound( "bounce.mp3" )
      end
end

--2.  Add runtime listener for the collision event
Runtime:addEventListener( "collision", onBallCollision )

To learn more about collision detection and media API's, please see the links below:

http://docs.coronalabs.com/guide/physics/collisionDetection/index.html

http://docs.coronalabs.com/api/library/media/index.html

Handling Gestures:

Corona makes it easy to handle touch gestures.  In this example, a swipe up with a finger is used to increase the gravity and a swipe down with a finger is used to decrease the gravity.

--1.  Implement the onBallTouch listener and modify the gravity when an up or down finger swipe is detected on the ball
local function onBallTouch( event )
      if ( event.phase == "moved" ) then
         if ( event.y > event.yStart) then
            gravity = gravity+1
         else
            gravity = gravity-1
         end
         physics.setGravity(0,gravity)
         print(gravity)
      end
end

--2.  Add an event listener for when the ball is touched
myBall:addEventListener( "touch", onBallTouch )

To learn more about the touch API's, please see the link below:

http://docs.coronalabs.com/api/event/touch/index.html

User Interface Widgets:

Corona provides a rich collection of familiar widgets such as buttons, pickers, and sliders for building user interfaces.  In this example, a slider is used to change the gravity of the scene so the ball falls at a different rate.

-- 1. Add required code to use widgets
local widget = require( "widget" )

-- 2.  Implement the slider listener and modify the gravity
local function mySliderListener( event )
      gravity = gravity*(event.value/100)
      physics.setGravity( 0, gravity )
      print(gravity)
end

-- 3.  Declare the slider and provide the coordinates, width, initial value, and listener
local mySlider = widget.newSlider
{
    left = display.contentCenterX-80,
    top = 0,
    width = 150,
    value = 50,
    listener = mySliderListener
}

To learn more about the widget API's, please see the link below:

http://docs.coronalabs.com/api/library/widget/index.html

Saving & Restoring State:

Corona provides file read & write capability so that app state can be saved and restored for providing an optimal user experience.  In this example, the gravity set from the slider is saved and restored.

-- Saving:

-- 1.  Provide the file path
        local path = system.pathForFile( "myGameFile.txt", system.DocumentsDirectory )

-- 2.  Open the file for writing
        local file = io.open( path, "w" )

-- 3.  Write the gravity value to the file
        file:write( gravity )

-- 4.  Close the file
        io.close( file )
        file = nil

-- Restoring:

-- 1.  Provide the file path
        local path = system.pathForFile( "myGameFile.txt", system.DocumentsDirectory )

-- 2.  Open the file for reading
        local file = io.open( path, "r" )

-- 3.  Read the gravity value from the file
        gravity = file:read( "*a" );

-- 4. Close the file
        io.close( file )
        file = nil

-- 5. Restore the gravity in the physics engine
       physics.setGravity(0,gravity) 

To learn more about the io API's, please see the link below

http://docs.coronalabs.com/api/library/io/index.html

Building the Android APK:

Corona uses a cloud based build environment to build the lua code into an Android APK.  To initiate a debug test build, simply click File->Build for Android and click the Build button.

To learn more about building and distributing Android APK's, please see the link below:

http://docs.coronalabs.com/guide/distribution/androidBuild/index.html

Launching the Android APK:

Launching the Android APK on an Intel® Android x86 device is easily accomplished by using the Android Debug Bridge(ADB).  ADB is part of the Android SDK that can be downloaded from developer.android.com.  To install the APK onto the device, issue the following command from the command line:

adb install -r <appName.apk>

To learn more about installation, please see the link below:

http://docs.coronalabs.com/guide/distribution/androidBuild/index.html#installapp

Additional Links:

http://www.lua.org/about.html

http://coronalabs.com/resources/tutorials/getting-started-with-corona/

++This sample source code is released under the MIT License

Hello community, I hope you can help me. I am making an application in which I would like to enable or disable the HDMI as there is in the android settings option. I've been looking for Android Developers but there is nothing that says you enable or disable the HDMI.



Thanks and hope they can help me.

I trying to install INDE.

Environment setup installed. But when ICC 14 installation pregresses it at one piohnt says it may not integrate with NDK.

How so, if they put together into same INDE conglomeration? Should this warning be solved or removed?

Right hand doesn't know what left doing...

1) Is it possible to do ARM binary with ICC for Android? Can ARM processor be a target or only GCC-based toolchain will do that (I mean ICC as part of INDE pack and the same for GCC variants) ?

2) As INDE main purpose as I see it to simplify dealing with initially Linux-based tools on Windows (GCC, Eclipse and so on - are Windows ports of Linux tools) maybe it would be possible to include in INDE Environment setup Cygwin too? In some pre-defined minimal configuration that would be enough for dealing with Linux-oriented source packs. Android has Linux in its base so the natural way of porting some app to Android (and x86-based Android too) is to take app's Linux sources. And here one needs configure, sh-scripts execution capability and so on - the tools that miss in Windows and provided by Cygwin for complete development environment.

Maybe this should be forwarded to another Intel's team (NDK-related perhaps) but cause NDK I installed was part of INDE I will report issues with it here.

Include file 

C:\Intel\INDE\Framework\NDK\sources\cxx-stl\gnu-libstdc++\4.8\include\cstdio

contains this line:

#include <bits/c++config.h>

but bits subdirectory doesn't contain such file:

 Directory of C:\Intel\INDE\Framework\NDK\sources\cxx-stl\gnu-libstdc++\4.8\include\bits

07/03/2014  01:16 AM    <DIR>          .

07/03/2014  01:16 AM    <DIR>          ..

07/03/2014  01:16 AM                 0 1

01/22/2014  12:48 PM            21,157 algorithmfwd.h

01/22/2014  12:48 PM             6,245 allocator.h

01/22/2014  12:48 PM            18,084 alloc_traits.h

01/22/2014  12:48 PM            25,579 atomic_base.h

01/22/2014  12:48 PM             2,253 atomic_lockfree_defines.h

01/22/2014  12:48 PM            15,116 basic_ios.h

01/22/2014  12:48 PM             6,032 basic_ios.tcc

01/22/2014  12:48 PM           112,117 basic_string.h

01/22/2014  12:48 PM            39,353 basic_string.tcc

01/22/2014  12:48 PM            27,048 boost_concept_check.h

01/22/2014  12:48 PM             1,505 c++0x_warning.h

01/22/2014  12:48 PM            17,360 char_traits.h

01/22/2014  12:48 PM            16,617 codecvt.h

01/22/2014  12:48 PM             3,340 concept_check.h

01/22/2014  12:48 PM             9,789 cpp_type_traits.h

01/22/2014  12:48 PM             1,811 cxxabi_forced.h

01/22/2014  12:48 PM            32,672 deque.tcc

01/22/2014  12:48 PM             1,643 exception_defines.h

01/22/2014  12:48 PM             5,413 exception_ptr.h

01/22/2014  12:48 PM            47,842 forward_list.h

01/22/2014  12:48 PM            15,531 forward_list.tcc

01/22/2014  12:48 PM            28,936 fstream.tcc

01/22/2014  12:48 PM             3,116 functexcept.h

01/22/2014  12:48 PM             6,195 functional_hash.h

01/22/2014  12:48 PM             5,518 gslice.h

01/22/2014  12:48 PM             7,769 gslice_array.h

01/22/2014  12:48 PM            62,513 hashtable.h

01/22/2014  12:48 PM            53,987 hashtable_policy.h

01/22/2014  12:48 PM             2,146 hash_bytes.h

01/22/2014  12:48 PM             7,861 indirect_array.h

01/22/2014  12:48 PM            28,515 ios_base.h

01/22/2014  12:48 PM            30,933 istream.tcc

01/22/2014  12:48 PM            12,494 list.tcc

01/22/2014  12:48 PM             5,220 localefwd.h

01/22/2014  12:48 PM            22,985 locale_classes.h

01/22/2014  12:48 PM             8,381 locale_classes.tcc

01/22/2014  12:48 PM            90,971 locale_facets.h

01/22/2014  12:48 PM            38,935 locale_facets.tcc

01/22/2014  12:48 PM            65,035 locale_facets_nonio.h

01/22/2014  12:48 PM            41,830 locale_facets_nonio.tcc

01/22/2014  12:48 PM             7,587 mask_array.h

01/22/2014  12:48 PM             2,419 memoryfwd.h

01/22/2014  12:48 PM             5,804 move.h

01/22/2014  12:48 PM             4,694 nested_exception.h

09/06/2013  09:27 PM             1,394 opt_random.h

01/22/2014  12:48 PM            12,315 ostream.tcc

01/22/2014  12:48 PM             4,002 ostream_insert.h

01/22/2014  12:48 PM             8,208 postypes.h

01/22/2014  12:48 PM             5,294 ptr_traits.h

01/22/2014  12:48 PM           177,346 random.h

01/22/2014  12:48 PM           109,149 random.tcc

01/22/2014  12:48 PM             3,132 range_access.h

01/22/2014  12:48 PM            85,498 regex.h

01/22/2014  12:48 PM            28,348 regex_compiler.h

01/22/2014  12:48 PM            11,066 regex_constants.h

01/22/2014  12:48 PM             2,761 regex_cursor.h

01/22/2014  12:48 PM             4,611 regex_error.h

01/22/2014  12:48 PM             4,332 regex_grep_matcher.h

01/22/2014  12:48 PM             5,541 regex_grep_matcher.tcc

01/22/2014  12:48 PM            10,910 regex_nfa.h

01/22/2014  12:48 PM             4,965 regex_nfa.tcc

01/22/2014  12:48 PM            19,423 shared_ptr.h

01/22/2014  12:48 PM            41,649 shared_ptr_base.h

01/22/2014  12:48 PM             9,340 slice_array.h

01/22/2014  12:48 PM             9,490 sstream.tcc

01/22/2014  12:48 PM           217,508 stl_algo.h

01/22/2014  12:48 PM            42,400 stl_algobase.h

01/22/2014  12:48 PM            29,675 stl_bvector.h

01/22/2014  12:48 PM             5,170 stl_construct.h

01/22/2014  12:48 PM            68,001 stl_deque.h

01/22/2014  12:48 PM            22,585 stl_function.h

01/22/2014  12:48 PM            20,472 stl_heap.h

01/22/2014  12:48 PM            36,625 stl_iterator.h

01/22/2014  12:48 PM             6,961 stl_iterator_base_funcs.h

01/22/2014  12:48 PM             8,388 stl_iterator_base_types.h

01/22/2014  12:48 PM            54,094 stl_list.h

01/22/2014  12:48 PM            37,660 stl_map.h

01/22/2014  12:48 PM            34,751 stl_multimap.h

01/22/2014  12:48 PM            29,055 stl_multiset.h

01/22/2014  12:48 PM            13,820 stl_numeric.h

01/22/2014  12:48 PM             9,865 stl_pair.h

01/22/2014  12:48 PM            18,652 stl_queue.h

01/22/2014  12:48 PM             3,455 stl_raw_storage_iter.h

01/22/2014  12:48 PM             4,599 stl_relops.h

01/22/2014  12:48 PM            29,295 stl_set.h

01/22/2014  12:48 PM             9,877 stl_stack.h

01/22/2014  12:48 PM             8,344 stl_tempbuf.h

01/22/2014  12:48 PM            54,838 stl_tree.h

01/22/2014  12:48 PM            20,433 stl_uninitialized.h

01/22/2014  12:48 PM            49,773 stl_vector.h

01/22/2014  12:48 PM             4,929 streambuf.tcc

01/22/2014  12:48 PM            12,624 streambuf_iterator.h

01/22/2014  12:48 PM             6,597 stream_iterator.h

01/22/2014  12:48 PM             2,426 stringfwd.h

01/22/2014  12:48 PM            17,601 unique_ptr.h

01/22/2014  12:48 PM            48,902 unordered_map.h

01/22/2014  12:48 PM            44,292 unordered_set.h

01/22/2014  12:48 PM             3,577 uses_allocator.h

01/22/2014  12:48 PM            22,655 valarray_after.h

01/22/2014  12:48 PM            21,743 valarray_array.h

01/22/2014  12:48 PM             7,254 valarray_array.tcc

01/22/2014  12:48 PM            18,228 valarray_before.h

01/22/2014  12:48 PM            26,164 vector.tcc

That results in compilation error when source attempts to include cstdio.

Intel has a vested interest in helping developers provide Android applications that run well (or even best) on Intel architecture. While Intel is working at the community level - optimizing Dalvik Java, V8 engine, and Bionic C; contributing to the code base; and providing releases with both 32 bit and 64-bit Kernels for IA; they are also creating new tools to help  Android developers. Many of these focus on improving performance beyond that available with the default ARM translation layer for x86: libhoudini

But first - choose the right tools. There are 3 common methods of creating Android apps.

1. Java compiled using the Android SDK APIs to run in the Dalvik VM.​  Note: An article covering ART will be available soon for Android L.
   Using the latest SDK takes care of most differences, although you may still want to look at memory allocated for high resolution screens. Most notably, testing goes faster if you speed up your Android emulation software with  Intel® HAXM (requires Intel® Virtualization Technology and XD, both set to ON.)
2. Web focused HTML5 and JavaScript.  For Open Source Android info, check out the Android-IA site. 
3. NDK created or ported (written in C++). This is the preferred method if you will have processor intensive functions or already have the C++ code. Native C++ code usually (not always) runs faster by speaking "natively" to the hardware as the code is compiled into a binary before execution and doesn't require interpretation into machine language.

This article will focus on optimizing NDK based Apps. These may be solely C/C++ code or may include 3rd party libraries and/or assembly code.  

Note: If you don't already have an Android development environment (IDE), the new tool suite Intel® INDE (Intel®  Integrated Native Developer Experience) will load a selected Android IDE and also download and install multiple Intel tools to help you make, compile, troubleshoot and publish Android applications.  Click these links for a series on registering and installing Intel® INDE and setting it up with an Eclipse* IDE with links to videos on setting up the NDK & SDK*, Eclipse*, and running on an emulator (including how to speed it up) or an Intel® architecture based device.

At a high level, NDK development involves the following steps and minimum changes to work with x86 architecture. 

1. Create the Android Project and jni folder. Edit Application.mk to show APP_ABI = all (if file size allows for ARM* and x86 to be in the same pack.) or x86.  Note: The APP_ABI setting also affects floating point operations - see below. 
2. Code. Any native (C++) code can be reused. Rewrite any inline assembly code or ARM specific code.  Use javah to create the JNI/native code header file.Be sure to interpret between the Windows standard C++ conventions and Java/JNI using the JNIEXPORT and JNICALL macros 
3. Compile/Build libraries (call generates .so libs and puts them in the appropriate project directories). Use "ndk-build APP_ABI = X86 "with a few build flag changes - see below. Also be sure to recompile any 3rd party libraries. 
4. Call it from Java.  Declare  in Java the  native( C++) function calls and load the shared library using System.loadlibrary().
5. Debug. ndk-gdb debug can be used by running ndk-build with the manifest set to debuggable. Make sure the adb directory is added to the PATH and only one target is running. 

Beyond basic "porting", there are some optimizations available, 

Optimizing Tips:

1. Speed up your software based Android emulator by using Intel®  HAXM for hardware assisted emulation. Intel®  HAXM requires Intel® Virtualization Technology (Intel® VT) and XD set to on.
    
2. Set APP_ABI = x86 (creates one apk with all binaries) or  = armeabi armeabi-v7a x86, depending upon your file size limitations.. (Note x86 includes hardware floating point as does (to some degree) armeabi-v7a-x86)
    
3. During compile, use gcc "-malign-double". (This is for memory alignment - see also #9)
    
4. During compile, add appropriate CPU threading flags 
   For  Intel® Atom™ processor's Hyperthreading capability try            -mtune=atom -mssse3 -mfpmath=sse 
   For non hyperthreading, (BYT, SLM, Merrifield) use                              -mtune=slm -msse4.2 -mfpmath=sse
   Use -march= to limit to the specified CPU (mtune runs on more models but optimizes for the type listed).  
   -mavx is not yet useful on Atom. 
    
5. Use little Endian (default with the NDK).  ARM* supports both big and little Endian, Intel® Atom™ only supports little, so check your gcc flags.
    
6. Use v 4.8 of gcc. Watch the 2 toolchain paths (android-ndk\toolchains\arm-linux-androideabi-4.8 vs. x86 android-ndk\toolchains\x86-4.8
    
7. Be sure to use the correct JNIEXPORT method signature to set the entry method into native code - (match the header file's function signature to ensure the source code compiles on Windows*).  
   JNIEXPORT void JNICALL Java_ClassName_MethodName
    
8. After compile, check the system log to make sure the target native lib successfully loads at runtime. (This will show in the log as "added shared lib //<path>"
    
9. Explicitly force memory alignment to prevent loading errors and network packet issues.  ARM occupies 24 bytes but requires 8 byte alignment for 64 bit variables, while x86 occupies 16 bytes, So try to ensure 16 byte alignment of data structures. Then use aligned moves (MOVAPS, MOVNTA) when loading from that structure into XMM registers. See Reducing the impact of Misaligned Memory Accesses.
    
10. Write data directly to main memory (streaming stores instructions MOVNTPS, MOVNTQ) since the Intel® Atom™ processor has no L3 cache, This also saves on bandwidth consumption by avoiding the dirty writeback on cache eviction.
     
11. Avoid stalls due to a limited L2 cache. Except for specific instances (where load and store of data is to the same address, for the same size operand, and done from a general-purpose register), the load on the Intel® Atom™ processor will stall for several cycles while writing to cache. Additionally, stores of SSE operands (from xmm registers) are never forwarded to subsequent loads,
    So for both forwarding and non-forwarding scenarios, try to manipulate the data within the register doing sums in the xmm registers.   For example in the mp3 decoder, there's a windowing loop to accumulate/compute sums in a register and then sum across the register. 
    This incurs a blocked store-forward stall between the 16-byte store to the pSum array and the following 4-byte loads from pSum. To avoid this, compute the horizontal sum in the xmm registers, using HADDPS instructions or with a series of adds and shuffles. (But beware, the HADDPS sequence is faster on Intel® Atom™ processors, but slower on many variants of Intel Core processors.). Take advantage of SSE min and max instructions to perform clipping on samples that exceed the 16-bit range.
     
12. Zero out the full XMM register (MOVLPS, MOVHPS, PINSRW) before use, since some instructions load only part of the register which can cause issues from code that may remain in the other part. 
     
13. Read articles on optimizing SIMD instructions (Intel SSE vs. ARM* NEON* ).  Consider using the library NEONvsSSE_5.h available here, (in place of arm_neon.h).  The article also mentions that there are performance penalties when working with constants (don't put initialization in loops, replace with logical/compare operations if possible), and avoid serial implementation (use vectorization).
     
14. Replace divide and sqrt operations, which take many cycles, with either a table-lookup operation, a reciprocal approximation (RCPPS instruction), or a Newton-Raphson sequence.
     

15. Watch floating point calls. Use Float instead of Double (since Double often uses SW lib routine). Float is faster and saves memory bandwidth on Intel® Atom™  processors. Also the APP_ABI sets whether SW (armeabi) or HW (X86, armeabi-v7a x86) floating point is used. You don't always want to be executing the full HW FPU calculations with the x86 algorithm. (For example, dividing by powers of 2 in integer code is a fast right shift operation but for Android optimization you should multiply by the reciprocal instead (y=x*.5 instead of y=x/2) 

16. Reduce the overhead of small functions. Use Inline functions in areas including parameter passing, new stack frame setup/old stack frame restore/preserving caller's stack frame, putting addresses on the stack; return value calls, and return functions. See also the.Intel® 64 and IA-32 Architectures Optimization Reference Manual  

Have more optimizations? Please comment below.

Post Written By: David Wingrove

Golden Hammer Software took a trip earlier this year to New York to attend the Intel Android CodeFest.  We updated Big Mountain Snowboarding, Trick Shot Bowling, and Scribble Worm to run natively on Intel Android devices during that weekend.  All three of these games use C++ through the NDK.   

Java-based apps don't require any extra work for Intel devices.  C++ apps compiled for ARM will run on Intel devices thanks to a run-time interpreter.  C++ apps that are more processor intensive would benefit from cross-compiling for ARM and x86.  The native x86 code should be faster and more efficient on an x86 device.  This article shows the steps involved in setting up an NDK project to compile for multiple target platforms.

Compiling C++ for Multiple Architectures

The first step is to edit the Application.mk file to add additional platforms under the APP_ABI flag.  It’s possible to put “all” here in order to create a .so file for every architecture supported by Android, but compile times would get very long.  Unless you are using special armv7 api calls, x86 and armeabi should be enough.  This will create two .so files.  Unfortunately, it also doubles the compile time.

Application.mk

APP_ABI := x86 armeabi

Linking the .so Files with the Java Project

The two .so files will be created in [ndk project dir]\libs\armabi and [ndk project dir]\libs\x86.  They need to be copied into separate directories under your Android java project.

We use a simple bat file to copy the files for us every time we compile.  This file lives in our NDK\[Project]\jni folder.

CMD /C ..\..\..\..\..\..\contrib\android-ndk-r9c\ndk-build

copy ..\libs\armeabi\libGHBowling.so ..\..\..\GHBowling\libs\armeabi\libGHBowling.so

copy ..\libs\x86\libGHBowling.so ..\..\..\GHBowling\libs\x86\libGHBowling.so

Supporting Multiple C++ Libraries

Our games use multiple C++ libraries.  We have our game-independent code in one library and our game code in a second library. The game library needs to link with the game-independent library.  We were able to add a concrete relative path from one project to another when supporting only ARM, but the Android.mk file has to be updated when dealing with multiple targets.  The flag $(TARGET_ARCH_ABI) will grab the appropriate library during each compile pass.

Android.mk

include $(CLEAR_VARS)

LOCAL_MODULE := libGHEngine

LOCAL_SRC_FILES := ../../GHEngine/obj/local/$(TARGET_ARCH_ABI)/libGHEngine.a

include $(PREBUILT_STATIC_LIBRARY)

Compiler Differences

I highly recommend testing on an actual Intel Android device. There are subtle compiler differences. We had a null pointer crash that wasn't exposed until we compiled for x86.  It was a real bug that existed on all platforms, but somehow the other compilers managed to create code that would function while touching out of bounds memory.  When we ran the x86 Android code on a Samsung Intel Android tablet, the game crashed on startup until we found and fixed the bug.

Final Thoughts

Intel has created a series of tools to make Android development easier that can be found at https://software.intel.com/en-us/android/tools.  These include an emulator, a graphics profiler, a cross-platform library, and a full game engine.  We have also benefitted from Intel® Developer Zone programs like the Intel Android Showcase.

Supporting Intel Android in your C++ app is a fairly easy process.  ARM C++ libraries are likely to work without modification, but a couple simple makefile changes will make them run more efficiently.  Java apps don't require any changes to support the new hardware.

Author Bio

David Wingrove has four years of experience making Android applications and 14 years of experience making games.  He is the co-founder of Golden Hammer Software, and has released games for Android, Wii, PC, iOS, Blackberry, and other platforms. 

Post Written By: Antonio De Falco

After my participation at the Intel Android CodeFest, I decided to make a tutorial on how to prepare Planet Conqueror to run on Intel based Android devices. The game uses the libGDX developer framework. I think it’s a good idea to write this article so that other developers using the same framework can successfully provide their apps with x86-architecture support and hopefully avoid any pitfalls while doing it.

My name is Antonio De Falco, and I am the creator of the game Planet Conqueror. Having graduated from University as a Game-Designer, I found myself inclined to develop games that are easy to get into but that still deliver long-lasting fun while playing it. I initially intended for it to be a pastime project.  I viewed it as an experiment to see how a relatively complicated genre like RTS can be made approachable to the casual gamer while still keeping in balance with the appeal of a strategic game. However, Planet Conqueror grew to be an app worthy of introduction to a wider audience. Taking part in the CodeFest contest was an opportunity to do just that. I took great satisfaction in making it to the Top 5 and winning an advertising contract which helped to make a real difference.

Some time ago I was introduced to the CodeFest contest. While reading about it, I discovered that an app with x86 support was required to enter the contest. I immediately started to look into the benefits of having an app that is natively built to run on Intel powered Android devices. Quickly it was clear that apps could run much faster on devices by avoiding the bridge between ARM and x86. This interpretation layer converts native ARM builds to run on x86 architecture during runtime. This means there is a big chunk of processing power going to waste. Another benefit is that running an app on emulators with x86 system image instead of ARM would also speed up things. Therefore, it ensures that the time schedule for testing is held up and has a more fluent experience while avoiding miskicks or user errors. It was also important in the decision-making process to find out how many x86 devices there were out there.  Sure, the amount of devices is relatively small but it is growing fast (https://software.intel.com/en-us/android/get-device). The next step was to find out how difficult it would be to implement the x86 nativity into a game running with the libGDX development framework. As it turns out, it’s easy. So, let me explain how to port your game to an x86 native game.

Planet Conqueror was built using libGDX version 0.9.8 (stable release) which did not have the needed support for Intel based devices. Luckily the newer version of the framework did. So first of all, we need to download the new version of libGDX (ver. 0.9.9 or higher). LibGDX offers stable releases that are tested and contain few to no bugs. Another option is to download the nightly builds that have more features but probably more bugs, too. If you want to risk it, you can download the nightly build otherwise go for the stable release. You’ll find both downloads here: http://libgdx.badlogicgames.com/download.html

Once the download is complete, extract the zip file to a location of your choice. We are going to overwrite some files and delete some others.

• First copy “gdx.jar” from the extracted folder into the “libs” folder of core project.

• Than we need to replace the “libgdx.so” files and the Android Backend in the Android project folder. Copy the “armeabi”, “armeabi-v7a” and “x86” folders and “gdx-backend-android.jar” from the extracted folder into “...\YourApp-android\libs\” folder.

• While you are in the libs folder of your Android project, go into “armeabi” and “armeabi-v7a” and delete the “libandroidgl20.so” files.

• Lastly copy and paste “gdx-backend-lwjgl.jar”, “gdx-backend-lwjgl-natives.jar” and “gdx-natives.jar” form your extracted folder into “...\YourApp-desktop\libs\” folder.

Having support for x86, ARM and ARMv7 incorporated in one “fat build” the Android OS will sort out what files to use all by itself. If you are using libGDX extensions for your app, you also need to copy the updated extension files to your project. In the case of Planet Conqueror it was the Freetype extension which allows loading font files instead of creating bitmap fonts.

• Just like before, copy “armeabi”, “armeabi-v7a” and “x86” folders from “libgdx \extensions\gdx-freetype\” to the “libs” folder of your Android project.

• Do the same for “gdx-freetype.jar” and “gdx-freetype-natives.jar” in the core projects “libs” folder.

Now that the first step is complete, you can start your IDE. You may notice some code errors showing up. This is due to changes that were made to libGDX in between the two versions. Check the documentation and change log to solve the errors that are specific to your app.

After that, you are ready to compile a build with x86 support and start testing for functionality. To do that you need to set up the emulator with the x86 system image from Intel. You will find a detailed explanation on how to work with the x86 system image here: https://software.intel.com/en-us/android/articles/speeding-up-the-android-emulator-on-intel-architecture

I do recommend reading the article above because it contains a lot of extra information which I will skim or skip in this article. Since I am working with Windows, I will skip the procedure for other operating systems. So if you do not use Windows, please refer to the link above. To start your newly build APK on a x86 emulator you need a few perquisites. The Android SDK which you probably have already installed and a computer which runs on an Intel processor with support for “…Intel VT-x, EM64T and Execute Disable(XD) Bit functionality…”. This all sounds more complicated than it actually is. I’ve managed to run an emulator with an x86 system image on an Intel Core 2 Duo E6600 first released around mid-2006. So, if you have a newer CPU, chances are that you got all of these perquisites. These functionalities must be enabled from the BIOS, but do not worry about it yet.

Let’s start by downloading the Intel HAXM (Hardware Accelerated Execution Manager) from here: https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager

Go to the location of the downloaded file and extract and/or execute “intelhaxm.exe” to start the install wizard. During installation progress you may get an error message, telling you that Intel VT-x is not enabled in the BIOS. If so, you need to abort the setup restart your computer and enter the BIOS at startup (Please refer to the Mainboard owner’s manual on how to enter the BIOS) there you need to set “Virtualization Technology” to “Enabled”. Save and exit the BIOS and restart the installation of Intel HAXM following the same steps as before.

Now that we have the accelerator installed we need to create an AVD (Android Virtual Device) with an Intel system image. Choose an Android version you want to use and download the image here: https://software.intel.com/en-us/android/tools (find different versions on the bottom of the website). Or use the Android SDK Manager for convenience. Once you have your system image(s) start the AVD Manager from the Android SDK Tools “…\android-sdk\AVD Manager.exe” and create a new AVD. Set up the new AVD as you need it to be. The only thing you need to do differently is to set “CPU/ABI” to “Intel Atom (x86)” and you have an emulator that runs with x86 architecture.

All you have left to do is test your app according to your testing-checklist. Of course, you do not have to test everything if you already tested your app thoroughly. Confine your testing-checklist to things that are relevant for the CPU. Do a comparison of the two builds on the emulator and/or a device to see how much of a difference it makes with your app.

The process of implementing x86 support into Planet Conqueror was fairly easy thanks to the libGDX framework. It was just a matter of updating the development framework, copying some files into the project, and the build for x86 devices was ready. From here it was a matter of testing it out to see if there were any hiccups during runtime. Getting the x86 emulator running was the first step, and it was completed quickly because of the drivers available for Intel powered desktop machines. Getting a hold of an actual device with x86-architecture was a bit harder but also manageable. In the end, no hiccups were found, and a new version of Planet Conqueror was ready to be uploaded to the Store for the x86-community to download.

Author Bio

Based in Krefeld (Germany), Antonio De Falco is, among other things, an independent game developer for Android devices. He graduated from University, with a bachelor’s degree in game-design. Since his studies, he has worked in Cologne and Paris, where he gained further experience in the surroundings of experienced software development companies. 

Other Related Articles and Resources

Post Written By: Jean-Claude Cottier.

I’m Jean-Claude Cottier, a video game industry veteran. I’ve been working in this field for the last 18 years and in 2008, I’ve setup my own solo game studio: Ovogame. My games are available on a few platforms including Android: http://bit.ly/1i8aA1D. Recently, during an Intel CodeFest, I optimized all my games for  Intel Architecture and it was dead simple. I’ll describe my experience with the process and hopefully will get you interested to do the same.

To develop my games, I’m using my own technology: a C++ multi-platforms engine (Android, iOS, BB10, Win32 and OSX). I’m developing almost exclusively under Win32 with Visual Studio Express (for speed and ease of use purpose). To port my games to the other platforms, I simply need to copy the resources (source code and data) and recompile using the dedicated tools chain (ADT-NDK with Android, XCode for iOS and OSX...). Usually, it only takes a few minutes because everything is 100% compatible across all the different platforms. To reach this little miracle, my engine is only using standard C++ code and cross-platforms APIs (OpenGL, OpenAL, OpenSL…). For managing file format (jpeg, ogg, zip…), I’m using a different C/C++ library available with its source code so I can recompile on any platform. Obviously, I’m still using a bit of specific code for each platform (Java, Objective C, DirectX...), but I keep this code to a strict minimum and it never gets mixed with the game code.

When you develop natively for Android, the NDK is compiling your C++ code into a library that can be integrated in the Java project thanks to the JNI interface. In my engine, the Java code is kept to a bare bones minimum (mostly the communication with the system) and never changes from one game to the other. It’s now possible to create an Android application using only C++ (no Java), but I don’t recommend it because sometimes you’ll want to use third parties Java APIs (to display banner ads for example).

Nowadays, you can find different CPU powering Android devices (ARM, Intel x86…). This doesn’t matter for applications developed in Java because it’s an interpreted language. But when you are developing in C++ like myself, you have to compile your code for specific architectures. The majority of Android devices are powered by ARM chips. Like many C++ developers, I was only targeting ARM architectures (armv5 and armv7). Thanks to the NDK, you can compile your code for different architectures - armv5 for old Android devices and armv7 for newer ones. It’s automatically managed by the system - your APK is containing both versions and when your users launch your application, the most appropriate code will be used. Devices powered with x86 architecture can’t run ARM code obviously (as they are different architectures). By consequence, these devices must interpret ARM code via a virtual machine. Even if the x86 devices are doing an amazing job at interpreting ARM code, it’s a shame to not use their full capacity. If you compile your code for x86, your application will run faster on Intel devices and will consume less battery. Overall, it will be a better experience for your users. It’s very easy to support as you simply need to include a new compilation target. You need to open the jni/Application.mk in an editor and update the APP_ABI variable (it’s the one defining the different targets). As I was only targeting armv5 and armv7 before, my variable was set like this:

APP_ABI := armeabi armeabi-v7a

To add support to Intel architecture, you simply need to add x86 to the list.

 APP_ABI := armeabi armeabi-v7a x86

Now, every time you’ll compile your application, you’ll get an extra target compatible with x86 architecture that will be added to your APK. When the application is installed on an Intel based device, it’s this new compatible code that will be executed. All my games are now fully optimized for x86 devices. If like meyou are developing your applications in C++ with the NDK, you should also target for x86 architecture. It’s so simple, it would be a shame not to take advantage of it.

Personally, I didn’t face any technical problems supporting this new target as my engine is using standard C++. In fact, I’ve recompile and updated all my games the same day.

You need to know that the APK will be a tiny bit bigger (to store the x86 code) which can be annoying if you are close from the 50MB limit on Google Play.

If you are using  third party APIs only compiled for ARM, you won’t be able to use them anymore. I try to use only external libraries with the source code provided because it’s more cross-platform friendly.

If you need to change something in your makefile depending on the current architecture being compiled, you can edit your Android.mk and add conditions:

ifeq ($(TARGET_ARCH_ABI), x86)

‘This code will be visible only when compiling the x86 target.’

endif

If you want a more in depth article about porting your Android applications on x86, you could head to the Inte®l Developer Zone for Android website: http://intel.ly/1jnDfAd

I really think that for the vast majority of developers using the NDK like myself (with their own engine or Cocos2D for example), adding the word x86 in the APP_ABI variable will be enough to support Intel based devices. You will agree that this is largely possible within two minutes. You should do it.

Author Bio

Jean-Claude Cottier is a veteran developer who spent the last 18 years working in the game industry. He worked as an Engine Architect for Lionhead Studios and was lucky to create the 3D technology for some truly amazing games (Black & White and The Movies). Despite his
fascination for technology, Jean-Claude wanted to be more involved with game design. He left the AAA industry to setup Ovogame, his own indie company. He created a native cross platform engine witch allow him to port his numerous games on most relevant platforms in matter of minutes.

Post Written By: Xer Gata and Daniel Rings

Competing for and winning the first place title at the Intel Android Codefest in 2013 was an amazing experience. Prior to the Codefest, we had attended quite a few hackathons and game jams in New York City. I was quickly familiarized with what was possible for a small team of developers and designers to get done in a short amount of time. These events became an important testing bed for polishing my skills, exploring concepts, and acquiring business partners and opportunities. When I heard about the Intel Android Codefest, I was keen to team up with developer Daniel Rings. A month earlier, I met Daniel at Hack’n Jill. Our team went on to win 2nd place at that hackathon, and we were ready to try out our luck again.

For Codefest, we signed up for the hackathon portion of the competition (there was also a porting event). We were tasked with developing a mobile app utilizing the Intel® XDK. Aside from that, there were very few restrictions and the judging criteria was clearly stated. Food and drink was also provided. When you step back and think about how awesome that is, you can’t help but attend these exciting events.

The game we created is called Hammerfield. Hammerfield is a physics-based game where you are tasked with defending the International Space Station from incoming asteroids. You do this by swinging a space hammer that is connected to your spaceship via revolute joints- in essence, it is a ball and chain. Guiding the space hammer to collide with asteroids was a rather cathartic experience. I had been meaning to implement the mechanic for some time, but I hadn’t decided on the theme of the game. Daniel had just met famous astronaut Chris Hadfield, and we drew inspiration from that!

Hammerfield was built in Construct 2, a powerful HTML5 game engine that conveniently had an official plugin for Intel XDK. While Construct 2 is an incredibly versatile game engine that has been used by developers to make several polished games, it doesn’t require any programming knowledge to make simple projects. This can get frustrating for a programmer, but Construct 2 becomes an incredibly potent way to quickly prototype smaller projects. It also serves as a bridge between designer and programmer, which allowed me to transcend the level of mute rubber duck. The Construct 2 to Intel XDK process was seamless. On top of the ability to take full advantage of Intel's hardware, XDK came with an easy-to-use emulation environment. Contrary to most of our experience with Android emulators, Intel XDK's were fast and even included accelerometer inputs and gyroscopes.  One of the more difficult - and more rewarding parts of the development process was making the asteroids. The asteroids needed to appear randomly, spin randomly, and start at random speeds. Daniel also programmed “atmospheric entry” burning onto the asteroids as they flew past the space station into the Earth's Atmosphere, which ended up looking quite cool. Construct 2 provided extremely fast prototyping behavior which was a huge help in this project.

One of our worries for the game was having performance issues as a result of the dozens of physical objects on screen at once. When we tested it via browser (HTML5), there were some minor frame rate hiccups that we rectified with better design. The surprising part for me was that when we ran it through the Intel XDK emulator- the game performed very well! Testing it directly on our Android Devices was also a breeze, thanks to the provided device templates. All in all, wrapping our HTML5 app with Intel XDK went without a hitch. From both of our experiences, this is usually the “black box” part of the development cycle where things go wrong, so we were pleasantly surprised when nothing did. I’d like to think that the Intel XDK played a big part in our first place win. Unfettered by technical issues, we were free to tweak the finer points of our core mechanics and develop an awesome game!

Author Bios:

Xer Gata is a game artist/designer based in New York, NY. A third-culture kid and University of the Arts Alumni, he is an active member of the game development community in NYC. When he isn't competing in a weekend hackathon, Xer can be found making games and hosting game jams with his partners at Brooklyn Gamery. The other half of his week is devoted to freelancing as a graphic designer and creative strategist. He enjoys long walks on the beach via Oculus Rift.*

Daniel Rings is a graduate from Pace University with degrees in Computer Science and Acting. He spends his weekends at hackathons, singing in the shower, and enjoying long moonlit walks on the beach. This fall Daniel will be entering the University of Michigan's Masters program in Computer Science and Engineering.

Relevant Links:

Intel XDK Feature Overview

Game Engines For Android
How to import HTML5 apps into the Intel XDK

Post Written By: Somesh Kumar.

Today I am writing to share my experience in optimizing Grace Application (an Android Application) for Intel® x86 architecture and using  Intel® WiDi to bring the Grace App to the living room big screen.

For those of you who don’t know about Grace, here is a brief introduction - Grace is a mobile learning application which allows users to tap into a variety of online resources including leaders, teachers, Universities and organizations. The goal is to simplify mobile learning by bringing together top learning content, tools and passionate learners to foster a successful learning platform.

Grace supports watching online educational videos, taking notes for the videos, and easily accessing Wikipedia for research needs. Grace brings knowledge from mobile (Smartphones and tablets) to the living room using Intel® WiDi technology so that you can learn from your mobile device while on the go, or use the big screen in your living room while at home.

Currently, Grace Application is supported on Android Smartphones and tablets running Android 2.2 or higher devices. We plan to release web and iOS versions soon.

You can watch this short introduction video to see what Grace offers, download it using the following link and give it a try: Grace On Google Play

Now that you know about Grace, lets talk about adapting this app on Android with Intel x86 architecture-based devices. For this exercise, I worked on a Lenovo Android device with the Intel x86 processor- porting the ARM-based binary to Intel x86 architecture was very straightforward. Grace Application uses OpenCV for automatic video pause and playback feature. The only change I had to make was to select the NDK build compilation flag to target all the processor architectures and recompile the source code to generate new binaries. I did this by modifying the Android.mk file for Grace and updating the value of APP_ABI to “all” or “x86” from “armeabi”, then running the ndk-build command to generate the object code for x86 and arm processors. That was it! Grace App worked on Intel x86 without any issues and with no changes to the code.

Most of the developers will require little to no effort in order to port their ARM based Android Apps to Intel x86. With a small amount of effort, you can make your apps run on Intel x86 devices and increase the reach of your applications.

There is a free eBook - Android on x86: an Introduction to Optimizing for Intel® Architecture  you can download to learn how to adapt and optimize your applications onto Intel’s x86 architecture. This book also talks about the business potential and the unique challenges and opportunities that arise from x86 devices.

Experience with Intel® WiDi:

In order to bring the Grace app to the big screen, I integrated Intel® WiDi technology during the Intel Silicon Valley CodeFest. Intel® WiDi technology allows applications to mirror smartphone display onto secondary display wirelessly and provides enhanced user experience. For Grace, my aim was to stream videos wirelessly from the app to the living room TV, and simultaneously enable the user to take notes from his/her Smartphone or tablet for currently playing video. With the exceptional support from the Intel team, I was able to  add Intel® WiDi support into Grace application.

The Intel team has created great tools to support development of quality applications. If you are an Android developer and use an Android Emulator, then you would want to use Intel HAXM Manager to speed up the Android emulator. I find HAXM extremely useful - it will definitely make your application development fast and save you the time and frustration. You can learn more about Intel® HAXM here.

Another tool from Intel worth mentioning is the Intel® Graphics Performance Analyzer. It enables developers to optimize applications by finding performance bottlenecks on  Intel chipset based devices. This tool could be very helpful to improve performance intensive applications and games.

For all the latest innovations, tools and resources for developers you can visit Intel® Developer Zone for Android,

Conclusion:

Overall, it was a simple and straightforward experience for me to add support for Intel x86 architecture to my application Grace.  Most of the applications using NDK or JNI should be able to run on Intel x86 architecture with simple compilation changes. Using Intel’s x86 architecture helps to expand the reach of your applications and grow your user base and business. Intel® WiDi is a very promising technology and easy to integrate with Apps and Games. It can add great value to applications and enhance the user experience with a minimal development effort. 

Author Bio:

Somesh Kumar (@someshk) is an entrepreneur and founder of Mobispectra Technologies LLC, a Silicon Valley startup which aims to create useful, intuitive mobile applications. Somesh loves to design and develop mobile applications to solve social problems and improve quality of life. Somesh participated in Intel Android Codefest - Silicon Valley in November, 2013 and his Grace application won 3rd place in Intel x86 Portathon contest.

Related Articles and Resources:

Grace App on Google Play

Grace App Introduction Video on YouTube

Creating and Porting NDK base Android Apps for IA

Free eBook Download: Android on x86 An Introduction to Optimizing for Intel Architecture

Speeding up the Android* Emulator on Intel Architecture

Intel Hardware Accelerated Execution Manager

Intel WiDi

Objetivo: A Lenovo, líder mundial no mercado de computadores e detentora da marca CCE no Brasil, está em busca de aplicativos Android para seus tablets com tecnologia Intel.

Detalhes: Os desenvolvedores podem submeter aplicativos Android de todas as categorias (Ex: Jogos, Infantil , Educação, Produtividade, etc...).
A Lenovo e a Intel avaliarão os apps e os escolhidos poderão estar presentes nos produtos da companhia via a central de apps presente nos dispositivos. Todos os aplicativos devem possuir ao menos um modelo de monetização. A Lenovo definirá em conjunto com o desenvolvedor o modelo de negócio para a divisão de receita oriunda do app.

Benefícios: os desenvolvedores dos apps escolhidos poderão firmar um acordo de distribuição com a Lenovo, uma das maiores empresas de tecnologia do mundo, e ampliar sua fonte de receita com os aplicativos.  

Requerimentos:
Os desenvolvedores deverão atender aos seguintes requisitos:

- Oferecer um app para tablet compatível com o processador Intel Baytrail CR, Memoria 1Gb, Flash 8Gb, Android 4.4, Webcam frontal 0.3Mb, Traseira 2Mb, bateria 2400 mAH, Multitouch 5 toques, resolução da tela 1024 X 600, sem bluetooth, Wi-Fi Only.

- O app desenvolvido para a Lenovo deve possuir uma diferenciação frente ao app disponível em lojas como o Google Play.

- Os apps submetidos devem possuir ao menos um modelo de monetização.

- Os desenvolvedores devem apresentar uma Ficha Cadastral constando: 

•       Nome do Aplicativo:
•       Categoria:
•       Principais Caracterísitcas e funcionalidades:
•       Nome do Responsável:
•       Contato do Responsável:

- A proposta de divisão de receita com a Lenovo será feito caso a caso após a aprovação do app.  

- Interessados deverão  enviar um email intitulado APP ANDROID LENOVO, com a Ficha Cadastral mencionada acima e um link para download da versão. Se o aplicativo já fizer parte do Showroom da Intel, a empresa só precisa enviar a Ficha Cadastral e o link do Showroom no corpo do email.

Datas: O período de escolha destes aplicativos inicia-se no dia 04 de julho o e vai até o dia 15 de agosto às 18 horas.

Processo: Os aplicativos serão avaliados pelos times Lenovo e Intel. Os desenvolvedores escolhidos serão comunicados por email com as orientações de próximos passos da parceria.

Emails de contato: Vitor Araujo  (varaujo@lenovo.com), Daniel Almeida (dalmeida@lenovo.com)  e Juliano Alves (juliano.alves@intel.com).

Mais: Só serão aceitos submissões de aplicativos feitos no Brasil e desenvolvidos por empresas já cadastradas no programa de parceira de software Intel®. Para se cadastrar gratuitamente acesse: https://software.intel.com/pt-br/grow-business-reports

LINKS RELACIONADOS:
- Acesse e saiba mais sobre o Lenovo Developer Program em: http://lenovodev.com
- Mais informações sobre o desenvolvimento de aplicativos Android acesse: https://software.intel.com/pt-br/android
- Para outras oportunidades de negócio acesse a nossa página do Brasil: https://software.intel.com/pt-br/brazil-partners
- Saiba mais porque é interessante a parceria com a Lenovo:DownloadLSP11102_LenovoDev_OneSheet_030414.pdf.

Brazil vs Colombia Live Stream

Brasil vs. Colombia en vivo

Hi, I want to develop an app that will be recording movements on screens on android devices but I do not know how to do it, can someone give me start ups?

Hi all,

How to mesure the Intel haswell CPU's memory bandwith?
Is memorytest86+ testing corecort? (17544MB/s)

Thanks!
Roger

By: Clay Montgomery

In the conclusion of this two-part series, I detail the best 3D game engine and middleware solutions for Android* tablets, including free, open source, and proprietary options. I also note which have native support for x86 Intel® processors.

Part 1 of this series introduced the essential concepts and categories of game engines, authoring tools, and middleware for software development kit (SDK) and Android Native Development Kit development and listed the best solutions for 2D game development.

3D Game Engines

3D game engines run on the Android device, parse the content from your authoring tool, and render the graphics through OpenGL ES*. They also provide essential services beyond the scope of OpenGL ES, such as rendering text fonts, detecting touch input, and providing audio and video integration. Most game engines originated on the Windows* platform and have been ported to Android fairly recently. Some are more comprehensive and mature (such as Unity* 3D) but also larger and more costly, while others are completely open source and free (such as the Lightweight Java* Game Library [LWJGL] and jMonkeyEngine).

The most complete solutions even provide portability for your game through OpenGL ES to game consoles, Apple iOS* devices, Linux*, and Windows, which can help get your app to a wider market more quickly—but at a cost. The pricing is usually tiered based on the functions you require, how many different platforms you’re targeting, the size of your development team, and the amount of revenue from your game’s sales. Of course, you can expect better support when paying licensing or subscription fees, whereas your only support for free software may be online user forums.

Some game engines are tightly integrated with proprietary authoring tools, and you may have to pay licensing fees to use the tools or the engine when the game is published. But open source game engines generally import content from a range of authoring tools, free or otherwise, in several industry-standard file formats for 3D asset exchange, such as Autodesk 3ds Max* object files or Collada.

Finally, some middleware solutions are not complete game engines but provide many of the pieces required to build custom game engines, such as the Imagination Technologies PowerVR* SDK and LWJGL, at little or no cost. These are good options if your app is limited in scope and doesn’t require all of the services of a typical 3D game or you need the source code for customization.

Physics Engines

Your game may need a physics engine to give your animations natural-looking movement that simulates the forces of gravity, friction, inertia, and restitution on constrained, rigid-body geometry in motion and to detect collisions. The most popular physics engines used for games are Bullet, NVIDIA PhysX*, and Box2D. Bullet and Box2D are free, open source projects. Box2D is limited to 2D, but Bullet and PhysX offer 3D collision detection as well as support for deformable soft bodies, like cloth and rope. Many of the 2D game engines on Android, including Corona, LibGDX, GameMaker:Studio*, Gideros Studio, and LWJGL, use Box2D; many of the 3D engines use Bullet. PhysX is proprietary to NVIDIA; for the Android platform, it is provided free only for educational and noncommercial use. Unity 3D and DX Studio* use PhysX.

Havok Project Anarchy*

Havok Project Anarchy* is a game engine and comprehensive toolkit for mobile game development that has just recently been released. Its licensing allows you to publish your game on Android, Tizen*, and iOS platforms at no cost. It features an extendable C++ plug‑in architecture that includes Havok’s vision and physics engines, animation, and artificial intelligence (AI) tools; a flexible asset-management system; and Lua* scripting and debugging. In addition, complete game samples and extensive courseware are included with the SDK. Havok asks developers to be co-marketing partners and compile with x86 tools to take advantage of the growing market of Android tablets with Intel processors. This is a free but professional new option for mobile game developers.

Unity 3D*

Unity 3D is currently the 3D game engine with the largest market share for Android. It supports a wide range of target platforms, including iOS, Windows, and game consoles. Unity 3D features a built-in integrated development environment; PhysX physics engine; C#, JavaScript*, and Boo scripting languages; multiplayer and network support; and streaming assets. It also supports art assets imported from a range of authoring tools. Developers can get started for free, but a license is required to publish for Android, and the license cost is among the highest. Unity 3D lacks support for Android devices that have Intel x86 processors, which limits the market for Android games built with Unity 3D.

jPCT-AE

The jPCT‑AE engine is an easy-to-learn, all-Java 3D application programming interface (API) that has essential features for building custom game engines for Android. It is free for personal and commercial use. It supports the Autodesk 3ds Max authoring tools, skeletal animations, shaders, texture compression, collision detection, various lighting modes, transparency, fog, and native x86 support for better performance on Android tablets that have Intel processors. It is built on the LWJGL.

Gameplay

Gameplay is a free, open source, cross-platform, C++ 3D framework aimed at indie game development for desktop and mobile games, including Android. It has a full-featured, node-based scene graph rendering system with particles, Bullet physics engine, audio and user interface (UI) systems, and more. It also includes solutions and workspaces for Microsoft Visual Studio*, Xcode*, Eclipse* C/C++ Development Tools, and CMake.

Esenthel Engine

This modern 2D and 3D, C++–based game engine for Windows, Linux, Mac* OS X*, iOS, and Android supports scripting, multiple renderers, an animation system, PhysX and Bullet physics engines, and streaming. It also includes a world editor, model editor, data browser, and code editor and features native x86 support for Android, with one-click, cross-platform publishing. Esenthel Engine is available for an unlimited free trial if used noncommercially.

Linderdaum Engine

The Linderdaum Engine is a free, open source, object-oriented 3D game engine for Windows, Android, and RIM BlackBerry* OS 10 written in C++. It is an integrated solution for the development of interactive 3D applications, including games and industrial and scientific visualization. It also features native x86 support for better performance on Android tablets with Intel processors.

ShadingZen

ShadingZen is a free, open source, 2D and 3D game engine written in Java. It is designed specifically for mobile Android devices that have OpenGL ES 2.0 accelerators and varying screen sizes and uses concepts from the popular Cocos2d framework to exploit modern multicore mobile CPUs to process parallel tasks behind the scenes.

Marmalade*

The Marmalade* SDK is a popular, cross-platform C++ SDK some large game publishers are using for new 2D and 3D Android titles. It supports a wide range of mobile platforms using either Visual Studio on Windows or Xcode on Mac OS X. The Marmalade SDK provides access to OpenGL ES, but it’s relatively new to building 3D games. The company also offers Marmalade Quick, which uses Cocos2d‑x to support building 2D games with the Lua scripting language, and Marmalade Juice, which allows you to recompile Objective‑C* projects on iOS natively for Android. You can evaluate these tools at no cost for 30 days, but a license is required to publish. The Marmalade SDK also features native x86 support for better performance on Android tablets with Intel processors.

ShiVa3D

ShiVa3D is a 3D game engine, editor, authoring tool, compiler, and massively multiplayer online server that has a wide range of supported target platforms, including Android. It includes advanced shading systems, physics, heads-up display rendering, Lua scripting, sound library, and more. ShiVa3D has a single-license, royalty-free pricing structure that covers all mobile platforms that the Marmalade SDK supports.

DX Studio*

DX Studio is a free 2D and 3D game engine that has its own editor for Windows as well as (recently added) support for Android. It uses the PhysX library for physics and can import content from several popular authoring tools.

SIO2 Engine

SIO2 is a cross-platform, 2D and 3D game engine targeting Windows, Bada, webOS, iOS, and Android. It features Lua scripting support, Bullet physics, path finding, sound APIs, a shader, animation, and networking support. SIO2 allows a choice of authoring tools, with several export plug‑in options. A free evaluation kit is available, but a license is required to publish.

Unigine*

Unigine* is a cross-platform, 3D game engine targeting Windows, Linux, Sony PlayStation* 3, Mac OS X, iOS, and Android. Two editions of the SDK are available: one for games and another for simulation, training, real-time visualization, and virtual reality applications. A free evaluation kit is available to develop commercial projects, but a license is required to publish.

LibGDX

One of the best free, open source 3D solutions is LibGDX. It is mostly Java, with some C++ for better performance. LibGDX abstracts away the differences between the Windows, Linux, and Android platforms so that you can develop on a desktop Windows or Linux* PC as much as possible and periodically test your code on an Android device. LibGDX also supports Mac OS X-, iOS-, and Web Graphics Library-enabled browsers. LibGDX is built on the LWJGL, OpenGL ES, FreeType, MPG123, Xiph, the SoundTouch Audio Processing Library, Box2D, OpenAL, and Kiss FFT.

Lightweight Java* Game Library

The LWJGL is a free, open source library for developing commercial-quality games in Java. It provides access to several high-performance, cross-platform libraries, such as OpenGL ES, OpenCL™, and OpenAL, some of which are otherwise unavailable or poorly implemented on Java platforms. LWJGL allows Android game development with 3D sound and access to controllers such as gamepads, steering wheels, and joysticks. Many of the 2D and 3D game engines targeting Android use this library, including jPCT‑AE and LibGDX.

jMonkeyEngine SDK

jMonkeyEngine is a free, open source, 3D game engine for adventurous Java developers who want to create 3D games using cutting-edge technology. It features tools for terrain sculpting, cinematics, networking, input, custom controls, and audio and video. Windows, Linux, Mac OS X, and Android targets are supported. For physics simulation, jMonkeyEngine uses jBullet, a Java port of the Bullet physics library. jMonkeyEngine is unusual in that it’s tightly coupled with the Blender authoring tool, which forms a completely open source and free 3D game development solution.

PowerVR* SDK

The PowerVR SDK includes tools and libraries that you can use to build custom game engines in C++ for many platforms, including Android. Particularly important is the PVRTexTool, which is required to compress 2D images into the proprietary PVRTC texture formats for the PowerVR GPU for Intel® Atom™ processors. This SDK also includes the PVRGeoPOD tools for importing content from several popular authoring tools, including Collada, and a comprehensive collection of tutorial OpenGL ES example programs. This SDK is proprietary but distributed at no cost with a permissive license. It is available through the Android SDK Manager as an Eclipse add-on. Follow the steps at the PowerVR Downloads site to install the SDK.

Table 1 shows the popular 3D game engines and available SDKs.

Table 1. 3D Game Engines and SDKs

Conclusion

An incredible wealth of 2D and 3D game engine, authoring tool, and middleware solutions have recently become available to help accelerate the development of new apps that exploit the larger, high-resolution displays and accelerated OpenGL ES 2.0 features of new-generation Android tablets. You can tap into these software solutions and choose from the many language, licensing, and cost options to simplify much of the complexity of the Android platform and provide more visually compelling user experiences that will make your apps stand out from the crowd.

For More Information

• Displaying Graphics with OpenGL ES, Google tutorial.
• Check out Game Engines for Android by Nathan Totura.
• See Intel® Demonstrates New Advancements in Mobile Graphics by Jerry Makare.
• See Intel for Android* Developers Learning Series #11: OpenGL ES* Support, Performance, and Features for Android on the Intel® Atom™ Processor by Clay D. Montgomery

About the Author

Clay D. Montgomery is a leading developer of drivers and apps for OpenGL on embedded systems. His experience includes the design of graphics accelerator hardware, graphics drivers, APIs, and OpenGL applications across many platforms at STB Systems, VLSI Technology, Philips Semiconductors, Nokia, Texas Instruments, AMX, and as an independent consultant. He was instrumental in the development of some of the first OpenGL ES, OpenVG*, and SVG drivers and applications for the Freescale i.MX and TI OMAP* platforms and the Vivante, AMD, and PowerVR graphics cores. He has developed and taught workshops on OpenGL ES development on embedded Linux and represented several companies in the Khronos Group.

By: Clay Montgomery

The market for games and other graphics-intensive apps for mobile devices is exploding, and important new developments are accelerating it. With better hardware, software, and ecosystems, the opportunity for Android* game developers has never been better. But where should you start? In this first of a two-part series, I explore recent developments in game engines, graphics software development kits (SDKs), and other middleware that will help you get your game or graphics-intensive app up and running on Android quickly and provide a richer, more compelling user experience with all those new pixels that tablets have available.

This first installment introduces essential concepts and categories of game engines and middleware to help narrow your choice, including SDK versus Android Native Development Kit (NDK) development. The second part will detail the strengths and weaknesses of specific game engines and middleware that are good options for 2D and 3D graphics development for Android tablets, including some you have probably never heard of. An incredible wealth of software is available for game development, but I focus on solutions that are well suited to Android tablets.

Better Hardware

The new generation of Android-based tablets with Intel® Atom™ processors are game changers. With longer battery life and large, high-resolution displays, it’s easy to see why these devices are displacing laptops running Windows* for many users and apps. Of course, it takes a serious graphics processing unit (GPU) to push a million or more pixels, and the integrated SGX544MP2 GPU on Intel platforms (codenamed Bay Trail) is up to the task. It may surprise you that more than 99 percent of all Android devices in use today have GPU acceleration of the OpenGL ES* 2.0 application programming interface (API) built in. But what about the software? Android still has a graphical user interface (GUI) designed for phones, and most mobile games still look like the console games of 10–15 years ago. Games that exploit all those new pixels well will stand out from the crowd. That is the opportunity, but it’s also the challenge. Success will require exploiting the latest software middleware and tools.

Better Software

Large, high-resolution displays demand better graphics. What was once cool on a 4‑inch phone looks really dated on an 8‑inch tablet without improved software. You need to exploit all of those available pixels to provide a more visually compelling user experience. For example, simply replacing solid colors and gradients with images that are rendered with animation or lighting effects can dramatically improve the look of a UI. Fortunately, many graphics SDKs, game engines, and other middleware recently ported to Android can help, but there are several options from which to choose, and deciding on one isn’t trivial. It’s a critical decision because any middleware can require a substantial time investment to learn and will directly affect the look and performance of your app. So, in this article, I hope to help you narrow your decision—or at least detail some of the better options you might not have considered, yet. But first, let’s define some important terms and middleware categories.

Android* Graphics APIs

Two graphics APIs are built into Android that most apps use today: the Canvas API and OpenGL ES. The Canvas API is part of the original Android framework and is limited to 2D (although some 3D effects are possible) and Java* technology. Support for OpenGL ES has also been in Android from the beginning but has improved dramatically since the Froyo release, with the addition of OpenGL ES 2.0 and support for C/C++ with the Android NDK. The Ice Cream Sandwich release brought a major redesign of the Android internal graphics system, which now relies heavily on OpenGL ES 2.0 as more than 99 percent of all Android devices now have built-in GPUs that accelerate it. The Canvas API has also been improved to use OpenGL ES acceleration. Developers now have the choice of using OpenGL ES 1.1 or 2.0 from Java, native C/C++, or both in addition to the Canvas API.

The SDK and the Android NDK

The Android framework SDK requires that app development be in Java, but the NDK for C/C++ is also available. Of course, you can use Java and C/C++ together through the Java Native Interface. Because most of the Android platform’s functionality is available only from the SDK, Google recommends that you implement as much code as possible in Java, but there is a trend for developers to implement graphics-intensive apps on Android partially in C/C++ with the NDK. Such a hybrid design may not be the most elegant or easy to implement, but it’s necessary if you want to use some of the best middleware available and get the best possible performance. Some middleware options are available only in C/C++, which is why Google decided to open the NDK to app developers: to use the large pool of existing software available for OpenGL*, which is typically in C/C++. Good all-Java options are becoming available too. Some of these attempt to provide native code performance while allowing your development to remain entirely in Java.

Intel® Atom™ Processors

Intel Atom processors provide outstanding support for the Canvas and OpenGL ES APIs on Android, with OpenGL ES acceleration and faster floating point than other processor types. Intel’s software support includes x86 system images for Android Virtual Device emulation, the Intel® Hardware Accelerated Execution Manager, and Intel® Graphics Performance Analyzers. These tools make it faster and easier to develop apps for Intel Atom processor-based Android tablets, and you don’t even need Intel Atom processor-based hardware to get started.

Authoring Tools

If you have worked with OpenGL, you have seen books and web tutorials that show how to draw a triangle or a textured cube. But what about more complex shapes? Constructing complex geometry programmatically is tedious; fortunately, there’s a better way: authoring tools. Professional game developers use tools like Autodesk 3ds Max*, Autodesk Maya*, or Blender to construct 3D geometry complete with texture maps, animations with physics, and lighting effects.

Some game engines and SDKs provide a specific authoring tool or integrated development environment (IDE) that is tightly integrated, particularly for 2D development. Generally, 3D engines support the major stand-alone tools, with plug‑ins for tighter integration, because that’s what game developers expect. A full description of authoring tools is beyond the scope of this article, but it’s essential to understand that this is where modern graphics content creation begins, and these tools are more accessible, easier to learn, and more widely used than ever. The cost of these tools varies widely. Blender, for example, is open source and free; hundreds of video tutorials are available online to help you learn how to use it. Content you create with these tools can be exported to a range of file formats that game engines use to render your graphics on Android devices.

Most game engines and other middleware assume that you’re using an authoring tool to create geometry in 3D scenes with animation and lighting effects. These tools run on a workstation to produce content that will be copied to Android devices and rendered by a game engine or other middleware. Therefore, your choice of authoring tool can determine which game engines or middleware are available to you (although most middleware support multiple authoring tools).

You might think you don’t need an authoring tool or game engine if your geometry is simple. Say you just want to animate some rectangles around the screen. That’s easy to do entirely with code, right? Well, do you want them to move with simulated inertia? Friction or gravity effects? Detect when they collide? Authoring tools create the key frame animations for rotation and scaling and apply those physics effects for you. How about some 2D images on those rectangles, with reflection and specular highlight effects? Authoring tools also automate the generation of texture coordinates and surface-normal data that OpenGL ES requires to render geometry with lighting effects. Game engines import this data from the authoring tools and render it as well as detecting collisions and handling audio, touch input events, and more. This is why using authoring tools has become so important for modern app development.

2D Game Engines

Why use a 2D game engine when the 2D Canvas API is built into Android?…because game engines provide much better graphics performance, most being built directly on OpenGL ES and bypassing the Android Canvas API. Even though the Canvas API also uses OpenGL ES, its performance doesn’t compare with the directly accelerated game engines that are available. Many of these 2D engines on Android are quite mature. In fact, many published titles and integrated features can save you a lot of development time, including 3D audio, networking, and physics. Some have tightly integrated authoring tools or IDEs and simulators to test and debug your game on a workstation before testing on Android, which also accelerates the development cycle. Finally, game engines provide platform abstraction, so you can easily port and publish your game to other platforms, as well.

Game engine licensing and pricing vary dramatically. Some 2D engines are open source and completely free, such as Cocos2D and AndEngine, but support is limited to online forums. Others offer tiered pricing models, so you can start developing for free, and then pay subscription or royalty fees when you need more technical assistance, advanced features, or are ready to publish your game. Some allow publishing at no cost if you can tolerate their logo splash screen or limited features. Generally, subscription costs increase with the number of different platforms for which you want to publish and the amount of technical assistance you need. Table 1 shows the popular 2D game engines and available SDKs.

Table 1. 2D Game Engines and SDKs

Conclusion

The new generation of Android-based tablets with Intel Atom processors; large, high-resolution displays; and OpenGL ES 2.0 acceleration have created a fantastic opportunity for app developers to exploit these devices by tapping into the wealth of 2D and 3D game engines, authoring tools, and middleware that have recently become available to provide more visually compelling user experiences on Android. Games and other apps that target this new hardware can stand out from the crowd by exploiting these new middleware and authoring tool solutions well.

Part 2 of this series will detail the best 3D game engine and middleware solutions available for Android tablets, including free, open source, and proprietary software. You’ll also discover which have native support for x86 Intel processors.

For More Information

• Get information about screen sizes and OpenGL ES versions used on Android devices.
• Learn more about Porting OpenGL* Games to Android* on Intel® Atom™ Processors.
• Displaying Graphics with OpenGL ES, a Google tutorial.
• Check out Game Engines for Android by Nathan Totura.
• See Intel® Demonstrates New Advancements in Mobile Graphics by Jerry Makare.
• See Intel for Android* Developers Learning Series #11: OpenGL ES* Support, Performance, and Features for Android on the Intel® Atom™ Processor by Clay D. Montgomery

About the Author

Clay D. Montgomery is a leading developer of drivers and apps for OpenGL on embedded systems. His experience includes the design of graphics accelerator hardware, graphics drivers, APIs, and OpenGL applications across many platforms at STB Systems, VLSI Technology, Philips Semiconductors, Nokia, Texas Instruments, AMX, and as an independent consultant. He was instrumental in the development of some of the first OpenGL ES, OpenVG*, and SVG drivers and applications for the Freescale i.MX and TI OMAP* platforms and the Vivante, AMD, and PowerVR* graphics cores. He has developed and taught workshops on OpenGL ES development on embedded Linux* and represented several companies in the Khronos Group.