From e3ab0fd9016bc24c5a0eb0807f171d5025c3bb79 Mon Sep 17 00:00:00 2001 From: Tor Lillqvist Date: Wed, 21 Dec 2011 13:51:50 +0200 Subject: osl_unmapFile can't work for files bundled inside the .apk on Android On Android, when an app is installed, arbitrary files bundled in the app won't be unpacked into actual separate files in the file system. They will exist only as archive entries in the .apk file (which is a zip archive). The SDK tooling puts such files under the /assets folder in the .apk. The LibreOffice bootstrapping code for Android maps the .apk file into memory. osl_openFile() knows about the /assets special case, and uses a separate abstraction for such memory-mapped files. Obviously, when producing an .apk, one needs to make sure these bundled files are not compressed, if one wants to be able to use them directly from the memory-mapped .apk file. We do that in our test and sample Android projects. When mapping such files under /assets , just return a pointer to the file's location inside the mapped .apk archive. We can't use the old osl_unmapFile() on such mapped files, as that would unexpectedly unmap fairly arbitrary pages of the .apk mapping, wreaking havoc on later use of the same pages. So, introduce a new osl_unmapMappedFile() function that takes also the oslFileHandle originally passed to osl_mapFile(). Use this instead in the few places where the code actually called osl_unmapFile(). Make sure osl_mapFile() is nonexistent on Android. --- sal/util/sal.map | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'sal/util') diff --git a/sal/util/sal.map b/sal/util/sal.map index 7ccc24ca631b..e8a9ab520477 100644 --- a/sal/util/sal.map +++ b/sal/util/sal.map @@ -610,6 +610,11 @@ LIBO_UDK_3.5 { # symbols available in >= LibO 3.5 rtl_uStringbuffer_remove; } UDK_3.10; +LIBO_UDK_3.6 { # symbols available in >= LibO 3.6 + global: + osl_unmapMappedFile; +} UDK_3.10; + PRIVATE_1.0 { global: osl_detail_ObjectRegistry_storeAddresses; -- cgit