Android does an ugly copy of all assets

[est31]

Currently, the Android copies all assets to the storage so that it is "inside" a directory. This however is totally ugly, as now there are two copies of the same files, using up highly constrained memory. Combined with bug #3464, the asset is stored three times on the disk! Also, it creates an overhead when starting the app, because the stuff has to get copied every time. And, it is bad when multiple forks of minetest are installed on the same device: they overwrite each other, and cause conflicts.

This bug is related to #2097.

I see two ways to fix this bug:

1. Use obb files. Once downloaded, they are very convenient to use as one can simply mount them to a point. No further changes required, except setting path_share accordingly. The problem with them is that f-droid doesn't support them right now, so we would have to host them ourselves, or convince/help f-droid to support them. Additional issue is that I can't test a potential play store downloader on my own as I lack the required developer access to the play store. It would be great if @nerzhul or @MoNTE48 could help out on this.
   One would also have to think something to get it work for development builds, perhaps there we can ship the obb with the apks assets and copy it to the place on startup (I know, irony xD, but this is only for development so no big issue).
2. Use the AAssetManager_* functions from android/asset_manager.h. Very tedious to implement, as for implementing it we have to replace the current direct way of loading stuff with our functions. A short cut would be to use hacks like this.

[MoNTE48]

I keep these files files.zip on assets, and then simply unpack the archive. I'm using the version comparison through sharedpreferense. Unpacking takes a few seconds and happens only if you delete the destination folder, or a new version of apk. Can I license my code as a LGPLv2 and help you if nrz apologize to me.

[sapier]

Well this isn't really fixable for following reasons:

1. Irrlicht doesn't support android/asset_manager.h
2. Minetests architecture separates client from server almost completely if you wanna use shared resources you'd have to mess up the design

@1, feel free to implement it for irrlicht I'm quite sure those guys will accept your patch.
@2 I know this is very painfull on android but messing up the design is even worse.

Edit1:
I can't help if those minetests forks did do bad work and not fix their own paths! Blame them not minetest!
BTW files aren't copied on any start the only thing done is checking if all files are present! So the only thing left is cache wich isn't copied if it's present too.

[est31]

1. I think I have a way to make it work even with current irrlicht. Either by using createImageFromData and then using createDeviceDependentTexture or if that is not possible by implementing our own IArchiveLoader.
2. that's more about Client puts assets into cache even if assets are already present in the game directory #3464 so better discussed there.

[est31]

Okay, implemented a first prototype with the AAssetManager_* functions: https://github.com/est31/minetest/tree/asset_loader

It works: you can connect to singleplayer and network games. But it has one problem: it is very slow. Most likely that's because every single file is decompressed.

Now I even wonder whether we should perhaps even keep an asset copy. But still, the way we currently do it is very ugly. We should store the stuff into an app-local folder, and we should use a better algorithm for checking whether something changed. Currently we don't update if the file changed, so that people have to delete the folder, and we do check every file on start, even though it causes an observable overhead.

[MoNTE48]

I once again an excuse to see my code. He's very fast. Checks only version of the game. If the version apk changed, then it will be Unpacking again.

[sapier]

est31: I remember some thing about assets on android. For what I remember reading a file from it involves decompressing whole assets till that file is found. Maybe that's why it's so slow to you.

[est31]

My next try will be obb :)