Access Android APK Asset data directly in c++ without Asset Manager and copying

Question

I'm using pure C++ in my engine to create a game engine in android. There is no single java file. Basically it is a game which should only be stored to external memory. When I move my asset data manually via adb to my external sd card the game works already fine and stable.

adb push ..\..\Bin\Data /sdcard/Android/data/com.fantasyhaze.%SMALL_PACKAGE_NAME%/files/Data/

This is not a good solution because it can not be delivered. Therefore I have my assets-data in Assets folder which gets moved into the apk file during building process with the following structure:

Assets/Data/MoreFolders/Withsubfolders Assets/Data/EngineData.zip Assets/Data/ScriptData.zip

But I don't know where those files are on the file systems to access them in c++ code.

So I tried to get the path to the file directories. And because of a bug in the native activity state I have to retrieve the information in normal code.

// bug in 2.3 internalDataPath / externalDataPath = null using jni code instead
//FHZ_PRINTF("INTERNAL inter PATH = %s\n", state->activity->internalDataPath);  
//FHZ_PRINTF("EXTERNAL inter PATH = %s\n", state->activity->externalDataPath);

c++ code for its equivalent to android.os.Environment.getFilesDir() and android.os.Environment.getExternalStorageState() ect

            // getPath() - java
        JNIEnv *jni_env = Core::HAZEOS::GetJNIEnv();
        jclass cls_Env = jni_env->FindClass("android/app/NativeActivity");
        jmethodID mid_getExtStorage = jni_env->GetMethodID(cls_Env, "getFilesDir","()Ljava/io/File;");
        jobject obj_File = jni_env->CallObjectMethod( gstate->activity->clazz, mid_getExtStorage);
        jclass cls_File = jni_env->FindClass("java/io/File");
        jmethodID mid_getPath = jni_env->GetMethodID(cls_File, "getPath","()Ljava/lang/String;");
        jstring obj_Path = (jstring) jni_env->CallObjectMethod(obj_File, mid_getPath);
        const char* path = jni_env->GetStringUTFChars(obj_Path, NULL);
        FHZ_PRINTF("INTERNAL PATH = %s\n", path);
        jni_env->ReleaseStringUTFChars(obj_Path, path);

        // getCacheDir() - java
        mid_getExtStorage = jni_env->GetMethodID( cls_Env,"getCacheDir", "()Ljava/io/File;");
        obj_File = jni_env->CallObjectMethod(gstate->activity->clazz, mid_getExtStorage, NULL);
        cls_File = jni_env->FindClass("java/io/File");
        mid_getPath = jni_env->GetMethodID(cls_File, "getAbsolutePath", "()Ljava/lang/String;");
        obj_Path = (jstring) jni_env->CallObjectMethod(obj_File, mid_getPath);
        path = jni_env->GetStringUTFChars(obj_Path, NULL);
        FHZ_PRINTF("CACHE DIR = %s\n", path); 
        jni_env->ReleaseStringUTFChars(obj_Path, path);

        // getExternalFilesDir() - java
        mid_getExtStorage = jni_env->GetMethodID( cls_Env,"getExternalFilesDir", "(Ljava/lang/String;)Ljava/io/File;");
        obj_File = jni_env->CallObjectMethod(gstate->activity->clazz, mid_getExtStorage, NULL);
        cls_File = jni_env->FindClass("java/io/File");
        mid_getPath = jni_env->GetMethodID(cls_File, "getPath", "()Ljava/lang/String;");
        obj_Path = (jstring) jni_env->CallObjectMethod(obj_File, mid_getPath);
        path = jni_env->GetStringUTFChars(obj_Path, NULL);
        FHZ_PRINTF("EXTERNAL PATH = %s\n", path);
        jni_env->ReleaseStringUTFChars(obj_Path, path);

        //getPackageCodePath() - java
        mid_getPath = jni_env->GetMethodID(cls_Env, "getPackageCodePath", "()Ljava/lang/String;"); 
        obj_File = jni_env->CallObjectMethod(gstate->activity->clazz, mid_getPath); 
        obj_Path = (jstring) jni_env->CallObjectMethod(obj_File, mid_getPath);
        path = jni_env->GetStringUTFChars(obj_Path, NULL);
        FHZ_PRINTF("Looked up package code path = %s\n", path);

