writing/saving files from native code only

[celavek]

I'm trying to build an Android app which makes use of the NativeActivity facility of the NDK.
I'm having the following structure:

- a bunch of native shared libraries installed in "/system/vendor/<company>"; I'm working
with a custom built Android image so there's no problem having the libraries there with
proper permissions and everything
- a couple of applications using the NativeActivity that depend in turn on the libraries
mentioned above

The libraries installed in the /system/vendor and my applications use a couple of
configuration files. There's no problem reading them using the standard C API
fopen/fclose. But those libraries and my application also need to store some files
as the result of their operation, like configuration, some runtime parameters, calibration
data, log files etc. With the storing of the files there is a slight issue as I'm not allowed
to write into "/system/vendor/..." (as the file system under "/system/..." is mounted
read-only and I do not want to hack on that).
 
So what would be the best way to create and store those files and where would be the
best "conforming with Android" storage area ?
I've been reading a couple of threads in this group and on stack overflow that mention
either the internal application private storage or the external SD card, but as I do not have
extended experience with Android I'm not sure what would be the proper approach(a small
code example in C++ would be very helpful).
Also there seems to be a problem with using from C++ the native activity's
internalDataPath/externalDataPath pair(a bug that makes them be always NULL).

Thanks

[Chris Stratton]

On Jul 2, 8:39 am, celavek <cetatzea...@gmail.com> wrote:
> So what would be the best way to create and store those files and where
> would be the
> best "conforming with Android" storage area ?

Since you are talking about small files, probably the internal storage
area associated with the apk in which you are running code.

> Also there seems to be a problem with using from C++ the native activity's
> internalDataPath/externalDataPath pair(a bug that makes them be always
> NULL).

You could call the java getFilesDir() API via jni - realize that even
a native activity still has a dvm in the process to handle interface
with the rest of android.

I have not tested it, but there appears to be an example in this
stackoverflow post:
http://stackoverflow.com/questions/10166638/access-android-apk-asset-data-directly-in-c-without-asset-manager-and-copying

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);
/* do something with the string, then */
jni_env->ReleaseStringUTFChars(obj_Path, path);

[celavek]

On Monday, July 2, 2012 4:54:34 PM UTC+2, Chris Stratton wrote:

You could call the java getFilesDir() API via jni - realize that even
a native activity still has a dvm in the process to handle interface
with the rest of android.

I would rather stay away from JNI. That's because I would have to "taint"
the code in the shared libraries with Android/Java specific stuff. But it might be
an option if there's no other way.

I have not tested it, but there appears to be an example in this
stackoverflow post:
http://stackoverflow.com/questions/10166638/access-android-apk-asset-data-directly-in-c-without-asset-manager-and-copying

Thanks for the link. Will give it a look. But still I would prefer to use only the
 C libraries or any other Android C specific API regarding internal storage access
(if there is one).
 

[Chris Stratton]

On Jul 2, 11:51 am, celavek <cetatzea...@gmail.com> wrote:
> On Monday, July 2, 2012 4:54:34 PM UTC+2, Chris Stratton wrote:
>
> > You could call the java getFilesDir() API via jni - realize that even
> > a native activity still has a dvm in the process to handle interface
> > with the rest of android.
>
> I would rather stay away from JNI. That's because I would have to "taint"
> the code in the shared libraries with Android/Java specific stuff. But it
> might be
> an option if there's no other way.

Regardless of what method you choose, you really only have two
choices:

- use something external to the library to handle the system-specific
parts - for example, call into the library providing the path name as
an argument, or provide a function in another device-specific library
which can be called to obtain it

- "taint" the library with platform specific code

Also bear in mind that you will have to keep android process lifetime
and re-use issues in mind throughout the library.

[celavek]

I implemented something using the app's internal data storage,
that is /data/data/<package>/files. I'm using only native code and
no JNI getting the path to the internal data storage through
ANativeActivity::internalDataPath and dealing with my files with
the C based API fopen/fclose.

Thanks for the hints.