Reading resource files from native code

If you’re working with android-ndk and you want to open an asset included in your apk package, you should make a request via jni to the Resource manager in your java code.
Something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public int[] openAsset( String path )
{
   AssetFileDescriptor ad = null;
   try
   {
      ad = getResources().getAssets().openFd( path );
      Integer off = (int) ad.getStartOffset();
      Integer len = (int) ad.getLength();
      int res[] = { off, len };
      ad.close();
      return res;
   } catch( IOException e ) {
      Log.e( TAG, e.toString() );
   }
   return null;
}

However this is not a optimal solution expecially when you have tons of file io operations, also because I prefer to limit the amount of calls between java and C++.
A better solution I’m using is to open the current apk application using the libzip library. Just download the library and compile as static library, then include it in your Android.mk make file under the LOCAL_STATIC_LIBRARIES section.
What you have to do first is to send the current application filename from java, once at startup, in this way:

1
2
3
4
5
6
7
8
PackageInfo info = null;
try {
   info = getContext().getPackageManager().getPackageInfo("com.example.text", 0);
} catch( NameNotFoundException e ) {
   Log.e( TAG, e.toString() );
   return;
}
setAppName( info.applicationInfo.sourceDir );

and in the C++ code you will have the corresponding setAppName method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <zip .h>
#include <zipint .h>
#include <jni .h>

char packageName[1024] = {0};
zip   *pkg_zip;

JNIEXPORT void JNICALL Java_com_example_test_MySurfaceView_setAppName( JNIEnv * env, jobject obj, jstring pkgname )
{
   const char *buffer = env->GetStringUTFChars( pkgname, false );

   int error;
   pkg_zip = zip_open( buffer, 0, &error );
   strcpy( packageName, buffer );
   if( pkg_zip == NULL ){
      LOGE("Failed to open apk: %i", error );
   }
   env->ReleaseStringUTFChars( pkgname, buffer );
}

Now you have a reference to the zip package. In this way now you can query the zip package asking if a particular file exists:

1
2
3
4
5
6
7
8
9
bool FileExists(const char* fname)
{
   if( pkg_zip != NULL )
   {
      int result = zip_name_locate( pkg_zip, fname, 0);
      return result != -1;
   }
   return false;
}

And open any of the files included in your apk package:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
FILE *FileOpen( const char* fname )
{
   zip_file *zfile = zip_fopen( pkg_zip, fname, 0 );
   uint32_t offset = 0;
   uint32_t length = 0;

   if( zfile != NULL )
   {
      offset = zfile->fpos;
      length = zfile->bytes_left;
      zip_fclose( zfile );
      zfile = NULL;
   } else
   {
      return NULL;
   }

   FILE *fp = NULL;
   fp = fopen( packageName, "rb" );
   fseek( fp, offset, SEEK_SET );
   return fp;
}

Using this method you will have a FILE pointer to the whole apk file so you have to take care of the offset and length field when reading and seeking the file itself.

  • sha

    Wow, I was just looking for this kind of thing yesterday for a dictionary app, thank you !!

  • Pingback: Tweets that mention Reading resource files from native code -- Topsy.com

  • Ascension Systems

    DUDE……. thank you so much. EVERY other solution I could find was so frickin over complicated it’s sickening. It’s not that I couldn’t figure out how to implement what they suggested, it’s that it was making me ill how much work it required just to get a file open. I found another solution about loading assets but it required building 2 or 3 libraries, one library that they don’t mention requires another library, then I had to use libpng and all this trash. I already have my own png decoder so.. yeah. This is fantastic, thank you.

  • Gskwon

    This is really excellent solution!! Thank you very much

  • Prouser64

    ‘struct zip_file’ has no member named ‘fpos’
    ‘struct zip_file’ has no member named ‘bytes_left’

    tried to use the latest version of libzip =(

  • Prouser64

    but it works fine with libzip 0.9.3