How-to debug native code with Android

This is a step by step guide for executing and debugging native code on Android with Eclipse.

1. Prerequisites

The SDK version used for this guide is Froyo with the NDK r4b ( crystax release ).
Also Eclipse CDT plugin it’s very useful for our purposes, so install it.
Last plugin to install it’s the Sequoyah plugin for Eclipse.

2. Project setup

At this point let’s create a new Android project, name it “Example” and use the “” package name, add also an Activity name of your choice.
Select Android 2.2 as base SDK version and complete the project wizard.

Now you need to add the native support for the newly created project. Just right click on the project root element in the package explorer and select “add native support”.

In the next dialog write the path of your NDK folder and give also name for your library.
After this operation a new folder “jni” will be created with a .cpp file, header filer and an Android makefile,, which can be edited to modify all the includes, linker and compiler options. In the file you also need to specify all the source file you want to use within the LOCAL_SRC_FILE directive.

3. Debug

In order to enable debug of native code in Android you have to face different problems, based also on the device and the firmware version, and if the native code is multi thread or single thread.
First of all you need to mofify the AndroidManifest.xml file adding the attribute “debuggable” to true ( remember also to enable the “Debug USB” option under the Application device menu ).
At this point you can debug all the java code within your eclipse debugger, for for the native C debug you need more steps.

Continue reading

Playing with a LocalActivityManager bug

If you already used the ActivityGroup class you probably used also the LocalActivityManager instance to manage your group’s activities. I was creating my activity which should also manages its internal history ( using a ViewFlipper for animating the activity views ).
The problem came out once I tried to destroy an activity from the history using the LocalActivityManager destroy method. After an activity was removed from both my internal history and from the local activity manager I was unable to create a new instance of the same activity.

After googling for my problem I found that it was because a bug in the LocalActivityManager class:
This is exactly my problem! In fact, debugging the android code ( see this post for debugging android code ) at that point it was clear that the record it’s not removed from the internal mActivities map.

Fortunately there are Reflections which can help me! I added this piece of code after the call to the destroy method:

Field mActivitiesField = getLocalActivityManager().getClass().getDeclaredField( "mActivities" );
mActivitiesField.setAccessible( true );
((Map) mActivitiesField.get( getLocalActivityManager() )).remove( id );

and that trick does the job

Reading resource files from native code

If you’re working with android-ndk and you want to open an asset included in your apk package, you should make a request via jni to the Resource manager in your java code.
Something like:

