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 “com.darkwavegames.com” 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, Android.mk, which can be edited to modify all the includes, linker and compiler options. In the Android.mk 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

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:

[cc]
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”
};
[/cc]

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 ):

[cc]
#!/bin/bash

strParams=””
CWD=’dirname $0’

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

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

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:

[cce]

Packaging resources
${asset.absolute.dir}
command=”package”
verbose=”${verbose}”
versioncode=”${version.code}”
manifest=”AndroidManifest.xml”
assets=”${asset.absolute.dir}”
androidjar=”${android.jar}”
apkfolder=”${out.absolute.dir}”
resourcefilename=”${resource.package.file.name}”
resourcefilter=”${aapt.resource.filter}”>

[/cce]

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

P.S. my claim token is: 7C8AATS7Q5A3

Amethyst Actionscript editor

amethyst screenshotIt’s since the first time I used Eclipse that I’m waiting for an actionscript editor non eclipse based!

I never like eclipse and hated all its problems.
Unfortunately Adobe decided to implement its editor over eclipse and also other nice editors, like fdt, used the eclipse framework to build their own editors.
I used Visual Studio for a while but that was enough to make me fall in love with it.
Visual Studio is indeed the best editor at all, without doubts!
Finally I discovered an interesting project for editing actionscript projects integrated into Visual Studio.
Amethyst is still in beta and probably too premature to be used in large production environment, but it’s a great news for me.
I hope they’ll continue in the development and create a serious competitor for Flash Builder.
For more info visit their product page: http://www.sapphiresteel.com/Amethyst-Product-Page

An experience with antlr, java and python

I just wanted to share a little experience with generating an AS3 parser using antlr and python.
I was trying first to create the parser using GNU Flex and Bison in C, probably the best way for a very performancing parser.
Yeah, that’s right.. but looking at the antlr syntax I realized that’s easier and easier.
Moreover I start using this very useful eclipse plugin for antlr debugging which made my life easier!

The grammar file I created is a compromise between the asdt grammar file and the ECMA-262 grammar specification.

Once finished working on my eclipse project I’ve managed to parse succesfully all the adobe corelibs files using this java test file:
package org.sepy.core.parsers.as3;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import antlr.CommonAST;
import antlr.RecognitionException;
import antlr.TokenStreamException;
public class Application {
public static void main(String argv[])
{
if(argv.length > 0)
{
File file = new File(argv[0]);
if(file.exists())
{
FileInputStream is = null;
try {
is = new FileInputStream(file);
} catch (FileNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
AS3Lexer L = new AS3Lexer(is);
AS3Parser P = new AS3Parser(L);
try {
P.compilationUnit();
} catch (RecognitionException e) {
// TODO Auto-generated catch block
System.out.println(" line=" + e.line + ", column="+ e.column);
System.out.println(e.getMessage());
e.printStackTrace(System.err);
} catch (TokenStreamException e) {
// TODO Auto-generated catch block
System.out.println(" line=" + L.getLine() + ", column="+ L.getColumn());
System.out.println(L.getGuessInfo());
System.out.println(e.getMessage());
e.printStackTrace(System.err);
}
CommonAST.setVerboseStringConversion(false, P.getTokenNames());
CommonAST ast = (CommonAST) P.getAST();
System.out.println("Tree:");
System.out.println(ast.toStringTree());
}
}
}
}

Ok, done that I decided to export the grammar file for python (thanks to antrl python export feature).
Everything works fine also for python, but I realized that the python script were so much slower than the java one!
import sys
import antlr
import AS3Parser
import AS3Lexer
L = AS3Lexer.Lexer(filename);
P = AS3Parser.Parser(L);
P.setFilename(filename)
try:
P.compilationUnit();
ast = P.getAST();
except:
pass

On a 75Kb actionscript file the python script took about 7 seconds to run, while the java application only 2 seconds. I know python interpreter caould be slower than many other languages, but I never thought so much slower.
So I run the python hotshot profiler to see which could be the bottleneck in the python script and I found most of the problems were due to unuseless antlr (the python module) method’s calls.
After making corrections to the antlr.py file the same script took exactly half of the time. Now 3 seconds. Wow 🙂
But not fast enough.
So I enabled for the antlr python script psyco module and this time the same script took only 1.6 seconds.
Now the python script is fast enough, even if I’m sure I can make more optimizations in the antlr module…

Flying away… holidays!!

Before leaving for my holidays i just want to make a quick post about the recent SE|PY additions…

1. Quick search bar

sepy quick search

The new “quick search” bar at the bottom. Thanks to Eric Dolecki who suggested me a more usable and fast to use “search” control (thanks also to Eric new icons suggestions!)
I use Mozilla Firefox from more than one year, i love the way it has implemented the find bar, and I never thought at using it in SEPY? yes.. that’s true 🙂

2. Right border enhancement

This is directly taken from an Eclipse feature i like a lot.
For every bookmarked line or line with a “TODO” comment you will have in the right side of each document a small clickable rectangle, with different colors, which show you the absolute position of that line in the document.
When you move the mouse over that rect you will see a tooltip telling you the content of the line and click on it for move to that line.
Nothing particular, but I found it really useful.
It’s now possible to customize the words SEPY is looking for (not only “todo”, but what you want)
Moreover, with the last addition of a sqlite database once you open a document for the second time you will see all the previous bookmarked lines, and the cursor will be placed in the same position you previously closed the document.

MTASC compile

Last addition is the mtasc compile dialog.
Using this dialog window you can compile yuor script in SEPY using the mtasc compiler and see in the same dialog a preview of the created SWF.
BTW, I will leave for my holidays on Monday (destination Tallinn, Estonia).
See ya again by the end of August.. and great holidays to you all!!
http://sourceforge.net/

Flash Platform Announcement

This morning Macromedia made several press announcements regarding the Flash Platform, Flash Player, Macromedia’s support of the Eclipse Foundation, and an upcoming toolset for Flex development, code-named Zorn.

http://www.macromedia.com/go/platform

Update on SEPY 2

As I announced some time ago the project for re-writing from scratch SEPY is already started..
actually the framework is quite complete and at the state of art it’s a full basic text editor. Today I met Gabriele, the same guy who helped me in the preliminary phases of sepy1, and we decided some of the new SEPY2 guidelines and how we want to proceed..
SE|PY 2 will be made using a similar, but more more simpler, process as the one used by Eclipse, that is plugin based.
This can help us, but also everyone who want to extend it in the future, with panels (which will be completely independent from the main application), and document classes.
As regarding panels we’re still thinking at the best solution for the workspace management.. maybe a solution similar to the one used by Macromedia software.
any preference here?

BTW, the very first thing in the TODO list it’s indeed the autocompletion system, which must be written as powerful as possible, thus mantaining good performances. This is the first and the core feature, without that the editor could not live…

Other important features will be the support for Flex and all XML in general, maybe using DTD for the autocompletion (for xml files)…

If it will be possible, we have thought also in extending scintilla functionallity in order to have a custom lexer for “.as” files, with extended folding and colouring features.
for example:
//#region

//#endregion
will create automatically folds region…

I hope that basing on the experienced I made with python in the last 2 years and thanks to all the feedback I received during this period to be able to create a better tool for developing flash..