How to build apk file using android SDK after creating NDK project

[Elvis Dowson]

Hi,
I have two top level folders, one containing the android-1.5
SDK and the other containing the android-NDK-1.5_r1.

Within my android NDK folder, I've setup the host tools and run the
following command:

make APP=hello-jni

This builds the required libhello-jni.so file in the libs/armeabi
folder.

Now I want to make the hello-jni apk, and add it to the android-1.5
SDK's build/core/main.mk file, so that when I build the android sdk,
the hello-jni applicaiton's apk file is created automatically and
added to the system image.

How can I do this?

Elvis Dowson

[Elvis Dowson]

[David Turner]

You can't really do that, the NDK is specifically there to allow *application* developers
to add native code to their third-party .apks.

Doing the same for the system image requires using the full Android build system,
which works a little differently. Fortunately, you will be able to reuse your Android.mk
but there may be other steps involved. I really don't know enough details, try to ask
in android-platform since this really is related to the NDK.
 

Elvis Dowson

[Elvis Dowson]

Hi,
I don't understand.

>
> You can't really do that, the NDK is specifically there to allow
> *application* developers
> to add native code to their third-party .apks.
>

I have a native c library that I want to call from my android app.
What do I do to create an apk out of it? The full build system is
inside the SDK folder. What should I do to build an apk file out of
the hello-jni NDK sample.

Elvis

[David Turner]

There is some confusion here :-) You ask specifically how to add an application to the
system image, and this is not supported by the SDK, only by the full Android build system.

If all you want is generate an .apk to and install it in an AVD or device, then
you should follow these instructions (assuming $SDK/tools is in your path):

make APP=hello-jni
cd apps/hello-jni/project
android update project -p .
ant release
ant install

Use "ant reinstall" is the .apk is already installed on the device/emulator.

Elvis

[Raji Reddy Kandi]

Hi,

 

This installs the native shared library libhello-jni.so along with the hello-jni android app. How can we install only the lib libhello-jni.so so that any android app can invoke it?

 

Regards,

[David Turner]

On Thu, Jul 2, 2009 at 2:50 PM, Raji Reddy Kandi <k.raj...@gmail.com> wrote:

Hi,

 

This installs the native shared library libhello-jni.so along with the hello-jni android app. How can we install only the lib libhello-jni.so so that any android app can invoke it?

 

You can't do that, there is no officially sanctioned way to share third-party shared libraries between applications.
You will need to put the libs into each application .apk instead.

[D. Kevin McGrath]

That's pretty wasteful.  So on a space constrained device, we have the situation that every package has its own copy of every library it wants to use?  How hard would it be to just make use of that linux core, and stick these libraries in /usr/local/lib/?

Or is this just another one of those "linker bugs"?

[Tim Hutt]

2009/7/2 D. Kevin McGrath <d.kevin...@gmail.com>:

> That's pretty wasteful.  So on a space constrained device, we have the
> situation that every package has its own copy of every library it wants to
> use?  How hard would it be to just make use of that linux core, and stick
> these libraries in /usr/local/lib/?
> Or is this just another one of those "linker bugs"?

It's probably for security reasons, and to avoid dependency issues. I
don't imagine Google wants users to end up with messages like "The
application depends on libsdjhfwoe.so. Please install it."

[D. Kevin McGrath]

But given the centralized distribution system, the dependency issue is
not, actually, an issue as described. If you need a given library
installed, it needs to exist as an APK in the android store, and can
just be downloaded and install ahead of time. Now, where things get
fuzzy is versioning. But that could easily be dealt with in the same
way.

I guess it all comes down to this: if there is a single, centralized
distribution system, we should get the advantages that it provides.
However, from what I can tell so far, we get all of the downsides, and
none of the ups. But that's just my view, and I could be incorrect.

[David Turner]

On Thu, Jul 2, 2009 at 4:12 PM, D. Kevin McGrath <d.kevin...@gmail.com> wrote:

That's pretty wasteful.  So on a space constrained device, we have the situation that every package has its own copy of every library it wants to use?

Absolutely
 

 How hard would it be to just make use of that linux core, and stick these libraries in /usr/local/lib/?

Applications don't have permissions to modify the system partition. On purpose.
 

Or is this just another one of those "linker bugs"?

Not a bug, a deliberate design decision.
 

[Tim Hutt]

2009/7/2 D. Kevin McGrath <d.kevin...@gmail.com>:

> But given the centralized distribution system, the dependency issue is
> not, actually, an issue as described.  If you need a given library
> installed, it needs to exist as an APK in the android store, and can
> just be downloaded and install ahead of time.  Now, where things get
> fuzzy is versioning.  But that could easily be dealt with in the same
> way.

It's just not worth it. You save a small bit of memory and disk space
in a *very small* number of cases. In return you have to:

a) Maintain some kind of Debian-like library repository.
b) Handle versioning - you're probably going to end up with multiple
versions of the libraries installed anyway.
c) Create a security infrastructure for allowing the installation of
shared libraries.

I'm sure there are other disadvantages. There are much more pressing
issues in Android anyway. :-)