I would like to know how an APK file is structured? I know that an APK
contains an "lib/armeabi/" directory (that contain all "*.so" Shared
Object Libs), a "classes.dex" file (that contains all java classes), a
"AnddoidManifest.xml" file and a "resources.asrc" file (generated by
the "aapt.exe" tool). After the installation, "*.so" are copied in "/
data/data/<application_package>/lib" directory of the Android device
but I don't know where datas are installed and where data are in APK.
Someone can help me?
Thanks in advance,
Msx64
--
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.
in addition to what Doug already told you, I also have a short remark:
> After the installation, "*.so" are copied in "/
> data/data/<application_package>/lib" directory of the Android device
> but I don't know where datas are installed and where data are in APK.
>
Additional data such as in the assets folder is not installed (i.e.
extracted from the APK upon its installation on the device) anywhere -
AFAIK. It just stays within the APK which itself is kept on the device
(which is why it's a bit difficult to access such data from an NDK app).
-hwh
Thanks to all
There seem to be different approaches on how to deal with the situation:
In my case, I pass full direct bytebuffers pre-filled with data to the
native library via callbacks from native code to Java. But depending on
your assets, that may be a veeeery expensive approach in terms of
memory. It also may not be fast enough.
Others resort to compile the data into the library (which makes things a
bit easier, but you pay in terms of memory allocation both of RAM and
installation footprint).
Another approach I've also heard of is to use a native code zip library
and extract from the APK. But note that this approach wouldn't work with
the copyright protection flag on that Andrei mentioned.
I'm still new to the platform, so please correct me, but I think that's
about it. Oh, yes, I also heard that people put such things into the
/lib folder, which indeed does get extracted upon installation. However,
you pay by install footprint and also personally I would feel somehow
dirty by implementing such an approach :-)
-hwh
I have put all data files the "assets" directory of the APK file and
I'm gonna use "MyActivity.getAssets().open("text.txt")" function via
JNI for open a file from the APK file not because I'm to lazy to use
open the APK file via the zlib/minzip libs... but because it's more
safe.
Thanks,
Mustapha
On 04/09/2010 04:06 PM, Mustapha wrote:
> I have put all data files the "assets" directory of the APK file and
> I'm gonna use "MyActivity.getAssets().open("text.txt")" function via
> JNI for open a file from the APK file not because I'm to lazy to use
> open the APK file via the zlib/minzip libs... but because it's more
> safe.
>
Yes, I think this is the most portable and clean solution. Maybe at some
time someone writes a C wrapper library to access assets using the Java
interface :-)
But please note that you do not only need to open the file via Java
interface but also to use Java functions for reading the data! (That's
why I wrapped that functionality in a Java callback function and call
this instead, to reduce the number of Java calls in my JNI lib)
-hwh
I am still looking for a solution to what Mustapha described above. To
be able to load a file to the assets folder and read it from a Native
C code. Is threr anyone who can give me a good set of directions?
Thanks,
Abhi
On Apr 9, 10:14 am, Hans-Werner Hilse <hwhi...@googlemail.com> wrote:
> Hi Mustapha,
>
> On 04/09/2010 04:06 PM, Mustapha wrote:
>
> > I have put all data files the "assets" directory of the APKfileand
> > I'm gonna use "MyActivity.getAssets().open("text.txt")" function via
> > JNI for open afilefrom the APKfilenot because I'm to lazy to use
> > open the APKfilevia the zlib/minzip libs... but because it's more
> > safe.
>
> Yes, I think this is the most portable and clean solution. Maybe at some
> time someone writes a C wrapper library to access assets using the Java
> interface :-)
>
> But please note that you do not only need to open thefilevia Java