Also, why don't you try and use the standalone toolchain with your existing
makefiles instead of writing Android.mk files?
See: ndk/docs/STANDALONE-TOOLCHAIN.html
Olivier
> --
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to
> android-ndk...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/android-ndk?hl=en.
The thing is that there is no recipe for writing an Android.mk for an existing
library. Each case is a bit specific.
Using the standalone toolchain should be easier than Android.mk files here.
Provided that you built the toolchain in /path/to/toolchain, then you should be
able to do something like:
export PATH=/path/to/toolchain/bin:$PATH
export CC=arm-linux-androideabi-gcc
export LD=arm-linux-androideabi-ld
export AR=arm-linux-androideabi-ar
./configure
And then just type make.
Olivier
I especially recommend that you follow the instructions in section 3
"Invoking the compiler (the easy way)".
Olivier
If you look at the docs to create a standalone toolchain, using the ndk
toolchain dir doesn't really work. You absolutely need to run the tool to
create a real standalone toolchain and then use that as your toolchain root.
--
Thomas Fjellstrom
tfjel...@gmail.com
Also, you don't need to repeat the path in every CC, LD, AR, etc.. variable,
that's what PATH is here for.
/path/to/toolchain was just a placeholder, as an example.
Try:
export PATH=/tmp/my-android-toolchain/bin:$PATH
export CC=arm-linux-androideabi-gcc
export LD=arm-linux-androideabi-ld
export AR=arm-linux-androideabi-ar
./configure
Olivier
./configure --host=arm-eabi
That's needed to tell autoconf that you're cross compiling.
If its a regular executable, you can't at least not if you want it to act like
a regular android application. Apps have to use Android API's to work as
normal Android Apps.
--
Thomas Fjellstrom
tfjel...@gmail.com
You haven't "made an application". You have compiled an executable and/or native
libraries.
Now, if you haven't done already, you need to create an Android application,
certainly in Java, to provide a user interface, with buttons, etc...
And this application must either call native functions of your library through
JNI, or run the executable with the appropriate arguments from Java with
Runtime.exec().
Olivier
PackageManager pm = context.getPackageManager();
String dataDir = pm.getApplicationInfo(context.getPackageName(), 0).dataDir;
Olivier
Beware that if you ever target the armeabi-v7a ABI (to take advantage of the
FPU, etc..), then the binaries need to be placed into libs/armeabi-v7a/ instead.
But if you don't pass any flags about ARMv7 when compiling, then you don't need
to care about this.
Olivier
Olivier
Your method is a good alternative IMO. But make sure that your properly handle
failures in case the filesystem is full.
Olivier
Olivier
You may need to run chmod with Runtime.exec() to adjust the permissions of the
executable. In doubt try 777.
I did test on Android 2.1 and it works.
Olivier
String args[] = {"chmod", "777", filepath};
Runtime.getRuntime().exec(args);
Where filepath is the absolute path to your executable.
Olivier
Olivier