Work records-OBB Solutions

Previous content about OBB:

Use native Io on Android

Notes about recent work problems

Work History [continued] Android OBB

 

Since I used Java to mount OBB, I have never encountered any mounting problems.

But recently, we tested on LG nexus5 and LG G2 and found that a file of about 30 k is read at one time, and an error will be reported during processing.

Finally, various factors are excluded. For example, in order to eliminate the buffer corruption factor, a new buffer is added separately during read, read at one time, and then dump to the SD card. comparing the dump files, we found that the entire file contains n Bytes (about 32-64, no number), which is different from the original file.

The test case is used to test the file separately. the problem is complicated. N files have been read consecutively, but error 100% is reproduced in this file. this problem does not occur on other platforms. it is disgusting. some people in stackoverflow encountered similar problems, but they did not solve them.

Finally, I decided to use the format defined by the company to solve the problem.

 

The Blade Engine you wrote in your spare time already uses the custom BPK format. due to many factors in the work, the custom method has not been used. now, the format defined by the company is more controllable and can be fixed if the problem persists. so far, we will summarize the best way to use OBB in native.

Use jobb that comes with the android SDK (optional SDK preset format ):

Packaging restrictions: fat16 is used. There are many restrictions, such as 512 entries in the root directory, MB limit for a single file, and 2 GB limit for the entire package. the bug of jobb causes the entire package to not exceed 512 MB, but the fixing code can be found online.
Runtime problem. When the native end fails to mount, it is solved after using Java, and then the recent bad data problem of reading files.

In general, you may not encounter so many restrictions or problems when using lightweight games. However, we do not recommend that you use the built-in system format. because of the openness of Android, every hardware vendor can customize the code. Maybe Google's original system has bugs and other vendors have fixed them. there may be no bugs, and new bugs are generated during vendor development. This has encountered similar problems in OpenGL ES 2.0, and various bugs of various devices emerge one after another.

 

1. For accumulated companies, you can try to port the original file package system. If the existing system is relatively stable, the cost of transplantation will be very low.

2. if a startup company does not have a stable file package system, but does not have the time and energy to write it on its own, you can select the ZIP format, which is simple and convenient to pack, with few bugs, runtime has more than N types of libraries and is mostly open-source, which is relatively stable. this is also a fast implementation method. the disadvantage is that the resources are easily cracked. Even if the encryption is simple, the attacks are relatively good.

3. If you do not have a ready-made file system package and have enough time and energy, you can rewrite it on your own.

The biggest advantage of doing so is that it is more controllable and won't be pitted by the system's API, and various inexplicable bugs cannot be solved. even if there is a problem with your own implementation, the code can be quickly fixed after debugging, and the code will become more and more stable.