前两篇在这里:
最近遇到的问题是,
java.io.IOException: FAT Full
StackOverflow的结果:
http://stackoverflow.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