Re: Reading resource files from native code

1,389 views
Skip to first unread message

Chris Perry

unread,
Apr 5, 2012, 5:02:23 AM4/5/12
to android-ndk
Hi android-ndk

So after extensive internet research we're still pretty confused over
the best way to access resource files from native code.
As far as I'm aware, there hasn't been a final response from the dev
team on how to properly do this.

Our situation must be pretty common:

-We've got a cross platform engine, using c/c++, now that there is an
NDK, we'd like to port our games over to the android platform.

-Our game assets live within a directory structure.
-Everything from models, to textures to sounds.
-All packaged into the apk uncompressed, via ant.


Ok, so now how do we load those files?

Options seem to be:
B) use the provided AssetManager to get a fd,offset,size etc
(apparently not recommended)
C) use input stream to get at the bytes directly
D) pipe the APK file thru libzip and use that lib to get at the files
E) unpack the APK manually on first run into the storage space
allotted by the system
F) embed the assets into a static lib or code

All we really want is option A:
-get a path from the system to the asset directory.

Please advise.




Tor Lillqvist

unread,
Apr 5, 2012, 12:38:12 PM4/5/12
to andro...@googlegroups.com
I assume your app uses the NativeActivity class?

Write a subclass of NativeActivity that calls some native function of yours to tell it the path to the .apk file. mmap the .apk file in your native code. parse the .zip archive directory to find the files you need. Use them directly as they exist in memory as part of the mmapped .apk file.

That's what we do in LibreOffice. Works fine. Of course, there are a lot of details that can go wrong, so be careful.

--tml

Dianne Hackborn

unread,
Apr 5, 2012, 4:30:33 PM4/5/12
to andro...@googlegroups.com
The official way is with the APIs in asset_manager.h.  Use NativeActivity, that has the AAssetManager for your application in its 'assetManager' field, and you can use the asset_manager.h functions to iterate, open and read the contents.





--
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.




--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Chris Perry

unread,
May 1, 2012, 3:30:41 PM5/1/12
to android-ndk
Hi again,

Thanks for the responses, we were able to get it working based on your
feedback!

We ran into some issues using the AAssetManager's API though so I
thought I should update this post.

Background:
We're using uncompressed assets (via <nocompress /> flag within the
build.xml file)
We're porting from IOS/OSX/Windows (all file access was done via
stdlib calls on a FILE pointer fseek,fopen, etc)
We're not using the Eclipse environment.

Problems:
We wrapped up all file access into a custom class which uses the
AAssetManager's API for Android builds.
We pass the AAssetManager provided by the NDK to this system.
At first we used the corresponding AAssetManager API calls directly
(AAsset_read, AAsset_seek, AAsset_getLength) etc.
However we got mixed results, files were not loading 100%.
Turns out we were confused over AAsset_getLength -we expected it to
work like ftell.
However it seems that a combination of AAsset_getLength and
AAsset_getRemainingLength would be required to simulate ftell's
behaviour?

Solution:
The solution we came up with was to use AAssetManager's API to obtain
access to the File Descriptor, starting offset and length
Then we perform all operations using stdlib's API on that file
descriptor.

We make sure to use AAsset_open and AAsset_close in addition to fdopen
and fclose

Suggestion:
In our experience we think that the NDK could benefit by adding
AAsset_tell to the AAssetManager's API so that it could be a 1 to 1
solution to stdlib.
Of course more documentation on the API would have saved us time as
well =]

Cheers,
Chris








On Apr 5, 1:30 pm, Dianne Hackborn <hack...@android.com> wrote:
> The official way is with the APIs in asset_manager.h.  Use NativeActivity,
> that has the AAssetManager for your application in its 'assetManager'
> field, and you can use the asset_manager.h functions to iterate, open and
> read the contents.
>
> On Thu, Apr 5, 2012 at 2:02 AM, Chris Perry
> <chris.pe...@muyinteractive.com>wrote:
> hack...@android.com

天才

unread,
May 1, 2012, 9:03:37 PM5/1/12
to andro...@googlegroups.com

David Turner

unread,
May 4, 2012, 10:00:34 AM5/4/12
to andro...@googlegroups.com
This spammer/bot account has been removed, sorry for the annoyance.
Reply all
Reply to author
Forward
0 new messages