public int[] openAsset( String path )
AssetFileDescriptor ad = null;
ad = getResources().getAssets().openFd( path );
Integer off = (int) ad.getStartOffset();
Integer len = (int) ad.getLength();
int res[] = { off, len };
return res;
} catch( IOException e ) {
Log.e( TAG, e.toString() );
return null;

However this is not a optimal solution expecially when you have tons of file io operations, also because I prefer to limit the amount of calls between java and C++.
A better solution I’m using is to open the current apk application using the libzip library. Just download the library and compile as static library, then include it in your make file under the LOCAL_STATIC_LIBRARIES section.
What you have to do first is to send the current application filename from java, once at startup, in this way:

PackageInfo info = null;
try {
info = getContext().getPackageManager().getPackageInfo(“com.example.text”, 0);
} catch( NameNotFoundException e ) {
Log.e( TAG, e.toString() );
setAppName( info.applicationInfo.sourceDir );

and in the C++ code you will have the corresponding setAppName method:


char packageName[1024] = {0};
zip *pkg_zip;

JNIEXPORT void JNICALL Java_com_example_test_MySurfaceView_setAppName( JNIEnv * env, jobject obj, jstring pkgname )
const char *buffer = env->GetStringUTFChars( pkgname, false );

int error;
pkg_zip = zip_open( buffer, 0, &error );
strcpy( packageName, buffer );
if( pkg_zip == NULL ){
LOGE(“Failed to open apk: %i”, error );
env->ReleaseStringUTFChars( pkgname, buffer );

Now you have a reference to the zip package. In this way now you can query the zip package asking if a particular file exists:

bool FileExists(const char* fname)
if( pkg_zip != NULL )
int result = zip_name_locate( pkg_zip, fname, 0);
return result != -1;
return false;

And open any of the files included in your apk package:

FILE *FileOpen( const char* fname )
zip_file *zfile = zip_fopen( pkg_zip, fname, 0 );
uint32_t offset = 0;
uint32_t length = 0;

if( zfile != NULL )
offset = zfile->fpos;
length = zfile->bytes_left;
zip_fclose( zfile );
zfile = NULL;
} else
return NULL;

FILE *fp = NULL;
fp = fopen( packageName, “rb” );
fseek( fp, offset, SEEK_SET );
return fp;

Using this method you will have a FILE pointer to the whole apk file so you have to take care of the offset and length field when reading and seeking the file itself.

Disable asset compression with Android aapt

Trying to embed all the assets resources into my final apk was not so easy as I tought.. at least using the ADT Eclipse plugin for building project.
In fact, using AssetManager.openFd to return to the C++ code a FileDescriptor does not work with compressed sources.
When aapt compile the resources into the apk file it compress by default all the files which extensions are not recognized and those which recognize as text files.

These are the extensions not compressed:

static const char* kNoCompressExt[] = {
“.jpg”, “.jpeg”, “.png”, “.gif”,
“.wav”, “.mp2”, “.mp3”, “.ogg”, “.aac”,
“.mpg”, “.mpeg”, “.mid”, “.midi”, “.smf”, “.jet”,
“.rtttl”, “.imy”, “.xmf”, “.mp4”, “.m4a”,
“.m4v”, “.3gp”, “.3gpp”, “.3g2”, “.3gpp2”,
“.amr”, “.awb”, “.wma”, “.wmv”

I was looking into the .project file of my Eclipse project but it seems that changing things inside that file ( like values into the tag ) does not affect the builder.

The first thing I tried was to remap the aapt executable using a shell script ( and renaming the original aapt file into _aapt ):


CWD=’dirname $0’

for i in $@; do
if [ $i = “-S” ]; then
strParams=”$(echo $strParams) -v -0 \”\””
strParams=”$(echo $strParams) $i”

tool=”$CWD/_aapt $strParams”
$tool 1>&2

In fact, when building the project in eclipse I could see the whole output, but the files are still being compressed, even if I call the same command in a shell the assets aren’t compressed.
I haven’t yet find a solution so for the meantime I decided to use ant to build my project overriding the default “-package-resources” target in this way:


Packaging resources


In this way the project is being compiled correctly and all my assets are embedded not compressed!

P.S. my claim token is: 7C8AATS7Q5A3

Android: Create your own sharing app

One of the first applications I did for Android was a very simple application which simply takes a picture using Camera and then send it to a remote server. Very simple, but it introduced to me into the android world and the notion of activities and communication between different applications.
A little addition to this application I wanted to make was the possibility to share any of the pictures already taken. To do that I wanted to add the application to the list of the choices which appear when an user click on the “share” button when view an image using the default Gallery application.

Continue reading

Haxe got (awesome) macros!

Hi guys, It has been a while since I posted the last time.
However I felt like it was the right moment to go back on the blog, to talk you about the new awesome Haxe macro system.

As you can read on Nicolas’s blog, they’re only present in the latest SVN update, but they will be included in the next build as soon as they will be perfect.
I must say I’m extremely happy about that addition: one of the most important reasons I’m so happy is the fact that instead of implementing an old-and-bording Macro system ala C/C++, Nicolas decided to go for a much more powerful macro system, which allows typesafe macros and real runtime code generation.

You are not limited to simple stuff like replace a macro call with a block of source code, but you can generate any kind of valid AST expressions that will be evaluated by the macro preprocessor at compile time.
Moreover you have access to almost the whole neko library (io, net, etc) which means you can write extremely powerful code generators and DSL! That’s an awesome feature – really.

Give it a look!

FlexLayout for AsWing

As you may have noticed I’m working with AsWing right now 🙂
Today I proposed a modification of the layout system. That’s because I couldn’t find any layout which satisfied my needs: a container which grows its components in order to fill the entire container size BUT which also keep in mind the component minimum and maximum sizes.
So it will try to grow all the components to the same size, but if a component has defined a specific minimum or maximum size, take that size under consideration.

Here’s a screenshot of the FlexLayout class in action ( click over the image to see the live demo ):

And here’s the code for using the layout:

f.getContentPane().setLayout( new FlexLayout( FlexLayout.VERTICAL, 2 ) );

Continue reading

Master of Alchemy is on the App Store!

After six months of hard development we’re so happy to announce that Master of Alchemy has been finally published in the iTunes App Store last Friday!

I’m sorry to spam again with this topic, but trust me, it has been a bet for all of us!
And actually it’s included into the “New and Noteworthy” section!
You can see Master of Alchemy page at the AppStore


Games Uncovered review…without a doubt one of the best iPad games yet.

Simply a fantastic puzzle game that is challenging, deep and graphically stunning. An absolute treasure.


Destructoid review:Score: 8.5 — (8s are impressive efforts with a few noticeable problems holding them back. Won’t astound everyone, but is worth your time and cash