前两篇在这里:

Android上使用native IO

最近工作中的问题笔记

最近遇到的问题是,

java.io.IOException: FAT Full

*的结果:

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

提问者自己解释了原因, 原因是obb超过512M就出错了. 但是FAT16最大可以支持2G, 这个是jobb的bug.

同时作者提供了jobb修复的代码和bin:

https://github.com/monkey0506/jobbifier/tree/master/jObbifier/bin (由于不懂Java/eclipse,花了点时间才编译打包出来)

最后关于在native下 mount一直报错的问题(AOBB_STATE_ERROR_INTERNAL, AOBB_STATE_ERROR_COULD_NOT_MOUNT)
logcat没有任何输出, 同时网上也没有任何解决方法可以解决我这里遇到的问题.

最后改用在java端mount, 竟然毫无错误的成功了...表示很无语. What‘s wrong with the NDK team? why mounting obb in native fails but in Java end succeeds?

另外, 网上可以找到关于native API code里的问题 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             return String8(path16).string(); //WTF? return a temp object‘s buffer?
160         } else {
161             return NULL;
162         }
163     }

由于没有看String8的实现, 但是单从表面上看, 返回一个local temp object的buffer, 应该是有问题的, 除非buffer是malloc的,但貌似文档又没有说要free之类的(或者是mountService内部的也可以). 而实际中我也遇到返回乱码的情况.

这个问题有人提出很久了, 但是一直没有人去改..

虽然obb的mount都是异步的, 但java的回调是同步的, 而且回调只有在开始了消息循环以后才会被调用. 而native的callback确定是在另外一个线程调用的,难道也要等到消息循环开始以后才可以? 即便是这样, 这种坑也应该在文档里面说清楚,或者给个native sample吧..现在只有java的obb sample.

感觉native API上对obb的支持有很多坑还没有发现. 这部分决定先用java了.

工作记录[续] android OBB,布布扣,bubuko.com

工作记录[续] android OBB