which works quite well and results in

INTERNAL PATH = /data/data/com.fantasyhaze.rememory/files

CACHE DIR = /data/data/com.fantasyhaze.rememory/cache

EXTERNAL PATH = /mnt/sdcard/Android/data/com.fantasyhaze.rememory/files

Looked up package code path = /mnt/asec/com.fantasyhaze.rememory-2/pkg.apk

But there are no files from the assets folders...

and I need to access a folder as normal working directory to read the files. which would be possible in

/mnt/sdcard/Android/data/com.fantasyhaze.rememory/files/Data

But moving all data from the asset folder (wherever it is) via asset manager to this folder, causes doubled consumption of memory.

assets >1GB would mean assets >2GB which doesn't make sense. More than that the assert folder seems not to work recusively and only for small data files which is not possible when using bigger pak files. Maybe the files can be access directly from the apk when using the unzip system and then uzip my ressource files, but therefore I have to optain the apk path anyway.

So My questions:

1. Where is the Assets folder in the apk on the file system?
2. What would be the code (c++) to retrieve the apk location or the location of the executable
3. Can I access it directly with a normal file open method or only if I unpack it. If I can use it without unpacking, how?
4. What would be the code (c++) to retrieve the information if the sd card is mounted?

I hope someone can help me :)

Edit: Added cache directory and the package directory code (and it's output paths) , to provide the source for everyone else who needs it.

Jakie

Getting assets from the NDK side is tricky and unreliable due to a bug in certain versions of the native implementation of Android. Let me find that nfo and get back to you. – Collaboration

If you're not bent on using a NativeActivity, you can use this method (just for future reference) for finding the APK and loading assets. androgeek.info/?p=275 – Collaboration

Hi , I am trying to use this code in this question. I need to get "getPackageCodePath" path for .apk file and Internal directory path. but it is keep throwing me error of can't call . anyone can help me ?? thanks in advance. in MainActivity I have : public native int test(); and load library . in C code I am calling JNI method and same given "package code path " for .apk : – Burst

error I am getting is: JNI DETECTED ERROR IN APPLICATION: can't call java.lang.String android.content.ContextWrapper.getPackageCodePath() on instance of java.lang.Class<packagename.MainActivity> in call to CallObjectMethod – Burst

Answer 1

I'm posting an answer instead of marking this as a duplicate because technically, you're asking for more details than are provided in the question/answer I'm going to link here. So, to answer the first of your 4 points, see Obtaining the name of an Android APK using C++ and the NativeActivity class.

As for checking to see if the SD card is mounted, that should be rather simply. Simply attempt to open the directory or a file on the SDcard (that you know should be there) and if it fails, you know the SD card is not available. See What's the best way to check if a file exists in C? (cross platform).

Collaboration

Thx for the information, seached so long for it but could not find this post in link 2! With the information there I finally could retrieve the location of the apk :) Added the code in the first post to provide it in a different form than the one from the link. The check for files is ok, but I thought there might be some method to check if the sd card is mounted in c code similar to: android.os.Environment.getExternalStorageState().equals(android.os.Environment.MEDIA_MOUNTED); as seen in link – Jakie

Answer 2

You may want to have a look at "Expansion Files" see APK Expansion Files.

As far is i understand this, this gives you a system that automatically puts resource files (your expansion file) on the "shared storage location".

So i think that this would solve your problem of duplicated data.

There is also a short introduction post on the android-developers blog.

Foraminifer

I did not know that there is a limitation of 50MBs !!! on apk file size? That's horrible and those Expansion Files could solve the problem, but again is there any source for using the AStorageManager in C/C++ to gain access to the odb files? Seems to be a lot of work reimplementing the downloader stuff in native c :/ – Jakie