質問

We have a cross platform mobile app that uses a native C library to read some data (among other things). On Android the data is in a obb file that we get using the Expansion APK mechanism. This has been working very well for us. However, we've found that on the 2nd generation (2013) Nexus 7 table and on Nexus 5 phones, we are reading some data from the obb that is corrupted. The actual obb file is not corrupted, but what we read from it is.

The best example I have is with WebView reading an HTML file from the mounted obb. The first part of the HTML will be fine and then there is gibberish in the second part. Interestingly, the gibberish is recognizable as binary data from elsewhere in the obb. It is almost like the Android code that reads the obb is getting the block mapping wrong.

I've narrowed it down to being triggered by some C code that reads objects out of the obb. If I comment this out, the HTML will be fine when I later access it. Now it is possible there are bugs in the C code, but this library has been used on two other platforms without issues. It also works just fine on a first generation Nexus 7 and on other non-Nexus devices.

So does anyone have any thoughts about what this could be? It seems to happen with both Android 4.3.x and Android 4.4.x on these Nexus devices. What could be different hardware-wise that could cause this corruption? I assume things like the C library come with Android and aren't built into the firmware somehow?

役に立ちましたか?

解決

I had the exact same problem, randomly corrupted assets when reading from the OBB in a native C library using stdio functions. Segments of 128 bytes were consistently corrupted in the mounted OBB. Any changes in the data would shift the byte segment, resulting in a different asset being corrupted. This was only a problem for phones running O/S v.4.4.x(KitKat) and v.5.x.x(Lollipop), phones running 6.x.x(Marshmallow) and later are unaffected as far as I know.

To circumvent this, rather than mounting the .obb, I ended up using the alternate .zip method as outlined here: https://developer.android.com/google/play/expansion-files.html.

I simply packed the data into a .zip with 0 compression(store), renamed to .obb, uploaded it to google play. When the user first starts the app, I extract the file to external storage using the APK Expansion Zip Library and then read the files directly rather than via mounting. This results in the app being twice the size on the phone, but it's preferable to being completely broken on some systems due to corrupted data.

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top