Work history [continued] Android OBB

The first two articles are here:

Use native IO on Android

Recent working Problem notes

The recent problem is that

Java.io.IOException:FAT full

Results of StackOverflow:

Http://stackoverflow.com/questions/18906055/what-causes-jobb-tool-to-throw-fat-full-ioexception

The questioner himself explained the reason because Obb more than 512M went wrong. But FAT16 can support 2G, this is the Jobb bug.

The author also provides the code and bin for the Jobb repair:

Https://github.com/monkey0506/jobbifier/tree/master/jObbifier/bin (because do not understand java/eclipse, took a little time to compile packaging out)

Finally, the question of MOUNT has been error (aobb_state_error_internal, Aobb_state_error_could_not_mount) under native
Logcat does not have any output, and there is no workaround on the web to solve the problems I have encountered here.

Finally, instead of the Java side mount, there is no wrong success ... It means nothing. What's wrong with the NDK team? Why mounting obb in native fails and in Java end succeeds?

Also, you can find questions about native API code in the Web Astoragemanager::getmountedobbpath

Https://github.com/android/platform_frameworks_base/blob/master/native/android/storage_manager.cpp

155     Const Char* Getmountedobbpath (Const Char*filename) {156 String16 filename16 (filename);157 String16 path16;158         if(mmountservice->Getmountedobbpath (Filename16, PATH16)) {159             returnString8 (PATH16).string(); //WTF? Return a Temp object ' s buffer?  the}Else {161             returnNULL;162         }163}

Since I did not see the implementation of STRING8, but on the surface, the return of a local temp object buffer, should be problematic, unless the buffer is malloc, but it seems that the document does not say to free or the like ( Or it can be inside the Mountservice). In fact, I also encountered the return garbled situation.

This question has been raised for a long time, but no one has ever changed it.

Although the OBB mount is asynchronous, the Java callback is synchronous and the callback is called only after the message loop has been started. And native's callback is determined to be called in another thread, is it not possible to wait until the message loop begins? Even so, the pit should be clear in the documentation, or give a native sample. Now only Java's OBB sample.

Feel native API on the OBB support there are a lot of pits have not been found. This part of the decision to use Java first.