Hi Tom, This is a great point, random access to resources is something we really wanted to get in for 1.0 but didn't have time. This is complicated because the standard Java classes are not conducive to this -- as you've seen, it seems to require using the internal implementation of the standard Java library. This is not something we have done anywhere else in the android frameworks as far as I know. :}
Personally I think the best approach may be to just copy the useful code out of harmony and make our own RandomAccessFileDescriptor or whatever class. This class needs to not only operate on a generic FileDescriptor, but also move and adjust access to a given range of bytes within that fd. One final thing, please note that files in a .apk usually -are- compressed. Certain file extensions will not be stored compressed by aapt when it is known that the file format itself is already compressed (such as .mp3 or .png), but otherwise they are compressed. This means that you can't use openAssetFd() to retrieve them. There is an option to aapt to give it additional file extensions to not compress... but you do need to be aware of trade-off here: generally people want this direct access because they have a large file, and a file that is going to be accessed like this will also compress quite well. So if you store it uncompressed you are probably going to explode the size of your .apk. Now if all you were going to do was copy that file into /data and access it there, having it uncompressed is the .apk and directly accessing it is a win. Anyway, I would certainly be interested in a patch adding this feature. On Thu, Dec 11, 2008 at 4:11 PM, tomgibara <[email protected]> wrote: > > There doesn't appear to be a way of obtaining the equivalent of > RandomAccessFile to assets (please correct me if I've missed something > obvious here). In my case I've got a simple trie implementation that > needs to seek over a binary representation which I'm bundling as an > asset in my apk. It's actually small enough to slurp into memory, but > I don't want to assume that's the case, so the way I'm doing it at > present is copying the asset into my app's data folder. But we can > guess how this extravagant use of storage space will be received by > users (see posts passim). > > Scanning the harmony and framework source code, it doesn't look like > it would be too difficult to produce a class which looked something > like: > > class AssetRandomAccess implements DataInput, Closeable { > ... > } > > which wraps a ParcelFileDescriptor obtained from > AssetManager.openAssetFd() and palms it off it to the platform's > IFileSystem implementation to do the actual shuttling of bytes. (can > code in the framework directly call the internal harmony classes?) > > If I understand things correctly, the assets are stored in the apk > uncompressed, so its just a case of adjusting reads based on their > offset. > > It would certainly be helpful to my application but is this something > worth adding to the framework? > > Tom. > > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
